ZK Application Design Patterns | Devcon Bogotá

Our talk was originally ZK application design patterns, but Ye and I got together and started talking and we realized a lot of what we really wanted to talk about was like what is the landscape of ZK applications. Uh ZK or ZKP or SNARK is quickly becoming like a big data-esque buzzword and very jargony. It's starting to mean a lot of different things. Um and so we're hoping in this talk to sort of like talk through some of the different application classes we're seeing emerging emerging today. And in in in the process sort of like plot what we think the next 6 months to 1 year of like new ideas coming out look like.

Um and if the core thesis core thesis were stated in a single statement, it's basically um maybe unsurprisingly to many people who work in ZK that succinctness and privacy are are kind of like the two sort of features of ZK that are interesting. And understanding what succinct private succinct apps require and what private apps require like independent of one another might help us understand how like these two applications exist. As Lakshman mentioned, we really think of ZK as this matrix where your proof can be either succinct or not succinct and your proof can either be private or not private. So, we think that each of these quadrants is useful in a different type of application. So, in the top left, if you have a private proof that's not succinct, well, it's going to be hard to verify it on chain, but you can still use it in some off-chain applications.

In the bottom left, if you have a succinct proof that's not private, well, that's perfect for on-chain infrastructure applications, but not so good if you're trying to hide information. And of course, you can have the best of both worlds in the top right, where you have both succinctness and privacy. But as we'll talk about a bit later in the talk, that's extremely challenging to do. So we think that almost all applications right now fit into one of the left two quadrants. So just to talk through some of them, on the on the top left, we have more social type explorations of what you can do when you can hide information about what groups you belong to and what payments you want to make with partial revelation of information.

And the top left there are in the bottom left, there are a lot of projects surrounding making blockchains more scalable or giving additional capabilities to decentralized applications using the succinctness property, but where everything's public already, so we don't care too much about privacy. And finally, in the top right, there are a very small number of applications that have managed to both achieve succinctness and privacy and you're probably I probably everyone is familiar with those shown. Okay, so we're now going to give an overview of where we are today on each of these factors, succinctness and privacy. So in the bottom left corner, if we ask for succinctness but not privacy, the general theme is that zkps are used to scale trustless off-chain compute. And the theoretical principle behind this is that if you run code on Ethereum today, every Ethereum full node has to rerun that code to validate that the execution of your transaction was correct.

So that's about 100k at times overhead and it has very high duplication. The new capability that succinct proofs give us is that only one party needs to execute the transaction and generate a validity proof of that transaction. Everyone else simply needs to validate that proof. So this removes the duplication, but just incurs a very high overhead on the prover. And so examples of applications that use this pattern today are all of the ZK rollups, as well as the sort of app specific rollups like DYDX or Loopring.

So another capability that we see ZK succinct proofs bringing is cryptographic interoperability. So one thing that ZK allows you to do is to take anything from the grab bag of crypto cryptographic primitives on the left and allow you to wrap it in a uniform format, namely a ZK snark. So while each of these primitives is useful for a different thing, um they are designed in a somewhat single-purpose way. And that makes it very difficult to aggregate or compose these things. So ZK provides an interoperability layer that turns all of these into a snark proof that is arbitrarily composable using recursion.

And while that snark proof adds some overhead, it makes this open interoperability possible. Okay, so let's talk about now what's necessary today to make this happen. The first thing is that because we're only asking for a succinct proof, we can really scale the prover. In particular, we can first not prove in the browser, we can prove on the user's bare metal CPU. So that gives us a really high 5 to 10x improvement.

Secondly, we can outsource the prover to the cloud. So we can send the user can send a request for a snark proof of something that's already going to be public, and then the cloud-based server can run a big large AWS instance. It can run a GPU, it can run an FPGA, or eventually an ASIC. And that can give another 5 to 10x speedup in the proving time. And finally, I wanted to talk about the last constraint when you use succinctness on chain.

And this is a pretty heavy one, which is that you have to verify all of your zero-knowledge proofs on chain. And in this case, the gas cost of verification really differs from the CPU cost. It's going to depend on the proving system you used, the choice of curve for that proving system, and also some proving system specific implementation choices. The most restrictive of these is the choice of curve. So, on Ethereum, there are precompiles for the BN254 elliptic curve, and those operations are much cheaper.

