Web3 Galaxy Brain 🌌🧠

Nicholas: Welcome to Web3 Galaxy Brain. My name is Nicholas. Each week, I sit down with some of the brightest people building Web3 to talk about what they're working on right now. My guests today are David Sneider and Chris Cassano, co-founders of Lit Protocol. Lit is a distributed key management network. Lit leverages multi-party computation and threshold signature schemes, spreading private key shares across a network of Lit node operators so users can sign and encrypt data without any one machine ever holding the entire private key. On this episode, David and Chris explain how Lit was born from their understanding of crypto's pain points after many years in the industry. We dive into the Lit node software, distributed key generation and signing, Lit DAO governance, Lit's intersection with roll-ups and off-chain data, and much more. It was great getting to know more about Lit from David and Chris. I hope you enjoy the show. As always, this show is provided as entertainment and does not constitute legal, financial, or tax advice or any form of endorsement or suggestion. Crypto has risks, and you alone are responsible for doing your research, and making your own decisions. Chris, David, welcome to Web3 Galaxy Brain.

David Sneider: So delighted to be here. Thanks for having us, Nicholas.

Chris Cassano: Yeah, thanks for having us.

Nicholas: Absolutely, I'm excited. The first question is, you were just talking before, you guys are so funny. How did you two meet in the first place?

David Sneider: Yeah, so the answer to this has some good blockchain history. Chris and I both moved to the Bay Area to pursue startups in 2013. Chris, you mentioned what you were working on in that era?

Chris Cassano: Yeah, yeah. Early Bitcoin days, and it was hard to store your keys. So I made Piper Wallet, which was the first hardware wallet. It was a Raspberry Pi in a box. And with a printer, you press a button, and it actually prints a paper wallet for you. So I moved to San Francisco and was working on that when I met Dave.

David Sneider: Yeah, and I was working on something not crypto-related. And the place where we met is actually where the Bitcoin meetups used to take place in 2013. Yeah. 2014 and 15 in the Mission District. And it was this, yeah, really, really fascinating spot in the Mission. And what was so great about it, I think, is there was, in that early era, a real aggregation of crypto-minded individuals. People love to use the phrase magic internet money, things like that. And so it's been really cool over the past 10 years to kind of like, although the industry is still a community in many ways, really mature as an industry, but it was, I think it was crypto-y from the beginning, from when we first met, yeah.

Nicholas: That's awesome. And yeah, it sort of comes through your expertise, experience, and like long history with blockchain in the way Lit Protocol is positioned. I feel it's, there's a certain maturity to the way you're approaching it. Maybe, could you explain how you ended up coming up with the idea for Lit?

David Sneider: Yeah, absolutely. Maybe I can just define what we're up to. Yeah, please. And then talk a little bit about how the concept came about. So Lit, what it functionally is, is a distributed key management system. So it's a little bit abstract, but if you kind of zoom out just to look at this from a certain perspective, really what makes digital ownership possible is two things. It's state machines and it's signing. And I think some evidence for this is if you look at the Bitcoin white paper, even in Satoshi's first two sentences, the first sentence, I'm paraphrasing here, the first sentence is something along the lines of, we need peer-to-peer cash. The second sentence, digital signatures provide part of the solution, but we also need a way to prevent the double spend problem. And then Satoshi goes on to explain proof of work in Bitcoin and the rest of the paper. But the insight there is in that second sentence. And so the two kind of fundamental components that make digital ownership feasible is state and signing. And so what we have done over the past three years at Lit is take the concepts, the design ideals of blockchains, which is fault tolerance, programmability, decentralization, and apply those to the world of key management. And I'm sure we'll get into all of this around like multi-party computation, secure encrypted virtualization. These are some of the components in terms of how we were able to do that. But that's really the core ideas. Give developers, users, applications, protocols, a place to store and use secrets like keys, There's encryption keys, wallet keys, where there's not a centralized custodian, there's not a leader, and also not a dependency on the end user to take on the responsibility of managing the secret themselves. And so that's been our design principle from day one in terms of how we got to that idea. So Chris and I started trying to work on startups together in 2018. And there's this metaphor they call the idea maze. We spent three years in the idea maze. We raised some money in 2018, shut down a project, iterated through six, eight different things. My background was in B2B SaaS. My last business was acquired by LinkedIn at the end of 2017. And we had basically one design constraint, which is like, let's not do enterprise SaaS. We're, of course, really interested in decentralization. Well, if you look around at the various types of projects that people spend their life energy on, there's-- there's some things that are more network effect oriented, where if you can get it right, like marketplaces are an excellent example of this. Blockchains, of course, are an example of this. Many middleware products are an example of this. The value that the underlying product creates becomes a kind of self-fulfilling prophecy, whereas those network effects aren't necessarily as apparent in like an enterprise SaaS context, where it can kind of feel like bare-knuckle boxing to provide value to the next partner or user. And I just spent four years doing that boxing match.

Nicholas: And yeah, I was really interested in-- Maybe in SaaS, it's easier to get to the first dollar, but it sort of limits the horizon, you might say.

David Sneider: Maybe. I think that's something that one could definitely analyze. But yeah, that was our design frame. And so we had-- this was--. this would have been like the end of 2020, early '21, right at the end of the pandemic. We set up this NFT marketplace. It was like on Polygon, no fees. It had a little bit of traffic. And at the time-- Chris, maybe you want to share a little bit about the work that you were doing on Hen?

Chris Cassano: Oh, yeah. Yeah, I was-- yeah, there was a marketplace called Hic et Nunc. There was shut down on Tezos. And it was an NFT marketplace, right? Typically. Typical NFTs. But what I saw that was really cool and unique was they had enabled a new type of NFT, an HTML NFT. And so instead of the NFT being a static picture or a GIF, it was actually interactive. It could be dynamic. And you could do things like load data from an external data source. And I think there's this feeling that we had of like, NFTs as just pictures is interesting, but there's got to be so much more to it and to digital ownership.

David Sneider: That's exactly right. And so we're looking at this kind of new construct. I remember playing around with a slider bar on an NFT. And the insight that we had-- we're talking every day throughout this process. The insight was like, whoa. If you think about the browser window, then there's this NFT that's almost like its own separate little mini browser window. And it was behaving a lot like a web one web page, which it was running HTML. Like, OK, what is the-- if the browser itself upgraded from web one to web two, with user generated content, what would it look like for an NFT to do the same thing? And we started to develop this hypothesis that what if the lobby of the metaverse is actually just your crypto wallet and your different assets represent different portals or gateways to experiences? Like, OK, cool. That's a cool hypothesis. Let's figure out how we can test this hypothesis. And in investigating that-- and these ideas are always around scratching your own it. You probably kind of see where this is going-- we really came down to this fundamental question around like, OK, if we want to validate this hypothesis, how do we make an NFT something that is unlockable, so to speak? And when you start to peel the layers off of that question, it really comes down to an even more fundamental question, which is the question that has guided our work over the past three years, which is, where does the key live? Where does the secret material live? And then it was just through a conversation. We're kind of going back and forth. Now that we've-- so much of this is like finding the right question in terms of the ideation process. And now that we had identified the right question, almost very naturally from that was like, well, what if we use a network of nodes to manage the key? And that was the lightning bolt moment. It was like, this is powerful infrastructure. We immediately like riffed off a bunch of other use cases for a distributed key. But it was kind of through that securitist investigation with really a specific-- you know-- use case in mind that we arrived at the concept and then started building from there. And then, of course, keys can be used for signing and also encryption. And that's very much part of the feature set of the lib protocol network today.

Nicholas: didn't get stuck on the NFT as an app idea, which I know is a very enticing one lots of people are interested in, but maybe not as fundamental somehow as getting signing material into people's hands in a safe way, or--. Yeah. --decentralized way. Yeah. How did you manage to move on?

David Sneider: I feel like, Chris, maybe you can validate this, but I feel like part of our friendship and partnership, even before we started working together, is like a fun thing to do-- this is a nerd fun thing to do-- is basically asking, what's the generalized version of this? It's always like an interesting investigation, whether it's around categorizing things, et cetera. So I think we had developed that as a heuristic. of what's the generalized version of this prompt. And through that, it was very easy to move towards something that is closer to a base layer.

Chris Cassano: Yeah. I think also, NFTs as websites is cool. But it's not that cool compared to having true ownership there. If everybody that can view the NFT can get the same content, then why are you buying it? You know? Like--. Yeah. So being able to actually say, you get additional functionality, you get something special, and doing it in a way that isn't centralized. Because you can do that with OpenSea, right? You could say, and say, only let the user get this if they own the NFT. But then OpenSea has it, right? And that's fine for low-value stuff. Maybe it's a game or something. But what if there was something extremely high value in there, and you don't want anybody else in the world to have it, except the people that have paid for it, or they're able to access it? And so then you need somebody else to hold that key, to hold that secret. And then you need them to validate access control. You don't want it to be a single party.

