ZK14 - Securing a $500B Computer: The EF zkEVM Security Sprint - George Kadianakis

Transcript

I'm George. I work on the Ethereum Foundation cryptography team. And today I'm going to talk about uh the work we've been doing on securing ZKVMs. Um yeah, this is a teamwide work. Uh the cryptography team has been working on this. It's not my work, but still I present it. So yeah, let's move forward. So I I think I should motivate a bit this talk why we're talking about ZKVMs. The answer is that uh ZKVMs are veh wait just to explain why we're looking at funky images. Um I'm uh well everything the images are all from Rome. Um, so you

can go around the city and see um I don't know like the sculptures and the things. Um, I'm not Italian, so this doesn't make much sense, but still like I'm just the aesthetics are Rome inspired. So yeah, anyway, let's continue. So yeah, so where was I? So ZKVMs um are particularly nice for Ethereum because um blockchains are fundamentally bottlenecked in the sense that um you know validators of decentralized blockchains at some point they're not able to follow the chain if it gets heavy enough if it gets big enough if enough transactions are in every block.

So ZK proofs and ZKVMs flip this around and it essentially allow um validators to verify a very succinct proof very fast and essentially follow a very heavy chain very efficiently. So it it basically resolves one of the fundamental bottlenecks of blockchains and that's why Ethereum is so interested in ZKVMs all of a sudden. Anyway, um moving forward, uh ZKVMs have been an interesting topic for years, but the performance of them has been a big question. So, um a bit more than a year ago, um the

Ethereum Foundation started looking at like the performance of ZKVMs to see if a ZKVM can actually prove fast enough to follow the Ethereum chain. And this was a blog post that was done that sort of set up some goals in terms of performance, in terms of prover costs. And the answer after lots of months of the teams working on it was a very big success like you know prover costs dropped uh many x's uh prover um hardware costs dropped a lot like like basically uh through this real-time proving initiative um the zkms on L1 were derisked and it stopped being an

issue of performance anymore And I think now it's more an issue of security in the sense that we know that ZKVMs can prove fast enough, but the question is if they can prove secure enough. And it's a good question to be honest because I don't think it's like a um a stretch to say that ZKVMs are an extremely complicated like cryptographic object to the point that I don't think humans know how to deploy such complex objects on the internet right now. I I think it's probably the most complex cryptographic object that is seriously being considered getting deployed and

the security um repercussions of of it getting hacked are huge in the sense that um if if you hack the L1 ZKVM, you can essentially do an illegal state transition in Ethereum. And this means that you can do many many bad things as yeah it's it's basically a huge issue. So we need to think about security seriously and this is a talk on the security of of how we think about security of L1ZKVM mostly on the proof system layer on the polomial commitment layer not so much on the implementation side or on the formal

verification side. I think it's worth doing a talk about the holistic thing but this talk in particular is going to be focusing mostly on uh proof system and you know like the foundational layer stuff. Um Nico I don't have um timer thing. There is no timer. Okay. >> Okay. Okay. Okay. Um all right. So um in the beginning of this year uh we did this blog post which basically sets again some limits some goals for how we see the proof system security going forward and it's going to be an initiative that lasts this entire year 2026 and it sets up some goals. So I'm

going to talk a bit about these goals and then I'm going to talk a bit about what we it's May now so a few months have passed. Uh so I'm going to talk a bit about the journey so far. Right. So um the first goal is to um is is for ZKVMs to get to 128 bits of security. Uh this doesn't seem like such a controversial goal in a wider industry sense because the wider cryptographic industry thinks about 128 bit security as the normal thing. You know like when you think about ciphers is symmetric crypto everything is tuned to 128 bit but ZKVMs have been traditionally

allowed to exist in like 100 bits 80 bits 80 bits conjectured security which I'm not even going to touch so much right now on so like you know like like like basically we have given like a bit of an artistic freedom to zkms due to them being so complex But now we sort of want to take it back and be like you know this is serious stuff. Ethereum is a serious uh business like you know like security of Ethereum serious business and also you know like if we want ZKVMs to be to find product market fit outside of blockchains like I think the other industries will also want 128 bit

security. So this is the first goal. Uh the second goal is that if you have looked at ZKVMs uh they're usually all they all have this very complex recursive structure where you know it's not like just a simple IOP or whatever like it's like a small proofs recursed recursed and then you get a final proof after lots of complex architectural thingies. uh what we want and this you know like we know how to prove the small components but we don't know how to prove the entire thing. So one thing we want out of this project is

