Nico Mohnblatt @ ZK Hack Meetup in NYC, Aug 2025

Transcript

[Music] All right. Hi. Um, >> last talk of the day and then we can chill. I'll be talking about the state-of-the-art of ZK in 2025. Uh, this is a talk I've given a month ago in Berlin at Zub Berlin. So I'm sorry if you attended that otherwise let's discover it is quite technical and it is sort of aimed at people who do already know what a proof system is. Um if you're panicked very early on please let me know and maybe I'll yeah um I can do a little introduction.

Cool. Yeah actually I didn't even change the date. I'm sorry about that. All right. Uh just to start a few confusing acronyms that we love to use. We have ZK. We have snark and we have snark. Um people like to say zk to mean any cryptographic proof. Uh they like to say snark for most proof systems. Um usually those that use elliptic curves. Um and they like to say stark for proof systems that use hash functions or specifically stuff being used by starkware. In academia we use the same words for different meanings. Uh we say zk for something that has zero knowledge. So that has some kind of privacy property.

We say snark for anything that is succinct. So a small proof and non-interactive. So just I send your proof, you verify it. Uh this includes the hashbased stuff that Starkware does. Uh and other companies. We say stark for system that is scalable, that's the S, and transparent, that's the T. Um scalable is a variant of succinct. Doesn't really matter. I'm actually going to stick to ZK and Snark. But do know that's this is what I mean when I say zk and this is what I mean when I say snark and don't think that I'm excluding the hashbased stuff. Cool. So with that out of the way, we've moved on to the state of the art of snarks uh in 2025 and the best one is it depends obviously. Um and kind of the

rest of this talk is going to be about uh a dive into all the different things we can tinker with. what what are all the differences? What's the trade-off space? Um and how do we think about it and what's the latest and greatest? So, we start with where are snarks deployed. Um ZKV, ZK validator has this map of ZK um which I really recommend you to go and check out. Uh it sort of lists all the projects that use ZK in the sense of like non-academic sense. This is the one time I'll use DK in in the second column sense. Um, you've seen Alo and Reclaim talk about how they use it. There's

plenty more teams. Some highlights that I've cared about this year. Um, on the left we have a table that comes from ETH proofs which is this website and initiative about proving Ethereum blocks. Um, this table shows sort of all the proof systems. It's actually out of date. This is from a few months ago. The other one is Google who recently used um zero knowledge proofs actually zero knowledge in Google wallet and I'll get back to that in a sec. The next question is how are snarks deployed? You have as a developer many ways to like write snarks and develop them and deploy them.

Um and the first thing we notice is actually we're mostly using what we call general purpose snarks. These are proof systems for any computation. Even if maybe you're just proving one specific type of computation, you could design a snark for a custom relation if you know that you're just going to use a custom relation. Um, right now no one does this. We kind of stick to the general one and then narrow it down at a different layer of the stack. The next question is, all right, if we're going to do something general purpose, how do we specify the computation? we have these circuits and the question is what kind of circuits are we going to use and so we have we have this spectrum here on the right hand side you have a custom circuit so this is really just implements your

business logic and that's it and you can prove your business logic on the other end of of the spectrum you have a circuit that is fully general it is a CPU it's a VM it does you can give it a program and it'll execute that program it's the circuit is fixed but it executes whatever program you want and you have inbetweens And the in-betweens are sort of where most interesting things happen. You could do a VM, so a general purpose circuit uh with pre-ompile. So these are smaller subcircuits that do exactly operations that you do often. You could also have a custom circuit, but that's not just business logic, let's say, but maybe it's a little machine. It's a little state machine that you can um I guess iterate through. Um, and ETH

