zkEVM fundamentals - Cody and Ignacio

I'm also starting the back up there and yeah, welcome everyone. Okay, thank you so much for joining us today in this uh intense week of the study group. So this week we actually have three talks. Matano cryptography on Monday and yesterday we already had one lean session but today we are looking more onto the execution side with the ZK EVM. So my great honor to have two guests here today.

We have very special session with two speakers Cody and Ignasio from the ZKVM team from Ethereum Foundation. Um and uh yeah today we will dive into the actual design architecture of the ZKV VMs. We heard a lot about it. So uh finally we will understand some of the cryptography and the uh protocol that goes into it. Folks uh the stage is yours.

Please go ahead. We will have questions in the comments. I will bring them up later. Uh if there is something people can also raise their hand. So just um feel free to feel free to speak and then uh if something comes up I will let you know.

Uh, you're muted, Cody.

Yeah, thank you. Uh, thanks for the invitation. You can hear me now. Yeah. Yeah.

Uh, yeah. Thanks for the invitation. I'm I'm excited to be here and I'm excited to see so many unfamiliar names in the in the crowd. Thanks. Thanks for uh joining.

So, yeah, here's a QR to these slides. You should be able to view these in web browser. And here's a link. And also links have been shared uh in the chat here and on Discord. So let's go.

Um if I can advance. Here we go. Right. So uh Ignosi and I will split the presentation roughly in half. Um, I'm going to set things up talking a bit about uh why we want to use ZKVMs and then I'll give a bit of a highlevel description of snarks in the history and then Ignosio will take over to tell us more about um some of the specifics of how uh we're doing this in the context of of proving Ethereum and what changes are coming our way to um work uh to help to help us ship ZKEVMs.

But yeah, overall the the presentation is quite Ethereum focused. I think there's a lot of quality material on Snarks and ZK in general and um I hope that that specificity will be really interesting to this crowd and and maybe make some of the um aspects a bit more explicit which can be helpful for understanding the generalities as well. All right. So, just to say it once and clearly, our goal is to allow the EVM to execute more compute per block while keeping the work done by the consensus network small to preserve decentralization. That's the goal of the L1 ZKVM uh project.

And so, what is the what are the requirements on the tester network? Well, here um this is excerpted from an EIP. And here you can see what the uh requirements are. This is a suggested set of hardware requirements for an tester. You need um you know this memory, this kind of CPU, this kind of internet connection.

And it's not um it's not a you know I think this is attainable for for many many people but it's also not trivial and um we care a great deal about keeping these requirements low because we want it to be easy for people to get the um setups necessary to participate in uh Ethereum in the maintenance of the network. Um so what is what does that mean more specifically? Well, uh, if we allow more transactions and really what I I guess I could be more precise and say like more compute in a block, um, well, that means uh, you know, if if if we don't increase bandwidth requirements, then at some point the and I'm speaking naively here before ZKVMs, at some point uh, the testers wouldn't be able to receive those transactions and at some point their computers would not be able to handle transactions even if they did receive them in terms of actually executing the computations and also at some point I mean the state uh grows to be too big and things begin to break um and so I wanted to say I mean uh I don't I don't expand on it here but uh we don't fix state growth with uh this L1ZKVM scaling project we actually make it a more immediate problem if we scale so this this is just to call this requirement out. This is a um another big issue for Ethereum to solve, but it's not what Ignosia and I will tell you about today. And so how do snarks help this?

Well, there is an asymmetry that ZKVMs and ZKVMs are a particular implementation of snarks. I'll say what all this all these words mean a bit more in future slides but to set things up um they allow this asymmetry where you can have a network of low power nodes and those are going to be verifiers checking the work of powerful nodes provers and doing this with not a lot of data and so you can see how this sets us up to resolve the issues on the previous slide namely the verifiers um they can check the work of of some provers. Those will be new um entities that are have a lot of computational power, but they don't need to be trusted. The verifiers can with low resources um trustlessly receive the claims of the provers and check that they're true. So to say it more explicitly, in our application, a testers are going to be running verifiers and they're going to verify proofs and proofs are going to be produced by provers.

Um, and we're deliberately vague about I mean where who where those provers are. There there's not a prover entity being added to the protocol explicitly. Um, and there's a big design space there and a testers are only going to need a small amount of data to to do this work of of checking the pro uh the proofs. So in particular, they're not going to need the whole block. So let's just be a little more um precise.

So without CKVM proofs right now blocks are about on average and this is a link where you can see the block size. This is a nice histogram. We have so much great data in Ethereum and so many great dashboards. You can always find something like this. Uh it's awesome.

Um so right now they're about 175 kilobytes. And there was a cap placed um recently through this EIP that sets the the max size here. But this is under some really adversarial setting. Um typically uh the this max won't be achieved but still um you know we're talking maybe that block sizes can increase realistically up to this value and and even in non-adversarial settings you know maybe we get tripling of this of this size here. Um so under currently allowed configurations um and so yeah higher gas limit means well more more stuff can go through so blocks are going to get bigger um and that means the data as things are now the testers have to receive more data but with GKVM proofs uh the proof sizes well right now we're targeting 300 kilobyte proofs and this is actually configurable because the the protocols have some parameters that can be set to to decrease these proof sizes.

Um so they do grow slowly and it's a technical sense like like log squared. Um but that's a manageable growth as it is and we we can trade off and ask the proofers to have a bit more compute to actually control this proof size. So it's something that becomes um under our control. And this this replaces um uh this replaces the the this sort of constantly growing like linear size object. And then so we we only need some summary data of the actual block which is very small in comparison to this proof here.

So we we achieve some constraint on the bandwidth through this uh proposal. Um and I I I suppose I should have said actually Oh. Oh dear. Okay. I I should have said maybe a slide here, but also the compute that the verifier like checking the proofs is is very lightweight as well um and grows slowly uh with with the inputs.

So it's effectively constant. Um great. So yeah. So how do we ship this? Well, I can I zoom I can't unfortunately zoom here.

Well, if your screen is larger than mine, uh I I just linked to the straw map. This is something that was published by EF Protocol architecture team uh I think about a month ago, maybe a little more. Uh and right here we have optional proofs. This is sort of end of this year going into next year in the H fork. Um we have optional proof shipping and then later on after another one two three forks we have mandatory proofs and that's expected sometime in 2028.

And the difference is that in optional proofs we have a network that has proofs flowing around where it's possible to um you know with some kind of asterisks in in most in most cases it's possible to actually operate the network on on those proofs. Uh but we need some more protocol changes to make that 100% true. But we have optional proofs and the main goal is to have the network in place and to ga gather a lot of data um on how provers perform on how the network performs under this load of proofs and to just to just watch everything function because it's a very big change that we're proposing and we want to be extremely confident in it and then later on those proofs will become mandatory. So in this gap here we can't actually scale uh based on the use of zk proofs but at this point on mandatory proofs we can right because um everything's in place and sca oh I I seem to have lost my timer when I hit the well I think I have 10 minutes off of this or so yeah um so so at this point we can begin to scale based on proofs. Okay so that's the uh end of the sort of overview.

Now, Ignosia is going to go into much more detail on on some of the specifics of um of the Ethereum upgrade, but for now, I'll I'll talk a bit about ZKVMs um and snarks to give some background. So, yeah, as I said in the introduction, I I don't think there's much value in me giving like a sort of first principles, you know, miniourse on snarks. There are a lot of really high quality resources out there. Um, you know, there's like the ZK whiteboard sessions video series in particular. There's Justin Taylor's book.

And if you want to go about this as if kind of like as a theoretical math cryptography um study like you have great resources and uh yeah so I'm happy to just give us maybe a sort of pocket guide to understanding these things um that maybe opens up the door to uh I don't know like uh participating in conversations without fully understanding the technical details. So one word is snark. This stands for succinct non-interactive argument of knowledge. And I define that here loosely as a logical argument that allows one party a prover to convince another party a verifier that they they being the prover did the work of executing a particular computation. Um and moreover I I didn't say that I mean that a snark is this but this definition is missing some key uh components namely succinctness like the amount of data that needs to be sent is small in a technical sense and the work of actually checking the argument is is low but a snark is going to be this this kind of thing right that meets our requirements and um I'm being a bit hazy sometimes times you'll hear the word snark used for the proof and sometimes for the protocol.

