 Hi, everyone. I'm Gubsheep, and I work with a research-focused organization called Zero X Park. Today, I will be talking about this idea of ZKPs and programmable cryptography, which is a phrase that we use to describe a lot of what we focused on at Zero X Park. I'll describe what programmable cryptography means and why we think it's important for anyone who is interested in the future of next-generation blockchain and decentralized applications. First off, I'll give a little bit of context into what Zero X Park is for folks who have not heard about this organization. Zero X Park is a relatively new research-focused org which supports what we call application level R&D on Ethereum and other decentralized platforms. This means trying to better understand what is possible to do on these kinds of smart contract platforms or with new decentralized application technologies that isn't necessarily currently possible today, but might be on the horizon. Projects that we support include things like Dark Forest, as well as Persona Labs, building things like Hayunon, or if folks were around the applied ZK showcase yesterday, you might have seen proof of email or various ZK machine learning experiments. We also build circuit primitives for ZK Snarks and focus a lot on infrastructure maintenance and third-party development of tool stacks like Snark.js, Sercom, Halo 2, and more. And we also do a lot of community-building efforts, and we work on cross-team and ecosystem-wide projects as well. Cool. So, one of our largest areas of focus at Zero X Park is applied ZK cryptography, which means that a big focus for us is understanding what is possible to do with ZK crypto, what theoretically should be possible to do with ZK crypto and decentralized apps, and what we need to do to get there to eventually bring those kinds of tools to production. And applied ZK is one of a category of relatively newer cryptographic primitives that we categorize under this term programmable cryptography. And in order to describe or give a feeling for why programmable cryptography is important, first I want to go into a little bit about a couple of the reasons that we think that applied ZK is especially important. So there's two concrete reasons that I think are especially compelling in terms of why ZK is going to be powerful for unlocking the next generation of decentralized applications. And I'll just go through those real quick. So the first thing is that zero-knowledge cryptography gives us what I think of as an expressive language for claims. So what does that mean? We'll go through an example to get a sense for what an expressive language for claims looks like. Let's take the example of ZK Snarks and group membership proofs in the context of claims about digital identity. So the simplest kind of identity claim that we have from cryptography and something that we've known how to do for many decades is prove a statement like I know a private key corresponding to someone say Alice's public key, which implicitly identifies me as Alice. So this is something that I can do with a digital signature, something like RSA or ECDSA. The invention of public key cryptography made proofs like this possible or made provable statements like this possible. And this is infrastructure that underlies so many of the digital systems that we know and rely on today, including secure traffic on the internet as well as blockchain systems like Ethereum or Bitcoin. So going up one level in complexity from the previous slide, we have claims like I know a private key corresponding to one of the public keys in a group. So for example, I know a private key corresponding to one of Alice Bob or Charlie's public keys. So this kind of claim is commonly referred to in the literature as a group signature or a ring signature. We do have cryptographic protocols that are purpose built to enable people to generate group signatures or ring signatures, but they are, again, special purpose built for this kind of claim. And the math or like the cryptographic protocols that make these sorts of claims possible are oftentimes incompatible with the math used for ordinary signature schemes. So we figured out how to do these group signature schemes a few years after we figured out how to do digital signatures in general. However, it is the case that in order to make claims like these or in order to build up a system or a network in which people can make these claims, you have to bootstrap like an entirely new key registry, you have to build a different key generation algorithm and you have to popularize that. So, you know, the math involved in making a claim like this can be incompatible and require you to sort of move to an entirely different system than if you want to, you know, use systems that allow you to make claims like this. So one thing that I want to note is that today, however, we have another much easier way of enabling these kinds of claims. And a manner in which a way which is, you know, actually compatible with systems for proving the first kind of claim. So, with ZK Snarks, the problem of building a system that allows you to make these kinds of claims from a system that allows you to make these kinds of claims is actually a really simple essentially two line code change in a ZK circuit. So rather than having to invent an entirely new mathematical protocol or new key generation algorithm, if I have a primitive that allows me to prove in a ZK circuit that I possess a public key corresponding to some private secret, then what I can do is I can construct a ZK circuit that says I know some public key corresponding to some secret private key. I'm going to keep that public key secret and that public key minus hash one times public key minus hash two times public key minus hash three equals zero. So if I can prove all of this in zero knowledge, what I'm effectively proving is that I know a private key corresponding to one of these three public commitments, hash one, hash two, or hash three. So this way I now have this system which uses the exact same key generation algorithm or key generation strategy as a system that allows me to simply prove that I know the private key corresponding to Alice's public key. And we've turned essentially this problem of building group signatures from a math problem where we have to go to a cryptographer, they have to write us a paper, do all this stuff, bootstrap a new key registry into essentially a programming task that any developer familiar with, say, CERCOM can carry out. So slightly more complicated than this, we can go a level even further up and consider augmentations to this protocol such as I know a private key corresponding to one of Alice, Bob or Charlie's public keys and the other two either can or cannot prove that they did not generate this message. So sometimes this property is called by various different names, some call it like disavowal. So as an example, like suppose I'm Bob and I generate a signature that is either coming from, you know, you can see is coming from one of Alice, Bob or Charlie. So yeah, there's cryptographic systems that allow you to toggle this property on or off, but again, these use new math are incompatible with previous systems and are generally fairly difficult to engineer. Again, however, with DK Snarks, this is a pretty trivial like two-line circuit code change. So again, we're sort of seeing this idea of this length of the code and the circuit code change. So again, we're sort of seeing this idea of this language that allows us to build these expressive claims that are compatible with, you know, previous claims that other cryptographic systems will allow us to generate. And finally, we can get to claims, you know, of this level of complexity, something like I know a private key corresponding to one of Alice, Bob or Charlie's public keys and I either possess a signed attestation from one of David, Eve or Fred, one of these trusted, you know, attestation service providers, or during a block with header X, I knew the private key corresponding to an account with at least 32 ETH and, you know, you can kind of compose a bunch of arbitrary, you know, predicates on this identity claim. And I think it's pretty fair to say that there's like no cryptographer in the world who you could go to and ask them to build a special purpose new cryptographic tool that would allow you to prove this specific kind of claim, nor would it even make sense to. But again, with ZK Snarks, this actually becomes fairly trivial. You have your building blocks in ZK circuits for each of these things, you know, key pre-image, signature, recovery, proof of inclusion in the Ethereum, Miracle Patricia try, and then you can just put all these together, essentially calling all these like different functions in your ZK circuit code to start building out these claims. So another framing of this idea of the expressive language for claims is that ZK Snarks turn math problems into programming tasks. Rather than having to go to a cryptographer to write you a new paper, every single time you want a new kind of digital identity claim to exist in the world and be provable, you can just have a ZK circuit developer compose the right primitives inside ZK circuit code. OK, so cool thing number two, which is closely related to cool thing number one, is that ZK adds interoperability to cryptographic systems. So what does this mean? Well, to explain this first, I just want to do a quick breakdown between two terms, snark-friendly versus snark-compatible cryptographic primitives. Snark-friendly cryptographic primitives are, you know, primitives like hashing algorithms or digital signature schemes or encryption algorithms that are specifically purpose-built to be efficiently provable inside of ZK snark-proving systems. So, for example, the MIMC or Poseidon hash functions or EDDSA signatures, these cryptographic primitives oftentimes have been invented in the last couple of years. And, you know, the hope is that with these primitives, we can move towards a world where we can do more and more inside of Snarks. However, most of the cryptographic systems that exist in the world use cryptography that was invented before we knew about ZK Snarks. So, for example, a lot of hash functions use a lot of bitwise operations, which are very costly to do inside of ZK Snarks. And so these systems are not snark-friendly, but they are what we have to work with. So, for example, all the signatures on emails signed by mail servers that are being sent out are not going to be snark-friendly signatures. However, we can start to at least connect all of these different snark compatible systems together by embedding these different signature algorithms, hash functions, encryption seams, et cetera, inside of Snarks, even if it is costly. So, as an example of a few cryptosystems that exist out in the wild, we've got key distribution and identity registries, such as, like, you know, you can build an identity registry of, like, GPG keys. GitHub allows you to generate locally a key pair and upload it and make it publicly accessible to anyone so that anyone can verify, you know, your commit history or things like that, repos you've contributed to. So, for example, if you go to github.com slash gubcheap.keys, you'll see, like, my RSA keys, Ethereum and Bitcoin rely on the ECDSA signature scheme. So, addresses are going to be, you know, a hash of an ECDSA public key in Ethereum. And I think mail servers use the DKIM protocol to sign and authenticate messages which, under the hood, relies on RSA. So, one of the things that's going on with all these different signature schemes is that they kind of can't really talk to each other. You know, if you're running on the RSA protocol, you can't really understand an ECDSA signature. However, by making all of these primitives snark compatible by implementing RSA signature verification, ECDSA signature verification, et cetera, et cetera, inside of snarks, what we can start to do is we can start to build adapters between all these different systems. So, again, if I have an RSA primitive and an ECDSA primitive inside of a snark, then I can start to make claims like, either I have a GitHub account that's contributed to the, you know, Ethereum GitHub org, or I possess at least 100 ETH. And, again, by making existing cryptography snark compatible and combining that with this expressive language for claims, we can start to make statements about all sorts of digital or online activity. So, both of these features are examples of the power of programmable cryptography, which probably, as you've rocked from now, you know, both of these features are giving us these tools to much more flexibly manipulate digital objects. So, now I'm going to kind of give my description of programmable cryptography, which is that it is a cryptography that can be layered on top of arbitrary computations. To contrast this with cryptography that we've been using for the last couple of decades, well, for most of cryptography's short history, the set of mechanisms that we've been able to instantiate with our tools has been, you know, quite narrow. So, we can say things like this message originated with Alice, as we've seen, or this message can only be read by Bob. But every single new mechanism that we want to build, whether it's like, you know, arbitrary identity predicates or read permissions or things like that, would require us to build a new special purpose cryptographic system. However, now we're seeing tools like, you know, ZK Snarks, as we've discussed, that allow us to move from this message originated from Alice to, I know, a private key corresponding to one of these people. I have an attestation from one of these service providers, et cetera, et cetera, to things like witness encryption. Witness encryption is a primitive that essentially allows you to encrypt data, not with, like, a key pair, where someone has to know a certain secret to decrypt a message, but it allows you to decrypt messages with, or sorry, encrypt messages with a program. So for example, I can encrypt a message with a Sudoku puzzle and anyone who solves the Sudoku puzzle will be able to generate a key to decrypt the message that I've encrypted with witness encryption. And this allows us to move from systems where we can do things like Charlie has published some secret vote that only a coordinator can read with the coordinator's private key to Charlie has committed to some secret vote that only attesters with a search and permission level can decrypt today, but which a class of auditors with a lower permission level can at least partially decrypt in exactly one week. I would say that smart contracts also spiritually kind of fall in the same category as a lot of these other programmable cryptography primitives. So imagine very early on in the history of this idea of blockchains, we would have these consensus engines where people could come to consensus on only very simple or specific data transformations. Data transformations like Bob can decrement Alice's balance by 100 ether to increment Alice's balance by 100 ether. Nowadays with smart contracts and programmable blockchains we can sort of execute arbitrary predicates at block B, 100 ether will be available for withdrawal by Bob, so long as Bob has closed his position in some smart contract and no one's submitted a fraud challenge, though an early withdrawal may be initiated if two of the following three solvency conditions are met, et cetera, et cetera. So in each of these examples, there's this common theme of moving from the specific to the general. With ZK Snarks, I can move from proofs of specific claims to a general purpose language of claims. Smart contracts allow us to move from coming to consensus on canonical data that can be modified in only very specific or narrow ways to a general purpose language for modifying or executing code on this canonical data. Witness encryption moves us from a world where we can permission data to only be read by a specific person or a specific set of people to having a language for specifying arbitrary predicates for read permissions. So I kind of imagine this as like decentralized OAuth tokens where anyone can plug into this global authentication system and specify who can read what and when. And there's all these new primitives that are continually getting better and better, more and more feasible. Things like fully homomorphic encryption, multi-party computation, even really far out things like indistinguishability, obfuscation, and more. Oh, and you know, there's a couple of folks who have sort of independently come up with this categorization or framework. I believe the SIRC team calls these computational cryptosystems, so very similar in general spirit to what we're calling programmable cryptography. Okay, so the second part of this basically thesis is that programmable cryptography itself seems like a very powerful tool. Blockchains are also a very powerful tool, but it's not sort of a priori obvious like why these two things are related to each other except that they both sort of derive from similar mathematical principles. But I claim that there's actually a very deep and complementary marriage between these two powerful things. And to explain why I think that is, first I want to give my kind of mental image of what Ethereum as a data availability layer looks like, say like five or 10 years out from now. So in my head, the way that I kind of conceptualize the idea of Ethereum, the global data availability layer is, I think of Ethereum almost as this like, giant super thick coaxial cable that basically streams humanities like global stream of consciousness. So humanities, promises, bets, secrets, dreams, et cetera, et cetera. And this coaxial cable is made available to any person or computing device in the world. So any phone, any computer that like lives on some like institutional server, anything like that can hook into the one gigabyte per second canonical data stream, look up data and know that they're seeing exactly the same thing as someone across the world is seeing. Now, right now, this data stream is completely transparent and that has been a design decision that has been necessary in order to gain acceptance of this particular data stream that we're wanting to claim is the canonical data stream or the legitimate data stream. So in order to build acceptance, we have this principle of don't trust, verify and in order to verify, you need to be able to see all of the data. But I claim that this is actually extremely limiting. There is a wide class of applications that you might care about to build where you don't want every piece of data to be completely public. And I think that when a lot of people talk about this idea of privacy or information asymmetry, people have various different beliefs on various ideological nuances around privacy. But I wanna go even a level lower to explain why I think this is important. Privacy is important not just as a matter of ideology but simply as a matter of mechanics. There's certain coordination systems that just don't work unless you have information asymmetry. And in fact, most of the complex systems that we see in the world today and most of the organizations we have in the world rely on the idea that different people know different stuff and can do different stuff. So the way that I think about this is that what we would really like to do is we'd like to be able to enforce read, write, execute permissions on this canonical data stream that is the blockchain. And the way that we do this is, in fact, programmable cryptography. Programmable cryptography gives us these expressive tools and languages for enforcing read permissions, like we mentioned with things like witness encryption, or write or execute permissions, which we're seeing with things like DK Snarks and smart contracts and more. So to give just a toy example of why this kind of permissioning or access control is really important, I wanna consider the example of games. So, for example, let's consider poker. In poker, a lot of the depth of the game relies on the fact that I know my cards, but I don't know your cards, and you know your cards, but you don't know my cards. Poker as a game would simply not work if we knew each other's cards. It would be completely degenerate, right? Like, it wouldn't really make sense, it wouldn't be any fun. And a slightly more complex example of this might be strategy games. So a couple of days ago, we had a talk on Dark Forest, which is a fully on-chain strategy game. You can kind of imagine it as something like Starcraft on the blockchain. And one really key mechanic of Dark Forest is that in Dark Forest, players' respective locations are all hidden, which gives the game a lot of its relative strategic depth. So the general pattern here with games is that oftentimes what we're gonna do is we're going to have players commit to a state that they keep private, and whenever they want to make a state transition, they're going to provide a zero-knowledge proof that they are making a valid update on their private state and committing a valid state commitment to the network. So this proof might prove something like, I'm moving my secret knight from secret location, A to secret location, B. I'm not gonna tell you what A or B are, but the zero-knowledge proof proves that there's an L shape between them. Or zero-knowledge proof might prove something like, I'm drawing some card, I'm drawing it validly according to the rules, I'm drawing it out of a randomly shuffled deck, I'm not cheating and just like continually drawing a bunch of aces. So there's a bunch of game examples, which we can kind of imagine where the game just simply does not work if all of the information is transparent. And while those are kind of toy examples, I think they allow us to start to hint at this more complex future where we're using blockchains for a much wider range of use cases. So I think one completely reasonable digital and interaction we might expect to see something like in the future is, you know, imagine like I walk into a store and perform a cryptographic handshake with the merchant and perform like a multi-party computation with some identity provider. After verifying the merchant's identity, I give the merchant one token that permissions them to access some specific data on my preferences for an hour. And another token that allows them to transfer a limited amount from my balance. After that transaction completes, I update my transaction history, that's private to me and committed on-chain, but only visible to myself. So, you know, each of the components of this interaction today are not possible due to the fact that there's so many things, there's so many constraints on what we can keep private. But again, with things like fully homomorphic encryption, witness encryption, ZK Snarks, et cetera, et cetera, these kinds of interactions may start to be unlocked while still preserving the neutrality where all this data is living on some, like globally verifiable blockchain or data availability system. So, the last kind of like analogy that I want to make here to kind of create an image of what this future might look like is, you know, I want to kind of describe the concept of an ender chest from the game Minecraft. So, Minecraft is a, you know, sandbox game in which you can harvest resources and build stuff. And in Minecraft there's this concept of chests. So, with a wooden chest, if I build a wooden chest, I can like place it down here. I can put items into the chest. If I leave and come back, the items are still gonna be there. The chest is a very important like primitive in Minecraft. If anyone else goes to the chest and they open it, they're gonna be able to see all the items that I've placed in there. In Minecraft there's also a very powerful tool called the ender chest, which is sort of similar to a chest but has these kind of magical property where ender chests inventories are marked as like per player inventories and are sort of shared across every ender chest that exists in the world. So, if I put an ender chest down here and put down like, you know, five stone or something and then I put an ender chest down over there and like I walk over there and open it, I'm gonna see that same five stone. And if someone else walks into the, walks over to the ender chest, they're not gonna see that same inventory that I have. They're only gonna see, you know, what they've put into the ender chest. The ender chest is an incredibly powerful tool for Minecraft players that allows them to execute on these larger scale strategies, build these much more complex constructions. Just makes it easier for you to do a lot of things. And I think as more of our social and economic activities move online, we're going to need primitives like these, these digital ender chests that allow us to carry things like our reputation, our financial history, our social context across different platforms. And in order to do that, we're going to need these new privacy preserving mechanisms that fall under this category of programmable cryptography. So that's all I've got for today. If you're interested in any of the work that we're currently working on around programmable cryptography or anything else, you can check us out at xeroxpark.org or you can find us on Twitter at xeroxpark. Thank you. Thank you for the talk. As we went through a lot of the slides, there were examples of ZK things where you have a claim and it's true or false and you prove it. But I guess the bigger picture of all programmable cryptography could have other sorts of statements like I summed all these numbers and this is the true sum. And so I guess those are other flavors and maybe that's homomorphic encryption, I'm not sure. How friendly are those with each other right now? Like proving things and doing math and getting continuous results. Yeah, this is a great question. So right now, as you've probably noticed we are specifically very focused on zero-knowledge cryptography which is one piece of this much broader category but it seems disproportionately represented. So why is that the case? Well, one reason is that zero-knowledge cryptosystems are simply much more mature today than a lot of these other systems where there only exist theoretical constructions or academic implementations. We expect things like witness encryption for example to be much further out and we're still even trying to describe the landscape of what is possible to do with multi-party computation. So unfortunately none of these systems are super compatible because a lot of them don't yet exist in a form where you can meaningfully start playing around with them but we hope that that is going to be evolving rapidly over the next couple of years. Hello, thank you very much for your talk. Have you made any kind of research around quantum cryptography, ZK? Yeah, so I think quantum cryptography is a slightly like orthogonal direction to what a lot of these tools are going to enable. Specifically, for example, like one way that we think about the interaction of quantum cryptography with these tools is considering which of these tools quantum or like which, for example, ZK algorithms or like FHE algorithms, we have our quantum resistance. In other words, once we have quantum computers, which of these algorithms might we be able to break? Now that's kind of a different thing, however, from necessarily the affordances of these tools. So for example, when I think about programmable cryptography, I usually think about it from the perspective of what these things can do for us rather than necessarily like what's the underlying algorithms and what are the computational models in which they might broken by or enabled by whether that's quantum or elliptic curves or large prime fields or things like that. Thank you for your talk. Can I ask you if I understand it correctly, the state currently in dark forest, you keep it locally and you just put the proofs on chain. That may not be ideal for the future. If you lose the state, you kind of lose the game. What are your thoughts on how to keep the state safe in other ways, either using a homomorphic in prescription or your general thoughts around it? Yeah, this is a great question. And I think like, as an extension of the debate that people have around the viability of everyone custodying their own keys, for example, on a blockchain. I think that there are a couple of things here that might be possible. One is like you mentioned, fully homomorphic encryption might allow us to store private state that is encrypted on cloud services, but still be able to retrieve that data and perform operations on it just like we would if it was local while still preserving the privacy of that data. That's pretty far out though. And in the meantime, I think the most immediate thing that we can focus on doing is building more user friendly solutions that allow you to keep critical or sensitive data on your own machine. I mean, everybody already does keep critical and sensitive data. So it's a question of like, as the volume of that data or as the sensitivity of that data grows, then how can we make those systems even more and more ergonomic and more and more secure? Hi, thanks for the talk. What do you think about the fundamental bottleneck of like ZKPs being quite slow and you have this trade off between like proof generation and verification? Do you think we will have sort of more like external off-ramp solutions, maybe like layer two is for ZK, or like do you see the most promising solutions being in like fundamental ZKP research? Like what do you think of that whole straight off? Yeah, so personally, I think that there's still a ton of low hanging fruit in terms of performance optimization for these currently very expensive crypto systems. For example, with ZK by some metrics over the last three years, over the last four years, the size of circuit or like the size of computation that you can ZK prove in browser efficiently has expanded by like three orders of magnitude. And we're still seeing like rapid improvements via new protocols, new better engineered libraries for proving stacks, more efficient circuit implementations and things like ZK friendly hardware are just getting started. So I think that like, well, eventually there may be some industry of services that arises around, you know, offloading computation or things like that. At the moment, there are still a lot of optimizations that have not yet been fully, you know, explored that I think can enable some really, really complex proofs even on like small client devices like mobile phones. Is there any other questions? Thank you.