proofs operates like the table I showed you earlier. Things are usually in the ZKVN side. Um, Google actually used a custom circuit because they know they were going to prove things specifically related to IDs and that's all they need. Cool. Zooming into the ZKVMs, what kind of machine are we building? Like what CPU are we replicating? Um, so I'm bringing back this ETH proofs thing. Um it's quite small maybe for you guys in the audience but that second column shows what instruction set is being implemented. Uh maybe the color coding you can see from a distance you'll see a lot of blue that's risk five. Um and there's actually a call about like ETH

groups are hosting a call at the end of next week about why risk 5 and should we stick to it. Um if you're interested I recommend attending. Um, why risk 5 in brief? People have been using it because it's open source. It have very has very few instructions and that's kind of what risk zero did and everyone stuck to that. Cool. If you're writing a circuit, how do you write circuits? Uh, we describe circuits in like specific language DSLs. Um, historically people have been using circum a lot and you can see this like I counted the number of repos that use circom and that's quite high. Uh recently Aztec for example used this language called Noir. Alio have Leo. You

might have heard of it earlier today. Uh Leo is actually quite hard to search for on GitHub because you have um like Leonardo stuff which is related to Arduino. Um so it's a lot harder and this is why here I'm just showing Circom and Noir, but there is a repo that quantifies this for all DSLs including Leo. Anyway, back to the point. Circom is historically the one we use the most. If you look at recent repos, you can see, for example, noir overtaking Ciron. Um, like I said, there are many more DSLs. They're hard to search for. Uh, there's Halo to Nark, Arcworks, SnarkyJS, Kairo, Leo. Um, and there's this is the repo down here.

Cool. Now, the next question is, all right, we have we've chosen our proof system. We've expressed our computation either as a ZKVM and then a program or as a circuit. Who writes proofs like who does the work of proving something? So you could do this client side on a mobile phone on a laptop in a browser. Um you could delegate this privately and there are many ways of doing this. You could delegate it to a single server not privately but it's just one person or you could delegate to a proven market and then it's all the way out there. And all these solutions draw the sort of trade-off between how private your proving is and how

quick your proving is. So I have uh the vertical axis here is privacy with full privacy at the top and the horizontal axis is proving speed with like fast proving all the way to the right. And so we can also already draw the extremes where if you're proving on a client device, you are fully private. But that's probably the slowest solution we have. Or if you're delegating to like a pro public prover market and there's competition to make sure that whoever's the fastest, you know, gets your proof. Uh that's going to be the most like the fastest but also like completely public.

The in-betweens are these other things I described where you could dug it to a single server. So you are revealing your information but not to everyone in the world. maybe to just one person and maybe you trust them, maybe it's a friend. Um, maybe it's not private. Maybe you're sending it to someone untrusted and then there's no privacy. The other in between is proof delegation with privacy and then there are also varying levels of privacy. You could have privacy via hardware using tees. How much you trust them, I don't know, maybe that puts the privacy like a bit lower than something else. Uh, you could use MPC or threshold threshold cryptography. Then you have an honest majority assumption also somewhere between fully private and not fully private. Um, you could have FHE, I don't know, more cryptography, who

knows? So, that's it for the privacy and speed tradeoff. And now the final question is what actual proof system do we use? And this is going to get also super technical. So, I apologize in advance for those who um maybe are less familiar with the Snark design space. The criteria that we care about when we choose a snark, when we choose our proving system, is how much prover resources I'm am I going to have to expend. How much verifier resources am I going to have to expend? How big is my proof? So that's kind of network resources as well. And then what's the security model?

And with those four things in mind, we can explore the current design space and the current like levers that we like to move up and down. One of them is do we want to use hash functions our as our cryptography or do we want to use elliptic curves or latises. Another one is do we want to use a monolithic snark or a peacemeal snark and I'll explain in a bit what those mean. Um if you're familiar with the idea of like recursive snarks or proving that I know a proof that falls under that category. Next question is are you going to use univar variants or multivaried polinomials and if you've looked into the anatomy of a snark this might ring a bell if you haven't it doesn't and that's all right next question is like how do we

