From ZK rollups to ZK Ethereum - Sergey Shemyakov

Transcript

Yeah, hi everyone. Um my name is Sergey. I'm the ZK researcher at L2Beat. And today I will be um kind of using what we see in the L2 space um and uh try to um talk about what's going to happen in the Ethereum L1 um itself. So, we see that ZK tech successfully scales um L2s today. And the Ethereum Foundation wants to use it to scale L1.

Um and in my talk I will tell what's the plan and what are the challenges. Mm. Here is the more structured agenda. I will start talking about um validity rollups. And um a small note, I will try to say validity tech, proving tech um because uh I will not be using actually the zero knowledge property of these systems. But for the legacy um reasons, people still often say ZK, which is not fully correct. Um Um yeah, so I will start with this.

Talking about state of the art. Next, I will go to the um present. I will um talk about the ZK EVM proposal to bring ZK to the execution layer of Ethereum. Um there is a proposal called um Beam chain that also tries to bring ZK to the consensus layer. I will not be talking about that. And I will speak about some additional challenges. So, let's start. Um here is a general picture of the proving system that you have. This is a way um as probably many of you know to attest some computation. And in this mental picture, you always have program that you're approving, a guest program. You have an entity, which is a prover, a

verifier, some proving scheme, and the key feature of this systems is the asymmetry between prover and verifier. So, here you can see, just to give you a taste of the scale of provers. So, for linear, they need approximately 1 terabyte of memory for running the prover. Um maybe a more modern example, um here you definitely cannot see, but these are the specs um of a proving cluster that the Ethereum Foundation plans to uh get up and running. Um so, the cost of the hardware it was estimated to be 250 K euros um back in February. The operation um is another 100 K per year. So, this

is uh you know, proving is a big uh big tough um thing, which not just has some big capital cost, but also running operation cost. Um so, the validity rollups is this technology that is quite well known, and the idea is that you take transactions um outsource them to L2. And to stick to our mental model of proving system, so the guest program that you're um proving is the state transition function of L2. This is your L2 client.

The prover is the operator of L2, and the verifier is a smart contract on Ethereum usually. Um and here's a picture that shows from our web website, that shows that the this um strategy of scaling was quite successful. So, here you can see a blue line, these are the transactions processed on Ethereum. So, on a good day, you will have maybe 30 um transactions per second, or other user operations. And the purple line are the rollups. Um so, to be fair, so most of this is ZK um rollups.

Um actually, most of this is one ZK rollup and if you want to know which one, feel free to visit our website. But we you can see the the systems on our website. And couple of things that we currently see right now. I just want to give you a taste. So, most of the projects that do have a functional proof system, these are the projects that we called called stage zero, stage one, or stage two. So, 23 out of 30 projects do use some a form of approving systems.

Interestingly, only around 13% of total value secured with these proving systems, but this will probably change very soon, less than in a week with base making an upgrade. But, interestingly enough, there's only one project currently that allows permissionless proving, so it allows anybody to submit a proof. And the rest of L2s, they have their own proving infrastructure so in the end, malicious actors cannot even attempt to break the systems and as a consequence, these systems are not really battle tested at the moment.

So, it's it would be fair to say that many of these teams have been working on the proving systems for years. They've done a lot of development work and they've done a lot of effort on auditing, formal verification. Here are some names. You can also learn more on our website. And maybe a key feature of these systems, let's say, are these vulnerabilities. So, here you can see one was found maybe 10 days ago in JOLT proving something that's obviously not true.

Earlier this year, um NL2 had to stop the operation because of the um problems with the EIP protocol and so on. Um Bugs have been found. So, this is the the reality that these bugs have been found pretty much every week and L2s fix them all the time with um emergency upgrades. They have to um stop operation. They have to do do these upgrades. So, this is um the general agreement I would say is that this tech is kind of not really mature to the standard that you can just uh put it out and um hope that nothing bad will will happen and no exploits will happen.

Um so, let me switch for a moment to speak about L1 now. When I say present as I'm a researcher, so this is kind of the present of research and development. This has been um actively um yeah, worked on right now. And um just as a reminder again, I will be talking only about the execution layer of um of Ethereum. So, let me remind you the current block production pipeline for Ethereum. Um it starts with validators auctioning off the rights to build blocks. So, validators, the people who stake uh the ETH token, don't produce blocks themselves.