David Sneider: I think to date, one of the best examples of-- I mean, there's a number of really excellent use cases of-- this category is generally called identity-based encryption. You could think about it as rules-based encryption. And I just want to add a little bit of context, right? Like, keys fundamentally do two things. They can encrypt, and they can sign. Yeah. In the context of public-private key pairs, or asymmetric cryptography, as it's called. So we're really now talking about the encryption side. We can have a whole other conversation about the signing side, and maybe we'll get to that. But on the encryption side, people are using this for things like token-gating content on things like Lens, data marketplaces-- we've been working with Streamr on that-- user-owned data in the form of encrypted verifiable credentials with consent and selected disclosure. And then a really recent example that has been exciting is Fox Corp. Corporation recently released a product called Verify-- Verify Media. And functionally, what they have designed is basically a news protocol. So right now, they just have their properties contributing to this. But if a publisher, like this podcast, for example, publishes some content, they can also publish it on this open protocol where the data is encrypted with LIT and stored on IPFS. And then any other party can pay for access to essentially license that data and either read it, listen to it, or the party that is licensing it can also then consume it in the form of-- consume it with an LLM, consume it with an AI. And so I think that's the big unlock of doing this in a decentralized way, is that LIT, as a distributed key management system, then can be a component, specifically the base layer around secret management, to other open distributed protocols. And that's really the unlock here, at least to my mind, what we're doing here, to go back to this heuristic in a general sense, like not just Chris and I and our awesome teammates here, but broadly in the industry, is moving towards a world where people consume services from networks, whether it's ledgers, secrets, news, data, et cetera. And there's a larger conversation around even the regulatory environment not really having a great grasp of-- having a great grasp on how to deal with the fact that there used to be organizations, individuals, and nation states. And now there's organizations, networks, individuals, and nation states. And we really are in a network era today.

Nicholas: Is it fair to say that LIT is fundamentally productizing MPC? Is that the core? There's a lot of different services and different functionality, but I'm trying to find, what is the kind of core technology? Is this network of nodes that are doing-- maybe MPC is over-specified version of it. But I mean, essentially, distributed key generation is an outcome of having a network that does MPC, right?

David Sneider: I mean, I think one way to describe it is it's functionally like distributed, programmable cryptography as a service. MPC is a component in the network being able to deliver that service, kind of going back to this idea that people consume services from networks. MPC is a-- this is a pretty broad category, multiple computers computing with one another. Specifically, we're focused on what they would call MPC TSS, so multi-party computation, threshold secret schemes. That's where the key comes into play. So the fundamental architecture is LIT is this 30-node network. All of these nodes-- this is the other aspect of it-- are running inside something called secure encrypted virtualization, a type of TEE for added security. And in order to-- Yeah. --generate a signature or some decryption, 20 out of those 30 nodes need to authorize that. But the node operators can't get into that machine and get the secret share, their part of the underlying key, because of that encrypted VM.

Nicholas: Because it's running in a TEE. Exactly.

David Sneider: It's running in a TEE. So you could say-- it's valid to say that we're productizing MPC TSS. But I think more accurately, that's just a component of the overall network and developer platform that we just call LIT protocol.

Nicholas: I think one thing that surprises me about LIT, or that is maybe not obvious, is that when you encounter the protocol, it seems like developer tooling. that's at a quite high level of abstraction. But it turns out, it's actually this very deep-- it's a whole new protocol, a whole network of nodes that are running a unique piece of software to implement this protocol. So I'm curious. It's like very ambitious to create-- to create a new network. How did you decide that it was viable to go about doing that? to get a decentralized network, or at least distributed network of nodes to run an entirely new protocol to enable these new services? It's like launching-- I mean, it's not a blockchain, but it's similar to launching your own L1, right?

David Sneider: 100%. Yeah. I mean, I think it goes back to this fundamental idea. Chris, I have some more to say on this, but I'm curious about your input.

Chris Cassano: I mean, it was the only way to make it work. You know? Yeah.

David Sneider: Yeah, I think we've seen MPC in marketing context be used and kind of bolted on, and it's definitely a key word. But our whole intention here has been to just like, how can we put users in control? And there's been times where it's like, oh, we're seeing other people get traction and this type of the other thing. But what's been just really reassuring is that by building with a sense of ideals, which is to say, we are on a mission. We are on a mission collectively in this industry to make the internet treat people with more maturity, give them protection, give them keys, give them a sense of agency and sovereignty. And that's really just been a design principle from the start. So yeah, I agree with Chris here. Launching a network is a symptom of trying to pursue that ideal.

Nicholas: So what is the software that the nodes actually run?

Chris Cassano: So there's a couple of different components to it. One piece that Dave touched on is the secure encrypted virtualization that's managed by a thing called LitOS. And that handles all the virtualization, attestation, provisioning of getting the node built. And then there's the node build itself, which is a whole lot of Rust code. And it effectively handles the system. It's secret shares, handles nodes joining and leaving the network, handles rotating those keys internally every 60 minutes, and then directly handles user requests so that the user actually connects to all the nodes directly and can get signature shares or decryption shares from those nodes, and then combine them on their side and create the final signature or the decrypted content.

David Sneider: Like if your listeners have like a mental model of how torrenting works, where you're connecting to a bunch of different parties and pulling down little bits of content, and you have like a PDF or a movie or whatever, it's a similar-- if you squint, it's a similar kind of model where you connect to all of these nodes, and then you get the authorization to sign. The other component that's important here is those nodes are also running a JavaScript execution environment inside of that TEE. And that enables a product that we've called Lit Actions, essentially. It's essentially being able to articulate programs or serverless functions in terms of how one wants the network to sign or decrypt something. And we've leveraged other distributed systems here. So let's say a developer creates a trading bot that they want to then commercialize and sell on a monthly subscription. They can put that trading bot up on IPFS, where the code is then made immutable, and the nodes, when they get a request that says, hey, buy 10 ETH, or buy 5 USDC, or whatever it might be, they will grab that program, the Lit Action, from this immutable content ID on IPFS. And so that's been really, really interesting, because even outside of signing and things like that, if you think about Amazon Lambda functions, Cloudflare functions, there's no immutable serverless function today, at least-- Yeah. Yeah. --in the general market. And so by leveraging the distributed systems and kind of thinking from this, let's make services that provide benefit and consume their benefits from networks, there's a bunch of really fascinating features that emerge out of that, like interoperability and immutability, in this case of writing these programs that dictate how the distributed keys will sign and encrypt.

Nicholas: Yeah, I want to get back to applications in a minute. But first, I just want to really understand how the network functions. We had-- Turnkey was on the show a little while ago. And I'm wondering if there's maybe some parallels for people who heard that episode. They have this Quorum OS that runs in a TEE. And they described a little bit in that episode the-- I forget the technical term for it, but the ceremony for installing new software in TEEs, this virtualization process. I wonder if that's similar to what LitOS is doing and then how the Node written in Rust runs on top of that. Maybe you can explain a little bit about how the Node software itself relates to this TEE hardware.

Chris Cassano: Sure, yeah. So the way that it works is there's probably a very similar sort of ceremony between what they do and what we do when we have a release. But we have a provisioning server that can build the VM. And then we have a reproducible build process so users can rebuild it. And check it against what the Node's built. But anyway, you make a build. And it goes on chain where it can be voted on by the DAO once everybody has checked out the code and that the build matches the code and all of that stuff. And then the Node operators use our LitOS system. We have a command like litos create. And they put in their various parameters. And the VM images actually get stored on IPFS. So it pulls down. And the VM image from IPFS. The images also have full attestation. And that's provided by our TEE system. And so that basically guarantees that the Node operator is running the correct build. When the nodes connect to each other, they attest. When the user connects to the nodes, they ask the node to attest. So you get some nice tamper-proof kind of properties there.

Nicholas: Can you say anything about how that works? Because that's very cool.

Chris Cassano: Yeah, absolutely. Yeah. So that's all powered by the AMD SCV-SNP system. That stands for Secure Encrypted Virtualization. And it's essentially a system that was built for cloud operators. So Amazon is running all these VMs. Wouldn't it be cool if you're running your workload on Amazon, and they couldn't alter your code? They couldn't change anything in the VM. Also, the memory is encrypted in the VM, et cetera. And so we use that same technology for our system, such that the actual final build uses a little tiny chip inside of the AMD chip, a little coprocessor, to create a signed attestation that's signed by the AMD certificate. And then Node operators, or anybody, when they check an attestation, they send over a challenge. The node. Yeah. It uses that internal AMD coprocessor to create the attestation using AMD's key. And then the user can actually just check that signature against the public AMD certificate. And it proves that it's signed, and it's genuine. And so that's the attestation side of it. And then the other component is the memory encryption, which is that the virtual machine memory is encrypted. We also encrypt the disk as well. That's not part of SEV SMP. We have to do that manually. But that basically means that the node operator, the VM to them is a black box. They can't see what's running inside of it. They can't tamper with it. They can't change anything. And it's really nice, because in any threshold network, you have the risk of collusion. And if you look at the crypto economics of a threshold network, for example, let's say you have the collective number of people staking 10,000, 10,000, $100 million, and they're custodying $100 million. It makes sense for them to try to collude to steal the user's money. And it's just a reality of any one of these threshold systems. And so by running everything inside this secure and encrypted virtualization system, it's like an extra layer of protection that basically prevents them from even being able to collude if they wanted to, because they can't actually get in to get any of the security.