represent our problems in our circuits what is the arithmetization um and what are their commitment costs those things are very linked are you going to use standard hash functions sha ketch the things we know or are you going to use something hash friendly like poseon on like all this newer stuff. Snark friendly just means it's easier to prove that I've applied this hash correctly. Are you actually going to implement zero knowledge? You have a you call it ZK, but does it have zero knowledge? What kind of fields are you going to use? Um what kind of codes are you going to use if you're using hashbased nars and codes? And finally, how are you proving your stuff? Are you using math

that we know we've known forever? math that is super recent or math that we're presuming is going to be proven in the future. There's a lot lot lot more, but these are in my opinion the ones we're thinking about the most in 2024 2025. So what I wanted to do for the rest of this talk is sort of go over these and explain what we've been doing so far and what the proof systems that we see in ETH proofs and in libk decided to do with all these choices. Um, how much time do I have? How are we doing?

>> Another 20 seconds. >> Wow, plenty of time. Okay, so quick evaluations. These are maybe the topics where don't I don't really want to spend as much time. Uh, the first one is what kind of hash function are you going to use. Um, it's very quick here to see that something snark friendly is going to be more prover efficient. It's going to be great for your prover. It doesn't really affect the proof size or the verifier time. Um but the security assumption is a bit weirder. Sha ketchuk have been around forever. They've protected important assets. People wanting to get access like to access these assets have tried to break sh and catch. In the case of more recent hash

functions uncertain. Um so prover plus security minus similar thing for security. if you're using well-known math, you're using pro proven security. Um, but you'll have worse everything pretty much. Whereas, if you use conjectured security, you'll have a better prover, a better proof size, a better verifier, but you're relying on conjectures. We do not have the math today to know for sure that this is secure. We assume it will be. We don't know for sure. Uh, last but not least in these quick evals, um, if you're using linear time codes as opposed to codes that take, I don't know, n login time to compute,

uh, you're supposed to have a better prover, but we'll see that might not be the case, especially if you're using this peace meal snark technique. Um, you will definitely have a worse proof size and a worse verifier. Is it worth it? Right now in 2025, we're saying no. Um maybe we'll find linear time codes are you know an elusive object. Uh maybe we'll find better ones in the years to come. That's it for the quick evals and now I want to look at what was remaining there. Uh and one of the big elephants in the room especially these past six 12 maybe 18 months has been what cryptographic assumptions are we going to use hash functions curves or latises.

So let me bring up again our criteria from before and let's look at hash functions first. Uh for prover resources it's very fast compared to the other two. Uh you're doing operations that our computers are literally built to do like the hardware has circuits specifically for that. Verify resources also fast. You're just dealing with hash functions. Proof size is okay. It's not the best and actually of the three is the worst but we can get to pretty small things. the security model here. You have postquantum security if you tune your parameters correctly.

Um and this is why I have like we have proven security only in the random oracle model which is something we cryptographers like to invent. Um it is not the real world, right? We don't have proven security in the real world for these things. However, the difference between the random oracle model and the real world is quite small and I don't think we've seen it exploited anywhere. For what it's worth, things like um schnore signatures uh EDSA also rely on random oracles. Next up, we have elliptic curves prover resources. Okay. And of the three, the slowest. Um why? because we are building these elliptic curves and these are you know bigger objects than just like hey

here's a bit let me hash that bit um verify resources pretty fast actually because even though we're doing elliptic curve of operations we're doing very few of them much fewer than hash operations happen in hashland proof sizes are tiny literally tiny uh it's like a few bytes few hundreds of bytes uh to this day we cannot beat the proofs that come from elliptic curves This is also why we've been using graph 16 so much because they are tiny and they're easy to post on chain security model. We are pre-quantum in this case.