It's it's just it's a whole field where some of the terminology is is not fully precisely used and as is typical. I don't see or hear anything Ahmad others can hear me right and see.

Yes, we are all good. Yeah. Yeah. Um I'm not sure if Ahmed joined late or has some troubles but it should go right.

Okay. Um yeah, sorry for that. Um, maybe somebody could at least share the slides. They're in the Discord. I'm not I guess you can't hear me.

Um, so yeah. Okay, a ZK snark is going to be a snark where the prover is able to keep some of the details of the computation private. And um, to make a zk snark, you have to do extra engineering and the the prover has to do extra work. And zk snarks are much less commonly in use than snarks right now. most of the applications that that you encounter um well this is changing I guess with privacy becoming um a forefront topic but at least historically uh a lot of the snarks that were built did not have the zk property some notable exceptions would be like Zcash and and Aztec providing these private snarks so zk is a term that's used uh sort of abusively to refer to all of this so even even uh like the field is return referred to as ZK.

We have the ZK podcast and the ZK whiteboard sessions. And I think it just sort of feels like a more I don't know grammatically correct thing than referring to it all as snarks. Um but it would a different term would be less less confusing. So ZK is used in the context where we don't actually have privacy. Um and therefore I feel it's always necessary to uh emphasize that difference when I present.

And a ZK stark. Okay. Okay. So, what is a Stark versus a snark? Well, the T here stands for transparent.

And uh this term Stark was introduced at a time when the dominant constructions in the world of snarks were um using uh constructions that have a trust assumption built into them. And it's a it's a a trust assumption that there's at least one honest party in the construction of some trusted setup. it's called, which is a piece of like public data that's necessary to actually execute the the snark. And it's not ideal to have that. And there was a breakthrough to produce um protocols that were uh viable for the same applications as snarks, roughly speaking, but that did not have this assumption.

And so you'll see this term, but you'll also see people using the term snark broadly to refer to all of this. And and that's the convention I like. It feels very uh inclusive. and as EKVM that's a particular appro uh approach to implementing snarks. Um and we'll get we'll get more to that soon.

So all right uh here's a just a rough history on one slide and I share it really not because I'm an expert on this but because I think it's pretty interesting and and fun to position ourselves in this history. So it's generally agreed upon and by the way I wanted to kind of collect a bunch of useful links for people in one place too. So, so all of these will take you to references. So, it's widely agreed upon that this is the beginning of of snarks in 1985, this paper of Goldwall and Rockoff. And then there was another breakthrough.

Uh, at the time I I think it was just purely theoretical this this breakthrough um introducing a protocol called Sunche, but it's actually become an extremely powerful tool um in the current constructions is maybe becoming even more and more in use. you can find papers saying like sum check is all you need from one or two years ago I think um so that was you know a handful of years later and then as I understand it um and I was pretty young during this period uh I there wasn't all that much happening between 1992 and the late 2000s at which point Yens started um publishing some uh some breakthrough papers and also we had the KZG this is some author author's names Kate Zavarucha Goldberg uh polinomial commitment scheme which is a really core piece of um of the puzzle at least um prior to uh to Fry but it's still very much in use um for people who accept a trusted setup and I can also recommend this paper is a very lovely starting point it's it's beautifully simple and and short and uh I think it's a great a great place to look if you're interested in getting into the the theory a bit Um, and then we had uh Pinocchio, which I've heard called the first sort of nearly practical snark and the zeroache paper coming out a few years later. And then we had Zcash launching a few years after that. Somebody's microphone.

Yeah, sorry about that. I'm unmuted here.

Yeah, should be okay. Yeah, there we go. Should be good. Thank you. Um, okay.

Yeah. So, so then we had Zcash launching and this is a private uh private blockchain with um yeah a native asset called Zcash. So you can make private transfers or um yeah and then it was around this time and this was using some older technology something kind of like Pinocchio if I understand correctly. uh and then eventually transitioned to oh did I not mention GRO 16 that's a shame well in 2016 I had this before on a slide there was an incredibly important paper called Grot 16 that came out um which is still in a sense of proof size I think is the state-of-the-art um and it has some serious constraints but is still a very viable option for some applications grow 16 um and then also I thought it was fun to collect some early ethereal references. So, I looked at really old Ethereum blog posts and uh some early ETH research papers to try to see what the conversation was like in the really early days of of Ethereum around ZK.

And you can look here, it's kind of fun to see. And then say uh let's say that the current era begins around 2018 um in terms of the the technologies that are in use. We have fry and starks being introduced and plon being introduced in this era and this unlocked some serious applications. So we have some L2s and we have the first ZKVM uh well we had ZKEVMs coming out as L2s or sort of powering L2s and we had risk zero as the first um risk five based ZKVM setting the stage for a lot of significant developments in the intervening years. So yeah, um that's all I'll say about history, but I I I like that it's um it's personally pretty fun for me that this is a a field that was sort of really theoretical and that has broken through explosively to some really powerful applications.

That's it's fun for me as a practitioner that to be part of that. Um and in fact I was told when I got into this field that real-time proving was impossible but now we're there with the TM meaning of course there are some you know the last 10% is 90% or something but uh but it's undeniable that we've seen just fantastic progress in ZK and in particular in the context of proving Ethereum with ZK. So this is a live view of the ETH proofs website where you can see that we are proving blocks and verifying them and that this has been going on for many months at this point. So yeah, very excited to work on this stuff. All right, so what about the proof systems?

What can I tell you about those? Well, um let's start with just the and again I'm going to be really high level. Let's say what intuitively interactive proof systems are. You have two parties, a prover oops, a prover and a verifier. And they agree on a computation, right?

And V wants to be convinced that P did the computation, but they're not going to they're not going to accept this fact unless they're really convinced by the um by the argument that P gives, right? And it's a mathematical cryptographic argument. Um, so you know they have the some public description of the computation and then P is going to write down every step. So they're going to fill in every blank. You can think of the computation as being something like a template and they're going to fill in every blank in the computation, you know, to show that they actually that they actually did the work of computing all the values that well I mean the computation is the comput is the computation of these values.

So they record the values and then they're going to exchange messages based on this. Okay. So it's going to be a game they play. Um and P the prover the set of the messages that the prover sends is what we'll call the proof. And so a typical kind of aspect of the exchange like each part of the exchange looks like this bit.

So V the verifier says okay use this random number that I chose you didn't choose to do some math and then send me the result and then I'm going to check that the result satisfies this formula right the the provers the protocol and so they know what sort of math the verifier is going to check and the protocol is designed in such a way that the prover has to say well okay even if I had all the computers in the world the only way I know of to make a result that satisfies that formula that you're going to check is to be honest. So I have to do that, right? The only way to lie is to have computational resources that are in infeasible for the the prover to to acquire. And yeah, I mean you should always ask, you know, if you're analyzing protocol like why why is this what's the this particular what is the particular instantiation of this exchange here? You know, like this this is the core idea.

And so what are non-interactive? Remember I said snark said succinct non-interactive argument of knowledge. Okay, so the goal is to avoid having the prover and the verifier communicate over a network. Right? If you're actually going to do some um synchronous interaction, then you introduce all this complexity of having two parties that are listening across a network, there's latency.

Um and so non-active arguments solve this with some theoretical cost to that. So the solution is that P sort of doesn't get messages from a live prover but rather they simulate this prover by using an outofcontrol function like a function whose values they can't control in a precise sense. Um and these are hash functions right and uh you know we these are just an absolutely critical part of really global infrastructure the hash functions they um but there are many of them and they've been in use for a long time and they have this property that you know the prover can't that the outputs are really insensitive or I should say they're very sensitive to the inputs they change uh very chaotically so the prover can't really like design the output of the hash to fool the verifier And so the proof and the verifier are both going to use this hash function to avoid having to communicate. Um and so they do this rather than asking the verifier for the random values. And [snorts] um and yeah, I mean that's basically how you how you create a non-interactive version.

So then the prover is going to uh to do the computation sort of replacing the verifier by this hash function. They're going to send all of their messages and then the verifier is going to like replay um the prover like the their side of things using this hash function and they're going to then pick up and check the um the verifiers algorithm and it's as if they had interacted um synchronously in in an interactive protocol with this extra assumption that the hash function is is a good surrogate for this interaction. Okay. So, so yeah, I mean let's talk now about the snark in in skeletal terms. So I said that the prover and the verifier agree on a computation.