Unfortunately, other curves are somewhat prohibitive to do directly in EVM, hence the need for a precompile in the first place. One way that is commonly used right now to get around this, for example in the ZK EVM, um is the operation known as aggregation. The strategy here is that if you want to use a SNARK, a very big one, that's not natively compatible for EVM verification, you first generate your SNARK A, and then you produce a recursive SNARK B, which proves the claim that you know a large SNARK A that proves the statement you claimed. In this case, you can choose B to come from a different proving system than your original SNARK. And that proving system could be very cheap to verify on Ethereum.

In this way, you can sort of transmute a very large SNARK from an arbitrary proving system to an on-chain verifiable SNARK from something that's compatible with Ethereum. The only caveat here is that you of course incur the overhead of this recursive proof. Cool. Thanks, E. Um Yeah, now I'll talk about the the other kind of interesting cluster we're seeing in the top left, which is uh application classes that seem to require privacy or pseudonymity of some sort, but don't necessarily require six sickness.

Um This is kind of like a more nascent uh ecosystem of things. Um Many of them don't require chains, and so uh I think relative to maybe a lot of the things that you talked about, they're perhaps less familiar to the average Ethereum conference attendee. Um, but what we're seeing is that they seem to they seem to cluster around social type things. Um, this doesn't mean that this is all it is in the future, but kind of want to talk about what what we're seeing today. Um, and so in thinking about this quadrant, I spend a lot of time thinking about sort of this spectrum.

Um, there's a spectrum So, let's say think about those arrows are zero knowledge proofs being made. The computers are like say like an end user computer. Ethereum there obviously is a uh, decentralized state machine with a highish block or a low lowish relative to congestion block gas limit. Those those bottom two icons are sort of uh, how proofs are being consumed and the top two icons are how proofs are being produced. It feels like there's a spectrum of applications in how we think about what is consumed.

Is it being consumed by a human? Is it being consumed by a state machine or a decentralized state machine? Um, if it's being consumed by a decentralized state machine like Ethereum, hence like on-chain verification, uh, you need things to be considerably more succinct. If it's being interpreted by a human, maybe you don't. Uh, maybe it can be like a much larger piece of information that is like human interpretable or has like some kind of like interesting graphical representation.

And so in thinking about this spectrum, and again, this is this is not including a lot of things in the middle. So, things in the middle might be things like uh, like being consumed by like an app chain or a layer two or a a a lower congestion layer one or a short-lived chain or something like that. But these two ends of the spectrum, um, I think we all quite understand like the chain side of applications. Like things that that use zero knowledge proofs that are that require succinctness tend to benefit from being very composable, creating things that are canonical. On the other hand, if we're talking about like humans interpreting proofs, it feels like it's the applications want to be higher velocity or can benefit from being higher velocity because you don't need a chain verifying every proof.

Things are more ephemeral. Maybe, you know, humans don't necessarily have like persistent memory themselves, right? Like we we see a lot of things on Twitter and sort of like form a vague understanding of what's going on. Um another mental model I think about is um ZKPs on the on the on the privacy not system side is uh like ZKPs sort of creating a new content type, which is like all these places where people create content online today, um what if they now were enriched with a ZKP of some sort? It kind of means something a little bit different, which which which is quite cool.

Um and so I didn't really talk about I realized I probably should have had a slide here presenting some applications, but um some examples are uh like um actually, let me just pull back go back to the the slide. So Semaphore, which is a project of the PSE, uh which is kind of group uh group membership in like proving private group membership, so you can prove that you are one of the people in a group. And so you can use this to do like private like uh pseudonymous message board or something like this. Um things like ZK email, like proving that you know, mail servers, turns out many of them uh like sign uh sign the email body. So, uh you can you can do a zero-knowledge proof that you received an email with certain properties or something like that, which is kind of cool.

And and these things like it's not obvious that that zero-knowledge proof in either of these cases needs to be interpreted by a chain. Um and so the requirements in this quadrant are quite a bit different um than and then the the quadrant E was talking about in that like verification complexity doesn't matter as much. Verification complexity matters as succinctness because um or matters when you're verifying on chain because you don't want the chain to have to spend a lot of gas to verify your proof. But if a human's verifying it like whatever, right? Like it can be done somewhere else like off chain and or like you know, it can use like some like even consumer hardware is more powerful than a chain.

Proving complexity tends to matter a lot more cuz we are operating usually on a consumer device for proving. So, consumer device proving friendliness as well. This is something we think about a lot is how do we make things work in a web browser? How do we make things work in a mobile device? Another piece is you know, like given that we care about privacy in this quadrant is respect for sensitive user information.