Quantum computers break these things. Um the proven security usually relies on a bunch of assumptions including the random model that we saw before. Discrete log. This is why it's not quantum secure. Uh and then we also need like weird assumptions about like did I know something when I committed to it? Um I mean in general we've been willing to accept all of these. Last but not least and this is maybe the newest one and the most interesting one is using latises. The prover resources is actually quite fast. Uh you're not using elliptic curves. You are dealing with more than just bits but still like our hardware is pretty good at doing this. verifier resources. I have it as to be determined um simply because there is a lot of work coming out and even

within the past three months there have been newer works making verifiers of lattice based hash fun uh lattice based snarks a lot faster. Proof sizes are small they're not as tiny as like elliptic curves but they can be smaller than the hashbased stuff. um security model same as for hash functions plus we need to assume that latises are hard to break um in my opinion super promising but there's a lot of exploration to be done the elephant in the room is quantum threats right do we really need postquantum security um so what I have here is like no unknowns we do not know

when we'll have quantum computers or if we'll ever have them what we do know is for our snarks a quantum computer will only break soundness. That is once you have a quantum computer you can make fake proofs. What you cannot do is see old proofs and see what was in it. You cannot break the privacy property of zero knowledge proofs. Right? So in other words whereas with encryption you have this attack that we call harvest now decrypt later like I'll take your cipher text and later when I have a quantum computer see what you wrote. We cannot we don't have this problem with zero knowledge proofs.

Um there's another thing that we do know is like our blockchains use elliptic curve signatures. So great you're gonna have snarks that don't you know won't break under quantum computers but the rest of your blockchain breaks down. So maybe it's it's sort of like it's not our priority. Um and the final thing is a lot of uh the internet and a lot of um sort of core infrastructures to humans and society still rely on things like RSA. Um so do we need to change our proofs just yet? I don't know for you to ponder.

Cool. Next category monolithic snark versus peacemeal snarks. Firstly, let me explain what I mean. A monolithic snark is, hey, here's a statement. I prove it. I get a proof. A peacemeal snark looks like this. Here's a statement. I'm going to break it up into a bunch of small statements. I'm going to prove each of them individually, and then I'm going to aggregate them into just one proof. Why is that nice? Uh, you can parallelize. Once I've done the splitting, I can dedicate one machine to each of the substatements. Or you could do things in a streaming fashion. If I'm in a low memory environment, once I've done the splitting, I can do the proving on something small and then do the proving on something else that's small and keep moving.

This is why earlier when I was talking about linear time codes, I was saying, well, maybe they don't gain anything because if we're using problems that are small, maybe n login is fine and we don't need something that's linear. um this language of calling it peace meal rather than saying like recursion or folding or aggregation comes from Dandon and I think it's a nice way to really um capture the idea that it doesn't matter what technique you're using what matters is this idea of splitting a statement and proving all the small ones so then for our evaluation oh sorry this is just what I mentioned um how do we do this with recursion like proving a snark inside a snark because here for example

aggregating what is the statement? Well, the statement is I have all these proofs and they're all valid and that's how you aggregate them. Um, evaluations a monolithic snark is very simple to analyze in terms of security and that's what all our papers are about. It's like, hey, here's a snark and it's secure. End of paper. With a peacemark, there's a bit more to think about. Um but the nice things is you can treat sub uh substatements in parallel or in streaming fashion. Uh the statements each individually require fewer resources.

And the problem is security analysis is a bit harder. Um especially when we're doing a proof of a proof, our security gets super weird there. Um and I won't get into the details. I'm happy to take questions or explain this a bit more uh afterwards. So overall using peacemail is better for your prover slightly worse for your security just because we haven't put in the work yet to know that it's same security univaried versus multilinear I will go over very fast because this is kind of deep into the internals of a snark. Uh the only thing we kind of need to know is like in multilinear

uh snarks we have this equation which everyone loves because it tells you to evaluate a polomial you take a sum of a bunch of values of the polomial. So if you already have a bunch of values you can create one more. Uh the other nice thing about this equation is we have a great proof system to prove it and it's called sum check. If this doesn't mean anything to you no problem. What is interesting is just to think that this equation saves us a lot of time and this is why a lot of people are moving from univariat snarks like graph 16 to multilinear um like maybe SP1 hyper cube that's what they're using cool it used to be also that commitment