What does that exactly mean? Well, you know, it should be a computer program. But it's important to call out that the sort of programs about which we have good hash function or not good hash function good good snark protocols are pretty different to the the programs that metal silicon computers execute and namely the the protocols are described in terms of arithmetic circuits. So what that means in practice is that you know traditional programs things are built up from logical operations and uh and you know boolean logic and in arithmetic circuits the core things are all numbers and math operations like addition multiplication subtraction division and so on. So we need a way to write these programs and that's a really non-trivial um task.

So um there are languages for writing these programs. Um some well-known ones are called circom uh noir cairo and then you have sort of the languages attached to particular proving systems. I call out narc here but you know there's there are a lot of them and um so the tooling so this means that you're using programming languages that aren't very common and that of course is friction for developers. It seems like things are improving, but there's there's no denying that the that it's that things are fragmented and um you know using a novel computer language is is an ask relative to using some commonly used languages. So we'll we'll come back to this point.

This is what ZKVMs will will help us with. So okay, what about sort of proving? What is a high level outline of proving? Um well, you have a step called trace generation. So you have your arithmetic circuit, you have your computation ready for proving and now what you need to do is actually fill it in.

All right? And that this is often called trace generation, tracing, witness generation is a term that's in use. And that's actually very common in the snark literature, but I'm avoiding that term here because we use the term witness and Ethereum for something related but different and and specific to Ethereum. Um but what you have to do is you have to go through the computation and execute every step and record the intermediate values in something called an execution trace and this is interpreted as a collection of polomials where polomials are the functions that you encountered in schooling um you know they're functions with a particular simple structure you can write down um using you know very small formulas typically. All right.

And then what happens is that okay, we have this data and then and again I mean there are so many permutations and and particularities of different program or protocols. I'm trying to just be general enough to give a good idea. So um said sort of uh imprecisely you have your your polomials representing the execution trace of of the program that you're trying to attest to. Um and you now commit to those. So you create a binding cryptographic fingerprint of that trace data using a polomial commitment scheme like KCG that I mentioned before or technically FRA is something it's not quite a PCS a polinomial commitment scheme but you can build commitment schemes from FRA and there are many options.

So then maybe the next step is reduction. So you want to reduce the work of checking the logic at every step which the verifier can't do because they don't have every step that's purposely not being sent. That's where the succinctness comes from. So we need to reduce the work of checking the logic to somehow uh some some simpler statement. And speaking vaguely this is this is done by checking the computation sort of at a random point.

And so once you've done this kind of check then that let's call that check spot checking. Um so you sort of check the logic of the computation is valued at a is correct at a random point. It's valid. Then you finally do a PCS opening where you link the data that was committed to to the um to the uh to the values that were used in the spot checking. And then altogether with some careful security analysis you get that that this should convince the verifier that the prover did have all of the witness data and that the witness data did satisfy the arithmetic circuit program that they agreed upon from the beginning with sufficiently many bits of security and so on.

Okay. So now to just take another pass and and um editorialize a bit on it. So trace generation right now for us is a pretty expensive serial bottleneck. Um it's one of the main engineering considerations when you're building real-time proofing of Ethereum and it returns polomials and those polomials can be univariant polomials or or multilinear polomials and that is an important engineering decision that is actually also a decision about the snark protocol. the commitment computation.

Well, we have Frybased uh polinomial commitment schemes or uh an innovation on that that is a significant improvement is werebased polinomial commitment schemes. We also have KZG and various like multilinearizations of KZG and we have highracks and there are many that have been published polinomial commitment schemes. I'm just calling out some of those that are most used at this point to my knowledge and I may well it's a big field I may well be missing something that I don't mean to exclude anything um in particular and then reduction well uh you have what's called a quotient argument or you have the use of sum check to kind of make these reductions and spot checking where you then evaluate the constraints at a random evaluation point and finally then you do this PCS opening and concretely that comes down to checking Merkel proofs and maybe some fry folding steps like some small bit of arithmetic or if we're accepting a trusted setup typically this involves computing an elliptic curve pairing okay so bunch of keywords I hope it's useful to kind of collect them together in a meaningful way here all right so then how do we actually put this stuff into practice well okay I mean that's a question of application Right? And different applications have different requirements and the snark and engineering decisions that you make around it have to be informed by those requirements. So what is some of the design space?

Well, okay, how do we write programs for proving the programs? Um so do we want to use a domain specific language or do we want to um use something generic where maybe there's some overhead? Um, do the applications need privacy? That affects where the computations will be executed and that feeds back into the language that could be used. Like how efficient do we need the circuits to be?

Um, and also how like how do you design the proof system? Um does it need to have low memory footprints or do we need are we okay with having um higher uh requirements on the on the computational um infrastructure so that we can have say like faster performance that that's a big trade-off and we need to know where the program will be proven. I guess I I just spoke this one I didn't flip. Um we also need to know where the program will be verified. Um and often in some applications there are many sort of sequential verification steps and where those happen matters.

Um because we have to think about how big can the proofs be if we're sending them around a network. Yeah. Okay. So then where do ZKVMs come in? Well uh the goal is to allow developers to write programs using normal programming languages such as Rust or C++ or Go or Java.

Um and that means that we need to produce and like something from them that can be proven. And what this does is unlock robust maintainable systems because well I mean the thinking is that more developers can um write this program and the language will not be as brittle component uh and there will be um you know you'll have faster turnaround time. you'll have um tools that are used by millions if not billions of people in the in the pipeline um that others will maintain you know uh so I just said this part but you know the reality is that um there is overhead to using a virtual machine approach uh but it's it's tolerable and overall it's very it's been very successful for our applications for scaling Ethereum And um well you can use these languages but you have to be a bit aware of the fact that you're targeting ZK and even that you're targeting Ethereum in particular um in some cases like we you might need to use accelerators for specific um uh operations that we care about a lot in Ethereum like catch hashing and there is go support it's improved improving um in recent weeks, but it's been it's been not very strong till now. Uh yeah. So, let me now say a bit about what the picture looks like.

And this is just a cartoon. Ignasio is going to pick up as soon as I'm done here uh to make this more precise. But roughly speaking, what you have is um and I'm and I'm making some choices. So, I'm saying we have a risk 5 VM because that's a canonical choice. Now though other architectures are possible but the prover now it you want to take the EVM and you want to shove some information into it like the block and then the state before the the state update and then the EVM implementation and you know the stuff around it the EL will uh update the state using this block right so you know right now we just have this little middle piece here and what we're talking about in uh when we want to prove Ethereum in ZK is to wrap this in a prover.

So what the prover does is observe the execution of the EVM and then produce a proof and this is what I call trace generation before right it observes it produces a an execution trace and then it spits out a proof after sort of operating on that trace. Um and how does it observe the execution? Well, the EVM is a program, right? The state transition function is a program. And uh that program needs to be uh turned into something that can be observed.

And the key thing here is to use yet another virtual machine which I'm saying uh could be a risk five virtual machine. And risk 5 is an open instruction set. uh that is uh it's it is in use. I've heard there are billions of chips in of risk five already. It's growing and it's an open standard as opposed to some of the standards that are controlled by big organizations that are more common um in uh actual computers these days.

Um, so we're using this open standard and we make a a machine implement or sorry a software implementation of this of this risk 5 computer and then we prepare the EVM function to be executed inside of that machine and then that machine is wrapped in this prover and really the ZKVMs are the ones implementing both the machine and the prover and they say give us your give us your program and then we'll produce a proof of execution. So this blue thing, this is called a guest program. As I said, Agnosio will say more precisely what's in there. But then once we have this, then the verifier just needs the proof and it just needs some roughly speaking some um roots of trees and a hash of the block and then the description of the program. And then the verifier can say, I don't know what was executed, but I know that this transition from this pre-state to this post state is valid.

Um and then the network can proceed um with the big assumption that the attesters, you know, yeah, this isn't a tester executing this verifier. The network can proceed under the big assumption that this all of this new software is correct. So that's what we're working on and uh I'm very excited that we're close to to bringing this into production. So yeah, maybe one more thing I could briefly say is that the um that the one benefit of this approach is that now it's not as if there's an arithmetic circuit for the EVM implementation, but rather there's an arithmetic circuit that describes the actual risk 5 virtual machine itself. So we actually um you you can argue that there's a smaller surface area for bugs.