So, if anyone was around for um Aayush's talk earlier today where where he's sort of been developing this new deterministic nullifier scheme. That came from realizing that we just couldn't do a lot of things with private key in in a in a client device cuz it would we we would need to pass this very sensitive piece of information around different parts of application memory. And so, we have to think of new kind of like mechanisms for not having to do that. Oh, this is still me. Oh, cool.

All right. So, some of the some of the some of the challenges that we see technical technical challenges in the next 6 months. So, as I mentioned earlier like we need to be very friendly on like for for privacy not succinct applications in in resource constrained environments like mobile devices like like uh web browsers. I think a lot of like um a lot of the ZK space is assuming that most ZK proofs will be produced on like very large servers or with FPGAs or with GPUs and you know, there's some like debate around which of those two things wins, of course. Um but if users are making proofs to other or humans are making you proofs to other humans, uh we perhaps can't quite make that assumption.

So, we spend a lot of time thinking about performance in research oriented environments. Um I So, specifically like you know, the specific example that I gave earlier earlier with Ayush, uh we need to think a lot about um non-private key nullifiers, like non-private key uniqueness uh of identity um because we don't want to have to deal with private key. We don't want to have to create like an environment or a platform or anything where we we assume private key is passed from app to app. And then we also spend a lot of time thinking about um representing more crypto systems where identity matters um in SNARKs. So, you know, Ethereum we all interact with Ethereum and it's quite obvious there's a lot of interesting things you can say about Ethereum stuff, but there are other net like networks in the world where uh you know, cryptographic signatures are made like like email mail servers like I mentioned earlier.

So, um we're constantly looking around to understand where new networks are forming and how to like put those operations inside SNARKs. So, Lock 1 spoke a bit about some of the challenges ahead for privacy and a lot of that was dominated by finding new ways to improve the user experience and find applications. I think on the sickness side, uh the split is the other way where what you want to build is somewhat more clear, but you need to have good enough performance to actually build it. So, in that sense, what what I view the challenge ahead as really optimizing the performance of our proving systems and our architectures. So, one direction is to really weaponize this operation of aggregation and recursion that I mentioned earlier.

And the reason here is that if you want a very rich infrastructure application, you need to prove for a much larger circuit than is even possible than the large in the largest circuits today. And so, there are a couple ideas here that are only beginning to be exploited by projects right now. One is to maximize what's called a prover-verifier trade-off. There's a fundamental trade-off between the proving time and the complexity of verifying a proof. If you feed in more compute, you can get an easier to verify proof.

Um so, we can do things like starting with a very fast-to-prove uh system and then wrapping it in an aggregation layer with which transforms it to a cheaper-to-verify system. One form of that is already in use with basic aggregation, but we can push it much further using multiple aggregation layers. And the things here to really optimize are non-native arithmetic and elliptic curve operations for these SNARK-based systems. And a second direction is that even if we really optimize aggregation, it's likely that the most interesting operation uh statements to make are going to require multiple circuits to prove. And so, in this schema, you divide up a large computation with um into multiple pieces, and then you verify each piece in a SNARK, and then you verify those SNARKs recursively.

So, with the ZK-EVM and other ZK roll-up VMs, we're seeing the beginnings of building virtual machines in this way. And I think that uh VMs for transaction execution are just the beginning of this trend. In a separate direction, um in the last 5 years, a lot of the progress in ZK has been driven by the emergence of many new types of proof systems that really pushed the envelope on what we can do inside a ZK circuit. So, just in as recently as 2016, really the uh most viable ZK proof system we had access to was Groth16. But since then, we've added many capabilities like custom gates, look-up arguments, and we've been able to remove some aspects of the trusted setup in newer systems like Plonk, Halo 2, and in STARKs.

Um in the landscape today, there are actually a number of new primitives emerging which may be equally or more exciting. Um, so systems like Nova allow for much more efficient accumulation. Uh, some check-based systems like GKR or Hyperplonk allow for fast and faster, uh, but larger proofs which could get then be recursively aggregated in other proof systems that we already control very well. And finally, there's the potential for much more efficient lookups in new systems such as Caulk. And so each of these represent a pretty big shift in the way that we can design ZK circuits and what type of programs we can express efficiently in them.