David Sneider: I just want to make, I think, a really important distinction here. There are MPC networks that exist, and then there are TE key management vendors. You've mentioned Turnkey. Folks like Magic Link and Fireblocks are similar. It is our view that one of those components by itself is not enough. So if you think about the TE process is similar in terms of the setup, but holding a whole key in a TE and calling it non-custodial, in my opinion, is completely deceptive and likely illegal under custody laws from the New York Department of Financial Services and FinCEN's guidance of 2019. I think that there is a serious reckoning coming from a regulatory point of view for the vendors that claim to be non-custodial, but hold and control a lot of money, an entire user's key inside of a TE, and say like, oh, we've got this whole TE setup process, and expecting that to be like technical and hand wavy, but really are fundamentally in control and paying the bill for the server where that single key is stored. And on the other side, there are some MPC networks that don't use TEEs, which the collusion risk is just right there. The node operator can grab that key share out. If a few of them grab those key shares, they can sit and wait for 10 years for there to be $100 billion in the network and steal it at that point. The marriage of the MPC with the TEE is the unlock that makes distributed key management a thing that is possible. So I urge deep caution to teams that want to build with TEE-only vendors, both from the risk that they're putting in that sole vendor, like some of the ones that I mentioned earlier. As well as thinking about working with MPC networks that aren't using TEEs. We explored both of these routes. They were both kind of interesting. But the reason that we didn't go for either of those routes and have spent three years getting this thing live is that the product is greater than the sum of its parts when you combine the MPC with TEE. This is a very kind of like known security principle called defense in depth. Security is ultimately about layers. And you have different types of layers. You have different layers that protect against different types of attacks, essentially.

Nicholas: Yeah, that's really interesting. So then the core LIT technology then is that marriage of MPC protocol running inside of TEEs, such that you get a black box that you can trust a lot more than the alternatives. Because I feel like in the marketing, not only from LIT, but from everybody, people want to focus on what the applications are. But just to make it make sense for people who maybe don't see what the need would be, or for whom distributed key management is a bit abstract, but it seems like that is really the core thing that you're doing. And then there's lots of applications that can be built on top of that, which we'll get into in a second. So you mentioned that there's-- I'm curious about the distributed versus decentralized language and 30 nodes. How are they selected? Or what is the nature of the network? How do we get to these people running the node software? And why should we trust them?

David Sneider: Yeah, so the first set has been-- I think by us, it's node operators, as-a-service companies, a bunch of Web3 industry teams. We have a criteria for that. But as soon as we have the token live, basically, the node operators essentially work as consultants for the DAO. And the DAO can fire node operators and bring them on. So the ultimate control of that, to bootstrap it, the development team-- --has found the first set. But ultimately, the authority of who gets to be a node operator in the network moves to the distributed governance later this year.

Nicholas: Because you are vulnerable. Like you mentioned a second ago about if you're running an MPC network without the TEs, then the operators can just go grab the key material. You could do a similar thing by stuffing the ballot box by just running as many nodes as required to control the threshold, right? So I guess the idea is that the DAO will limit maliciousness. from joining the network such that they can't gain a sufficient majority to your-- it's 2/3, right, the threshold?

David Sneider: Yeah, that's right. Everybody's KYC'd. Everybody's a corporation. All of the teams that are running nodes have full-time infosec professionals and system administrators, not like startups that are just trying to put stuff together. But yes, that's totally attack if somebody stuffs the ballot box. And then to complete that attack-- and again, coming back to this idea of defense in depth-- what that would require is breaking the TEE. So in a case where somebody was able to masquerade as 2/3 of the network and did a Sybil attack but was still the same person, in order to steal the secret, they would still-- because we have a set of half dozen data centers that we've authorized the node operators to work with. They'd still have to break into the data center and perform a physical attack on the machine, which is one of the best things. rather than just using the admin keys to get into the box and pull the secret material out.

Nicholas: And you think that even with a fungible, free-floating token, tradable token, that it will still be safe?

David Sneider: Yeah. To Chris's point earlier, the security model is not a crypto-economic security model. The security model is cryptography-based with the TEE and the MPC network. So if the-- the value held by the keys in the network massively eclipses the value of the token, that's still totally OK. Because one being higher than the other, like, they're not dependent on each other by design.

Chris Cassano: I would just add one thing, too, which is that, like, you know, there's lots of TEEs out there, right? The most popular ones are, like, SGX, CVSMP. There's Arm Trust Zone. They're all maturing over time. And, you know, like, various attacks pop up here and there. Like Dave said, the only known attack against SEV right now requires physical access. But, you know, a really cool architecture for the network is also using multiple TEEs, right? If we have a 2/3 threshold, and we have 1/3 of the network on Intel SGX, 1/3 on SEV SMP, and 1/3 on Arm Trust Zone, then you have to break two TEEs, you know, in addition to all the other stuff that you have to do. So I think-- so I think that there's still, like, a lot there in terms of, like, the protection that you get. There's a lot of things that you can get from the TEE, and obviously there's ways to diversify that.

David Sneider: Yeah, and let's-- you know, I think something that can help kind of level set. this is, like, let's talk about what's the use of TEEs today outside of Web3, right? Like, Amazon has a TEE product that their banking clients use to store all of their information. Like, TEEs have proven a level of safety, but again, in the way that we've been thinking about it, when we start to think about how does a system like this exist in an adversarial way? It comes back to that defense in depth. The TEE is just one layer in keeping the key safe, which is the fundamental design principle.

Nicholas: So once we have these nodes running on these TEE machines-- well, actually, before that even, why is it of interest to node operators for, let's say, other node software for other networks? Why are they interested in running lit protocol nodes? What's the benefit to them?

David Sneider: Yeah, there's a utility token that we'll be launching. You know, we-- we are currently in the midst of an incentivized testnet. We'll have our mainnet beta out soon, which will have true distributed keys, but still use the testnet token. And then later this year, we'll have, like, the actual network token live. So, you know, coming back to this framework of what are we really doing here? Well, in this industry, we're building networks that provide services. In the case of lit, that service is key management. And so on the demand side, you have application builders. And on the supply side, you have node operators. So, you know, just like Ethereum or Chainlink, the node operators are compensated for providing aspect of the underlying service.

Nicholas: Got it. Yeah, that makes sense. So once they're installed, what do the nodes actually do? Like, what does the software do? Yeah, yeah.

Chris Cassano: Yeah, so the first thing that happens when the network boots up is they run a process called, just, distributed key generation. I think it's really cool to explain this because it provides some insight into how threshold cryptography actually works. And what that means is that the nodes come together. They all kind of, like, generate some random data and combine it in a very specific way. And what they end up with is a, like, a key pair, right? Just like your wallet has a key pair with a private key and a public key. But the cool thing is that nobody knows the private key. None of the node operators actually know it, right? The public key is known to everyone. Nobody knows the private key. Instead, each node operator only has a share of the private key. And if you were to aggregate the shares above the threshold, you could create the key. But you can also use the shares on their own to sign and create signing shares or decryption shares, send those down to the user, and then they can combine those to get a signature or a decryption out. So it's possible, basically, that the core difference, for example, between, like, something like Shamir's secret sharing and one of these threshold signature schemes, is that you don't have to create the key to use it. The key remains unknown to everyone, but you're still able to use it. And so, yeah, they run that DKG operation. Then once they have the key, they can, you know, start performing encryption services for people. And then we have a rotation or refresh mechanism that runs currently every hour, and that basically, you know, it does multiple things. But one of them is it lets nodes join and leave by mathematically resharing the secret to the other nodes. It also sort of scrambles the shares across these epoch transitions. And so what that means is, like, if you have a network of 10 nodes and, let's say, five leave, five new ones join, the shares across that boundary of when the new nodes join and the old nodes left are incompatible. And so-- Yeah. --you know, if you wanted to collude, you'd have to do it all, like, within an hour. You couldn't, like, slowly collect the shares over time.

David Sneider: Yeah, I think a couple things to add here. Also, I want to, like, draw a distinction between what does the node do, which is a fully automated process, and what does the node operator do, which is just keep paying the cloud bill, and they can't even get into the box. I think one thing that might be illustrative for your audience, for folks that have, like, a good mental model around how something like-- like, Layer 0 or Axelar works, which is you have a bunch of nodes come together, they do a DKG. Now they have this key for reading data from chain A and writing it to chain B. Lit is kind of similar, except when those cross-chain messaging protocols, when they move from epoch 1 to epoch 2, they're actually doing another DKG, and it's a different key. So the same key material isn't maintained throughout. And so this is that key refresh, also known as proactive secret sharing process. And this is the key that Chris was describing. And so Lit, as nodes are joining and leaving the network, is actually maintaining the same secret throughout via this process, all happening in this attested to encrypted VM.