Um, and I buy that argument. If we implement the virtual machine and then plug in the programs to be executed by that machine, it's just a static target that can be used for proving any kind of program. So yeah, with that I will hand it over to Ignasio and thank you for your attention.

Thank you so much Cody. Um, yeah, that's awesome. Let me maybe just tackle a couple questions before we move on. I'll take a minute maybe to get some feedback from people. Folks, if you have any thoughts, any questions, feel free to raise your hand or write them in the in the comments here.

Um, we had a question from Astrion before um about uh the verifier that the ZKVM tester doesn't verify the C network at all, just verifies the proof. That was for the part.

Yeah. Right.

Yeah.

Yeah. So the verifier has the proof and the proof says that this um this summary of the state of the network before leads to this summary of the state of the network after. Um so the the verifier has to plug in like the the roots of like the state roots before and after roughly speaking though the Agnosio will correct this shortly but it doesn't just check the proof. has to actually have some information about the the state before and after and that's enough for it to know that the state transition was valid.

Yes. So basically it's just verifying a proof. You don't need to know about this state. That's the that's the heck that we have. So basically a prover machine is a VM EVM uh in another VM risk VM machine in the prover itself.

Um it's a comment if you want to elaborate on that maybe feel free to also raise your hand guys.

Uh yeah that that's accurate. I'm glad that that was clear.

So and what happens to the transactions where the transactions themselves get stored because those still have to be available right? So is there like alternative meool or

well yeah I mean I'm only speaking about the work that the testers have to do but yeah the transactions still need to be out there and you know you still need to be able to build blocks and so on. So this is just about the sort of checking component.

I understand that we've uh trying to make dev right with normal programming languages ra C++ Java. But what about the paradigm shift of writing zkm program? Wouldn't that be quite challenging even for solidity devs?

Well to be clear um solidity there's no change there. Um you [clears throat] could ask about replacing the EVM by a risk 5 VM. is something that Vitalik has raised but this is not what we're working on. Um there is a belief that it would make the ZK proving more efficient. There are reasons to think that but in the moment there are still solidity smart contracts.

Um you know you can still use solidity and deploy and proven ZK. It's not affecting that at all.

Hey awesome. Maybe I would I would just uh add one quick question because I've been I I've seen this discussion before in like earlier ZKVM or ZK chain uh uh discussions that basically some languages I don't know maybe noir or uh some designs are more like uh low-level in the math uh circuits level basically where you have a different paradigm you cannot use the regular style of programming but you get much more optimizations or efficiency do you think that like this sort of um trade-off is real. Do you think it would make sense to have some alternative tools?

Yeah, I think this trade-off is real. Um, and maybe for Aztec where you know you want to prove in hundreds of megabytes of memory and it has to happen in in web assembly it makes sense. Um, and I for Miden I don't know how Maiden solves this but they have a VM model that uh that I think is also is also viable. Um but yeah, there is a real trade-off there. But for Ethereum, I think the the where we should land um is is quite clear.

The VM model is is working and I think it's better.

Yeah, of course. Yeah, it makes sense. Okay, that's great. Thank you so much, Cody. Awesome.

And u Ignasio, if we have you, we can can continue.

Cool. Uh can you hear me correctly? Correctly.

Yes. All good. All good.

Nice. Uh well I just want to repeat again saying thank you for Mario and SH for inviting us to give this talk and yeah also hope that this will be useful for a lot of people here. So uh now I will talk about um what is this Ethereum guest program that we are pro that we are proving and also which protocol changes uh we are kind of thinking about uh that will be needed to make this real. Uh I have a lot of ground to cover so I have to go pretty fast. Uh that's kind of intentional to really be able to touch on a lot of things that that we think are are interesting.

So you can maybe dig on some stuff later uh by using the slides. So uh as a quick like super high level refresh on how the network works today. Uh Cody already touched on this a bit so this is just a refresher. If you want to run a node in a network, you need to run two software, the CL node and the Y node. And briefly, the way it works for a tester is that it's listening for new blocks u in the network.

It does some checks and at some point you have to verify that the execution of the block is correct. So you have to validate the block. Uh the way this happens is that the CL use call um uses an API from DL called engine API and basically sends the block information to DL. Um DL gets this block, executes it uh and then verify that the its own execution is coherent with the block header that was uh received. And uh as something to highlight here is that the L has a full database of the Ethereum chain.

So this basically means that the L software needs to know all the balances, all the nonses, all the bite codes, all the storage slots of contracts. Um because basically since it can receive any block, any block can contain any transaction and any transaction can potentially touch any part of the state. So that's the reason why you need a full state and at some point it it returns hey I think this block is correct and the CL does some extra stuff and send the stationation to the network. We want to move to a future where uh this is the way you run a node in the network for a testing or validating the chain. You would only run the CL node and instead of only receiving the full block you will receive let's say like the block header.

I will touch more on this later. Plus this proof that Kodi has been explaining. And what this proofs does is basically allows you to have an equivalent assertion of what you are doing today with this API call. So this verifying these proofs basically means something equivalent to calling uh an an E node with the full database to validate the block. So um yeah Cody already touched on this so I will go pretty fast.

Um using this technology is pretty useful for many reasons. Uh we can think about it in multiple dimensions. on the CPU dimension uh it exploit this prover referring a symmetry uh so we put more effort on the proving prover side role in network and we make 95% of the network which is a testing life easier. So they they verify proofs um uh in a way that the proof verification has constant time and is quite fast and this constant part is really important for for gas limit increases because we are untangling gas limit from proof verification which is pretty different from re-execution where re-execution cost is linear with the gas limit. Um so apart from that apart from CPU resources uh savings we have storage resources are being liberated because if you are not running an EL that basically means you need this full database.

So this basically means uh yeah uh most of the network don't don't have to really store all the um Ethereum state and I'm sorry regarding network resources uh the proof size is rather small. This is like in quotes because if you compare it to the current block average size might not seem that small but I think it's kind of interesting to think about that instead of having to propagate the full block which size increases linearly with the gas limit now we have to propagate a proof which has constant size. it might be like somewhat big compared to the block today but I think it's some somewhat interesting to know that now the bandwidth the bandwidth usage in the network is somewhat predictable um so yeah I think this is some something really interesting to to consider uh as also cod touchs don't solve all the problems over Ethereum uh in particular cigms have uh I think accelerate an already existing challenge which is who holds the whole state in the network right because as I explained before a test don't really need to hold the whole state but there are other roles in the network that are pretty important but they do still need to hold the state so one of them is RPC nodes or chain explorers um because I know if you are an RP RPC node you can receive whatever query is possible asking for any part of the state. So clearly for serving RPCs you need the whole state or if you are a block builder clearly you want to grab a graph um a set of transactions from the main pool of some private flow and a priority you don't know these transactions which state they will touch. So that basically means you need the whole state to rebuild the block.

And um yeah regarding state growth and stage size, the state growth will continue to exist even after we create the proofs because the state grows as we execute more and more transactions in the chain because we don't have any kind of state expiry solution yet. So we have this critical questions of okay if 95% of the network now which are testers are not really holding the state who is holding the state how many people are holding the state which are the implications for no syncing if you want to sync the whole state and I will leave this as an open question uh that I don't think we have thought about about it more uh but maybe cigiums can unlock unlock some new ideas here. But just want to make clear this kind of challenges is a challenge of any kind of stateless solution. CDVMC is a particular solution for statelessness in the network. But if you remember some years ago we had burl trees uh which is also was also like a stateless solution and with burk trees we always we also have all these kind of questions because uh the the the the main problem here is uh statelessness right because most of the network doesn't have to hold the state.

So if you want to if you want to know a bit more detail about like what proof verification latency is uh we have some dashboards that you might find interesting. So here uh here you have the link so you can visit it later and see it uh in with more time but in the left hand side we have a bunch of cigms and uh here in the x-axxis you can see the verification time of the proof and in the y-axis you have the cigms uh you have two kind of points you have circle points and triangle points uh each of them corresponds to different machines which satisfy the IP that Kodi mentioned before about the hardware data testers run. And basically you can see that verifying proofs is pretty fast. But the most important part at least for me to highlight here is that this uh these proof verifications are for 500 mainet blocks with different gas usages. But you can already see that the proof verification is rather constant.