costs were a lot higher for multilinear polomials and as of recently it's exactly the same so better for your prover size doesn't change um this is actually quite Yes, choice of fields. Also, this is deep in the internals. This matters mostly um I guess when you're trying to express computation in a provable way. A large field is kind of inherent to cryptography. We need things to be hard to break. We need things to be hard to guess. So, we need large fields. The question is how do you build your large field? Is it prime like this is just one big object or is it an extension field?

It's like small objects that we combine together. Um in elliptic curve stuff we need to use prime fields. We need to use one big object and this is why things are slow. Um however our signatures also use these exact same fields. So if you're trying to express like how like verifying a signature as a verifiable statement a circuit for signature verification then actually you're fine working with prime fields. That's what you're trying to prove anyway. Um, small primes and their extensions are great because our hardware deals with them very well or much better than large prime fields.

We can even use binary fields. This is just like a field with 01 and binary fields plural is uh extensions of the 01. This is great for expressing bit or by wise operations like all our hash functions. If you want to write a circuit about them, this is probably the way you should go. Um, finally, you can use towers of binary fields. This is a proof system that use binary fields of a bunch of different sizes. Um, in general, going for smaller fields mean faster provers with no trade-offs. That's it.

Arithmetization. Um, how do you pick the way in which you've expressed your problem? Um, one of the main tasks of the prover is to commit to your witness data, to commit to your private inputs, commit to all the intermediate steps of a circuit, for example. Um, or actually, as we'll see, not always true. Um, different ways of expressing the statement will yield smaller or larger witnesses. In general, uh, we commit to all these values that I have in red and in orange.

So, you have your circuit. We actually commit to everything that's not public. Um, there are other proof systems which allow you to only commit to the inputs to the circuit and not the in between. That's a big save. This is like the GKR stuff. However, there have been recent attacks on GKR again because of all this random oracle stuff. Um, and they've shown that with a large circuit and GKR and using hash functions, you might have a back door. Um, so the circuits need a lot of attention in that case. So our evaluation here is if you use a proof system that allows you to commit to smaller witnesses, you'll have a faster prover. Um, if you push it a bit too

far, you might have some security issues. I have it as a question mark because there's more work to be done. All right. Zero knowledge. Zero knowledge is absent for most libraries that are zk proofs like that's it. Most of the libraries do not give any privacy. Um if you want privacy, you need zero knowledge. We have actually a zik hack puzzle about this. I really encourage you to go either try it for yourself or read one of the uh solutions to it.

It's it's a fun puzzle like we give you a bunch of proofs and you have to extract the secret information behind them. Um there are two general methods to get ZK. One is to just take your proof system, open up its internals and write a ZK variant of it. So you're going to do some hiding of the secret data and have the same proof system. The other way to do it is like to just wrap your proof with a proof that is ZK like hey I'm now going to take a proof that is private saying I have verified this non-private proof. Um, in general, ZK comes as at a small overhead for your prover, uh, but an incomparable gain in privacy.

Cool. So, that was a lot. I'm sorry. Um, but now we can sort of look at the whole picture and see all our evaluations. Um, the only one that I don't have on this summary is the hash versus curves versus lattises because we have a big table there and it didn't fit. Um, in general, you'll see a lot of things where it makes things everything better except security, right? We have everything better except security. Better prover less security. Better prover questionable security. Um, same up there. Same pretty much everywhere.

Um, and this results, this is something that we'll see, actually, let's not stick to this just yet. Something that we'll see in the decisions made in 2025. So, to finish the talk, to wrap everything up, we're going to go back to the two applications. I said I liked the two like I think in my opinion fastest state-of-the-art proof systems we've seen this year. One was libk and they decided to go with hash functions. They decided to go with a monolithic snark. Uh multilinear we said wasn't surprising. They used GKR. So we're going to have to be careful about the circuit that they use. They use standard hash functions. Interesting. They use zero knowledge. Important. Um they use