Nicholas: Because if you were to change the secret, would it mean that the private key that nobody can see directly would have to change? And so you'd have to-- if it was an EOA, let's say, you'd have to change-- you'd have a new address.

David Sneider: And that's why you see the likes of Axelar and Layer 0 highly focused on cross-chain messaging, because you just have to change it. Because you just need the key for the moment of transferring information from chain A to chain B. We've seen people build similar cross-chain messaging in bridges with Lit, which has been really cool in the ecosystem. I know we're going to get into some use case stuff. But yeah, just from a mental model perspective, that's why those type of systems, which are using some of the same underlying cryptographic primitives, are confined to those cross-chain messaging use cases, because the key keeps changing. Whereas if you want to encrypt something, and then set a rule such that it can be decrypted in 100 years, you need the key to be the same throughout.

Nicholas: And just to put a point on it for the Layer 0 and those other cross-chain options you mentioned, the reason it's OK is because the transaction resolves across chain within a known time frame, right? Chris, you mentioned the signing shares. Is the idea that the client can ask the different nodes to sign and then combine those signatures on the client? Or maybe could you explain signing shares a little more?

Chris Cassano: Yeah, that's exactly right. I mean, that's the core technology of TSS, Threshold Signature Schemes, right? Which is, yeah, the user talks directly to the nodes. Each node independently verifies the user's authentication and authorization. And we support a lot of different auth methods. And then each node independently verifies and creates the signature share or decryption share. And in the case of a lit action, they would also each independently run the code that governs whether or not the signing or decryption can happen. And then, yeah, at that point, the user collects these shares up and combines them. That all happens in our SDK. It's like a mathematical operation. And then, yeah, they're good to go to start using it. It's really important, by the way, to mention that, like, there's no man in the middle here. Right? Like, you know, if you had some kind of man in the middle, right, then they could collect the shares and decrypt the content or get the signature or whatever it is. And so we have, like, a fully encrypted attested tunnel between the user and the nodes, or each node specifically.

David Sneider: Okay.

Nicholas: That's interesting. And is that how the --? I know there's distributed key generation, but there's also distributed key signing. So the distributed key signing is actually the fusion of the parts that's happening on the client, not in the network.

Chris Cassano: That's right.

David Sneider: That's exactly it. And then I think that gets particularly interesting when we start talking about encryption and user-owned data. You know, it's still early, but there's some really amazing builders who are imagining a future where, when you have a data backpack, as a term that has been thrown around, where privacy through that, where you kind of, like, move into a full client-side encryption and client-side decryption world. And so we're now in Web 2 where it's, like, the powers that be have all of the clear text of everybody's information. And in talking about that, kind of, like, going back to the idea around, like, what does a more mature Internet look like that treats people with more respect? Architecturally, what that looks like is you're encrypting data client-side and you're decrypting data client-side. And again, whether it's decrypting or signing, it's the collection of those shares that enables that to happen client-side without a man in the middle.

Nicholas: And the point being that you can store it. You can store the data wherever you want because the encryption and decryption is happening on the client, right? Yep. And I guess, you know, probably most people have understood it by now, but the point of contrast that you made earlier with Shamir's secret sharing is that you can cut up a key into parts and have a threshold, but once you reassemble the parts, you have the clear text key, which this system is, just to put a point on it for people who maybe haven't thought about it as much, the NPC TSS unique properties that you don't then need to rotate your key altogether because someone might have been looking over your shoulder or something like that.

David Sneider: The way I think about it is kind of like considering Shamir's secret sharing scheme one-time use. It's a little bit of a scratch off, if you will.

Nicholas: And that's why there is potentially a need for something like LIT protocol because although you can roll your own Shamir, it's not an enduring solution. It's a part of a solution. Yeah.

Chris Cassano: It also works if you have a trusted party. Like in some of these various like wild onboarding services, like the user signs in with Google or whatever it is, right? And then they just like generate a key on the user's device, split it into two parts, you know, give one part to some service. The user keeps a part. Maybe another part is backed up somewhere else. And like that use case is like mostly okay. because like what happens, right? The user wants to sign. You can recombine them on the user's side. They already know it. But it's a problem. Yeah. It's a problem if you don't have a trusted party.

David Sneider: And that also works on the assumption that the user's device is not compromised, which is not the case 100% of the time.

Nicholas: And the whole supply chain of whatever app has the key in memory, etc. I'm going to skip around a little bit. There's a lot more we have to talk about on LIT protocol. But just as we get to that point, it does kind of remind me of Passkeys and this new quite well-distributed technology where the user themselves also kind of has this black box private key where they never see it. Is this in competition with LIT somehow or is it enabling of LIT?

David Sneider: I don't think so at all. We have integrated Passkeys as an authentication method. We've seen it become really popular. And basically, like if you zoom out, I think, and I'm going to, you know, there's like WebAuth in the standard. There's Passkeys. For the sake of this conversation, let's define Passkeys as it's your device key that's stored in your device enclave. But that's also backed up by your major cloud provider, either Apple or Google. And I think if, you know, if we keep staying on the trajectory that we're on and get lucky in a few places, basically people are going to have the option of I trust Google with my life, I trust Apple with my life, or I trust distributed systems with my life. So the competitive frame is more around like centralized versus decentralized. But Passkeys as an authentication, as an individual technology to authorize from a device, I would say is, yeah, in deep harmony with the work that we've been up to. And another way to think about it is that like, let's say you have like your Passkeys stored on your Apple iCloud. You basically now have an architecture that's kind of like one to many, where if you used Apple Passkeys as one of your authorization methods, and you had a bunch of other ones, and that was managed by LIT, this distributed network, you're now more of a many to many frame. We'll see how that plays out over the years. I'm, for one, just really excited about Passkeys. Chris, any comments on Passkeys?

Chris Cassano: Yeah, yeah. So like Dave said, Passkeys are an auth method we support. They're definitely a good part of LIT. And I think it's an amazing key management innovation, right? To finally give users, this is crazy. We've had public key cryptography for like decades, right? And people are still typing in passwords, right? Like, so from that aspect, it's truly amazing. From the crypto perspective, I think like, you know, we see it as another auth method, but then also more broadly, there's still a lot of like use cases, I think, where you want a system that can handle automation. It can be always online, things like that, right? And if it's like, you have to scan your face every time you want to use your wallet, you know, you think about the future of like, AIs. talking to AIs, your personal bot is like buying your groceries for you during the day, you know, or while you're asleep, right? You don't necessarily want to have to, like. maybe you want to just set rules around that and let it run with the rules. You don't want to have to, you know, to be present all the time. So there's certain limitations there.

David Sneider: Yeah, non-human in the loop, human out of the loop operations, Passkeys are constrained there.

Nicholas: Yeah, it's interesting because it does seem like we're headed, as you say, sort of trust your life to Google or Apple or potentially distributed systems. There is this setup in the iCloud keychain world where Apple will throw away their key and ideally you've also set up the recovery contacts feature so that you have, I believe it's advanced protection plus recovery contacts, which are two separate features, but when combined mean Apple cannot, you can't call customer support and have them recover your account. They actually can't do it, or at least that's what they say. Of course, I don't know how great our optics are in the future, whether they're into the stack of what they're doing, but at the end of the day, are they, I mean, I don't expect you to be specialists on what they're doing, but I mean, they are running code in TEs, but we just have less, I suppose it's not open source. It's not attested in the same way from the user's perspective. It's like LID offers a greater degree of visibility into how the stack is functioning. And also it's running on a variety of node providers according to a threshold, as opposed to just whatever the one iCloud instance is. Is it, would that be some of the differences?

David Sneider: I mean, and one, they could be combined, right? Like, you know, this, you could, you could have a passkey that's backed up with social recovery, be an off method in LID. Like maybe there's a future where you could have a LID signature, be a social recovery aspect for your, like, like back into Apple. So there's, you know, there's very much like a middleware feel here where there's a bunch of kind of permutations and setups that are possible between like LID and iCloud in the backup. But I think one way that we can look at this conversation, even without like a deep insight into the inner workings of how Apple is managing this, is just to look at like the state of social recovery today from like a user experience point of view. So like social recovery has been possible and is being absolutely used by a number of people in the crypto Web3 industry, but it is by no means a super popular, regular thing. I think a lot of times people just like, it's who's ever around becomes their social recovery. And I think, you know, to that end, there's a reason that Apple has put that in their advanced features. So, you know, for people who are motivated to do self-custody with social recovery, not trust Apple, it's like, that's awesome. That's really, really great. You know, don't use the systems that can, that don't provide that. Do that if that's what you want to do. But not to be like too dramatic here, but if we're, what we're really talking about is like, how do we use mathematics to like liberate the masses of humanity on the internet? That is probably not going to be the most viable route just based on, you know, like beyond even saving a seed phrase. Now you have to like talk to other human beings to do your, your backup.