And that's one of the most like important traits of all this technology right is that proof verification is constant uh regardless of the gas usage of the block. Um and a part of being constant is pretty low. And on the right hand side we have a bit more details about the mean and median proof verification time. But we also have proof sizes and security bits which is rather important to have in mind because of course if a particular CDVM is not yet ready and has like pretty big proofs well clearly we cannot really compare the proof verification time with another CDVM which has a smaller proof size right and the same happens with the security bits uh we have some target for security bits which is quite relevant for proof verification too The security bits are gathered here from the sound calcul project. Uh this project is run by the cryptography team in the F.

So if you are interested in security bits and things like that, here's a link that you can look at it later. So let's dive a bit deeper about what we are trying to prove. So as I mentioned before uh this is the current situation of how the network uh works and there's like this particular step where the CL calls the engine API in DL to verify a block. In particular the the API that is used in this step is called engine new payload. Uh this is for our testing.

So basically in this uh API the parameter is called new payload request. We will see later what is this which which things are in here. Uh but basically you can think about it. It is kind of sending the the block with the transactions right. So what the EL does whenever it serves this API is it does some checks of this input to check some internal consistency that I will explain later and then it kind of does a transformation from a CL domain types to a domain types.

So in particular is kind of constructing the EL block from the CL types and after we have the EL block it does the state transition function which basically means taking the L block and executing it and verifying that it's correct which is what most people understand that the are doing in general. So if you have to remember a single slide from this part of the talk, it's probably this one which gives you a pretty accurate mental model of what the guest program for Ethereum is doing. So clearly if we if we if the goal here is to replace this step with a proof then uh what the guest programmer should do is basically whatever the engine API API call is doing, right? This is the clearest way of thinking about it. So um the guest program is yeah just like a program coded in whatever language and it has these private inputs and public inputs.

So the private inputs are basically inputs that are sent by the prover. Uh so we have the new payload request which as you see is like the same input that the API receives here. So that makes sense. uh it has this public keys and chain config which are some optimization inputs and configuration stuff which doesn't matter much and then it has this execution witness input. Okay, so you have the new payload request and the execution witness.

This execution witness is basically all the state that is required to execute the block because uh remember that the guest program is simply a pure function, right? It's it's just some code running in a sik VM and this this guest program doesn't have access to the external world. It doesn't have access to a database. It doesn't have access to network. So everything that is required to execute the guest program must be receiving via inputs.

Okay. So of course whenever you are executing a block you will require balances storage slots and things like that. So we'll dive more about this on on this later. And the public inputs are the inputs of the guest program that are visible to the proof verifier in this case the right. So uh the shift here is that the public inputs are a hash of the new payload request.

So the CL knows that the proof was done for a private input that corresponds to something that it expects, right? Because the CL wants a proof of a particular new payload request. So the way to link them together is to check that the public input hash corresponds what it wants and is valid is basically just a boolean saying is this block execution concluded that the block is valid or invalid. So usually this is valid is expected to be true. So let let's dive a bit more into the stuff.

So if if we look at like the first part of the guest program which what I usually call like the ancient API part uh we have the new payload request which I know if you already know about CL stuff you might recognize this strct. So basically has the execution payload uh have the version hashes of the uh data sampling um done for blobs and you have some other fields uh required for for the L. Uh the execution payload fields are kind of pretty similar to the L block. Uh usually like a onetoone correspondence and basically what this step does in the G program is to validate some internal consistency here. For example, it validates that the version hashes uh corresponds to the type three transactions of the execution payload.

So all this is all logic that exists in the engine API. And then it transforms this input into the E domain which basically means the E block. Uh so it's basically a transformation from these tracks to these tracks. And after we have the E block, we can jump into the next step which is the state transition function which is executing the block. So the state transition function is something that I guess most people here already know what it means.

So executing a block can be thought about in three main stages. We have the pre-transaction execution stage where we usually call system contracts like EIP 2935 and and things like that. After that we basically execute the transactions. This is these are all like screenshots from G if you're interested. You basically uh have a for loop with all the transactions.

You execute this transaction and collect the outputs. And then after you execute the transactions, you do some post transa it it process withdrawals. Uh it um it does the block rewards and things like that. And basically after this execution finish, you have a bunch of results and you basically check that your re-execution results matches whatever the block header has. So for example that the new state route that you calculated in your reexecution matches the state root of the block.

So all this is this state transition function. Now if if you look at things here you might have noticed this part which is shaded which says execution witness validations. So notice that whenever you are re-executing a block, you have a database with the whole data of Ethereum that you use to execute the block. And there's like an assumption here that you trust that the data of your database is correct simply because you it's yours, right? You constructed it.

But in the case of the guest program, you receive all the state required for executing the guest program as inputs. And these inputs uh cannot really be trusted, right? Because I can give you like some particular block with one transaction that sends it from my account to call this account and that block is valid or invalid maybe depending on what I receive in the execution witness, right? because I can receive that my balance is too low and that transaction will fail or the prover can send another execution witness saying that my balance is very high and that transaction will succeed. So uh clearly the guest program should also have a way to verify that the execution witness so that the chain data received is actually the correct data for the block and not some arbitrary data.

[sighs] So what is in this execution witness thing? So this execution witness has three main fields. It has uh the ancestors or this should say headers but it's the same but the name doesn't matter. It has nodes and it has by codes. Okay.

So let's think about this for a second. Whenever you execute a block what which is the kind of data that you will need? So uh well clearly if you in some part of the block there's a transaction that calls a smart contract then you need a by call that seems pretty obvious. Uh clearly whenever uh you do a transaction you will need to know no uh accounts balances or nonsense. So you need things from the state tree and you need uh ancestors or parent headers mainly because you have to do you have to call system contracts uh because EIP 2935 is related to storing parent hash in a system contract but also because there's an op code in EVM called block hash and this up codes allows the EVM to access uh the block hash of parent blocks up to 256 parents.

So whenever there's like an block hash up code execution in a transaction clearly this this block hash execution might ask for parents uh parent headers parent block hashes uh but as I mentioned before we cannot really give this data in face value let's say like only like the raw data we need to also provide extra information that allows the guest program to verify that this data is correct. So in the case of ancestors is pretty obvious. So let's say that we have a block hash execution in EVM that asks for the parent block of the current block that we are executing. So uh what we have to send to the guest program is the parent parent header and the parent header and we have to check that the current block parent hash matches with this parent that I provided and that this parent parent hash checks uh the block hash of this parent parent. So you basically verifying the the whole chain.

This is the way you verify that the ancestors data is correct. For the nodes it's pretty obvious. We apart from giving accounts nonsense balances and things like that we provide an MPT proof where the MPT proof root node is the parent state root right so recall that in an Ethereum block today whenever uh you see the state root field that state root means which is the state of Ethereum after this block is executed. So basically for the current block if I want to prove that before the execute before I start executing this block the balance of some account is X I have to provide an MD proof where the run node of that MPT proof is the state root of the parent header which is like the pre-state of this block and finally for by codes uh the by codes are not really part of the state tree uh but u the way to link them into some provable claim is that you have to hash the provided by codes and check that the hash corresponds to a cold hash uh field of an account um in the in the account MPD uh because yeah remember that accounts uh in the in the state tree has the nons the balance and the gold hash in the case uh that is a contract this gold hash is not empty and this gold hash corresponds to the hash of the pyon so in this way the programs can really verify that the provided data in inputs is correct and it's mainly rooted in checking hashes using the current block or linking everything together to the parent state route. Okay.

Uh after we did this bulk of the work, we have to do some extra last step which is calculating this public inputs. This public inputs uh calculation is basically proving that the public input that is provided to the proof verifier really corresponds to this private input. Um and the way we do this is we basically hash the new payload request receiving private inputs using the hash tree root. This is a construction um from SSC encoding. SS and encoding currently only using the CL which now is being considered use uh to be used in DL.

