Skip to main content

Introduction

Smart contracts are powerful but generally isolated to the blockchain ecosystem on which they reside. Things like oracles and bridges help but must be set up on a case-by-case basis.

What if a smart contract could have it's own public and private keypair, just like any other wallet? And what if that smart contract had the ability to make arbitrary HTTP requests and use the data in it's computation? Imagine smart contracts that can read and write from any HTTP endpoint, blockchain, state machine, or decentralized storage system.

We're building this at Lit: The smart contracts are Lit Actions and the key pairs they can use are PKPs.

Programmable Key Pairs (PKPs)

PKPs are public/private key pairs generated by the Lit network in a process called Distributed Key Generation. Each node custodies a share of the underlying private key, meaning the key never exists in its entirety. Currently, users can mint a PKP in the form of an ERC-721 NFT. The owner of the NFT becomes the sole controller of the underlying private key, their wallet signature becoming the method of authorization for the Lit nodes.

We are in the process of adding support for additional auth methods, such as Google login, Discord, and Apple Passkey. This will allow users to login to the decentralized Web with the click of a button, helping facilitate more seamless onboarding experiences for non crypto natives by abstracting away the complexities present in the current UX surrounding web3 wallets. You can learn more about these updates here.

Continue reading about PKPs here.

Lit Actions

Lit Actions are immutable JavaScript programs stored on IPFS. They can be thought of as our native implementation of smart contracts, only much more powerful. They are the permissionless rules that govern Lit’s signing automation.

Lit Actions are blockchain agnostic, giving them the inherent capacity to communicate data across blockchains. This enables interoperability between previously disconnected ecosystems.

They can also use off-chain data sources in their computation by making arbitrary HTTP requests. For example, calling an off-chain price feed (via API) for potential oracle or conditional signing use cases.

Get started with Lit Actions here.

How do Lit Actions and PKPs work together?

A user can mint a new PKP and grant a Lit Action the right to sign using it, giving it the ability to sign and decrypt arbitrary data based on pre-defined conditions.

Why is any of this useful?

Because Lit Actions + PKPs + web3 storage can be a replacement for a traditional web2 backend. Imagine a web3 Twitter clone that stores the data on Ceramic. You could create a PKP that owns a Ceramic stream, and then grant access to sign with that PKP to a group of Lit Actions for things like createPost() and likePost(). Your Lit Actions can work just like a web2 backend, with business logic to ensure that only correct data is written to your Ceramic Stream. For example, the likePost() function could check that a user has not already liked a post, and only write the like to the stream if they have not already liked it.

In web2, your backend has "god mode" access to the database. Using Lit and web3 storage like Ceramic, you can create Lit Actions that have "god mode" over a Ceramic stream, because the Lit Action has been granted the ability to sign with a PKP that owns the Ceramic stream. However, the Lit Action will only write to the stream according to the logic of the code inside it. This makes moving from a centralized web2 paradigm to a decentralized web3 paradigm much easier.

How does network consensus work?

As mentioned above, each node only holds a share of the underlying key pair. These shares must be combined above the threshold to form the complete signature or decryption key. This threshold is set to two thirds of the network, meaning any signature or decryption key generated by Lit must have been approved by at least two-thirds of the nodes.

Lit Protocol doesn't have a traditional consensus mechanism like most blockchains do. This two-thirds threshold is mathematically enforced by the threshold cryptography algorithms Lit uses.

State of the network today - Serrano Testnet

The Lit Actions and PKP network is in a testnet state. In this state, we have only implemented the ability to generate a new PKP for ECDSA signatures. A single BLS PKP is shared by all Serrano Testnet users. The data on the Serrano Testnet is not persistent and may be erased at any time. Therefore, we do not recommend storing anything of value on the Serrano Testnet.

How can I know that a given PKP wasn't used to sign a bunch of stuff before it was granted approval to use a Lit Action? What is Mint/Grant/Burn?

Suppose you have a Lit Action that will check if a number is prime, and if it is, sign that number. If it is not prime, the Lit Action will abort. If you were able to mint a PKP, assign it to that Lit Action, and then burn the PKP in a single atomic transaction, then it would be provable that the PKP was not used to sign anything before it was approved to use the Lit Action. You could then trust that any numbers signed with that PKP are indeed prime, without needing to check them yourself. This creates a powerful way to prove the output of any JS code by checking that 1) the signature is valid, 2) the lit action code is correct, and 3) that the PKP was minted using this Mint/Grant/Burn pattern.

We provide functions to do this called Mint/Grant/Burn. You mint the PKP, grant access for a Lit Action to use it, and then burn the PKP in a single transaction. Burning the PKP destroys the ability to grant access for a Lit Action to use it, so you know that no other Lit Action can ever use that PKP. You can see the definition of a MintGrantBurn fuction in the contract source code here: https://github.com/LIT-Protocol/LitNodeContracts/blob/main/contracts/PKPNFT.sol#L157