Nicholas: Yeah, for sure. And we don't even really talk about it yet. People don't think about deplatforming vis-a-vis Apple ID, but there is, there's obviously a censorship angle also. That's not just about leaking the key material, but just losing access to the key material, which both Google password manager, when it's renamed pass key manager, what have you? and iCloud both have this major problem. So it's not just the, and there are, you know, that each of these transparency reports where they are heavily involved in all kinds of actions against their own users on a variety of dimensions and in every territory in the world. So it's not a, it's not just a theoretical thing. So that's where it's worth thinking about. Do, do signers have to pay anything when they're using lit protocol or like, does a signer have to worry about access to their keys being financially gated somehow?

David Sneider: Yeah, Chris, do you want to explain the capacity credits system and how providers can work with users and delegation there?

Chris Cassano: Yeah, yeah, absolutely. Yeah, so we, we basically have a system where you can pay to mint an NFT that gives you a certain amount of capacity per 24 hours. You can use up to that limit every day. And then the nodes just track your usage against that limit. It's like I said, it's 24 hours, so it just resets. And yeah, you very simply like pay a flat rate for each request.

David Sneider: Yeah, I mean, and there's some kind of like continuing to ideate around pricing. What we've been targeting is a 10th of a cent per signing request. Again, there's this whole delegation system built in. This whole system is designed like Lit as a service to be consumed by developers where they can abstract that cost away from the end user. You have to figure like AWS delivers compute as a service, but the end user isn't paying AWS. In the context of Lit, Lit is delivering cryptography as a service, but the end user is not paying Lit. That's the implementer's job. But they could pay for it if they wanted to, like let's say that application failed or whatever. There's no dependency on that application. This is more from like a user experience point of view. But yeah, it's a service. It will cost money. We're really excited about basically being the low cost provider. This is a known aspect of networks, what they call like a lower take rate because the node operators, they're compensated on a cost plus basis, which is fixed. And then that's basically it. There's like different economic constraints on like an open network. That is a nonprofit association or foundation versus a commercial company that has much different constraints from like an economic point of view, investors, returns, et cetera.

Nicholas: From an economic point of view, do you foresee that the fees that are paid by, let's say app developers who integrate Lit on behalf of their users, the fees that they pay go directly to the node operators? or how do you see that working out?

David Sneider: There's a whole smart contract set up. There's a treasury. The way that we're going to start is just like everything iteratively in terms of like moving towards sustainability to date at the start of the network. The nodes are compensated at a flat rate. Then there's like additional kind of staking mechanisms, et cetera. But essentially there is a contract that is holding the network revenue and then disbursement happens through there. And a lot of that is we're just trying to set up the initial contract and then move this towards just distributed governance. We've been really inspired by the graphs model which uses a council that is elected and ratified by the token holders. And in the context of Lit, now that we're talking about governance, just to touch on this a little bit, functionally the three parties here in terms of the current design are the node operators represent a party. They have certain authority. Do they choose to unplug their computer? Do they choose to update to the newest software? Then there's this council that you can kind of think of as like the elected officials by the token holders. And then there's the token holders themselves who can also be involved in decision and have some authority. So right now our attention has been to just try to like set up same default initial conditions as it relates to the relationships between those three parties. But yeah, this is definitely part of the adventure of making and building networks in community and with ecosystem partners, an effort that Chris and I are very much up to here is to see how that optimizes over time and make sure everybody can get their needs met.

Nicholas: Yeah, it's interesting that you mentioned the graph because some people perceive that as overcomplicated, at least as it plays out from a developer perspective for EVM. But it sounds like you're more inspired by the council element and not so much maybe making requirements that people purchase the token in order to become developers building on top of it Or their application, which might be more streamlined.

David Sneider: Yeah. I mean, the people like developers will need the token to pay for the service. That's true. But, you know, it's like there's test nets, there's free networks. Those are already up and out. But yeah, the reason that that model was exciting to one of your earlier questions, rather than just doing like full, you know, token weighted governance or something like that is like keeping the keys safe beyond anything is the number one design priority. And so the governance model that we've just talked about, a little bit about at a high level, is inspired by that as the goal.

Nicholas: Do you think that the members of this council or however it ultimately shakes out in the design would be compensated for that role?

David Sneider: Yeah. Yeah.

Nicholas: Yeah. Yeah.

David Sneider: You know, it's like you have to just, I think, you know, we would never like have an intern on our team who isn't paid. I think like compensating people for their time is just good manners.

Nicholas: I want to get into a bunch of the features that are kind of named products that you offer in a second. But before we get there, how are nodes able to, in principle, incorporate on and off chain data into their access control, effectuation of access controls? How do they go and get data from either of these sources?

Chris Cassano: Yeah. Well, they use the Internet. And but yeah, but more seriously, you know, the nice thing about the encrypted virtualization solution that we have is that it lets you talk to the Internet. Right. Like if you use Intel SGX, some of these other systems like you can't talk to the Internet because this is a full encrypted virtual machine. It has, you know, certificate authority certificates in it. It has the ability to validate SSL, you know, to prevent any kind of man in the middle or anything.

Nicholas: So it's pretty simple.

Chris Cassano: Like you.

Nicholas: It's got Internet Explorer in it.

Chris Cassano: Yeah. Yeah, exactly. It's got a fancy version of Internet Explorer. Yeah. But yeah, it's pretty simple. Right. So like you set up your conditions, right? Like your conditions could be chain based, right? Like you have to hold an NFT at this contract address on this chain. Your conditions could be a lit action. This JavaScript function has to return true. And then, you know, like depending on what you want to do, like the nodes will make an RPC call to Ethereum, for example, to check and see if this wallet holds the NFT within a lit action. We let people just use the fetch JavaScript function, which lets them make HTTP requests. And, you know, there's some limits there so they don't abuse it and stuff. But it's like pretty easy. Like you could just, you know, hit any other API that you want and then use the data. And then you can, you know, so you could very easily make a lit action that says like only sign transactions when it's like below 30 degrees in New York. And it's super easy. Just, you know, hit the endpoint, get the data and then write an if statement.

Nicholas: And so all the nodes do that independently. And then if the conditions are met, they will do the signing of their signing chart. And then or is it maybe I'm using the wrong terminology. What did you call it? Signing share?

Chris Cassano: Share, yeah.

David Sneider: They use their key share to generate a signing share. And I think this, Nicholas, what you just said brings up an important point, which is like in the broad space of multi-party computation, there is definitely a class of academics and teams that are using MPC for efficiency. How can we make more efficient compute? That is not the take here at all. It's actually incredibly redundant to have multiple nodes have to do the same operation. But the benefit that you get from that is no centralized controller. And so, yeah, just for people who are kind of like thinking about MPC, sometimes people go, yeah, MPC. That's the idea. If you have some job and you divide it up into parts such that it can be done faster. That's not what's happening here. Here, the whole intention of using this technology has been for user protection and control.

Nicholas: So it's not parallelized. It's massively serialized. It's all these machines doing the same thing. At least today, yeah.

David Sneider: That's definitely on our roadmap in terms of how to make that more efficient. We've investigated some ZKP stuff there. But for the v0, that's the case.

Nicholas: Yeah, I think that makes sense. People want things that they can actually use more than ideal solutions that they can't make use of. Yeah. What does the LIT relay server do?

Chris Cassano: Yeah, it's pretty simple. So we have a rollup that we use, an L2 rollup that we use as basically the database for LIT, right? So you create a wallet using LIT. It needs to store the permissions, like who's allowed to access it, et cetera. And so that goes on chain into that rollup. Now, obviously, there's a very annoying.

David Sneider: Yeah.

Chris Cassano: Yeah, exactly. That we've all seen, right? Where it's like, okay, I want to use this service. I have to go get gas for it, right? Jeez, I got to go to Coinbase. It's like a 30-step process, honestly, if you list out all the steps. Yeah. And so what the Relayer does is it literally just pays for the transaction to mint that wallet on the rollup chain. Yeah.

David Sneider: The way I think about it is it's basically a hot wallet that subsidizes the first transaction. So it's not like a 50-step transaction of associating the authentication method like Google, Passkey, another wallet, email, et cetera, with that wallet. Because if somebody doesn't have a wallet, how can they pay to connect the auth method? Yeah.

Chris Cassano: I think it's cool to bring up what that actually does, too. What is it actually doing when it makes that transaction? What it's doing is it's minting an NFT. We call these NFTs a PKP. It stands for Programmable Key Pair. And that NFT essentially, whoever possesses that NFT basically has that NFT. It has root access to that wallet, right? And so what that means is you can actually make wallets themselves fungible, right? This can break sold-out tokens. This can let you do like a wrapper wallet. Like, for example, if you have vaults. Vaults, that's what it's called, right? Yeah. Where if you wanted to put 100 NFTs in one of these and sell them all at once, you don't have to make 100 transfer transactions. Yeah.

Nicholas: So is the... Well, first of all... First of all, why do you need a place to store the data? Why can't you just store the data in nodes themselves?

Chris Cassano: You could. You could.