And yeah, this is pretty convenient because using a way of hashing that is a mean to the CL uh is the right choice because uh this hash has to also be calculated by the CL whenever it verifies the proof, right? because ACL receives the proof. It receives this public inputs. I want to check that the new payload request that it has really matches this hash of the new payload request of the proof. Uh the reality here is that hash root is also useful for other property that it has where the hash root of the new pay request is the same as the hash root of the new pay request header.

The new payload request header is the same kind of the same of the new payload request but instead of hiding the execution payload with all the transactions it has only um the execution payload header. So it has a commitment to the transaction. So the the the size of this is constant. This is quite relevant for something I will mention later. Uh and also it was mentioned by Kodi that for verifying a proof you don't actually need the whole block and and all the transactions.

um you only require like a commitment to it. Okay, let's say that this is a guest program as I explained but how how how do you know what is this uh what is all this in more detail if you want to write one. So uh we have been working pretty intensely in the last weeks on the specs and tests for all these uh both for the execution witness generation and for the guest program. uh standardizing the execution witness with the specs and tests. Uh it's quite relevant for something that might not be obvious superiority, but the execution witness as we saw here is pretty critical for generating a proof, right?

Because it's one of the private inputs. It's one of the inputs required for the guest program that we want to prove. So the provers should have some kind of clear way of generating this input, right? And we don't want to be in a world where only like one EL has this logic available because that basically means that if for whatever reason we want to approve a block and this E has a bug and crashes generating this execution witness then we don't have any other option that means we don't have we can't create the proof and that means that we we we kind of halt the network in a because we are having some kind of limeiness issue uh because the the the testers won't be able to attest because they won't receive the block the proof I'm sorry. So what we want to do is to be really clear about how this execution witness is constructed.

So many can implement an RPC let's say um a new RPC that uh can generate an execution window for a particular block. So in case that one year has a problem, we really know that um uh we have like many other options that we can switch to pretty fast. And uh also this execution witness is pretty complex as I told you before regarding okay it has to include this MP MPT proofs and things like that. So a lot of things can go wrong in constructing this. So yeah uh the only way to have more central thing that all these things are working correctly is having an spec and after you have a spec you can have a lot of tests to know to really have more certainty that all the else really work correctly and regarding the guest program um you know most of the logic here already exist in specs like the state transition function is already in the execution specs repository but there's a lot of other logic that I mentioned here regarding the engine API stuff all this execution witness logic that is new right this execution witness logic is new critical logic inside the guest program that today uh don't have a spec well today it has a spec because we wrote it but this is something that we have to do uh which was new and this execution window validation is really critical right because if something goes wrong in the guess program implementing this logic correctly, it means that it might be able to accept incorrect data for executing a block.

So for example, let's say that EL for whatever reason don't check correctly the ancestors data. That basically means that a block uh a block hash up code could eventually receive wrong data because there's no correct validation of the provided data and the conclusion if the block is correct or not is false and that's pretty bad because you have a proof of a block that is invalid. So having spec and test uh for the guest program is is pretty important uh for that reason. And the other reason is that we have standardized guest program that means we have a standardized inputs and outputs. So this basically means that with the same private inputs that the prover calculated you can plug and play different implementations of guest programs and that simplifies a lot the infrastructure.

If you want to know more about this, you can see the projectvm branch in the execution specs repository and you can see here the latest releases where you can have like a uh a sense of what which are the things that we are working on lately. So let's say okay we have the specs and tests which which is like the engineering work to make this real. So you have like two approaches on how to build a this program. You can start from scratch and say, "Okay, I will see the spec and write something from scratch in a new language or whatever." And the only thing that you need to do in quotes is be able uh to compile that language to the risim.

Uh this is an approach starting from scratch that is used today by the Vessu team. They are working on starting from scratch writing a guest program in SIG. So if you're interested in their project, here's a link. Um, and another strategy is to say, okay, we already have a uh there's a lot of logic of these cls that can be reused because they already implement the state transition function. What I have to do to really adapt this work to apart from being useful for re-execution also uh be useful for uh being a guest program.

So there are some challenges here because re-executing a block and being a guest program are two different execution environments. So um yeah as mentioned before the guest programs don't have access to the disk don't have access to network. So you have to do some work into reorganizing or refactoring a bit your code. So for example whenever you access state you cannot really assume that you will access the database. you need some abstraction where you can plug a database or an execution witness.

Uh also you have to consider some performance optimization differences because it's not the same what is fast for re-execution and what is fast for guest programs. So yeah most of this work comes from this tension between like the re-execution mode and the guest program mode are two different execution environments. But yeah, uh many ELS like Ethrex or Reth and and GU are are trying to come up with a way to make the same codebase be useful for both execution environments while being maintainable. And yeah, so apart from everything that I said, we also want to standardize the CGVMs. um a couple of cigm stuff.

So remember that you can run a guest program uh on many CGVMs, right? Uh there are many CGVMs out there and at some point the guest program has to interact with the CGVM. So for example, it has to read the inputs or has to write the outputs, right? So what we want to do is to standardize the IO interface for inputs and outputs such that guest programs don't have to have like custom code of how to do particular stuff per CGVM because this multiplies the complexity because now uh Ethrex and G need to have like custom code depending on which CQVMs their EL is being run on. The same happens with accelerators.

Accelerators are basically special APIs that the CGVM provides through the guest program to accelerate particular kinds of computation. Usually these are EVM pre-ompiles which are pretty heavy computation and usually if you try to let the guest program run this with risk five instructions that takes a lot of work to prove. So what CGVMs did is basically provide like a special API that the guest programmer can call and say, "Hey, calculate catchback of this um and give me the results, right? So it's not there's not like a lot of risk five instructions calculating all this and the CKVMs can do whatever they think is more efficient to do that relation. And we also want to standardize the target like which is like the target of risk five that you should compile your quest program to.

Um because yeah if each cvms has their own target that means that all the guest program yells have to now uh deal with okay if I'm using this cvm I have to compile to this if I have this other CVMs I have to compile to another thing. So the the conclusion here was standardizing 564 IM plus an extra extension for uh yeah analy memory access. Uh if you want to know more about this this is super interesting. Uh you can look at this link where the standards are explaining more detail. Okay so that's was everything about the Ethereum guests and what are we trying to prove.

Hopefully that was somewhat enlightening. uh and now let's jump into uh the protocol changes required for doing all this. So as like as a high level maybe obvious thing here is that one thing is thinking about this in the like in in in the vacuum right like in in theory on how these things work but another thing is like okay we have to actually deploy this thing in a running network and reality the the interesting interesting thing about reality is that resources are limited and there are constraints right so we want to define some uh resources uh required for executing the proof. So we we cannot really assume that provers would have a thousand GPUs and uh $10 million to really create proofs, right? We we want to make proving somewhat uh attainable for for not for anyone because that's not needed.

We need at least one prover for each block. But still it's very healthy uh to have like a certain certainty that if all existing super efficient proers disappear tomorrow you don't need like to buy a data center to keep a 3M alive right so for this we define the capex and opex which is basically the capital cost that you need to create the proof uh the prover hardware to buy the prover hardware so like let's say uh I don't know 100k USD dollars is the the money that you should need to buy the to buy the required hardware and the operational cost is okay how much it cost to keep this thing on. So the electricity maintenance and things like that and yeah and also like bandwidth in the in the protocol is limited. We have some other constraints in the protocol which is the proving time. We don't have like infinite proing time to create the proof.

There are some limitations on proof sizes because this has network overhead because the bandwidth is not unlimited. We have proof verification time really needs also some bound because whenever the proof is propagated through the network we want to uh make each hop to verify the proof. So that means that each hop has at least this amount of latency uh overhead. Um so hopefully this can be pretty low and also we have the security bits right because yeah uh we can make everything faster but this if it is not secure this is really not worth anything. So uh the the the thing here is that we need to consider all these resource and constraints and for many things we need some help of the protocol to make this work.

So the most obvious uh protocol change that we need for this that you might have have heard before is this how do we deal with this proer killers. So pro killers are basically um operations in the EVM that are let's say cheaping gas compared to how hard are to prove right or what you can say they are mispriced. uh this is like similar to say that some EVM op code today is very cheap compared to how hard is to execute that op code using re-execution. So if you have the situations where let's say the catch hack op code is very cheap in gas but for the proving uh of it is super super super hard. You can have the situations where some adversary block builder can build a block full of this um really cheap gas and uh make the the the proving time really not be possible.

