Keynote + Demo: zkEVM attesting by Justin Drake, Ethereum Foundation

Transcript

All right. Hey, Justin, can you uh see and hear me? >> Yes. Hi, guys. >> All right, >> I can hear you. Okay, great. Uh, welcome everyone to the Eve proof day uh demo. And I want to give a massive thanks to Will who has worked extremely hard uh on on on on today's event and is just generally shipping so many uh great things. Um so today is a bit of a of a special day. It's uh uh new territory that uh we'll be stepping uh onto. Um it's a a small step for my validator node uh and a giant leap uh for for Ethereum L1.

So today's presentation will be split into uh three parts. First of all, I'd like to share a little of context about what is uh happening and then jump into the live demo and then finally uh say thanks and give kudos to uh many of the teams that were critical for the success of this demo. Okay, so if you zoom out, we're entering a new paradigm where we're moving from execution proofs to sorry, execution clients to execution proofs. Execution clients are extremely heavy pieces of infrastructure that have to redownload every single transaction and replay them and requires gigabytes of RAM, terabytes of disk, uh very sophisticated um SSDs

uh called NVME drives as well as many many CPU cores. Uh with execution proofs, we have a much more lightweight setup where you don't even need to download the proofs. it suffices to do data availability sampling and you also don't need uh to re-execute the proofs. So this is my uh home setup. I'm actually giving the talk on on my um staking uh laptop which is an old MacBook Air. Um I have a consensus node which is running Lighthouse. I have an execution client running GE. And I also have two other clients, what's called a validator client, which is also uh Lighthouse, and a sequencing uh client.

Here I'm running an alternative to Mev Boost called commit boost uh which I which I really like. Now the three three of the clients here are very scalable in the sense that when you increase the gas limit, uh they won't break a sweat and they'll be able to handle the the throughput. But we have one strander here uh which is the execution uh client which is a massive uh bottleneck towards the the gigas frontier. So the hope here is to uh remove the execution layer clients and replace them by execution proofs thereby uh also removing the uh bottleneck.

Hence the the the title of this slide dev disconnect. And what I'll be focusing on uh in the demo today with the the terminal logs is these two portions here, the two Lighthouse clients, both the beacon node uh and the the the validator client. So what we did for this demo is that we started with Lighthouse and we made it ZK. Uh what exactly does this mean? It means that uh we added a new flag d-execution proofs which uh when you put on your uh command line will uh listen to a new gossip channel also called execution proofs. Um and we'll be

listening for ZKVM proofs and using those as our our source of truth. And I'd like to uh say thanks to Kev who has drafted the initial version of ZK Lighthouse. Uh Dapline who reviewed Kev's work uh and Farah who finished uh the the end to end uh demo based on on ZK Lighthouse. So today we're going to have seven different proving clusters proving every single block. Uh and that's across four different ZKVMs.

uh uh five different ZKVM, sorry. We have four here, Airbender, OpenVM, Pico, uh SQ1, Hyper Cube, and we have another ZKVM called ZISK uh which is being proven not only by the corresponding team uh in in Spain, but also by an independent prover here called uh ZK Cloud. And what these proving clusters um have is that they have they have different sizes. So the number on the left here represents uh the number of machines that the clusters have and the number on the right here represents the number of GPUs. So there's a wide range of number of GPUs. Airbender for example has two GPUs and OpenVM for example has

32 GPUs. Now when I was thinking of doing this demo I didn't think we would have seven different proving clusters. I thought we have three maybe four. So this is really an excellent outcome and not only that um three of the clusters are using 16 GPUs or less and therefore under the 10 kilowatt uh target that we that we set ourselves. So congratulations to Airbender, SP1, Hyper Cube and Zisk for for reaching that target and I believe that uh OpenVM and Pico will will reach it very very soon. Uh possibly next week, maybe next month, we'll see.

So what these proof uh proving clusters are doing is that they're submitting as quickly as possible proofs of L1 mainet EVM blocks onto e- proofs. Those proofs get forwarded to a gossiping node. The proofs then get uh gossiped to this new um subnet uh in purple. And then uh in yellow is my home validator node running again a modified uh version of of lighthouse and using the EVM ZKVM proofs as the the source of truth.

Okay, let's uh let's try the demo. Let's see if it works. Um it's not completely production grade. So I don't recommend you to try this at home unless you want to be an early adopter in which case do DM me or Farah and we'll try and get you uh hooked up. So uh I just want to briefly tell you what I'm about to to show you. So um I'm going to load efroofs.org and show you all of the the beautiful ZKVM diversity that we have. I'm going to be showing you my beacon node which is uh running right now on this computer. the validator client which is also running right now on this computer.