David Sneider: It's a bit of a harder problem.

Chris Cassano: And I think that a blockchain is just better suited for it because of the fact that the blockchain comes with payment built in. It comes with like, you know, it's a central data store. So you don't have sync issues between the nodes. And, you know, we initially started with this design because like from the very beginning, right? Like, okay, I want to boot the network up. How do I know who to talk to? Like, who are the other nodes that are participating with me? Right? And what do we really want that to be? It should be other people that are staking. Right? Where do they stake? They stake on chain. So, you know, using the chain as a place to mediate like payment and staking and all of this stuff, you know, I think is a better design decision than trying to basically rebuild a blockchain within the nodes.

David Sneider: Yeah. It's almost like... We need a public immutable database. Does anybody know any technology that fits that design constraint?

Nicholas: That's great. And so all the data that's going on to the roll up is really this public data about access controls. There's nothing private there. It would be things... Can you give an example of what a PKP might specify?

Chris Cassano: Yeah, absolutely. It would specify generally like the ETH wallet. The wallet address for that PKP because they are kind of randomly generated. You don't get to pick one. And it also specifies like all the permissions. So like if you signed in with Google, it'll, you know, store a hash of the information needed to like to authorize you with Google so that when you come back and you try to use that PKP, the nodes off you, they can hash the same data, check it against the one on chain and say like, all right, you're good. You're in.

Nicholas: So it might be something even like a public key of a pass key would be in a PKP if that was the... Yeah. Yeah. Yeah.

Chris Cassano: The hash of a public key of a pass key because we always hash it. But yeah, totally.

David Sneider: I mean, Chris, I think, you know, in the context of you don't get to pick one, it might be interesting to detail claimable keys a little bit.

Chris Cassano: Oh, yeah. That is true. Yeah. Yeah. We also have a feature called claimable keys where you can essentially like without the user interacting with lit. Yeah. If you want to know what the auth method is going to be, you can predict what their wallet address will be. So what that means, for example, is like if like I'm on Discord, for example, and I want to send you an ETH, but you've never used lit, but I know you're going to log in using Discord and I know your Discord user ID because I'm in Discord. I can essentially derive what your wallet would be when you do sign in someday. I can send funds to it. And then when you're ready to use lit, you can show up, log in with Discord. And this works because the keys are like deterministically derivable based on the auth method. Right. You can come back and claim that key and there's already money in it ready to be spent.

David Sneider: Yeah. One of the things that I'm really excited about this feature specifically on is like you think about what got people not into decentralized tokenized money, but like digital money. But, you know, a few decades ago was PayPal. And PayPal's mega growth feature was sent to email. And so basically that's what we're talking about here in a crypto context where people can send money to an email and then same exact flow as PayPal. You know, in the PayPal world in the 90s, you had to then author your email and then you could get your funds. Same thing here. You author email, which is this authentication method. And now you have control over these tokens and cryptocurrencies in this wallet.

Nicholas: And is that dependent on something from Discord? For example, that you're able to ping in order to derive or you can just know just from the username and how the Discord APIs work. Do you need to interact with them? Could they change something such that you'd have to resign for the new deterministic hash or whatever it is?

Chris Cassano: Yeah. I mean, potentially. Right. If Discord like changed their user ID format tomorrow. Right. Like they were like, oh, we're going to make it alphanumeric instead of numbers and we're changing it globally. You know, ideally, like they wouldn't do that overnight. Right. There'd be like a warning period. You know, we're going to be breaking existing applications, whatever. But yeah, that's definitely always one of the risks in general of using any outsourced auth system. Right. Like the gold standard that always going to be the most thing you have the most control over is some kind of self custody solution. Right. And you can use that with lit as well. Like you can you can have a wallet as an auth method on lit. So you could. you could still if you wanted to, you could still write down 12 words and use Discord. And then if Discord dies, you still have this like emergency, you know, backup you can use to get in. But we support lots of auth methods. You could use Google and Discord, whatever. But I guess that's kind of the answer is like we recommend setting up at least two auth methods just to protect against the risk of some third party provider like changing something.

Nicholas: If you were going to have like a multifactor PKP and maybe we should just give like a quick definition of what a PKP is in some more generic sense as a product. But if you were going to have a multifactor one with, for example, an EOA and Discord account, would they both be defined inside that one NFT you described on your roll up?

David Sneider: Excellent point. So the NFT that we talked about on the roll up, that is actually an auth method itself. So you so like basically that NFT and the third party wallet and the Discord username are all sitting on the same bench, so to speak.

Nicholas: They're each an NFT. Yeah.

David Sneider: Yeah. They're each an authentication method. Okay.

Chris Cassano: Yeah. Yeah. Yeah. Just to describe it right. There's a PKP NFT contract that mints the NFTs and there's a separate PKP permissions contract and you can attach multiple permissions to one PKP.

Nicholas: And every authentication method will get a PKP NFT or there are other kinds of authentication that don't require an NFT like that?

Chris Cassano: Yeah. I mean, the auth methods don't like. the PKP NFT is the wallet that you're going to use. Okay. And so, yeah. And so like there's a lot of different ways to auth with that, which are the various auth methods. But yeah, they're kind of like the auth methods themselves and the NFT are separate.

Nicholas: So it's sort of like smart account, like your own flavor of smart account. That's exactly right. Focused on this permissioning thing.

David Sneider: We're talking about auth methods rather than signers, basically. Yep.

Nicholas: Okay. I see. I see. So does it make more sense? We touched on them a little bit, but does it make more sense to talk about PKPs or lit actions first? I think it would be good to get like a very clear definition of how these things stack up for a dev who wants to use lit. Yeah.

David Sneider: Let's start with PKPs and then go to actions and we could provide examples of how both of these things are being used. Sure.

Chris Cassano: Yeah. So PKP stands for programmable key pair. The idea is that this is a threshold wallet. Right. Where did the actual, where does the key live? Right. It's split up amongst all the nodes using our threshold wallet. So it's a threshold signature scheme and it's represented in our database, our rollup as an NFT. So it's transferable, which is very cool. It can have auth methods like we talked about. We support a lot of different auth methods to make it really easy to get on and start using it. And, you know, it's kind of a good segue into lit actions. You can also assign a lit action as an auth method. You can also assign a lit action on your PKP, which is basically, it's very similar to the approval flow that you've seen in Ethereum where you can approve a contract to spend your tokens. In this case, you're basically approving this lit action is able to use my PKP. The lit action is immutable. It's JavaScript. So just like a smart contract, like the developer can't come in and change stuff and rug you. So as long as you trust the code or the audit or whatever, you can feel safe doing that. And then what are lit actions? Lit actions are basically JavaScript programs that you upload to IPFS. That makes them immutable because IPFS is content address based. And yeah, that means that basically you can run these programs. They run across all the nodes at once inside of a JavaScript runtime. We give you like a lot of really common features, make it really easy to use. You can use fetch. So you can talk to the outside world. You can do Oracle use cases, you know, whatever you want. You could also use the, oh, go ahead. Yeah.

Nicholas: It's the IPFS CID is written to the roll up to enforce that immutability.

Chris Cassano: Yes, exactly. Exactly. Like, like you, you say, like, I want, I have a PKP. I want to let this IPFS ID use my PKP.

Nicholas: Got it.

Chris Cassano: Yeah. And so, and so that's, you know, that that's how you can basically create these programs that can govern signing. Yeah. And, you know, lit actions itself though, is also basically a serverless runtime. So it's also possible to use it for just like generalized JavaScript JavaScript execution. I don't think that's a use case that we're targeting right now. We're really focusing on the cryptography stuff, but that's something we might move into in the future.

David Sneider: Yeah. I mean, I think to that point, what's been really interesting is, you know, to closely track all of the developments and use cases around ZK proofs and especially in like consumer business applications for proofs. And to Chris's point, like you can use this MPC plus MPC TSS plus TE setup to functionally generate a proof, right? You could have one of these actions say, is this number prime or has this person been KYC validated and get a true or false return? And I think it'll be really interesting to see where folks gravitate towards that in terms of, you know, if you want to like create a proof of state, like in the context of a, of a, of a ZK L2. ZKP, awesome technology to use there. But if we're talking about things that are a bit more pedestrian and everyday, definitely the security properties of MPC TSS plus TE, what we've got going on at LIT become really interesting for these proof based use cases. I think it's still frankly too early to say like, our proof's going to be, or proof's going to have the impact globally that like, I know there's a lot of expectation for them. just as like a functional way of like. Communicating between parties, but that's something that we've definitely been paying attention to.

Nicholas: It reminds me a little bit because with ZKP so often what you're doing is moving some of the computation off of the expensive execution environment, like a chain and instead just making proofs about having executed that computation elsewhere. Which you can also do with other technologies depending on what your application is. But one of the advantages of the distributed key generation signing and encryption in LIT protocol is. That you can get permissions without having to do on chain computation, right? You don't need to execute in even in memory space inside of a transaction on an EVM in order to decide whether or not someone is permitted to do something. Instead you can do that work on the other, on the node outside the system and then bring the result implicit in getting, have gained access to the key, right? Is that one way to think about it?