circuits over two types of fields at the same time because they're proving hashes and they're proving signatures. So they said all right we'll use prime fields for our signatures. We said that's good. And we'll use binary fields for our hash functions. uh they use retentment codes because they're proving small statements. They don't care about the asmtoics and they're using proven security. So if we look at all these decisions, they actually went for as fast as possible. However, we keep like solid security. We're not going to go into like proof of a proof. We're not going to go into conjectures and we're going to go with like standard hash functions.

The choices in S1 hyper cube are slightly different and I've highlighted the differences with colors. We keep hash functions, we keep resolment codes, we keep multilinear polomials. Um, we've removed zero knowledge because they don't care about zero knowledge and their application. We're proving only over public data ethereum blocks. Um and then the remaining choices are all those ones where we could make things faster for the prover and just better in general at the expense of our confidence in the security of the system. It doesn't mean that these systems are not secure. It just means we are making more assumptions and we are a bit more let's say hopeful and optimistic um about the security of our systems. I do suspect that all these things will be proven to

be fine within the next I don't know five years except maybe bottom right. Cool. That kind of wraps it up for me and what I thought was the state-of-the-art of 2025 and this big design space and how it's been explored and where we're at these days. The question is what's going to happen next year? Like where do we go from here? So here's a bit of a wish list. The first one is I would like people to explore latisbased snarks a bit more uh simply because they seem to strike a nice trade-off between um like uh having a fast prover yet having a very small proof.

Um then there's a bunch of security questions peacemeal snarks. We have this issue where we are proving something in the random model but then we instantiate the random oracle as a hash function and then we prove something about that. We do not have full security proofs for this. we have a little step in the security proof which is like hey hope for the best. Um and I yeah I want people to look at this a lot more and I hope we're going to have positive results there. The next one is to look at smart friendly hash functions. I know the Ethereum Foundation has put out a lot of bounties. Um so if you want to go and analyze things like Poseidon or try to break it there is money there if and you will be rewarded for doing it.

Um also more scrutiny on error correcting codes and these conjectures. So right now we're using codes and assuming that they behave super well in any range of parameters. The proofs the real math tells us well we can only use about half of the parameters. Um it's a very big open question and I think uh this will also be heftily rewarded for whoever finds solutions. Finally I would love to see zero knowledge for real the actual ZK in our libraries. Um and I think yeah that was it. Thank you very much.

>> Questions? >> What's up? >> Should we do questions? Questions? >> Oh, yeah. >> I don't know. I >> If if you have questions, we can do questions. Yeah, >> please. >> Uh okay. U everything revolves around polomials. Yeah. >> Understand encoding is because of the dilemma to polomials different in most points. Yeah. >> Even the just proving >> anybody looked at anything else a platform there could be something there we could uncover some big leap there.

>> Yeah. Um >> be on my wish list. >> Absolutely. We you could express all this in terms of linear algebra if you wanted. >> Um at the end of the day the properties are those of polomials. Like at the end of the day the things that makes us click is this zip alignment like you said. Um >> there could be something nicer. >> There could be something nicer and that sort of that was the promise of doing cryptography from error correcting codes. >> Um >> you can see from NPC like an MPC perspective also like >> yeah true you have this idea of doing like MPC in the head of like doing an MPC protocol and then inspecting and making sure that it was fine but also I don't know if there it relies on secret sharing which also is polomials. So

there's you always somehow seem to come back to these ideas. Uh so this is more of like a deeper math question. >> Yeah. Yeah. Yeah. >> So no I I don't know. Yeah. >> Thanks. >> Great. >> Very cool. >> Cool. >> Nice. >> Thanks. Thank you very much. [Applause]