I'll be switching to uh beacon chain which is a block explorer for validators and then I'll be showing you the beacon note again but this time showing you the bootup phase. Okay, let's move to uh eeroofs.org. Okay so just going to reload the page real quick. This is a new landing page that we have uh for e proofs. Um so here we have a a slot number 895 and you can see the proofs are gradually during the slot uh being uh downloaded and and verified.

uh zk sync air bender is only shown as proved not verified because we haven't yet integrated the verifier but that will be fixed uh shortly um and so yeah it's a really fun page which is which is super dynamic uh and I recommend you you you have a look okay uh next up what do we have um we have the beacon node so this this is the u my beacon node Um, we have some new EF proof logs. So, I hope the font is not not too small, but basically uh we we're downloading a bunch of proofs and uh let's search for this keyword verification. So, when we

receive a proof, we have verification started. When we've verified the pro proof, we have verification completed. So, here in this case, we have a ZISK proof from a ZK cloud. It came for slot uh 957 and we received it at millisecond 550 verified at millisecond 568. So it took 18 milliseconds to to verify uh on on my laptop. And if we search for the slot number here you can see that for this specific slot I've received multiple proofs. And there's a very important message here which says minimum required execution proofs received. So in order for a a block to be considered valid by

my beacon node, I need to have three ZKVM proofs downloaded. And so in this case here, I have uh proofs for proof ids 7, six, and five, which corresponds to uh Pico, ZISK, and ZISK from from from ZK cloud. And as soon as we receive that, the block is is again considered uh valid. And another thing worth highlighting is that as soon as the proof is accepted, uh meaning that the the proof has been verified, it is then gossiped to all of the other peers. So this is a a peer-to-peer uh gossip network for for these uh various proofs.

And then one final thing that I wanted to show you real quick is that we have these synced messages which are exactly the same as a a normal beacon node with with one exception here which is the the block is shown as empty and the reason here is that this is the head block and it's not being um validated in real time. There's a little bit of a delay in order to receive uh the proofs. There's a roughly a onest delay. Uh and so the the the verified head is is is empty here and that's going to be important uh later. Okay, let's hop onto the validator client. So here um you not much is happening. We have uh info log

telling me that the the my validators are active and and connected to the beacon nodes and I'm successfully publishing uh at the stations uh which is you know exactly uh what what we want. Now um let me move on to uh beacon chain. So this is my my validator. Um and one thing I wanted to show you here is the the different attestations that I've been making recently. So here if we look at the latest uh attestation I've um I have the correct uh I I got rewards for the source the target but not the head vote. I don't know if you can see it says zero uh guay there. And this is to be expected because I'm publishing

attestations late because uh I I'm waiting for the ZKVM and proofs and I'm getting penalized because I'm not getting this timeliness reward uh for for voting on on the head uh immediately. So right now what I'm doing is a little bit of irrational behavior. Um even though uh there's I guess two things to say. The first one is that this will be fixed with uh delayed execution and two uh I can run on much uh lower cost hardware and so since I only have one validator it might actually be rational for me to lose a little bit of uh of rewards for the headboat uh but make it up on the hardware.

Okay, let's see what we have next. Um, yeah, I wanted to show you that, you know, my beacon score is pretty terrible in the last 30 days. And part of the reason is that we've been doing a lot of testing in in the last uh couple weeks and I've had a a lot of downtime. Okay. Now, one final thing that I wanted to show you is uh the the the beacon node um uh boot up. So here we have um the the various flags that I'm using.

I'm I'm specifying a specific boot node and and and a trusted peer ID. So this is all networking stuff and the reason is that right now there's only two nodes in the peer-to-peer network uh that are understanding the proofs and so they need to be directly paired which is what this is all about. Uh, I have the staking um flag because I'm staking and uh I also have the execution proofs flag uh for which is new uh for for this demo. And um when you load things um you'll see that uh there's an info log here which says we're running with execution proofs meaning that no E is

needed for proof verification. And um you know shortly we should be uh seeing uh here that I'm subscribed to the to a new topic. So this is a info log saying which topics I'm subscribed to. And here if you can see it uh we have a new topic called called uh ex execution uh proofs. So that's it for for the demo today. uh it seemed to have uh worked great and you see already we're we're we're receiving proofs and verifying them >> [clears throat] >> uh locally on on my computer.