Uh I will dive bit a bit more into this because why it would make sense that someone build this block but I hopefully that will make sense a bit later. But this is something that uh might also be a problem even without an adversary just like you are building a block. You are just grabbing transactions from the main poolool uh satisfying the rule that the the amount of gas is less than the limit. You might already know that there's something that you put there that is really hard to prove and then you have a block that you cannot really prove. So let's look at an example here to understand things better.

So let's say that we have at maximum 7 seconds for creating a proof and for the current gas limit which is 60 million we also already know that the adop code uh uh price is like is uh three gas. So that basically means that roughly in a 60 million gas uh limit block you can add around 20 million ads uh to be executed. Right? So that basically means that if you have 7 seconds to prove this you need to be able to prove 285 million ads per second. Right?

This is just taking this number and divide by seven. So I need to be able to prove this. If I don't have this proving throughput for that, that's really bad because uh I won't be able to create the proof on time. So let's say that I benchmark proving this block and I realize that I cannot only prove 1 million additions at per second. So I need this throughput.

I have this throughput. This basically means that I need to re I need to repric the adop code by this factor such that the amount of additions that I can add in this block is way lowers. So I I can really satisfy this proving time with the current proving throughput. So this basically means that instead of having an ad that cost three gases today, we need to repric the ad to be nine gas. Okay, this is like a very simple example.

uh if you if you are interested in this, I wrote a two-part article about uh this repricing topic uh where I dive in much more detail. Uh so yeah, highly recommend you see that. Uh I want to make a quick mention here to fossil uh which is uh an EIP that is now a headliner for Hayota and I think this is important to understand which the what what this means for pro killers. So today we don't have fossil uh not having fossil means that the block builder has full liberty in selecting which transactions going to the block. So clearly if there is like a transaction in the main pool that it has a proer killer uh the builder can simply say okay I won't I won't put this transaction in the block so I'm not being forced to prove any kind of mispric gas.

So technically today like block builders can in theory avoid this problem by simply not choosing transactions that that are hard to prove. But when when we have fossil there the situation is different because fossil main goal is to force the block builder to include transactions that are considered censored. Right? That is the goal of fossil. Um so this means that the block builder might be forced to include transactions in the block and these transactions might contain uh mispriced gas.

So here's some quick math like one inclusion list from fossil can have let's say 40 transactions and these 40 transactions can uh can can be transactions that you see 17 million gas which is the transaction gas limit we have today. So this means that a single inclusion list can force up to 680 million gas. So that's a lot. So basically an inclusion list can really force the block builder to use all the available gas uh with whatever transactions uh uh it wants. So this basically means that anyone that is proposing an EL can include transactions that are poorer killers and the block builder must include these transactions in the block.

uh because this is enforced by the protocol. So there's no way around it. And this block will have to be proven. And if we don't have the right pricing for stuff, this is a risk because it means that someone can force a block into the protocol that we can already prove. And as we saw before, if we can already prove it on time, that means a tester won't receive the proof.

And if a tester don't receive the proof, they cannot attest. And if they can attest, uh, we have a big problem, right? So if we want to know more about like numbers um benchmarks around up codes and exploring more these repricings we have a dashboard where we are running uh benchmarks for up codes and pre-ompiles and publishing the results for different VMs and ELS uh we are still using a prover hardware that is not optimal but you can already see uh like this data and start having a sense of how we are approaching this problem. So here's the link. So unfortunate unfortunately uh not all the problems in the protocol regarding improving time can be solved with repricing and this might not be entirely obvious because it's like a pretty obscure corner case that has been known for a couple of years but yeah is still a bit weird.

So to also be able to guarantee that we can prove all the blocks, we have to do something in the protocol called code chunking and this code chunking is related to this by code field that we saw in the execution witness. So as I mentioned before whenever you execute a block you might you might need to know the by code of a contract because you will have to execute it. But there's a interesting reality here where usually whenever you execute a contract in a block, you don't actually execute the whole by code, right? You only execute like a particular let's say solidity function which is like a couple of bytes of the whole by code. But the way that the by code is committed committed into the state tree is via the call hash.

And this call hash is the hash of the complete by code. So to verify that the by code data is correct in the guest program we need the whole thing not only the by the bytes of the by code that we need for the EVM we need the whole thing so the problem here is that I can construct a block where all the transactions only touch let's say one bite of uh maximum size contracts so 24 kilobytes today and That basically means that I'm forcing a lot of 24 kilobyte by codes into the execution witness and this means I have to hash all this data to check that it's correct against the gold hash and this is extremely bad. This is one of the worst cases uh for for asper killers. So the solution here is that instead of having B codes this way, we basically chunk the B codes of contracts and put these chunks as part of the state tree. If we have this construction uh this allows uh us to instead of having to provide the full by code, we can only provide the chunks that are needed for that block.

And this uh kind of solves the problem. This is something if you have been tracking Ethereum for a while that was planned whenever we were working in Burkel trees. Part of changing the state tree is trying to also make at the same time this code chunking thing. Um but now that Burkel trees are not really happening and we are more thinking about switching to binary trees. The idea is the same is that whenever we switch to a new state tree uh which can help on other things like a more useful hash function that is faster to prove than than ketchup let's say or having smaller uh proof sizes.

Um at the same time as we change the tree we leverage the opportunity to also put this by code chunks as part of the tree. If you're interesting more about this topic, there are I wrote like I think a year ago this is research post explaining all this by code merchandis in more detail with some options. And here's the IP of the current binary tree um proposal but I think there are other kind of uh binary tree designs that are being explored today too. Okay. So what else we can do at the protocol level to help proving?

So today here in the left hand side we have like the current structure of a slot. So slot starts at time zero and it finish at time 12. So we have like 12 second slots. And as you might already know, we have this detection deadline at time 4 seconds where a testers are assumed to be uh sending their station for the proposed block at time zero. Right?

So what this basically means that in the current slot structure um we need to uh create a proof. we have like up to four seconds to generate the proof and propagate the the proof through a network and 4 seconds is pretty low. So fortunately uh now in the next fork uh EPUs will come which is doing some slot redesign and I won't go into much detail here. You can see the IP link here and read it later. But it kind of reshuffles a bit uh some stuff and it gives like another meeting to the state route of a block.

So it kind of delaying the execution by one slot and that basically give us more time than 4 seconds uh maximum to create the proof. How much time exactly is DBD? Because this PTC deadline relevant for that answer is still not decide. Uh there's still some research if this PTC deadline is fixed or variable. So yeah, the important part is that EPVS and uh is kind of pretty relevant for us to gain more proving time um for blocks.

[snorts]

So something else that is quite relevant and Cody touched on this before is that for verifying a proof you don't actually need to have the full block. So you don't need a full uh the block with all the transactions. You only want to know that this block has been executed correctly. Right? That is valid.

Um so you can actually instead of having the full block have uh like the block header let's say so you have like a commitment to the transactions and this proves guarantees that the block was executed correctly and indirectly this means that since the block header has the commitment to the transactions the correct transactions were used for the block. So uh this basically means that we can stop considering propagating the full blocks through the whole network and we can try to put the block in blobs. So this is similar how how L2 choose work today. L2 choose use blobs to put their trans their blocks there or state diffs and what we are thinking about is a we can really do the same for the layer one. So the layer one will become kind of a layer two in a way.

You can look at it in that way if you want where while the blog is not being propagated to everyone. We still want to give the guarantee that this block data is available right we want to know that the block builder the the proposer has really revealed this block and it's available to the network but at the same time we don't want to send it to everyone. So if you're interested more about this here's the IP that we wrote some weeks ago. um uh that explain this in more detail. Okay.

So what else we can do to help on the proving time um in speeding up the proving time? So if you if you think about what proving means uh we can think about it that the proof generation has two stages. We have the risk-fi emulation stage and the proving of the execution trace. So the risk emulation is something that Kodi explained in a diagram in his last diagram. So the guest program runs inside the EVM the CQVM and this guest program is a risk five uh program right.

