Decentralized Programmable Key Pairs | Devcon Bogotá

foreign [Music] my name is David Snyder that's Chris casano and as you can see we're going to talk about decentralized programmable key pairs we are the two co-founders of a project called lit protocol and to start with a big exciting hook we are living in a world where with threshold cryptography from a certain point of view you can consider that private Keys no longer exist so what do we specifically mean by this this netlit network is essentially a distributed custody programmable key and one of the key Technologies at the heart of this is something called a dkg a distributed key generation and so what lit is specifically is a distributed network of nodes that are custodying shares of an underlying private key I'll take a quick moment to talk about how security works on this network and then we'll get into some of the use cases but essentially this key is formed in this distributed key generation context and stored as shares across the these nodes and then all the nodes operations take place inside of a trusted execution environment and then there are named node operators who are staking that are running the programs on this underlying key and so now let's talk about what some of those programs can be so as you know a key can functionally do two things it can read or encrypt and write and this network provides the same functionality in a programmatic way so let's talk about how the read works first the hexagons in the middle represent the lit nodes in this case Alice let's say is a Creator and wants to say anybody who owns Alice's nft can see her video she would encrypt that video client side and store it somewhere in public whether it's on a blockchain or a storage Network like ipfs and then create a set of rules that says only somebody who owns Alice's nft can see that video Bob owns that nft he shows up later he signs a message and he broadcasts that to the nodes each of the individual nodes validates against the blockchain does Bob own that nft and the whole kind of frame of view here is thinking about these Public Storage uh excuse me public State machines as Access Control lists at which point the nodes verify that Bob has that node or excuse me has that nft and each of the individual nodes produces something called a decryption share you could think about this like an authorization those authorizations are then sent to Bob who's collecting them client-side and a good mental model is kind of similar to the way that you may think about torrenting you know torrenting you're collecting little bits of media from a bunch of nodes in this case you're collecting bits of authorization and once you've collected a threshold of those authorizations in this case decryption shares Bob can reproduce that symmetric key associated with the video or that content and decrypt that client side and so some of the applications that we're seeing this used for today a are things like token gated social media like tokengated chat this technology is used hand in hand a lot with like the lens protocol for example where only let somebody who's following me on on lens see my posts we also see this in uh happening in the context of intellectual property whether it's token gated videos or various other content and then really excitingly there's also been a lot of stuff around verifiable credentials and selective disclosure so I'm sure you all are familiar with the notion of like signing in with Google as an authorization method for how one logs into a site what we're starting to see is some teams build this out in a much more kind of user Sovereign type of way whereby when a user goes logs into a site they're conveying decryption rights or quote the read writes to that application to see their private information and starts to become like a pretty interesting picture and we'll talk more about what this this user-owned web looks like but in a way this is kind of one definition of web3 where the user rather than necessarily showing up to a website with their own kind of self-sovereign server they're arriving with their own encrypted Shard of the open web and then selectively disclosing two various friends or applications what information from that Shard they can decrypt or read and so this product has been out since January we still are running all the nodes centrally and we'll have those decentralized by the end of the year and there's hundreds of applications that are leveraging this but just last week we started um talking publicly about a new capacity which is the ability to essentially do distributed custody programmatic signing and as you can see the architecture is incredibly similar but instead of the nodes reading the blockchain as an access control list they are reading programs that are stored at a specific CID on ipfs each of those nodes is running those programs and now in this case instead of producing the decryption share which lets that party decrypt some content they're producing a signature share again coming back to the idea that keys can functionally do two things kind of encryption and signing and then those shares can be aggregated and you can make a right to your favorite decentralized state machine like ethereum and so talking about some of the applications for this there's a huge list right thinking about the a key as an application development platform we kind of like think about it as a paintbrush we're really just starting to explore some of the application potential here but I'll run through a couple right now so one would be like defy automation the state of the art for self-custody defy today is if you have some staked tokens and you have to the state of the artist to sign up for some defy alerting Service Such that when the price starts to drop you get a text you have to wake up in the middle of the night and push a button on your Ledger but in a world where you've staked those tokens from one of these Cloud wallets as we can kind of call them you could have that program listening to a feed and when the price drops have a program that kicks off that unstakes the tokens sells them for usdc on a decks and sends them to your Ledger and this is all happening kind of without a human signer in the loop because the key is custody in this distributed context at the network level Chris will talk a little bit more about vaults but in a way what we're talking about here is making private Keys liquid so you could send a bunch of nfts and tokens to a given address and then trade the underlying ownership of that address there's also a lot to explore here as it relates to account abstraction doing things like cooking up a biometric auth like apple Pass key as the auth method into one of these Cloud keys in this whole context of how do we bring the next billion users into this ecosystem and Abstract away the complexity associated with the seed phrase this is really exciting and certainly a lot to explore in the context of cross-chain messaging and bridging as well and so with that I'll pass this clicker off to Chris thank you David uh yeah so I'd like to introduce the idea of a decentralized programmable key pair which we call pkps a pkp is an ecdsa key pair that's held as private key shares custody by the lit nodes you can create a pkp by minting an nft that represents ownership over that pkp and so whoever owns that nft can ask the pkp to sign anything on their behalf including ethereum or even Bitcoin transactions you can do this by writing some JavaScript code that we call a lit action so this is a really basic hello world uh lit action it literally signs the string hello world uh with ecdsa and what happens is this code will be run on all the lit nodes in parallel lit actions live on itfs and are immutable just like smart contracts and I just explained that whoever owns the pkp nft can request a signature using the pkp but what's actually more interesting is that you can also Grant the ability to sign using your pkp to a lit action this is very similar to the Token approval pattern that we use on ethereum where you can grant a smart contract the ability to transfer your tokens but instead of granting the ability to transfer tokens you're granting the ability to sign anything with this programmable key pair so here's how it actually works the user can create a lit action execution request which you can see at the top there to add a laser cool and they pass in an itfs CID which is some JavaScript code and a cryptographic signature that could come from their ethereum wallet and apple Pass key or any public key cryptography scheme they send that execution request to all of the lit nodes in parallel the lit nodes use a JavaScript runtime to execute the lit action from ipfs they check the pkp authentication by talking to a blockchain where the pkp nft lives and the lit action can also make arbitrary HTTP requests so it can also act as a kind of Oracle um it can also act as a kind of Oracle um so you can pull any data in and use it in your JavaScript lit action the lit action can request a signature using the threshold private key share that creates a signature share that gets sent down to the user that initiated the request they could be using a browser or this could be like a server-side client they combine those signature shares and they broadcast that signed transaction to ethereum or any ecdsa blockchain and I'm talking about a transaction here but it doesn't actually have to be a transaction it could be any signed data like a right on a ceramic or anything else like that an interesting pattern that Lit supports is called mint Grant burn the idea is that you mint a pkp grant it the ability to use a lit action then burn the pkp in a single Atomic transaction this means that the pkp can only ever be used by that Lit action because burning the pkp makes it impossible to use the pkp for signing anything else a kind of fun toy example would be creating a lit action that takes any number as input but will only sign that number if it's Prime since anyone can check that the signature matches the public key of the pkp they know that any number signed by the corresponding private key must be Prime and the signature acts like a proof that the number is prime you end up with a kind of prime number certification system this can be used to create a proof of any JavaScript code execution and this is kind of similar to how ZK proofs work conceptually but instead of being proven by pure math it's proven by the guarantees provided by threshold threshold cryptography via the lit Network and here's kind of how that works the um the way that you interact with and Grant access to use things is by talking to a pkp Smart contract that currently lives on cello but we're going to move that to polygon soon and you mint the pkp grant access for it to use the lid action in this authorized lid action table and then you burn it all in one transaction uh we talked a little bit about using a pkp as a vault you can mint a pkp then send a bunch of assets to it like nfts tokens ethereum and even ones not on ethereum like Bitcoin or Cosmos tokens then you can sell the pkp nft on openc and transfer all the assets at once you are essentially trustlessly trading a private key something that has been impossible until now this breaks Soul bound tokens because now you can trustlessly sell the wallet that contains your soul bound tokens in the same way that you could sell a traditional non-sol bound erc721 nft this also enables things like liquid staking for chains that lock up the staked tokens like ethereum 2. you could use a pkp as an eoa Cloud wallet because a pkp can grant the ability to sign to a lit action you can create any auth method that you want as long as it's possible to express it in JavaScript you could create a wallet that will only sign if the user calling the lit action is a member of a dow you could use another signature algorithm for verification that's unsupported by ethereum like ed25519 or BLS you could even create a wallet that will only sign transactions on Tuesdays you can use a pkp for automation because the lit nodes do the actual signing you could create a lit action that checks the price of a token you're staking and if it drops below a certain price unstake the token and sell it this works across chains and could run while you're asleep you can make any sort of complicated automated trading bot without needing to have a hot wallet sitting on a server somewhere that will get hacked when you forget to update your Linux distribution and here are some ideas of a lot of different things that you can build I won't read them all but yeah you can check them out we could talk about uh some of these ideas I think is is worth pointing to but maybe just uh um a few more metaphors like one of the ways that I really like thinking about uh this programmable key pair notion what we've been calling a pkp in a way like the centralized equivalent is thinking about this like an Amazon Lambda function plus the Amazon KMS but in this case the KMS isn't something that's centralized it's uh distributed across this threshold cryptography based Network and these lit actions are the equivalent of the land Lambda functions and so it's this distributed system for doing the same type of operations that you would build with Lambda function and Amazon's KMS but in this case you as the application developer when you come and bring customers on board you have this kind of distributed back end where you can't get access to the keys where if you like build the defy automation bot and start selling to somebody as a subscription today you you could jump into Amazon's KMS and grab the keys and the funds out at any point a couple other interesting things that I think are really fun to think about when we start to think about the notion of kind of this Cloud key there's a lot of implications for this um as a Dows key so we could talk about Dows and D Phi and and use our own social media but in the context of a Dao the current state of the art for Dows is of course to use Smart contract wallets to manage their treasury but more and more especially protocol dials we're seeing things that want to extend across chain and cross ecosystem and so to start to think about the account abstraction not at the level of the blockchain but at the level of Designing algorithm and creating the rules and the governance around this at the level of the signing algorithm starts to get really interesting because you can have the same rules around governance issuing verifiable credentials for your Dao making transactions on eth doing right to rights to ceramic all from the same underlying curve um and then yeah I think another one that's kind of really uh interesting here is thinking about uh this in the context of mainstream adoption we touched on this a little um but you know there's always capacities to add different levels of authorization and security to wallets but we've been really really excited about groups that have started to integrate this with the likes of Discord and apple Pass Key and there's definitely a lot of opportunity to build really sophisticating Tooling in this ecosystem it's one of the reasons that we're really excited to give this talk like we have a core team that's super focused on this threshold cryptography component but there's all kinds of opportunities to like stick an email server inside of an enclave and use that as a methodology for authorizing this with email that's something that we're not going to build internally and so if that's if this kind of tooling and privacy tooling and mainstream adoption tooling is something that you're interested in definitely come talk to us us but yeah maybe we'll keep this slide up and uh we'll take questions for the next 10 minutes if there are any thanks so much [Applause] how do we establish the trust relationship between the clients and the the notes because like anyone kind of like snooping on that can essentially you know rebuild the uh rebuild the signing or the Christian key yeah I mean uh right now you pass a cryptographic signature with your request to the lit nodes so that could be a signed wallet message um like if you want to prove something about your wallet it could be any other cryptographic signature so it could be you know you need some encryption right because like you you need to keep this you don't need encryption just a signature and the nodes verify the signature and and by verifying the signature they can prove that you own that wallet yes but they're gonna send you in exchange like a key share right yeah yeah they they don't actually send a key share they send a decryption share or a signature share so the the key shares themselves never uh never leave the node got it okay I think that like I misunderstood this part and so the the second question that I have is essentially like can you do in for any form of resizing of you know this I wouldn't call it like a quorum but like you know just this uh this set oh like uh changing the set of nodes and changing the threshold for example exactly yeah absolutely yeah so we use a technology called proactive secret sharing um and what that uh lets us do is it lets the uh the nodes like new nodes join and leave the network um and keep the underlying secret the same but the private key Shares are incompatible uh between like epochs when it when nodes leave and when nodes join basically the this process of proactive secretaring is quite similar to the distributed key generation process um and you know the the secret uh is very very simply put right a line on a graph and in this key refresh process you're signing new points along the same underlying secret such that the shares in Epoch 2 are incompatible with Epoch one but they still represent the same underlying secret and that's functionally the goal of this network is to persist a shared Crypt photographic Secret in perpetuity okay I think that that ties into my third question which is how do you ensure kind of like the any form of like non-so like counters so that you know essentially like the number of time that this thing has been signed or like decrypted uh maybe you want to like ensure it that like you know you can decrypt it x amount of times you don't want to you know you you may want to like sequence essentially especially for vaults like operations right like the signing of like specific nonsense uh or like just ensuring that like you you don't have is essentially just like resigning operations with different announces either I'm actually curious how do you think about that yeah um so what you could do so the the lit nodes themselves are mostly stateless okay so they don't necessarily have a place to store anything like that um but what you can do in the lit actions is you can read and write from blockchains or from ipfs or wherever so um you could like at the end of a lit action after you create the signature share you could uh write to a chain to record that a transaction has already happened um and then if somebody tries to run that Lit action again it could you know check and see like you know did this transaction already happen or not and if so it wouldn't sign um and that that's like how it works within the lit system uh within like you know the if you're signing an ethereum transaction for example right you would just include the nonce in the thing to be signed um when you send up like whatever you want the lit action to be signed um and so then you couldn't reuse that signature right um because it has already been broadcast cast with that nonce maybe I missed how you explained how to create a pkp without any keys but how does that work and how does the user not have a key and how do they authenticate what things they want the network to do yeah I mean they need some kind of key um right it could be an ethereum wallet or it could be like apple passkey which is like one click and they generate a public private key pair for you that's backed up to your iCloud in an encrypted way it could also be like potentially a web 2 auth method like Discord login anything like that it just needs to be basically an authentication method that can be verified by the lit nodes every time someone creates a pkp do you generate a new threshold key and where is that key stored are you spinning up new Cloud nodes to store those keys so the lit nodes uh each node support like stores multiple key shares um so there's a million keys on the network and 100 nodes uh each of the nodes would store million key shares representing one share from each of the underlying Cloud wallets or Cloud keys and what kinds of thresholds are you guys using in production in test like like the number threshold like yeah we're using two-thirds right now and that's like hard-coded across the network so it's not user changeable um and uh yeah and we're using uh you know ecdsa non-interactive signing on the um the signing side and then on the encryption and decryption side we're using BLS keys super we have some more questions in the middle of our area still do you mind if I have one more question uh that's our fourth one right super uh what are your plans for decentralization and how do you plan to grow this network it sounds like it's a pretty fixed set and you do no rotations well so there's this notion of the proactive secret fairing um which is not I guess not quite a rotation because it's the same underlying secret um but yeah some of our Cutting Edge work is right at the notion of changing the threshold oh it's just people makes the network be able to become like more Dynamic over time but currently there is the capacity for new nodes to join the network and for the key to be refreshed creating those new shares in Epoch two three four and so on and then practically in terms of the plan um by the end of the year this network will be up with a handful of named node operators and then those node operators are functionally a Dao of sorts that decide who comes in and who comes out uh to the system thanks everybody Applause [Applause]