Keynote: Road to zkEVM is Paved w/ Good Engineering by Kev Wedderburn, Ethereum Foundation

Transcript

[clears throat] Okay. So, I think the next couple of uh speakers you'll really see that now that real-time proving is no longer feeling like a a figment of our imagination, but something that's uh already attainable. Um, a lot of the researchers are really beginning to pivot their uh, thoughts towards security. So, next speaker, Kev Wburn, uh, team lead of the ZKVM team, always kind of thinking about the next wave of sets of constraints and requirements that we need to be, uh, you know, really sort of

encouraging all the teams to uplevel too. So he defaced my beautiful slide here. So rather than just prove it, it's it's just secure it. So we're going to hear from from Kev and then after that from the cryptography team, Arancha. And so uh welcome to the stage Kev. Uh we're going to be talking about the how the road to EVMS is paved with good engineering. [applause] Testing testing. Can you guys hear me? Cool. Um, yeah, there's going to be a bit of duplication with uh my slides just because of we've talked a bit about them. Some parts are a bit spicy, unfortunately, as I've just learned from the previous panel.

Uh, so what do I want to talk about? I want to sort of explain to you guys why are we shipping ZKVMs, what are the components to shipping VKVMs, and what are the milestones that we need to achieve to ship ZKVMs. Okay, so what problem are we solving and for whom? Here's a graph that shows the relationship between the gas limit and the resource usage of the builders. So prezvms, it's a linear relationship. If you increase the gas limit, the resource usage of the builders increases.

Post uh ZKVMs, it is still a linear relationship. It's a bit higher and this is because the builders now need to prepare inputs for the provers. Now there is no prezkvm prover line obviously but post zkms the resource usage of the provers as the gas limit increases is a linear increase maybe even super linear. RPC providers, we sort of have to mention them if I know there's a lot of core devs in the audience. ZKVMs do not help RPC providers. They still need to have the state to re-execute to collect

things like logs. Now, for nodes that only want to validate the chain currently, as you increase the gas limits, their resource usage also increases linearly. Once we introduce ZKVMs, they their resource usage becomes roughly constant as we increase the gas limit. And as you can see, there is a point in time where it does make sense to switch to ZKVMs. When this is, we currently don't know. And one point I want to make is on the gas repricing uh projects that's happening in Ethereum. This makes resource usage efficient but it does but there will be some point in time where

we have to where where it makes sense to switch to ZKVM still. Okay. So one important thing that I want to note is that ZKVMs do not solve state growth. The builders and the RPC providers will still need to have the state. What it does solve is for the nodes that only want to validate the chain. They no longer need the state in order to do this. At the at the Ethereum Foundation, we have a specialized team, the stateless team who's also working on solving this problem. So this is a problem that we do want to solve and we do see it as something that's important.

Right? So the TLDDR of the first section is that we utilize compute asymmetry in order to have some nodes do little and other nodes have needing to do more. And these nodes that are doing little are nodes that we care about. These are the nodes that are validating the chain. So, how does this all actually work is a good question. The current workflow, as you saw from Justin or well, I'll show you the I show I'll show you the workflow that Justin was going through, but currently on Ethereum, a beacon block arrives with the payload. A node validates that the payload is correct using their EL and

this requires state. Then they attest to the block if it's valid. As we saw in Justin's demo, the beacon block now arrives with the payload header. They wait for the proofs to arrive. Proofs with a s uh which attests to the payload correctness and then we verify the proofs and attest to the block. So this is the consensus layer and that's sort of the top of the stack. Now let's just look at uh all of the stack. If we start at the bottom, we have the snark prover and the snark verifier. Uh for people in the crowd who are not sort of cryptographers, you can think of the snark prover as this component that proves execution for a particular function and the snark verifier as receiving the proof uh attesting uh