These blocks are produced by just a handful of entities here um on the chart, you can see for example, around 50% of the blocks um currently are built by um Titan Builder. There are a couple more uh entities that build blocks um which, together with Titan Builder, build a good majority of all the blocks. And these block building entities, they are quite sophisticated operators. They They um some non-trivial uh software. They run quite uh um performant hardware.

And when these blocks are produced, then the validators have to check that the built blocks are correct, transactions are fine. So, they do it by re-execution and these blocks also then propagate through the network. And the step of re-execution of transaction by validators is the current bottleneck on L1 preventing us from raising gas limit to higher and higher values. The reason is that these validators are expected to be running quite normal hardware.

So, some operators at home and so on. So, the ZKVM is a proposal to basically solve this bottleneck that I just showed you. And the idea is conceptually exactly the same as the idea of validity roll-ups and L2s. The idea is that the validators will not re-execute the transaction transactions, but they will just check some proofs of execution. And this should look somehow like this, the new the new pipeline.

So, again, validators auction off the rights the builders build the blocks. And then there is this new entities called provers that now prove the blocks, produce zero knowledge proofs of the correctness. And and validators have to just verify this block block proofs instead of re-executing them. And then the blocks propagated through the network. So, here you can see there was the old bottleneck with the validators, and now it's not a bottleneck anymore because verifying proofs is very fast, very efficient.

But with this um strategy of the KEVM, you introduce a new bottleneck. Um Number three with approvers. Um so, this will be quite an intensive um step. And the whole idea of the strategy is that this big beefy prover machines will be able to prove blocks faster than uh validators will be able to re-execute on their um customer level hardware.

Um so, yeah, this is how it's uh supposed to be um working. Couple of uh words about implementation. So, how you do this? You take an L1 execution client like Geth or Nethermind. Optionally, you can re-execute it in a ZK-friendly language. Rust seems to be a popular choice these days. But, next you want to um compile this program execution program into um a ZK-provable program called uh guest guest program.

And then, if you want to um prove a block, you have to prepare the input into the um into the prover. And this will aggregate all information like transaction state access info. This is a big uh part of current research and development actually. And then, you prove um all this information with a proof system. Uh this is the the let's say the most um demanding step of the um of the pipeline. Um so, this strategy of the KEVM is being uh kind of promoted and pushed forward um uh by team around

uh Justin Drake. And here I have a picture from um Devconnect in November last year. Uh on an 8+ event, he uh presented the demo where his client locally was doing exactly this. His um local execution client was verifying the proofs that were generated um or written in real time. So, this already shows us that this is not um let's say ambitious strategy and this is something that is actually um kind of realistic to um to do.

Um So, recently Ethereum Foundation published this straw map um which is a proposal for a for a timeline. And I looked through it and I picked um points that are relevant for this ZK VM um timeline. Currently, we're in these first steps, the hardening of the tech. The ZK clients and provers still has to do a lot of work. Um the security standards are being set up right now. And the next deliverable is supposed to be in um Hegota. This is called EIP 8025. And this is optional proofs. So, validators will be allowed to not re-execute blocks, but verify zero knowledge proofs.

Um I would say this part is not really contentious. Next, it's kind of up in the air. It could change many times over. But, the next idea is to maybe optimize something on L1 for um more efficient ZK proving and eventually introduce mandatory proofs. Um So, I would like to share some reasons why um I think it's kind of um realistic to expect that this timeline will work. And the first biggest reason I would say is the success of L2s. So, we see that it is um more performant to um uh proof uh transactions than re-execute them.

But, then also there was a lot of development in the ZK um technology last year and I think Jordi's talk um earlier was a good illustration of this. Um so here in the last year the speed of proving increased five times and the cost dropped by approximately 15 times. This are very impressive numbers. This is from the blog post by EthProofs who track these things. So it's quite um uh quite good numbers. So then there are also some teams that already operate this lead cell tools.

They have experience in the operation um uh thing and then we also can kind of say that the outsourcing block building was a success to um to produce this quite um quite intense and complicated pipelines. So all in all I think there are some some good reasons to be optimistic about this plan. But um of course there are still some challenges and I might go on to mention a couple of those that are unique for L1 and that L1 has to solve separately from the um what L2s um already have figured out.