by the end of the year to be able to have a security proof for the entire thing. Um which we believe is going to illuminate lots of hidden details of the proof architecture that are currently hidden. Right. So that's the second goal. And the last goal in a sense is that we're doing these things now because the proof system layer is the foundation of the ZKVM. So if we get serious about the foundation foundational layer and it freezes and it oifies because it gives

us what we want out of it. This will allow us to start working seriously on the layers above which is implementation formal verification these kind of things that we we're currently working on but I think when the bottom layer is frozen it will give us you know we we can we can invest more because we know that it's not going to change. So yeah, these are the three goals of this year's security sprint. And now I'm going to talk a bit about um you know, it's May now, so a few months have passed. I'm going to give like a bit of a of of of of what happened. We have a bottle of water. Ah, any time. That's

good. Thank you. Let's do a small right. Okay. So, so we're going to go a bit on what has happened so far. We're going to go a bit in layers. So, we're going to start from, you know, like the bottom, like the more mathy foundational layer, and we're going to go up and up and up. Um so and a bit also like on a urgency layer in the sense that the first things we're going to talk about we have sort of solved them already but the last things are still kind of open.

So anyway let's get started. So um on the math layer um all the hashbased ZKVMs rely on a thing called proximity gaps which is a very niche thing and it basically it's like math theorems on how error correcting code code words behave when you combine them or even more interestingly how error correcting code non-code words behave when you combine them like you don't want to take two non-code words and combine them and get another code word. I mean it's very niche and I'm not going to get into it but it these sort of theorems are

extremely important and it's basically what this whole ZKVM thing is based on and the theorems that sort of define how these things behave were introduced a few years back and in some extremely prolific papers. But then you know there was like a theorem and then next to the theorem there was like you know there was like oh it behaves like this and this is a security proof of how it behaves and then next to it was like a conjecture that said we cannot prove this but it probably behaves also like this and we're going to use this conjecture as our security of our system because by using this conjecture you get lots of security for free. So you know

like a system that is 60 bits of security on the provable theorem side can be 100 bits of security on the conjecture side. So you know people started using these conjectures and when one person uses this conjecture all the other people are forced to use this conjecture due to the industry being competitive. So we ended up in a situation where last year um projects were offering you know like 80 90 100 bits of conjectured security and this was all fun and games until you know like uh one paper came out that started digging hole into the conjecture. Then

another one came out. Then another one came out. Then another one came out. And you know like basically at the end of this of last year essentially the conjectures were attacked so hard that it was extremely hard to uh rely on them and they're still getting attacked. like I could there's a few more papers I could stack on top of this but uh essentially I think one stance we took in the beginning of this year was to sort of only look at provable security which is what you can prove the theorems and this stuff. So this was sort of the beginning of this uh security sprint journey to focus only on provable

security. All right. So that's for the math. Now on the sort of um a bit above like on the proof system layer on the protocols um so when you look at ZKVMs uh and you and you know they they say oh we have this security we have that security and you see how they compute that security level they each ZKVM has its own way of computing it they have their own soundness calculator one is written in Rust the other is written in Python. The other is like some section on the readme like you know like every project is computing security

differently and that made it very very hard to compare apples to apples and and we had to compare apples to apples when it comes to L1 stuff because like you know we're a neutral base and we need to see like we had to be able to compare projects. So what we did naturally is make our own soundness calculator uh which is universal and you know like uh you can plug any ZKVM into it and get the soundness of that ZKVM and so you it's it's called sound calc you can find it on GitHub and then it outputs a table like this that I have

not made nicer sorry about that but basically you know it has the open the ziki VMs in the left and then how many bits of security and expected proof size and it sort of it might not seem like it by looking at this but it sort of makes it easier to compare things and and to and to get a better idea of where things stand. Um yeah, so that's another thing that happened in the beginning of this year. Um and we're sort of in a good position right now. Now let let's go into things that we're in a less of a good position.

Um so right so uh there is this thing called pose. It's a hash function that is very nice to be used in recursive contexts and zkvms are recursive contexts. All the ZKVMs use recursion. And if you use recursion, you want to have a hash function that works well with recursion. And Poseidon is one of them. And the AF has launched the Poseidon initiative a few years ago, which basically gives grants and bounties for people to attack Poseidon.