So the CKVM is basically has a a riskfi emulator that really execute all these instructions and while it executes all these instructions it generate this execution trace that is later used by the proven system to generate the proof. So the important point here is that this frisk emulation step is single threaded in most in all CQVMs today and the proving part after you have this result of the execution trace and you are in the proving system uh stuff this part is very paralyzable and you can do all the computation in GPUs. So the insight here is that if you try to throw hardware at the problem, you can make this part shrink a lot because you simply use more GPUs and you can make this shorter. But throwing hardware at the problem for this part doesn't really solve anything because even if you use a CPU with more cores since this is single threaded as we increase the gas limit clearly this part will be grow bigger and bigger and and the amount of proving time is fixed. So at some point this risfire emulation step will be a bottleneck.

So uh probably many of you have heard about balls lately. Uh balls is a protocol change that will uh happen in glamsterdam. And what balls are in short is basically that the block comes with some extra information of all the rights that happen on each transaction. uh it also comes with some extra information about grids. But basically the idea is that instead of today where you have this reality where you execute a transaction and then you execute the next and then you execute the next you can really execute them in parallel without uh without having you you can execute this in parallel because you have all the information that you need about the pre-state before each transaction because it was provided in the BS right so with the BS I can construct which is the state of Ethereum of transaction number three let's say after these two transactions are executed without re-executing them right that's the whole point of it so uh without doing any execution I can really understand how to execute transactions in parallel and which is the correct pre-state to use before them uh if you want to know more about this IP um here's the link and this speed ups re-execution Because yeah instead of running things serially you can things you can run things in parallel and this allows you to do some batch IO and things like that and and also calculate the state the post state route in parallel because B val also allows you to have the state of the world after all the transactions are executed.

So that's exactly the state of the world that you need to calculate the new state route. So you can calculate the new state route at the same time that you are executing transactions which is pretty efficient. So how we can use this B stuff for proving? So in guest programs you cannot really spawn threads and things like that. That's kind of a limitation of CQVMs.

So you cannot really parallelize in the same way that you do for in in re-execution. But what what you can use you you can split the guest program execution in many parts. So you have like one guest program that let's say it's called subblock validation and to this guest program you can say okay you will execute and prove the first three transactions and there's another guest program that will receive another input to execute the next three transactions and do like this parallel proving of different guest programs executions. So this allows you to indirectly parallelize the Brisfy emulation bottleneck that we had before. And after you prove parts of the block in parallel in different guess programs, you need like a final guess program that gets all the proofs, verify that each proofs of each part is correct and it does some coherency checks like you're not like missing some transaction that was not proven or things like that.

And yeah, basically with this way you can um parallelize this riskfi emulation that was a bottleneck whenever you use a single guest program. And as a last slide uh we have the proven incentives which are pretty important for the protocol for the protocol let's say economics. So uh if you're a block builder and you're creating Ethereum blocks uh you are not we we are not expecting block builders to create blocks uh for free or being altruistic right we want this we want creating blocks to be something that makes economical sense um so if creating proofs is not required to have valid blocks and graded proofs is quite expensive regarding computation, we need to make sure that creating blocks still makes sense economically, right? So um this might mean that I don't know maybe we realize that the current block rewards are enough to cover these costs or we consider that MEV extraction should be considered as part of the rewards that are used to do this work or maybe we realize that we need to give some extra incentive in the protocol for for covering this proof generation. Um so yeah there are some really uh open questions here.

I think that the the Rick team in the F is mainly doing this research uh on how we make sense of uh block builders still being incentivized to generate the spruce and yeah that's mostly it. Um we [clears throat] have some um a couple of goals that you might be interested in. So we have like the e-roof calls that is uh run by the e proof team in DF. Maybe you have already joined this before and we have uh some monthly CGVM breakout calls where we share some uh updates about what we are doing and yeah here's some couple of extra references that you might be interested and that's all. Thanks for for your time.

Yeah that's awesome. Thank you so muchio. Nice. Very well. Uh it's amazing intern over you guys and it's been a lot.

We are um almost at two hours. Uh it's still good. We have some maybe last couple of questions to take before we wrap up if you guys don't mind. Uh thank you so much Cody for answering in the comments by the way. I think you touched uh most of them already.

Uh there was one last from Lee about how the provers will be rewarded for a single blog. How uh how to do we decide them? So uh yeah if we are like mining is like maybe proof of work where only the one um who who wins gets everything or how do we uh distribute the

right

yeah so the the way this works in mandatory proofs is that the block builder is responsible for sending the proof. How this is done is kind of opaque for the protocol a priority. It might be the block builder is really generating the proof or maybe the block builder is delegating this works to some other prover entity or a network of provers or who knows. But from the protocol perspective, the block builder is the responsible uh the block proposer is the is their responsible entity to somehow h put this proof there and make sense of the economics of of how how this is done. Right?

If the block builder is the one generating the proof, it might already have the hardware and that's what makes sense to them. And for others, it might means that they have to delegate this work to some other entity and they will have to pay them. So they will have to make sense if the rewards of the blog really make sense to cover that cost. Yeah.

Yeah. Awesome. Thank you so much, Gatsio. So it's pretty much the current model of PBS where it's up to proposer how he builds the block whether locally or externally.

Yeah. Correct.

Yeah. Awesome. Awesome. Um, okay. Lee has a question maybe if you want to speak up as well.

Yeah, thank you. But I remember in our previous like uh meetings uh is proof call uh uh I think uh uh just mentioned uh we need like diversity uh provers. So uh if we only reward the like the first builder or the f uh the far like the most efficient builder uh we can see according to the statistic uh performance of all these provers there are actually a difference between like according to which proof system they are using. So with that makes all the approver actually goes to one specific implementation one specific uh proof scheme and lost the diversity of the uh prover ecosystem

right so uh this is a great question so uh let me rephrase it a bit to see if uh this is clear so uh you're raising the point that we are planning to um not actually have a single proof per block but actually multiple proofs like let's say that we decide on five CGVMs or 3CVMs uh we don't only want one proof but we want like multiple ones this is mainly following a similar logic as EL diversity today we cannot really trust a single EL to be correct so the way the we run things now to have more security is that we we kind of enforce course we kind of um incentivize or try to explain how important is the L diversity so people are running different GLS uh so we gain more resilience if something goes wrong in the case of proofs we are planning to do the same a priority where let's say we have up to five proof systems let's say we are going to ask to provide at least three proofs in the block uh which three proofs are selected is up to the block builder And this block builder is responsible for creating these three proofs. So uh in the way to think about how this makes sense economically is the same as thinking about a single proof. Um because it doesn't matter which CGVMs are selected. Uh the the block builder is responsible for generating these three proofs. So if they use one CQVM or another doesn't really matter because they are running the software and they are creating the proofs.

They are not like relying on the CGVM teams to create proofs or similar. Um hopefully that makes sense. uh but with that result like all the builders uh concentrate on like three or four implementations, right? So the the way we think about this is that the candidate CGVMs that are uh accepted need to pass a couple of uh let's say constraints like they have they need to have this proverse security bits they need to have this proven sizes uh proof sizes that we need they have to they need to have the enough pro performance. So these are kind of these five candidates are kind of selected this way.

let's say and which three of them are used for a particular blog is up to the blog builder. Uh so usually they would use the fastest ones right as you say like they look at statistics from before which CGVMs are the fastest and usually they would pick the three fastest ones. But the important part here is that if for whatever [snorts] block the one of the three fastest cigms crash because they have a bug or the block has some workload that is really inconvenient for them. they will need to pick one of the uh other two that are available, right? Uh so this is kind of the dynamic that we expect that will happen that usually you will receive the same three type of proofs but we still need these extra options just in case that something goes wrong with these fastest ones.

Uh yeah. Okay. Uh thanks a lot.

Okay, awesome. Thank you guys. I think we have covered a lot. Honestly, I had some more questions but we are running a bit late. Uh I see also coding responding to the resources.

I would just add uh all the resources that are mentioned here and all the resources that are in the presentations and more you can find in the study EPF wiki afterwards. So uh we have like the full wiki of resources there that you can learn from as well. Um but for now I think uh we can slowly wrap up because we're almost at two hour mark and I don't want to uh keep you guys late. Uh we got we got great number of people here and uh we learned so much today. It was very insightful.

Thank you so much both Cody Ignasio uh we will uh have a recording so this will live forever now as our guide to ZKVM introduction. Uh it's been it's been an honor. Yeah. Thank you so much and yeah, I will I really hope to see you around uh soon elsewhere. Hope you guys