David Sneider: That's it, a signature as proof.

Nicholas: Yeah, exactly. Which to the EVM perspective we're working on. I think the EVM or whatever chain is really gas efficient. It couldn't be much simpler. Very interesting. How does someone coming from an EVM background verify that the network is actually doing what it claims? Why should people trust? How can they verify?

Chris Cassano: Yeah, I mean, so the, you look at the source code, right? We're publishing that pretty soon with the main net release. And yeah, it's like pretty straightforward. Trying to keep the code really clean and easy to understand. We have a number of audits as well that we've received. that, you know, help us with that.

David Sneider: But do you want to talk about a bit about the reproducible build process that is underway as well?

Chris Cassano: Oh, yes. Yes. Also, of course that. Yeah. Yeah. Open sourcing the code isn't very useful if you have no way to prove that you're running the code. that's open source. And so we have a process of reproducible builds. because of the encrypted virtualization system that we're using. It's actually, it's necessary. That the build be done centrally because you have to create that attestation that's valid for all of the other nodes when they installed to compare against. And so in order to do that, we have a reproducible build process where you can take a specific commit hash of the code in the repository. And you can basically, you know, like say that's a release, right? It's like that's V2 or something, right? You can rebuild that on your machine. Yourself using our build process and get basically the same binary out. And then you can download the virtual machine image and check the binary inside of it and see that it actually matches. And, you know, you can look at the rest of the virtual machine image to make sure that there's nothing else sneaky going on. But that that's a process.

Nicholas: It's interesting to compare to the blockchain node software world where the implementations are different. They are very different. And yet they adhere to a set of rules. Whereas here you really do need to be running the exact same compiled version. Yeah.

Chris Cassano: For right now. I mean, you know, in like obviously client diversity is a very important topic. And I think we want to get to, you know, to that state. That's what they call it in Ethereum, right? Client diversity. But it's in our case, it's like node diversity. There being more than one implementation of the node. You know, Solana is working on Fire Dancer to fix this problem. I definitely think we'd be open to that. Right? It's just like a question of like. Building that out, getting the community to validate it, getting, you know, the community to agree. Like, hey, we, you know, we think that this is, you know, safe enough that it's not going to break the rest of the network. But we do have like a well-defined API specification to make that possible. And then, you know, what that would mean is setting up the attestation system to accept builds from this other client. So it's totally possible someday.

Nicholas: Yeah, maybe one day. We're on LIT. Well, I guess version three, maybe it's the SDK version three or the whole protocol version three. But I guess I'm curious, how has your vision for LIT changed through encounters with reality building it over the last few years?

David Sneider: Yeah. I would say there's basically been two big insights along the way. One was let's use a network of nodes to custody a key. And then one, Chris loves it. Just kidding. Maybe he gets embarrassed when I tell the story. But Chris basically, about a year and a half ago, had the same insight that Phil had. Which is that setting up a blockchain is a huge pain. And so the invention of smart contracts is you can get the benefit of a blockchain without having to set up nodes. And so that second big insight was the idea of LIT actions, which is like we are really going through an extensive process to get this network up and running. And the introduction of LIT actions where people can run programs across the system. This network are kind of a similar insight. And I would say, you know, let's use keys or let's use a network to manage keys. And then let's make those keys programmable have really been kind of the two big insights along the way. Of course, there's a bunch of other iterative learnings that happen from there around usability. We love to attend hackathons, work very closely with the developer community, provide a world-class experience, whether it's from a self-serve or being able to talk to us or getting community support perspective. But from a macro point of view, we've actually been like pretty coherent in terms of heading in this direction. And it's just that this is like an extremely non-trivial project from an applied cryptography and privacy point of view. So it's definitely taken some time to do right and do safely. Especially given like the fact that at the end of the day, this is like an ideals given project around. Let's give the power and the control. To individual users.

Nicholas: You know, latest like pitched, at least as I understand it, as for crypto devs and for this private public key pair, distributed key generation, et cetera, everything we've talked about. But it seems like it might have lots of applications that have nothing to do with crypto as private keys become just more frequently used across not only technology, but just in general. People seem to be we seem to be at some kind of inflection point for private public key pairs. Partly steward. Partly by the blockchain stuff, but also just, I don't know, people have gotten used to the idea or something. How do you perceive of that? And how do you think it might be useful for people who are not building crypto applications?

David Sneider: You're absolutely right. I think, yeah, we're in the midst of something really, really interesting happening, especially like cryptography is the counterpoint to the AI era. Functionally, what you just set up is that prompt is what dictates our cryptography roadmap. And then materially. What that looks like is implementing new signing curves, new signing algorithms, new methods for generating signatures. So there's things like Alasaur, which is for like private revocable credentials. Definitely some really interesting demand from nation states and governments and things like nurses and medical professionals from there. Adding more curve types such that different chains can be supported. Solana, the move chains. We very closely are tracking the NIST curves and have those on the roadmap. That definitely opens up the opportunity to move out of kind of the crypto web three development space and do this more broadly. And so that's all like curves inside of the protocol. I'm speculating a little bit with what I'm about to say. But then the other thing that starts to get really interesting, like the dream here would be that, you know, the member states. Of the EU fork lit protocol and each member state runs a node. And then, like, as a public good for members of the EU in this example, they just get to provide keys for the citizens of that geographic region. So, yeah, there's some really interesting stuff happening there. The other things that get really interesting are thinking about like hybrid networks whereby some of the key shares are stored in the network. But some of them are on prem inside of an organization. And so this like this fundamental idea of there used to be two choices, which is self custody or let somebody else manage custody is kind of we're breaking that apart in the context of crypto and web three development with this introduction of distributed custody or distributed key management. But it's not. You're absolutely right. It's not just crypto projects and teams that do key management. AWS KMS has been out for years. Hashtag Corp is a four billion dollar publicly traded company that functionally does key management. And so like enterprises, for example, like if you're if you're a bank and you are a customer of Salesforce dot com, the CRM, you have the same decision today that somebody who's buying their first NFT does, which is do I let Salesforce manage my key? Or they have like Salesforce has a feature that's called bring your own key where you have to like bring your own key, which would be the self custody equivalent. And so the same thing that's happening where that dichotomy breaks apart. now that keys can are a thing that can be managed in a distributed way, I think will continue to happen inside of the enterprise, inside of nation states. And it just kind of fundamentally makes sense that we have an air gap security model like where even in centralized custody or self custody, there's no air gap security there. The key itself is living as one. Coherent thing that is. that is very, very high risk. So those are the two ways we're thinking about the implementation of more curves and use cases whereby somebody would want to run their own distributed key management network.

Nicholas: We glossed a few applications, but there are lots of applications that are very interesting here. And I guess do they all conform to this before we dove into some of them? Do they all conform to this notion of access to the private key? Means that you have. Sufficiently you've passed the test of the access controls. Do they all like, for instance, decrypting some private media associated with an ownership of an NFT? If you can connect your wallet and prove that you're the holder of that NFT, then lit will decrypt the data that's stored. It doesn't really matter where IPFS or something and show it to you. Do they do? all of the applications follow this kind of pattern of the access control test is like the user is challenged. Do they both need to be lead by the network to prove that they. Meet its limits? or like a lit action is doing this periodically on its own. Or are there other ways to think about the types of applications that exist?

David Sneider: I mean, if you squeeze that mental model in and say like, hey, you have to prove something to be the case in order for some action to happen or some operation to happen. I think probably the clear way to think about it is. Just recognizing the two function fundamental, like features or properties of public private key pairs in general, which is encryption and signing. And that's like how we articulate things in the docs, for example. So the encryption side, we have like token gating, like you were talking about user owned data, data marketplaces, licensing, and then the signing side, the main use case that we've seen become popular is things like wallet with this authentication methods and the onboarding, but also people building out bridges, people building out oracles. Like I'll give you an example of, uh, of a cool thing that came out at a hackathon called true P2P. And the product was, uh, like, let's say you have Alice and Bob, um, Alice puts 10 USDC, uh, into a contract. Um, Bob from Fiat to Fiat sends Alice, uh, $10 over Zelle, like over the traditional rails, Bob has set, up this application that uses the bank connector tool called plaid. If you've come across that before, I'm sure you have, um, plaid in this context, it's hooked up to lit. Lit is almost acting as a private Oracle. And when that program sees that Bob has sent 10 us, or excuse me, $10 Fiat to Fiat to Alice, it will generate a signature that then releases that 10 USDC, which is on chain to Bob's wallet. And so like in that way, I don't know, you know, you just talked to the folks at ZK P2P. Similar mental model there, but in this case, like using lit and plaid to like onboard Bob in, in, into crypto. Um, this is like another cool signing kit use case.

Nicholas: Yeah. That's very cool. Um, are there any others that come to mind or partners who are using the technology today in cool ways? I know that one of the classic demos I've heard, was it Chris? I I'm not sure which one of you, the Tesla NFT demo stuck in my mind. That was Chris.