And people did attack Poseidon. And now people uh especially this paper from ETHZurich they broke Poseidon in some way like they didn't break it exactly in the sense that the security level did not change but still some fresh attack vectors were found in Poseidon that Antonio talked about earlier today and it basically made us more distrustful of Poseadon. So now the question is um how to think about this, how to think about posed going forward.

Um we don't have excellent answers for this yet but we do have ideas and yeah that's another thing that happened this year. And finally going to the sort of like top layer of architecture. Um when you think about ZKVMs, this is sort of how things look like like you have a recursive architecture. In the bottom layer, you have all these small proofs that you have like a huge statement. You chunk it, you take small proofs, you recurse them, you get smaller proofs, and then sort of in the in the top of the thingy, you get like one tiny proof that corresponds to the entire

execution. This is like a classic ZKVM architecture. And this is nice, but like when you start digging more into it, you see that like you know this nice thingy is actually much more complex. Uh there is like between these nice boxes, there is abstraction leaks between them there is global memory arguments. There is global things going on. um um you know projects that are using hashbased snarks also use an elliptic curve argument to do global memory checks or other projects that are hashbased they use latises as

subprotocols and and this is very hard to understand like very hard to to illuminate and to to to sort of map out when you're investigating a ZKVM because these are like very tiny details that might matter in security. So this is this inherent complexity of ZKVMs is what we've been trying to tackle this year. And one one one one way we think is is a good way to tackle it is to sort of provide the framework that allows teams to formally prove the security of their ZKVM like like of uh of of this entire

thing. Like we humans are pretty good at at at proving the security of these boxes, the individual boxes, but not yet that good at proving the security of this entire thing for many reasons. So we hope that by the end of this year we provide a framework where teams can use to to get a more overarching security proof of the entire thing. How we do this plenty of Okay.

>> Okay. Okay. Right. >> Okay. So these are sort of the things that are happening um on the various layers and has happened in the past months and like sort of looking forward in the rest of this year given the goals we have is um well to to start with a positive sentiment one thing is that we know that 128 bit security is achievable and it's achievable with a reasonable proof size.

Uh we know that because uh there is projects like ZISK that have gotten to 128 bit security already by using a very granular recursive architecture and by hardcore optimizing the heaviest circuit. So we know there is ways to do it. We also know that other projects can do it using a multilinear proof system where you know like you have a big table and instead of uh treating each column separately which adds lots of proof size you sort of do like a multilinear trick where you consider it as a huge column and then you can still argue about the

individual columns. Anyway, like there is techniques that we know of that can get 228 bit security in a nice way and this is a positive thing for us. Um and also um we have um like various research leads going forward that we would like to explore more. For example, um latisbased proof systems are getting uh more and more powerful. It would be interesting to see how hashbased proof systems combined with latisbased proof systems. Um you know uh hashbased proof systems are very fast but latisbased proof systems

are smaller. So maybe there is a nice combination that we could see there. Um another thing is uh binary field proof systems uh used to be very exciting. I think they can still be very exciting. And not only that, but also projects that use binary field proof systems can also prove traditional hash functions efficiently. And this allows us to potentially use them to move away from posed or from algebraic hash functions and use like a shatu or Blake.

So you know these are potential avenues in the future for solving some of our problems. So yeah, like closing up, I think we have a a good path for the rest of the year and also definitely interesting research directions to to continue uh moving forward. And yeah, uh thank you very much and happy to take questions. Any questions?

Um when you say 128 bit security is that referring say in your table for example to 128 bit classical security um or is it in the Q ROM or um >> no it's on classical security >> I thought so yeah because the when I looked at the STOs paper it had no analysis of the postquantum concrete security at all um so do you think 128 bit postquantum security is necessary. >> Yeah, that that that that's something that I I don't have a good answer yet. I mean, it's even more interesting because the the sound calcul table I showed is showing

um security of the interactive protocol, not even compiled into non-interactive yet. So, it's it's still hiding a few more details that we need to decide as a community how to handle. It's hard to say about the postquantum security bits. Yeah, my my intuition is don't cheat on this because >> correct. Yeah, >> more questions. Oh, very clear. >> Thank you very much, George. Thank you.