And so it'll be exciting to see how fast these things can come to production and what new applications they can enable. Oh, yeah. Um, and so so finally um, and to talk a little bit about where we see kind of these two things converging in the third quadrant. Um, this is probably what the future will look like in the sense that so so that the left side is the kind of uh, privacy side and the right side is sort of the succinct proving side. And the idea being that hopefully we reduce the surface area of the private to public-ish proof to something quite small that can then be recursively included in a larger proof uh, that is that you know, that that is in the kind of like succinct but not private uh, kind of like um, technological requirement land and then that is interpreted on chain and then this is where we get all you know, all of the nice benefits of privacy and succinctness and on chain applications with pseudonymity and cool stuff like that.

Um, yeah, that's it. Sorry, maybe a silly question for the audience, but um, can you explain a bit more like what actually succinct means? Like what's that property um, you know, in the in the layman lay layman lay layman's terms? Yeah. Yes, so succinctness is a property of knowledge proofs which says that the size of the proof can be asymptotically smaller than the size of the computation you're able to do.

So, depending on the proof system, either the size of the proof could be constant size in the size of the computation or it could be logarithmic. But either way, the point is that you can verify this proof in much less compute than doing the actual computation itself. Hey, and perhaps there's another distinct slight thing which is many many of many I mean most of these proof systems do have constant proof sizes but also like the the lower the lower the constant proof size the better for something that is interpreted on chain obviously. But yeah, his answer is better than mine would have been. I was just going to say small.

Hey, so when when we recursively prove stuff, so over here, sorry. When we recursively prove so there is a proof and then you are proving the proof, right? So, there are multiple layers of integrity checks, right? That that is the assurance that you get. So, and these circuits are super complex and there could be like million arithmetic operations in in there, right?

So, what about the security of these proofs because if you have a single bug in a circuit, right? That is going to traverse down to like this very small proof that you will post on chain. So, what are your thoughts about that? How are how is the security landscape around verifying CK systems? Glad to hear thoughts.

Yeah, definitely. I would say on the succinctness side, definitely recursion and aggregation make it substantially more difficult to verify that your circuits are correct. So, we have obviously traditional unit testing, we have randomized fuzzing, and we have some emerging formal verification approaches for ensuring circuits are correct. Where recursion make these more complicated is that you may need to encode assumptions slightly external to your circuit itself to check things. I'm sure Lakshman has some views on how that affects privacy as well.

Uh I mean like I I think this is actually something we need to think about very seriously. It feels like I mean if any of you are familiar with like supply chain attacks in the node.js ecosystem, um it feels like we could easily that that is like I don't want to get too pessimistic, but that is like a very bad worst case here because it's like it's very hard for the the recursing proof to make strong assumptions around the soundness of like proof that it is recursing on. Um I don't have any optimistic takes, unfortunately, but I think it's something we need to think about. There are lots of great people, like especially in the zero-x ecosystem, kind of thinking a lot about about like formal verification and things like this.

And maybe like yeah, there's formal verification of the dependency graph type things needs to needs to start happening. I I don't know. Hello. What measures can we take to make our proofs quantum resistance for the long term? So I think of the different proof systems, most of the ones which are based on elliptic curve cryptography are not going to be quantum resistant since they will require at least a discrete log assumption.

We actually do already know proof systems which are quantum resistant, like STARKs, which only require a random oracle hash assumption. Um so if you want something to be really standing the test of time, you probably want to use one of those quantum resistant systems. Um I just want to add to the succinctness part. There's a difference between space succinctness and time succinctness. Um I usually succinctness will mean like both.

Um and a question on Caulk. Um what do you mean by Caulk being more efficient than um you know, using a look up. So from what it seems to me that it can actually be applied to like look up arguments in circuits or in the Merkle tree setting where you want to have, you know, um zero knowledge membership proofs. Because that the there's a con- like there's a linear overhead when maintaining this, you know, pre-processed proofs. Yeah, that definitely.

Like I would say we're being a bit sloppy with the use of succinctness here. In most of the systems that are deployed today, you get both verifier and size succinctness. With regards to Caulk, I'm more trying to gesture towards the idea that there are people working on enabling lookup arguments to be more efficient, and that that would really transform how we write these circuits. I totally agree that they're not Caulk is not like today going to enable much more efficient lookups. Well, the music is coming.

I guess we are coming to an end. Uh thank you so much. Big round of applause to Lakshman and Yee.