Okay, back to the presentation. So, I just want to uh wrap this up by saying uh you know congratulations to to many of the teams. First of all, I'd like to congratulate all of the teams that have integrated with Eve Proof. So, we have uh 13 different different teams and we're expecting two more CNO and Jolt to to integrate uh this year. It's, you know, pretty amazing that the E3 project is less than 10 months old and and it's been such a success uh so far.

Um there's a few teams that didn't participate uh in in the demo, but I do want to give them a shout out. So for example, Powder is working on these really cool auto pre-ompiles and Zyron is the only team that has decided to experiment with something other than Ris 5. So they've gone with meips which is a great data point to have. And I also want to give a shout out to some of our independent provers for ma sci marlin snify and zilkworm and and zilworm in particular is doing something interesting because they're trying a different so-called guest program uh specifically evm1 as an alternative to to ourm and ref.

Okay. So in terms of those who did participate in the demo, we have SP1 Hyper Cube. Um you know, it's really amazing that they reached the the 10 KOW um goal. Um they're also going to make their GPU accelerator source available very very soon. And one thing which I only learned recently is that they've made a big effort on formal verification and have formally verified a very large subset uh of of the of the circuits uh which is uh something that many other teams will will have to do and follow their lead. Uh we also have the Pico ZKVM by by Brevis. Um two things that I wanted to highlight is that they will very very soon um be running on 16 GPUs

as well. uh it was a little bit unfortunate that they were receiving their hardware a little bit too late. Uh and they will also be open sourcing their their GPU extremely extremely soon. So shout out to Succinct and Pico. Uh we also have uh OpenVM that uh gets bonus points for being fully MIT and Apache 2.0 uh open source and for being postquantum. And we have the the air bender team uh that has done a couple of interesting things. The first one is that um they have a completely um from scratch guest program called ZKSync OS. So the the only team currently uh sorry the the one

of two teams that are not using uh our EVM alongside Zilkworm. Um, and by having this new implementation, they they've managed to get the proving of every single Ethereum block on on just two GPUs, which is really really uh impressive and and and uh really portends very well for for the future because a lot of the other teams will be able to learn from the the tricks that they that they have up their sleeve. And then finally, we have ZISK, which has the most uh bonus points. So you massive congrats to to the ZIS team.

They're fully open source. They're targeting 128 bits of security. Their proof sizes are under 300 kilobytes. They're postquantum. They've reached the 10 kilowatt power draw uh goal. And they've also built their own on-prem cluster. So over the course of a couple weeks, they built this this this cluster which seems to be in a in a small kind of room um in some sort of a a basement somewhere. Um and uh yeah, the the whole setup cost them less than $100,000 and they have 16 six 16 GPUs, one GPU per per machine there.

So this is a a really really cool outcome. Uh congratulations to to the Z team as well. And this is my uh final slide. I just wanted to highlight uh a couple things. First of all, uh you know, highlighting that we have this this new team as Will said with with with Farah leading. Farah has only been with us for for three weeks, but she's already made herself uh essential to the to the Giga Gas um effort. And we're we're looking to hire a a gig gas uh champion who who is that would be someone who is extremely uh technical but also has the social chops to to make some sort of of a social

intervention to try and convince as many people that this is indeed the future and have uh everyone uh rowing in the same uh direction. So feel free to email us gigagasthereum.org. That's it. Thank you so much. Just uh prove just prove it. [applause] [cheering] >> Yeah. Hey, uh congrats to everyone. So, I forgot to plug the QR code here for Q&A. If anyone has questions, we've got five minutes set aside here that will go to the mercat and we can ask uh Justin a couple questions if there's anything

that is on the top of your mind. So, we just received the first question. Justin, you still able to hear me? >> Yeah, I can hear you. >> Okay, great. Uh the question is, why the push for proving on consumer hardware? Shouldn't the emphasis be on fast verification and let block builders run fancy proving hardware? Yeah. So we absolutely need the fast verification and that's something that the snarks give us. You know I I showed in in the logs you know verification on the order of 18 milliseconds. This is actually quite unoptimized and I expect it to be singledigit milliseconds uh ve very soon. Um now in terms of the prover side of things um we have what's called

