Secure Scaling With ZKEVMs | Cody Gunton - Ethereum Foundation

[music] Thank you everyone for attending our first talk. Up next we have Cody from the ZK EVM team and he'll be talking about the road to ZK EVM scaling. [applause]

All right, thank you. So yeah, I have uh my slides available here through this QR code if anyone wants to follow along in that way. There are some links that are possibly interesting references at the end. And yeah, as the introduction said, I'm a member of the ZKVM team at the Ethereum Foundation. Um, I'm working more narrowly on like the security aspects of the project, but I want to present more broadly on um the the project and and then focus a bit more on the security roadmap.

Um so to just set the stage like ZKVMs allow us to take advantage of a certain asymmetry where you can have like low power members of a network checking the work of very highowered members of the network using not all that much data. And [clears throat] so our goal is to scale Ethereum using this asymmetry by having the attesters start to verify proofs that are produced by provers who have um big computational resources. And the switch will also allow these attesters uh to keep low resources both in terms of the compute that they have and the amount of data that they need to receive to do that work of checking. So here it is a bit in pictures. Um so sort of prior to ZK and this is you know a cartoon there are things missing but uh prior to ZK what we would have is the um just the sort of middle section of the diagram here without the prover and the VM.

So you would you know have an EVM implementation that processes a block and updates the state of the system. And what happens with ZK uh EVMs is that you have that uh EVM implementation running inside of another virtual machine. Um here I say that it's a a risk 5 virtual machine. That's a choice. It's it's quickly become the canonical choice.

Uh but there are other possibilities. Um you'll hear about some of them today shortly. And what happens in the ZK setting is that you have this VM running inside of a prover who observes the execution of that machine and then produces this green block this addestation to the execution which is the proof. And then the atttor only needs sort of summary data so hashes of the trees and of the block to check the update was correct. And I just want to say explicitly that there are proposals about changing the EVM to use uh some other model um maybe a risk 5 machine and um those are not related to what our team I mean they're related they're potential optimizations but they're not something that our team is working on.

They're not part of our um more immediate L1 scaling goals. Um there are optimizations where you could imagine that sort of the blue box if it's more similar to the enclosing risk 5 VM then you you'll have some efficiency gains but yeah [clears throat] okay so ZKVM versus ZK EVM um a ZK EVM is just a combination of a choice of a ZKVM and then a program of the blue box the EVM implementation that runs inside of it. Um, so here are two screenshots of Justin Drake talking about each kind of thing. He tracks um carefully what what options are available. On the left, these are both from um from YouTube videos.

You can find it these links in the in the blue um where he tracks some existing guest programs and some ZKVMs and Al Priori. Any combination of these could produce a ZKVM um though there are technical challenges which gu will speak about in the next talk. So how will we ship? Well, okay. Uh this is a huge change and we need to be very careful.

So we're going to do it in two phases. The first one we call optional proofs where the testers continue to do the normal work they had done up until now. But they do this extra work of checking these proofs which you know need to be produced. Um so this is a trial period. We can see how the network performs.

make sure that we do have 100% real-time proving uh and you know respond to bugs and um because it's optional we can't increase the gas limit. If we did then the re-execution that the pro that the attesters are doing would start to break down and we would have um you know centralization um like by via increasing requirements. So we we don't want that. Eventually once we're happy with how things look in optional proofs we can start to increase the gas limit and [laughter] you know by doing so make it required to increase these attested requirements or what we that's not what we want uh what people will do is just rely on the proofs right so at that point if the proofs disappear the network uh can function um but we can increase the gas limits so here's a concrete proposal proposal. Um, right now it's very basic.

It's in draft form, but this is the EIP for optional proofs. And you'll see uh in my references at the end a link to this and also a link to the ongoing work actually in the um consensus layer specifications fleshing all of this out very carefully. So who's shipping? Here's a list of a bunch of stakeholders and we're organizing around this uh GitHub organization which is called the we call it ETH act applied cryptography team. There are 20 30 repositories in that organization where we are building like universal prover execution framework called array.

Um we have the planning repo I'll show you where we discuss the plans for the the shipping optional proofs um test monitoring I'll show you standards for the provers a lot of stuff and we have really robust discussions and try to get um you know widespread rough consensus about these things uh and make them official through pull requests in the repositories here and we also have as of last week a breakout call where we're discussing all of this and I will show you some things that I presented there. [snorts] Here's what the planning repo looks like. Here's our list of plans. Um, project 7 is the security plan that I'll address, but there are many uh other important aspects of the project like prover incentives that I won't touch on. Um, here's our uh we have a channel in Ether R&D discord where we're also having discussions maybe more preliminary to the proposals that go into ETH act.