receiving the proof of uh receiving the proof and if it if the proof returns true or if the verification returns true, sorry. uh then you can be sure that if you had executed the function yourself, this is the output that you would have gotten. Now on top of the snark verifier, I've written the virtual CPU for the ISA. What this means is that there is a function that takes in some bite code risk 5 byte code was on bite code and this is what the snark prover is proving. So if you have a risk 5 ZKVM, what you have is a ZKVM that allows you to prove execution of a particular bite code, a risk 5 bite code.

These three components together is what we usually refer to as a ZKVM. Now on top of this we have the execution layer state transition function and this is what your ref eff client will be uh written in. This is a function that takes a block and a state proof and executing this uh allows you executing this allows you to know that the state transition function was correct on this particular block. This function gets compiled to risk 5. And this is what the ZKVM's taken.

And at the top of the stack, as I wrote before, is the consensus layer. And this is the component that takes proofs uh from the network, verifies the proofs, and if the proofs are valid, they attest to the block. Uh so this is the whole of the stack. I mean, you can sort of uh go deeper on the snark prover. There are things like polinomial IOPS and PCS's, but I feel like if I start explaining this to this audience, it's probably not going to be super useful. You just need to know that there's a snark prover. There's this component that allows you to create proofs of execution of a particular function.

So let's look at the first component. What do we want now? We want open source open source GPU implementations that achieve real-time proving. What do we want next? We want reliable provers. This means that your GPU implementation needs to be reliable and where you're hosting the provers needs to be reliable. And what we want later or technically in parallel is to be hardening these implementations. The next component is the snark verifier. What do we want now? We need 100 bits provable security with grinding by Glamsterdam.

What do we want next? 128 bits provable security with grinding by HSAR. And in parallel again, we're going to be working on hardening these implementations. You can also see a rancher's talk which comes after mine who will go into more detail as to why we want these things. The next component which is the ISER or the virtual CPU for the ISER. We really want this. We really want the circuit that you've created to conform to the ISA spec that you said it conforms to. So if it's risk 532 IM, it should support all of the instructions in risk 532 IM.

And again in parallel we're going to be working on harden insecurity. Uh this is going to be an important theme. You can also see the talk I did at Zisk where if you're a risk 56 if you're a risk 5 ZKVM we propose that you support risk 564 IM none the none means that we won't be supporting the Linux sys calls if you're a was zkvm you can do whatever you want for now this proposal doesn't say you have to support risk 5 it just says that if you are this is the minimal that we want you to support uh the QR code links to the PR with the proposals and sort of the analysis we've done in order to arrive at this conclusion.

Okay, the next part is the execution layer state transition function. So this goes to the EL's uh the execution layer core devs in the audience. We'd like you to implement a stateless uh state transition function. So this is a function that takes in a block and the MPT MPT witness. The next part we want you to ensure that the STF passes east and this is a minimum requirement. It needs to pass all of the Ethereum execution spec tests. And again, security hardening is something that we care about. And the last layer at the top is the consensus layer. What we want now is optional proofs on devets and test nets.

What we want next is optional proofs on mainet by Gstar. And later we want to um well, we want to investigate and we want to get to mandatory proofs. Getting to mandator getting to mandatory proofs does require a lot more components and it is the part where we do need to do a lot more investigation. But for optional proofs, we're completely sure that we can do it. You saw Justin's demo uh and we want to ship it as soon as possible. Okay. So what is the path forward? You will not get onto mainet if the ZKVMs are not secure. Like this is the thing that I think we should take away from this talk. Like if your ZKVMs are not secure by the definition that we've

said, it will not get onto mainet. Uh any questions [applause] here, Kev, we got this sorted by popularity here if you want to read through here. Um, so the first two are kind of referencing one another. The first person asked, "What will you do to make sure that ZKVMs actually ship and not get hung up on research questions and processes?" Um, someone went ahead and asked, they've already done that.