a one of n assumption meaning that we only need one prover proof system to be online and producing the proofs for for all of Ethereum. Um but we want the N to be very very large and in particular we don't want to depend on data centers and today we have roughly speaking 100 data center operators around the world and so it's plausible you know in a very extreme situation that all of them would simultaneously want to censor Ethereum improving which is why we want to have this pullback of home proving uh and increase this number n from a hundred to thousands if not tens of thousands Um so it's it's you can think of it as very

similar to a trusted setup where we have a one out of n uh assumption and we want the n to be to be as large as possible. >> Great. Uh we have another question uh couple coming in. So can I as an individual submit proofs to e proofs? >> Yes, you you can. Um so contact farah will or me um will give you an API endpoint. Right now, what's happening is that the proofs go through ETH proofs as this centralized choke point. But now that we have this new peer-to-peer uh gossip network, nothing prevents you from permissionlessly submitting the proofs on the the the new execution proofs uh gossip channel. And I'm what I'm hoping will happen in a few weeks is

that a lot of the provers will submit directly to the gossip channel. that's going to shave, you know, maybe one or two seconds of latency that's introduced by having if proofs in the middle. >> Great. Uh, one more question or another question. Uh, what do you think the timeline will be for the majority of networks of the network's nodes to be running on ETH proofs? >> Yeah. So what I expect will happen roughly is that we we'll have 1% participating in what's called phase zero which is this um you know early adopters uh phase which will last you know from now to let's say mid 2026 or end of 2026 and then we'll have phase

one where we will fix the incentive alignment uh with with delayed execution and here I expect about 10% of the validators to opt in uh and then finally the phase two which is when 100% of the fully validated nodes need to opt in because literally you know these ZK event proofs are are part of the fork choice rule part of of the official u cons consensus layer uh definition um so it will take a long time as as as will said um I'm hopeful that we can accelerate timelines especially with a a dedicated uh champion push pushing the ball forward. Um,

you know, I'm I'm cautious with dates, but like I would hope 2027 uh for phase two, which is the mandatory proofs, uh, is is possible. >> Oh, yeah. They're asking me to go on stage, so I'm on camera view. All right. So, maybe we'll do uh two more questions. So how does how does proving function under an economy of scale? Can two times the size prover more than two times a one times machine? Is there a a benefit to a return on uh the economy of scale?

>> Yeah. So at a rough first approximation uh because proving is so parallelizable uh if you double the number of machines you have twice the capacity uh to prove um now it's possible that there are economies of scale you know if you're if you're running a data center um but uh you know when we're not really targeting that we're not trying to unlock these economies of scale what we're hoping to have is provers on a reasonable budget which is $100,000 uh and a reasonable power draw which is uh 10 kow. And these numbers were you know highly inspired by electric cars.

So if you if you buy you know a Tesla Model X for example, it will cost you roughly $100,000 and your home charger will draw roughly 10 kow. >> Okay, great. Uh final question. Why not solve state expiry first? Yeah. So, um these things are like slightly, you know, unrelated. Um you know, the what we what we're trying to do here is is ultimately increase the the gas limit. But, you know, he the the ZKVM proofs um lay the foundations uh for for doing that. In some sense, state expiry is all about managing state after uh we've um we've we've increased the

the the gas limit. Now when we have a very very high gas limit let's say uh and we we've reached 1 gig of gas per second uh states you know would grow fast if we were to keep things as is. And there's there's several solutions to to our disposal. Um one is to have um states be priced differently. So just like blobs are priced differently to gas, we can have state growth be be priced differently and have an independent uh gas limit. We can also try uh state expiry. The other thing that we can try and and do is just be a little bit more vent about it. And the reason is that today state growth is really problematic for the validators

which are assumed to be on weak devices. But but with proofs uh you're running statelessly. And so the fact that the state is large is is not so much of a big deal. the the two things that we care about with um with states are the the size of the state uh and and and here um the if the state grows to to to terabytes, it's not a big deal because the the cost per terabyte of of NVME drive is not that high. Uh and that's certainly a cost that the the provers uh can can can and the builders can handle.

Um and then there's another issue that we care about which is the the access the latency to accessing state. Uh and that the good news is that it grows logarith logarithmically with the size of the state. Um today we have um unoptimized databases uh where the latency grows log squared with the size of the state. So that's something that we have to do but it's totally traditional engineering. It's not moon math and it's I'm hoping it's something that that we can do o over the months to come and it's something that some of the clients for example Ephrex which is one of the new execution clients they have as I understand you know a well-designed database that only grows logarithmically as opposed to uh log squared with the

size of the state. All right, thanks so much. >> [applause]