David Sneider: Yeah. Yeah.

Nicholas: Yeah. Yeah.

Chris Cassano: Thanks.

David Sneider: Yeah.

Nicholas: Um, yes.

David Sneider: Doing it for the tweets. Um, yeah, I mean, you know, there's like, I would say some of the high level things are like, certainly we've seen people implementing this in the context of developer products, um, that then end up in a bunch of different categories, like signers for account abstraction, uh, interesting work with, uh, verifiable credentials and resumes with teams like talent layer, uh, teams that are building, like mobile wallet tooling, like snowball wallet teams, like a team of collab land recently want launched a product called tele friends that adds a wallet inside of telegram, uh, folks like obvious patch wallet coin. Easy burnt has built a cosmos chain that has like lit keys, very integrated with it. Silk is doing some interesting things for recovery, um, with cross chain messaging. So we talked earlier around like how there's some, you can do cross chain messaging, but there's lit, there's a team called Pharaoh working on that personal data with credit, uh, Awamo terminal three gateway, um, data marketplaces, like what we talked about with Fox earlier, checked and carrot Dow streamer. Um, also we've seen some like really interesting digital product NFTs. So molecule, uh, has their IP NFT that uses lit token gating. There's an application called Alexandria that does, uh, eBooks as NFTs. Yeah. Yeah. uh, use lit to encrypt the content of the book. Um, there's recently an NFT of Michael Jackson's first album that went up on another block, uh, that uses lit. I've also seen things around, um, treasury management, uh, and, and like, and then all of these systems kind of work both with blockchains as well as everybody's favorite private storage systems, Filecoin, IPFS, Ceramic, WeaveDB, Pinata. Um, so I know I just threw a bunch of stuff at you. Um, some other interesting things that are kind of like right on the cusp of fascinating applications that are starting to develop are people who are thinking about, um, essentially like autonomous economic agents. An example of this is like an NPC, a non-player character in a fully on-chain game. What does it look like to basically have like the shopkeeper in the game have an LLM brain that can then like buy and sell and trade on-chain directly? Uh, you know, now we're starting to really get into like interesting things that have been characterized as part of the quote fourth industrial revolution around like non-human economic agents, which is kind of like a little bit of a brave new world and maybe it requires its own separate conversation, but that stuff is really

Nicholas: cool. Is there that kind of example? How would, uh, an LLM agent, for example, authenticate into lit? Do you have a sense of...

David Sneider: It would actually run in lit. So NVIDIA GPUs can talk directly to SEV.

Nicholas: Okay. So... There would be a network connection between the LLM directly, like potentially even on-prem and, uh, and a lit node. or what do you mean by directly? I guess the nodes themselves could be upgraded to run LLMs inside.

Chris Cassano: Yeah. You just, you just jam a GPU into the node.

Nicholas: Why not? Sure.

David Sneider: Yeah, exactly. Yeah. Yeah.

Chris Cassano: I mean, like David said, NVIDIA has a whole confidential compute framework that works with AMD SEV SMP. And so you can actually preserve the confidential properties of lit protocol, but still... You can still use, uh, GPUs for that. So you could have confidential LLMs running in the cloud.

David Sneider: That sign transactions on-chain.

Nicholas: How do you think about, uh, like all that's going on with, uh, like the OP stack and all these other roll-up stacks sort of developing, even, I guess, flashbots, um, developing forks of the main, uh, geth implementation. And then as this, like, it seems like there's a lot, there's something happening. There's something in the water overall. Maybe it's just, you know, it's just, you know, it's not all about, you know, looking at just the overall maturity of the EVM ecosystem, but also things like eigen layer, where node operators will be incentivized to run additional software. Do you, obviously nobody can predict the future, but do you foresee that, uh, someone installing, uh, you know, someone who's operating their own node might install lit protocol, node alongside their EVM node for main net or for helping out other networks? Do you think it becomes a more common task that way? Or. Okay. Yeah. Yeah. the dao it's. it's not ultimately not that applicable to sort of get the uh economy of scale of running multiple nodes.

David Sneider: i mean i think yeah. to me it just comes down to like you know state and signing. the blockchains and keys are kind of like fundamentally like very much linked but different things. so there's a number of permutations where those things can work together. there's some interesting developments around like um verifiable npc where i could see you know there's like a lit subnet that also has dual staking with eigen layer involved. um the chain that we're using today is part of the op stack. um so i i i think there's like a number of ways these things will come together in terms of is somebody going to like uh set up a blockchain that those nodes are also lit nodes? maybe but it probably would make sense initially just to like use lit as a service and integrate it at the sdk level?

Chris Cassano: you yeah i i would i would add to that like the idea of a home staker very appealing. i mean i'm personally i'm super into that and i think we want to work towards that in the future someday. there are just like some roadblocks to overcome. like you said there's the civil attack problem. right who knows maybe world coin will save us there. um and then yeah the other problem is just like the realities of a home internet connection versus like something in a data center. right where it's like dream bandwidth is extremely limited in in most locations right. so in terms of home connections you can't you know receive incoming connections things like that. um so like right now you do have to run a node in an environment that uh you know can provide all of those things. you also need to use an amd epic chip which is like kind of hard to get it home too. i mean it's it's not hard but like most people don't have it. um so yeah long-term goal yes we want to. you know i. i would love to get to a point where we have a hundred thousand a million lit notes. the architecture of the network will have to change a lot to the our to make that possible.

Nicholas: speaking of the roll-up why did you decide to do your own roll-up? why not just situate all this content on some other cheap i don't know l3 or something cost basically okay just because running a sequencer is not that expensive.

Chris Cassano: yeah it's also. it's also a little bit about sovereignty right like that's true like you know you you want you want the network to not have these. you want it to minimize the external dependencies basically.

Nicholas: and uh why did you choose the op stack?

David Sneider: the? that's where we started. i think we're we've you know at this stage with is the end of january 2024. we're in the midst of investigating a few alternatives frankly um around like some other l3 options um and we have like a lot of specific constraints around like specific cryptographic pre-compiles that are required.

Nicholas: uh so that's an open discussion for us right now around what that stack will ultimately end up as and it seems like a huge range of things that you're doing like very ambitious across serious cryptography you dao operation running a roll-up as well as all the developer tooling. that kind of makes it easy to consume for a developer. uh how many people are working at lit now and how do you manage to do so much?

David Sneider: yeah we're we're just under 20 and uh we just do one thing at a time. basically um yeah uh it's it's. it's a really great group really diverse group so many sharp people um and i think one of the things that uh has long been a tenant of uh Dais ES uh uh uh oh it costs a if serving the ecosystem. And one of the, I don't know, little fun things that we like to say is like from a developer who's going to start interacting with the system, like they're the ones that are out there building the applications, building the new protocols, like they're on their own hero's journey. They're Luke Skywalker. If we can be like Yoda and provide guidance and good tooling, here's how to use the lightsaber. That's kind of our job in the mix. So yeah, it's kind of a cliche startup-y answer, but just relentless focus and making sure that like what we're doing is for the person who we're serving ultimately. And so from that, people need a lot of stuff. It's a whole new type of thing. Like there's certain expectations around development and ease there and developer UX that there's a bar that we want to obviously meet and exceed.

Nicholas: Great. Are there any topics that we didn't cover that you think we should get to?

David Sneider: No, this has been amazing. I guess. Yeah. The only thing that I would add is like, we're super approachable. If people are like considering building something on on lit or just want to like brainstorm some ideas or all that kind of thing, we're always in discord. We've contact us for on the website. Like we just love this stuff.

Nicholas: Also popular at hackathons.

David Sneider: And hackathons are super fun. Yeah. And we're, we're, we're around.

Nicholas: Building on lit at hackathons. I've found, yeah.

Chris Cassano: I, I would add like, Oh yeah, this is probably going to be the same thing, which is come, come see us at eat Denver. We will be there with a, a cube. that glows. Um, so look for the, the cube. Um, and yeah, we got the website developer docs, uh, um, get lit.dev to, to get started with developer docs. Um, and yeah, what else? I don't know.

Nicholas: Yeah. Yeah. Twitter docs. Uh, what's the, uh, lit website URL.

David Sneider: protocall.com.

Nicholas: protocall.com. I'll put links to all that. That stuff in the show notes. Uh, David, Chris, thank you so much. This was a great conversation.

David Sneider: This has been so fun. Thank you so much. And thanks for everybody who tuned in.

Chris Cassano: Yeah. Thank you guys. Awesome.

Nicholas: Awesome. All right. Thanks everybody. See you next week. Hey, thanks for listening to this episode of web three galaxy brain. to keep up with everything web three, follow me on Twitter at Nicholas with four leading ends. You can find links to the topics discussed on today's episode in the show notes. podcast feed links are available at web three galaxy brain.com. Web three galaxy brain airs live. Most Friday afternoons at 5 PM. Eastern time, 2200 UTC on Twitter spaces. I look forward to seeing you there.