Um, these are all posts from yesterday.

[clears throat]

and you're very much uh invited to join us there in these discussions. So here is um what I presented last week. I made a a basic road map in terms of security for the shipping of optional proofs. Um it proceeds in these phases um which I will now dig into a bit further. [clears throat] So phase one we have um these kind of four first shortest bars are basically they're solved problems but it's good to put them down [clears throat and cough] in a you know one place in the in ETH act but you know we've we've put forward like capex um requirements for provers you know what's a reasonable number of GPUs and um you know power consumption for to say that provers should have in order to produce the proofs for the network.

Um, we have cryptography requirements that have been articulated in blog posts. So, most of this stuff is done. It's just maybe it's good to to kind of defragment the um discussion a bit and put it down in one in one place. So, that's that. And then these longer bars here, we have uh we need to be more precise about the level of testing that is uh prudent and necessary for optional proofs.

that'll be a lower bar than mandatory proofs where we need to be extremely high bar for security. Um and similarly uh part of understanding these systems is having good specifications. Right now the landscape of specifications is is not great. Things have moved very fast. Um you know the engineering kind of p uh pushed beyond the careful specification.

I I think that's acceptable. But now we need to make sure we have very good descriptions of the ZKVMs um so that they can be analyzed by cryptographers and um other cryptography engineers. So that's you know exactly what the right way to write these specs is is something to discuss. The next two bars we have are from the cryptography research team at the EF. So they've made something called sound calc for precisely describing the number of bits of security that these uh ZKVMs have.

There were conjectures that were in use. Um and just generally speaking, it's it's it's not all that simple to to know exactly how many bits of security, but we need to know that we have very high quality security. So then the so that'll be and by the way the the bars here are sort of roughly temporal like each vertical um slice I mean is something like a month or a month and a half. Um I had to be a bit fuzzy because there are some already established deadlines for things and there are also uh more fuzzy aspects of this but this is you know reasonably um temporal I would say. So here we're saying you know in the next basically month or two all this is done the sound calc implement or integrations are done so that the ZKVMs have given us all the information we need to know that they have sufficiently many bits of security or at least that we know how to track their bits of security because then we [clears throat] excuse me we um we ask then that they um have 100 provable bits of security rather than conjectural bits of security and smallest proofs, 300 kilobyte proofs by a specific deadline that was published by the cryptography research team.

And then uh this final phase is we need to be very precise about um or at least very thoughtful about how uh we're going to make use of diversity of these provers because sorry we um uh we're we're we'll have multiple verifiers in the clients to to be sure that a single prover failure um a bug doesn't bring down the network. So we want to have make sure that we have a diversity of software dependencies between you know not all the same compiler not all the same VM not all the same guest program that kind of thing and knowing what [clears throat] what the right balance is there is something that we need to have a good discussion about also criteria for including a given ZKVM we need some rough consensus on that and we also need to make sure that these uh yeah hardware requirements are are reasonable and that the ex uh performance we've seen on ETH proofs is um something that can we can reproduce. It's not specific to a particular setup for instance um hard to reproduce. So then we have that here are some um uh some some pieces of work I've put in uh on these first uh on this first phase. So I have this test monitor that checks for compliance with the risk 5 standard for these DKVMs.

um they have they support different targets and they have different degrees of support. Um it's still a bit custom. We have a precise specification of the target requirements that all integrate and um most of these would would meet that. And I also have some starter specs. So I've been using AI to create starter specs, executable specs even.

So these are backed like this. This is derived from a Python specification and it's backed by real test vectors that are extracted from the C++ Python or C++ prover library. So it's it's just kind of a starter to get something uh down that maybe the um some of the teams could use to provide these specs uh in a short time frame. And I have only half a minute but in the next phase we need to implement testing. We need to build monitoring.

We need to do this specking work. We need to increase the security to the canonical 128 bits and reduce proof sizes. And then we need to do um kind of incident response planning reviewing of all of the specs and um stability monitoring before we launch uh where we aim to launch in Hegat. So that is the end. Thank you for your attention.

[music and applause]