Um so here on the on this slide you can see the diversity of Ethereum clients, consensus layer, execution layer. Um there are many different clients and this is um the the reason why Ethereum has been operating uh for almost 11 years without going down. So this is um very important for liveness of um of the system. And it's also thought that this diversity should be the solution for uh potential bugs in the in the all proving infrastructure. So in all the key related stuff.

So it should be something like this. We need to implement three different guest programs. So three different this ZK clients. Maybe repurpose the already existing ones. We need to implement three different proving systems. Then we pair them together. We have these three different proofs. All the proofs always must agree. If um one disagrees, then I kind of we can use the other two as a source of truth. But you can see that this is just a huge engineering coordination task. Um you basically have to implement the same thing uh three times.

And this is um yeah, a lot of a lot of work. And by the way, all tools have it easy. They don't um diversify. They usually run just one guest program. They have um just one proving system. And they don't um don't need the same level of um diversity that um Ethereum expects. So, the next challenge um is the speed of proving. Um the issue here is that uh the validator wants to sign a block um before propagating to the network. So, um okay, there is a proposal for delayed execution. But realistically, there is around, let's say, more or less 10 seconds to prove um an

Ethereum block. And this is not um not too much time. So, there was a lot of uh progress with parallel GPU proving. I don't think if you can see uh the right um part of my slide. But here, uh approximately 91% of can already be proven um in under 10 seconds. This is the current data from Eth proofs. But still, there is a way to go. And this is also the the main idea. This GPU parallelization is the main idea for this um proposed EF cluster backed with the GPUs.

Um but even with this hardware uh solutions, realistically, we should still um see some optimizations for proving systems. Um They They need to be sped up. It's an interesting question whether the central decentralized proving is feasible. I think um Jordi in his this presentation tried to make an argument that this this could be done, and I would be happy to see this. But anyway, this is um also a challenge. And for L2s, this real-time proving is not not a concern. So, release So, what they do in practice is they um publish a block to L1, and the proof arrives maybe minutes, maybe hours later. Um so, they have this settlement

time. But this is a completely different timeline, so they don't have to um prove these blocks um in real time. So, the next um challenge is a very important for um theorem coordination. This is the question of okay, who will be producing these uh proofs? This is um as I mentioned, has a big operational cost depending on the prover and so on. But let's say this is the um the range in which the the um prover costs are.

So, 100k to 1 million. And this um this is for example for one prover. If we have three, you multiply this by three. In the initial proposal of this optional proofs uh that is coming in Hegota, um the provers are assumed to be altruistic. So, this is really like a bootstrap version. But of course, one term we will have to find um economical solution to this. And the question is how we will pay for this proving. Will it be be uh paid from block building MEV? Uh maybe uh transactions have an additional prover fees, how it's uh for example currently done in some L2s.

Maybe we'll have additional ETH issuance. I don't know. We have to ask ourselves. And another related question is whether this will lead to some further centralization long term. So, here it's a bit similar to block building and I already showed showed you that block building is quite centralized. But I would argue proving is still a bit different because with proving if you cannot prove a block, then you kind of the whole blockchain is stuck and proving you need hardware. And even if all block builders go down now, validators will still be able to to continue building blocks, maybe not this efficient. And um

not so well as a block builder can do this. But anyway, this is another risk that we definitely should keep in mind. And of course, all tools don't have a question of who is proving. They are the ones operating the systems and they everything they in centralized. And the last problem I want to mention is that we see currently in all tools the guest programs and provers um are upgraded all the times. You have upgrades and fixes. So, we would need some sort of upgrade process around and versioning to avoid malicious upgrades. This is something already have in the clients, but now we also will have this proven system additional layer of complexity. So, this

is just a coordination challenge. Um just throwing thoughts out there, maybe we can have some on chain registry for programs and um provers. And all tools, they obviously don't care too much about the auditability and transparency of the upgrades. They just do it and then um that's it. And just at L2Beat we have an experience of tracking the upgrades for for programs of these proven systems for also um proof provers. And this is actually not very transparent and not very easy to track. So, this is something we should keep in mind for L1 as well.

So, that's it. That's the end of my presentation. If we have time for questions, I'll be happy to answer. Otherwise, feel free to catch me if you see me. Yeah. Thank you.