Have you seen the demo on ethof.org? So, >> feel free to jump in there or the questions lower. >> Uh, what is this question? Uh I think this was just answering that question suggesting that uh those two we could probably hide if you want to look at the ones. >> Look at this one. >> Yep. Okay. Uh how do you envision this new architecture transforming the experience of smart contracts and application developers? How can compilers and dev tooling make developers lives easier in this transition?

H so I'm not sure I understand the question completely. I guess one thing to note is that there are two uh similar I guess projects. There's the EVM to risk 5 project and there shipping ZKVMs that use risk 5. EVM to risk 5 is more longer term and we haven't this has nothing to do with my talk. Uh shipping ZKVMs on L1s helps the validators or the testers. Uh so I don't see this affecting smart contract developers. uh currently I think one thing that might hurt smart contract developers is when we increase uh the gas repricing of certain op codes for example we might want to increase the

gas repricing the the gas cost of ketrack for example and solidity uses ketrack a lot so that's the only place that I see ZKVMs possibly um affecting smart contract developers what form of verification standards do you envision I will leave this to Alexander Hicks who's in the he's not in the audience at the moment. Uh he's done bas he's basically the lead of this and yeah I don't want to misquote him. So I'll leave that question to Alexander Hicks.

Uh what will you do to make sure ZKVMs actually ship and not get hung up on the research questions and process? This is a good question. Uh Ethereum is a very special place uh if you want to ship things fast. What we've been doing so far is just trying to integrate into the ACD process or integrate with client core devs as much as possible to make sure that we solve whatever the bottlenecks they think we have. Um, and currently I think it's going well. We know what sort of the questions we know what the blockers will be and we currently have solutions for most of them. I think this is the only way. You just have to integrate and yeah when are we going to start thinking in

breaking free from CUDA and Nvidia? O yeah [laughter] big O. I'm not sure. Uh I think every ZKVM team uses Nvidia. Uh you guys can correct me if I'm wrong. I don't think it's a high priority to be honest at the moment. Uh what is the consequence of a ZKVM implementing a different risk 5 flavor? So you can implement the risk 564 IM none was the minimal.

You can implement uh whatever you want on top of it as long as we support the minimal. The reason why we do have this standardization process is that is so that such that the ELS and the ZKVMs have a common contract. So you don't have one ZKVM being slower, but they support everyone and then two another ZKVM being the fastest, but they only support one EL. Can you get onto mainet if you're not secure? [laughter] How will you choose and distribute proof validation systems?

H um so I'll rephrase this question. How will the So when an tester receives a proofs there's n uh different proofs there's n different proofs that are registered on the network and they need to receive k of them before they say that the the atestation the payload is valid. How do we choose this N? We don't currently know. The reason this process is a bit contentious is because the end proof types that you choose, you're basically choosing ELS that become semi-enshrined into the protocol.

Whereas right now, if you launch up your Python EL, you can validate uh the execution payload. So there is this sort of permissioned aspect to adding ZKVM proofs. So, we're not currently sure how we're going to choose N, how we're going to choose K, and we're not quite sure what those values are at the moment. Who is responsible for providing security and how can we help? Uh, currently on our team, we have Cody Gunton. I'd say reach out to Cody Gunton. He's uh right there. He's putting up his hand.

How optimistic are you compared to six months ago? I feel like Justin wrote that question. [laughter] Um, it's not that I'm I'm uh [laughter] I'm I'm always quoted as being not optimistic. It's just that I I have a lot of questions. Uh I don't like to I think we know more than we knew six months ago. So I would so yeah I would say I'm more optimistic but I always just have a lot of questions and I like to be very conservative in things that we're going forward with. I like to be very rigorous in the way that we're thinking about this. Um so yeah I'd say I'm more optimistic now that we've sort of got the proof of concept out that we can do realtime proving. And the thing that we

should be focusing on now is security. Like we just need security. The chain just can't go down. This is this is one of our requirements. Um are those all the questions? Okay, these are all the questions. and