Devconnect ARG Day 5 - M2 Yellow Pavilion

[music] Heat.

[music]

Heat. Heat. How you know? Heat. Heat.

[music]

[music]

Heat. Heat. [music]

[music]

Heat. Heat. [music] Heat. [music] Heat.

[music]

Heat. Heat. [music]

[music]

Heat. Heat. Can you hear me? Hello everyone. Okay, he can hear me.

So Justin can hear me. I

[music]

Hello. All right, we got audio. We got visuals. I'm told we've got a connection coming up after me. All right.

So glad to see you all. This is very exciting. So, welcome to Ethroofs day. Raise your hand if you've been to an ETH proofs call. All right.

A bunch of people. Okay. So, we hope today is going to be a lot like an ETH proofs call. We're going to speedrun through a lot of topics. We got 24 things to go through, lectures, panel discussions, so on so forth.

Hope there's going to be a lot of alpha, a lot of announcements, new benchmarks, and a lot of opportunities for Q&A. Uh hopefully everyone's getting a t-shirt or has gotten a t-shirt or attempted to get a t-shirt. You should also have an opportunity for some lunch, some coffee because we're going to have to keep you fed. We've got 10 lightning talks, seven keynotes, three spicy panels, one demo. If you're ever lost in terms of like what's up next, go to efroofsof.

deday. It's the first website I ever shipped. I'm very proud of it. Um, we've got 10 teams that are presenting or representatives from 10 teams and five actually seven teams from the EF that are represented today. So, who am I?

Uh, I'm Will Corkran. I'm a research coordinator at the Ethereum Foundation. And before I started in the fast-paced world of open-source cryptographically cryptoeconomically secured distributed protocol research coordination uh I was an architect. Um this is one of the last buildings that I designed this or worked on. I was the project manager.

Uh it's a co-located Chicago public library branch and Chicago public housing. Um I think it's pretty cool. It's a very very challenging project to have done. Um, and the reason why I mention it is because based off of the constraints that we had in front of us, the site, the schedule, the budget, the tenants that we were trying to find a home for, the long-term sustainability of the project, the only way it was able to happen was through a public private partnership. Um, which is very much how I view this race towards real-time proving of Ethereum L1 execution layer blocks.

It's a public private partnership and the the reason why it's so important is because the potential benefits are massive. We've got an opportunity to significantly increase the transaction throughput without sacrificing on decentralization or security and we're just in my opinion like entering phase zero. So this is going to be a long process uh and it's going to require a lot of teamwork and a a strong sort of sense of purpose to be able to accomplish it which I really really feel today and I've felt very much for the last several months. So this public private partnership in my opinion like the reason why they're so important is because you rely on the the dynamism of the private market to be able to do things that large institutions you know sort of like a a large agency isn't able to do isn't able to be as nimble. But then you also need the public entity to be able to think out the box, be collaborative and help uh usher things along and and connect dots to un to remove blockers for that private institution.

So or private entities. So in our case, it's really begins and ends with all of these amazing DKVM teams that just keep blowing out new benchmarks and shipping new technology. And we've got eight of them on ETH proofs. Uh right now there's uh I think nine or 10 that are going to be on the stage today, but then there's a whole fleet of others that are at different stages of development that we've been tracking and we're also in conversations with. I think I've got like 45 Telegram channels with different ZKVM teams.

The other side of that private uh uh private dynamism comes from the prover side. So these are the teams that are excelling at DevOps hardware acceleration uh orchestration and really making all the ZK VMs dance and um are submitting these real-time proofs. So these provers come in all shapes and sizes. Um mult we're really really interested in these uh sort of uh multi-GPU clusters that are uh you know we call them like not at home but at garage or or at office uh proving could be at home someday. There's also larger entities provers which we'll hear from a couple uh on the final panel today and then all the the ZKVM teams are also like have their hands dirty.

they're running their own they're dog fooding their own software and submitting proofs and learning a lot about uh the whole process through those iterations. So on the public side and I'll kind of use that term loosely to describe the EF and the research uh efforts that are going on. First and foremost, you've got the ZKVM team really just like setting the tone in terms of uh what is going to be an acceptable framework for real-time proving and always make sure that we land on in a or we trend in a direction that's consistent with Ethereum values of decentralization and security and you know have everything done in a very like provable way that can be reproduced. You also have the cryptography team. These are the people that are looking at all of the foundational cryp cryptographic primitives, the proof systems and you know really sort of making sure that we're building on a foundation of soundness.

You also have the protocol snarkerification team which the sort of uh you know primary effort that uh they've been championing is the formal verification effort. So really making sure that everything that gets specified and audited you know is what you see is what you get. You also have the robust incentives group. So Julian from rig is going to be moderating the final panel today. And so as we are looking at uh prover dynamics and prover business models um you know I think that we want to make sure that we have a clear sense of the incentive structures and so that there's no centralizing vector that comes out of uh the prover activities.

And so the new kit on the block is the fifth team that I would add to this. So this is ETH proofs. Um just recently announced as a team fair as a team lead been doing an amazing job and really kind of consider this as this interface between public and private research and industry. And it's also this kind of mimetic wrapper. That's usually where I come in to try to help with strengthening community and making sure that like all of these uh individual efforts and visions are uh you know move forward in a in a coherent aligned manner.

Uh so quickly about ethroofs launched uh January 28th of last year. E uh the ethereum.org team did an amazing job with uh standing up the first uh minimal viable product and rolled that out. Uh when I came on board, I was really focused on uh driving community and we've hosted several community calls, six in total. Um and the each one of these calls usually uh gets about 250 uh participants.

A lot of exciting information comes out of those. Right now on ETH proofs, you can see if you go to the website, we've got 13 teams uh ZK uh eight ZKVM teams, 21 clusters, and we've uh out of those clusters, we've had about a million proofs submitted to ETH proofs in less than a year. Since January 1st to today, when you're just looking at a single 4090 proof, we asked provers to submit one block for every hund or one proof for every 100 Ethereum blocks. On that metric, we've seen latency go from 16 minutes to 26 seconds at the highest point for a single uh GPU submitting that proof. The cost of that has also gone from $169 to fractions of a penny.

Uh we also have in browser verification. We've got Telegram bots. We are in the DMs of all the teams letting them know the stability of uh of us receiving the proofs so that we can like sort of keep an eye on this top of funnel and and track the many while the researchers really kind of track all of the very detailed use cases. Uh we've introduced some countdowns. Shout out L2B.

Um you know we're really trying to drive everything towards reproducibility, open source. I think that we're making great strides with that. We've been really strengthening the API. We uh shipped a public uh product requirement doc and roadmap. If you go to ETH proof's uh GitHub repo, you can find that in the PM repo.

We just did a a really great uh collaboration with client side proving um you can see that dashboard now on the full V3 refactor that just shipped. Uh again, welcoming a new team lead in Pharaoh. And if you liked Ethroof Day, you're going to love Beast mode. So, we've got three events coming up in Can. I just want to plug real quick.

I'll be having the QR codes up later on. We're going to have one that really focuses on ETH proofs and lean execution. We call that beast mode. And then we're also doing a a similar effort with advancing lean consensus with our PQ interop. Some of those teams are here.

We're going to have fort mode for that. And a little hacker house running two days, which we're calling Villa Lean. So, um, when you get a chance, try to sign up. So, we're going to start off. Uh, first we've got this demo that we've been talking about, and then we've got a panel and then two keynotes from key EF researchers.

So, um, I think we'll we'll throw it to the uh to the shared screen if if we can do that now. 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 a 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 meth 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 proven 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 Zist 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-roofs. 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 eero.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 efroofs.org. Okay, so just going to reload the page real quick. This is a new landing page that we have uh for EF 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 proof 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 e- 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 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. It'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 my validators are active and then 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 I'm waiting for the ZKVM 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 an 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 exe 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 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 efroof. So we have uh 13 different different teams and we're expecting two more CO and jolt to to integrate uh this year. It's you know pretty amazing that the e-roof 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 Xyron is the only team that has decided to experiment with something other than risk 5.

So they've gone with MIPS which is a great data point to have. And I also want to give a shout out to some of our independent provers for CYC, Marlin, Snockifi, 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 our EVM 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 reach the the 10 kilowatt 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 ZKY OS. the the only team currently uh sorry the 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 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 a 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 gigas 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 gigagas ethereum.

org. That's it. Thank you so much. Just uh prove just prove it. [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 Merkat 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 a 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 proving 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 assumption and we want the end 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 far will or me um will give you an API endpoint. Right now, what's happening is that the proofs go through Eve 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 ZKV event proofs are are part of the fork choice rule part of of the official u cons consensus layer uh [laughter] 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 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 the 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 which is $100,000 uh and a reasonable power draw which is uh 10 kW. 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 kilowatt.

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 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 gas per second uh states you know [snorts] 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 then about it. And the reason is that today's 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 state 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 a 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 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 log squared with the size of the state.

All right, thanks so much. Big round of applause for all the teams contributors that were involved in that. Um so now we're going to move on to a real time proving panel. Justin, you're happy to stick around and just kind of loom over everyone if you want or or we'll go back to the presentation. So, um, if you could put the slide deck up.

This just has kind of some names. But, so the moderator is and maybe you guys can come out and I'll just kind of introduce you. So, moderating the panel, this is a real-time proving panel. So, we're going to hear some uh firsthand war stories and and best practices and lessons learned from all the teams that were submitting proofs in the demo. So, uh, moderating is Sophia Gold, the lead coordinator on the ZKVM team that's been just a a force of nature behind the scenes with all this.

And then we've got the team leads from ZISK, Jordi Bina, uh, Ye Sun from Axiom, Michael Dong from Brevis, uh, Tamir Hemo from Succinct, and Porter Adams from Matter Labs Airbender ZK Sync.

[applause]

Oh, and sorry, I'll I'll get the hang of this. Always scan the QR code. So, I've moved the the active discussion to this panel, which in the QR list is called L1ZKVM update and discussion. Um, so you can feel free to go ahead and ask your questions there. We're going to try and leave five minutes for Q&A at the end of this session.

Okay. Uh, this is not on there. Is this working? Oh, okay. Um, so I think it's hard to overstate the significance of the demo we just saw.

Uh, ZKV EVMs are now at a point where we could launch them uh in a solo rollout on mainet in less than a year. And we've only reached this watershed moment.

[applause]

Um, we've only reached this moment through incredible amount of work and a really world-class level of talent from all the ZK the ZKVM teams up on stage here. So, um, perhaps you can give them a round of applause. The the future of Ethereum. [applause] Um, so questions for the panelists. I guess let's start out hot.

Uh in addition to the uh a tester client demo we just saw most of the teams up here, you've done your own real-time proving demonstrations uh throughout the past, you know, several months um on often different hardware targeting different levels of uh of percentage of mainet blocks proven different levels of latency even. Uh and so I'm going to ask something that I've been asked by many people in the community. Are real-time proving demos dishonest marketing or valuable proof of work that drives the needle forward for the future of Ethereum?

Yeah, I can

I guess I can start.

Oh yeah.

So we have not done such a demo but I would say my viewpoint is similar to the securities and exchange commission where in US equities what matters is not what you do but whether you disclose it. So I think that so long as all the demos are clearly disclosing the assumptions and security guarantees then it is helpful to see what teams deem to be the most interesting thing they can present.

I think it's time now to probably we achieve uh I think real time proving is a reality. I think nobody discuses that we have seen in the demo but I mean internal teams we know that this is possible and now we need to have um need to find new challenges. I think that security of course is the first one. Putting all the things in production is maybe another one. Of course other more more technical things like uh improving sites verification time.

I mean there is a lot of things that stills probably still some optimizations but uh it's good that we change a little bit this challenge. I mean probably it's time to uh compete if you want but maybe compete with other parameters uh if this needs to be to follow and to continue improving the space.

Yeah, just say one thing about marketing. In May, we did a demo for like the feasibility of real-time proving where we used a lot of GPUs to prove over 94% of blocks. And Ethereum is a community of people and I think it's good for the people to know what's happening and that this is a feasible thing. So if we convince all the validators to like switch to proving, I think they need to get guarantees that this is a good thing for them to do. Um and I also agree with Jordy that uh once we have a standard for what is secure and what is an acceptable real-time proof that will also be good.

I think people are optimizing for different things. For you it was like the bits of security for us in conjectures like there's all kinds of different things that are important to us.

Yeah. Well, you know, I guess I can also answer to that marketing stone question. So uh you know uh in October we released uh uh the uh our prover that is capable of proving like 99.6% six% of the blogs in real time and uh that particular tweet uh got like three million views uh and a bunch of like tens of thousands of likes and kind of the community suddenly knows about us and uh people started think that okay you guys did a marketing stunt um so yeah I can kind of tell you kind of what's behind the scene that how we got those kind of a numbers and uh you know what's the secret behind this and you know what's our view about the marketing stunt so first of all there's like no you know overstatement of numbers in any kind so like Our tweet was actually kind of extremely dry. It's something like uh announcing picle prism that we did uh you know let's see what's a tweet.

Yeah. So it's something like yeah announcing picle prism that we we reached like 99.6% of the you know we can prove ethereum block 99 6% of ethereum blocks under 12 seconds. This is like as plain as this and uh you know accompanied with that tweet we have a fully reproducible step-by-step GitHub repo that allows you to reproduce the uh performance that we just show and the numbers themselves are not also kind of a doctorred in any sense because like we asked Justin how can we convince you that you know we reach real time proving just said don't do random sampling you just approve one single day of block every single block and we say which day Justin said September 1 okay we did that um so you know that's how we got those numbers. Um but you know in fact our marketing operation is kind of uh not really good because we didn't even go to any PR agency.

We didn't even pay any PR agency to put this out to the PR media outlets. Uh what really happened was that you know uh Ethereum Foundation we basically just ask Ethereum Foundation to see okay we did this and we have all these kind of comprehensive result can you help us to retweet this and uh very gratefully you know Ethereum Foundation helped us do that. Justin did that too but Justin retweeted with like very long post mentioning all these ek VMs as well. So that's what happened and uh you know we also work with numerous different partners. So our partner amplified and somewhere along line Vatic also helped us to retweet and uh you know this whole thing got viral and got a kind of a 3 million views.

So it's there's really not no kind of a secretive marketing operation planning behind this. This is just what happened and uh you know but I can understand people are surprised because we are probably the poorest ZKVM pin team out there and we just announced like you know this thing less than a year ago and we we did this while we kind of launched like 35 different partners that using our product in uh live in production. So people say oh my god there must be something fishy about this. Uh so you know we okay so I have a confession to make that we definitely cheated. This is how we cheated.

Uh so our our team works a 100 hour at least 100 hour per week for 300 days. No vacation, no national holiday, no weekends. This is how we did it. You you guys can learn from it basically and [laughter] and uh yeah you know onto the topic of marketing. So like we uh you I have been building this space for like 10 years now and uh you know things has changed the world has changed now.

We're in the age of attention like people kind of drive attention and you know kind of have influence that way. The a very unfortunate truth is that scammers and grifters they are so good at getting attentions because that's all they do right so we got to do some real work ourselves. Um so I would say like in terms of marketing we as the Ethereum community builders should be like Jedis basically. Um, you know, we should not submit to the dark side of the force, but we should know how the force works and uh, you know, whenever we we we did something that is amazing, we should report this with high integrity, but we should marketing stone the of this because it should be us, the builders, the innovators, developers, the Ethereum lovers who actually got the attention and get to influence where the entire industry is going instead of those scammers. Sorry, I got very emotional, but yeah, thank you.

[applause]

I will just add quickly, I know that uh this is probably the biggest audience for ZKVMs we've had. There's a lot more interest now. You might be newer to ZKVM marketing than we are on stage. I would say benchmarking before this was much more contentious and there was a lot more that was kind of like hidden and hard to tell about the ZKVM announcements and benchmarks beforehand. I think ETH proofs is like by far the most clarity we've had and like it's a real world example that people can actually kind of see and measure and like understand.

So very happy with this.

Okay, let's um ask something a little more technical. So I'm curious what changes did you have to make to achieve real-time latency with low GPU count and also what changes do you expect to have to make in the future to grow with Ethereum? So in other words, to prove higher gas limits, shorter slot durations or make your proof smaller.

I guess the most impactful change that we made was to switch to ahead of time compilation for execution. Um so we're now able to emulate risk 5 at about half of native speed. Um which was a pretty significant bottleneck in previous iterations of the system. Yeah, I would add to that execution is definitely a bottleneck for latency because you can only prove what you can execute. Um, for us, lowering the GPU count is basically cost.

So, building a new proof system that is built for the ZKVM workload was meaningful. And I think what we have to do next is I mean it's a full stack optimization problem. So there's places to improve all around. Um, and I think there's also new techniques that are going to come in. So I think in the in the next year we're going to see even better numbers or that's what I I foresee.

We have um I mean some pending optimizations uh say probably the the place where we have pushing less is the zone of the client side. I mean what goes from the client to the exeutor. I think there we are losing at least one two seconds easily uh on that side and we haven't probably go so deep in the client here we we I mean we we help that uh all the clients uh a good collaboration with the clients uh expect collaboration with the client so we can improve this part of the proof that's important uh there is some in the can announce that we will have some good news for the ketch uh uh the ketch uh pre-ompiled. I think those are good optimizations there. Uh but the main I would say that the main work in the upcoming month is going to be uh auditing internal auditing securing documenting putting the things uh uh in place.

uh if this needs to be done in in in in production and what I'm saying in production is holding millions if not billions of dollars uh uh that rely on the code that we write uh we need to fit the code stop uh go there clean the things put the things out the things and this is the this is the next challenge that at least we will face in the in the Yeah. So for us uh you know uh I think right now uh you know uh our emilation is definitely our bottleneck right now execution side of things and uh you know fortunately we got that recently uh solved as well. It's just like we didn't get the servers in time to actually plug that in. Uh so uh but going forward I think there are several things we are exploring. uh you know uh we are actually looking taking a very deep and hard look at GKR uh specifically and I think there's going to be a talk on with J is giving a talk this afternoon so you know uh so we do think that there's something that is like very interesting on GKR side that we can do um to you know fundamentally kind of improve the performance of the proving um uh so that's uh that's another direction we're exploring right now

I would say like our focus on the entire stack of optimizations all the way down to the hardware ware like we really design everything with the hardware in mind and this will be what my talk is about like later today. Uh but it's like everything from the execution client, the ZKVM, the cryptography algorithms you use like all needs to be designed uh with the hardware in mind and going forward. There's actually like still so many optimizations we need to do. You probably just saw like our 2GPU announcement yesterday uh finally got ready just in time. Thank you to our engineers who have been working super hard to get that done in time and have not slept until right now probably.

And so yeah, there's there's still more optimizations to go when we also do need to work on like our security audits, proof of uh security bids, stuff like that.

So many of you have mentioned security and um you know my view is the latency is just about good enough and that the next real-time proving will be provable security. I think we'll be hearing some uh alpha about that later this morning. But I want to ask all of you, how have your choices around security uh currently impacted your performance and how do you expect this to change with increasing your security in the future?

I think there's two dimensions in security. Usually it's the whether it's provable or relying on conjectures or the number of bits that are being targeted. Um I would say generally going from conjectural to provable security is more or less just engineering. Um it's maybe a you know 50 to 100% uh impact on recursion which is a relatively smaller portion of the overall workload. So I'd expect that to be relatively fast to work out.

um on bits of security to get a larger number of bits as a target often it might require changing uh the field or doing some more fundamental changes to the system and so it's definitely a bigger effort uh but I would say maybe not maybe double the um effort on provable

yeah I think security actually has two faces to it one is the cryptographic security which is kind of what you're alluding to is u conjectures and bits of security. We prioritized the conjecture work and actually it does have it does come with um significant overhead and luckily our proof system is kind of made for that but but maturing our industry is and not relying on conjectures I think it's like a really important thing and on the other hand uh setting the bits of security to like the cryptographic standard is important but also um innovating on the auditing and verification of the code itself that it actually does what it's supposed to do um is important. In the case we are we are in our case we are 128 bit security from the first day I think this is I mean it's the industry standard so we don't want to go lower than that here is all these conjectures this is very recent and there is a lot of papers I mean we're we were waiting a little bit for the foundation recommendations there definitely will go into proven security uh for that this has some impact uh in the prover maybe something between 20% % uh penalty that we have to do. Of course, I mean we need to do the numbers. There are things that we are not doing right now.

We may consider to doing especially for the for the positive sides of all these papers like grinding and all these things like that. So I think that overall when we put all the things together we probably will end up uh more or less in where we are. But uh this is probably one of the works of the coming weeks. Yeah, I think like cryptography uh security and also kind of you know formal verification uh audits are you know of course like things are very important and all the panelists have mentioned uh I think another thing uh when when we look at like ZK uh EVM specifically is to think about how we actually operate this uh in the field like in the future right so like once we have this live you know the entire Ethereum ecosystem is going to rely on these provers to actually generate proof and you know to be actually live And uh how does that work? Um you know what's a transition path to that uh you know operation wise like you know do we do like three out of five how do we pair you know different clients?

Do we kind of have a different clients on the same VM different VM on the same clients. So these kind of a consideration are actually very important when it comes to application use cases. In this case it's a zik uh you know EVM and kind of a upgrading the consensus protocol itself. So I think this is a kind of an area that is like right now getting a less attention and this is something that we want to contribute in as well.

Right. Potentially hot take but I am not too concerned about like a two to the 80 cryptographic like attack uh in 12 seconds right now. I know Zika's uh it's at the moment are a little bit lower than the others on the stage but this is like the the bugs that I'm worried about is more like what Tir said which is just like making sure that the code actually does what it's supposed to do. Uh that's why at ZKSync we're looking for like we want to have multiple execution clients uh multiple ZKVMs even besides just Airbender. air bender so fast and cheap that we can probably just run a whole second CKVM and get security that way by not having any single dependency.

So just curious like you know have you guys tried to run things like risk uh in air bender and uh you know because you guys are using kind of a customized a client program that is different from the rest of us right so like uh you know what's your yeah just curious about that

yes I believe someone in the audience has been working on it um I'm not sure uh exactly what the benchmark comparison is between just regularly compiling ref and then using like our custom execution client but I think it's like multiple times increase uh performance by writing because the L1 execution clients are designed for normal computer programs. So they have like multi-threading like a lot of kind of stuff that you would use on a normal processor, but then when you're trying to prove things inside the ZKVM, a lot of that stuff is like not too helpful and like kind of creates a lot of overhead. So writing like optimized code for ZKVMs is quite different. And so like it's nice to just say like we'll just use a link client and we'll slap it together but uh there is a performance hit there.

Yeah. So you know I think you know just kind of a want to uh disagree on the approach here because like these kind of a clients uh you know that we are using has been running in production for years has been security audit and everything. So like writing a customized uh you know client for uh you know Ethereum execution that is equivalent that is supposed to be equivalent to the the ones that has been battle tested in field for years. We'll definitely add overhead. We'll have performance benefit granted but uh you know we'll definitely have overhead when it comes to security when it comes to how soon we can actually push this uh uh to live in production.

Not sure what uh you know the rest of the panel thinks about that. Yeah, I think I actually want to emphasize this point too. Like there is a benefit and this is kind of the promise of ZKVMs is developers do not need to change anything and we will absorb it and we can do it. Now obviously up to a point there's clients are complicated. So there are things that we can cooperate on but being able to run existing battle tested clients is really important to us.

And I also think 80 bits is kind of risky. I wouldn't sleep well.

I'll agree with you that I think 80 bits of conjectured security is not sufficient for the L1, especially when currently malicious provers can likely prepare soundness attacks ahead of time.

Yeah.

Um, so I I think we have about five minutes left. I don't know if there are any questions from the audience. Here's all the Merkat questions if you want to. It's sorted by popularity, so feel free to ask what you would like.

Uh, okay. Um, the top voted question, why not open source from day one? Actually, I myself was going to ask, what do you think are acceptable licenses for L1 CKVMs?

MIT MIT uh patch from the first day. This is the This is [applause] so [laughter] I mean I appreciate Jord's commitment to MIT. I actually I I like it in a way. However, I also think there is a big question about our ecosystem like how do we make it sustainable? doing these EKVMs took a lot of work for a lot of people that need to get paid somehow and I think going too much on this like you have to be commoditized and open source is a little bit mean the incentive is aligned in a bad way because then I have to make money another way right um so I think there's room to think about okay what can an L1 specific license look like or I think there's like leave it to the business people to talk about but I just want to emphasize like who pays the devs who pays the prover devs as well is important.

Yeah,

Ethereum has been developed in the open-source uh space and I mean I think that Ethereum has been very well developed and there are ways

ways maybe they don't I can agree that maybe they don't maximize I mean I know that launching a token and pumping it I mean this is good and it's good for for for and you get a lot of money but it's not the only way it's not the only way to um I mean to live from open source a lot open source that are not even in crypto they survive uh quite well and if we are building common good we need to do common good on scratch I mean I don't want uh uh having an Ethereum where you have to pay a royalty every time that the block is mined and uh I want to be open I want everything I don't want to look at your code and being afraid if I can use it I cannot use it if I'm getting I mean I just want to use open source We're literally open source. This is how the space has been built.

Just grow or just to emphasize the VK ZKVM itself should be open source MIT and SP1 is MIT. The proving system itself is MIT. The prover code right now is under like a business license because you can write your own prover as well. There's nothing stopping.

Yeah. But it's what happen if the network is running your prover and your prover just stops. What about lightness? Uh

there are other poofers as well the other teams I've been working with the develop poofers.

Yeah but you should be able to uh uh built in common. I mean you are learning a lot from the open source uh projects. We are going you can take the code. I mean this is how we grow as ecosystem. I think it's not fair that there is uh [applause] I would say license aside.

I do think licensing the prover and putting your monetization on proving actually creates kind of a negative incentive in that if proving proving monetization is going to be cost plus. So as proving costs go down, you know, the the revenue opportunity goes down. So I I don't actually see a case where you know cost plus proving aligns incentives between ZK teams and applications.

Yeah.

I mean yeah

I think I mean so for us like we care much less about the the entire VM stack licensing uh because like you know as mentioned for us like we build a general verifiable computing platform and ZKVM and Ethereum execution is one of that. Uh the well you know again we were the poorest team here is like this guy have 100 million this like hundreds of millions but you know so we we need to kind of figure out

don't you guys have a token

we don't we don't we don't we don't yeah so uh yeah so like soon

you know so yeah so uh you know but we what we focus on is that we kind of try to build more use cases that can use verifiable computing like zkm is very important at the consensus layer but you can actually tap into the power of verifiable computing now in your application because you can offload some very complex configuration into the ZK VM and into things like co-processors that you can generate proof and then use that proof back in your smart contract today. You can actually tap into that power now and this is the kind of thing that we build and this is where we want to monetize and not specifically kind of on the VM side. I know we're still kind of in the business license side but we're kind of changing that pretty soon as well. Yeah.

Nothing.

I mean [snorts] there's a panel later on and who pays the provers. [laughter]

Okay. Uh okay. The next most voted one in which part of the stack say GPU implementation prover arithmetization compiler client do you expect the most gains going forward?

In which part of the stack do you expect the most gains going forward?

I think the place that's been less pushed on because of the security risk as has been discussed is on the compiler side. Um it there's a lot of room to optimize guest programs for ZK and for ZKVMs. Um but it is more dangerous to actually move on that front. Um so I think the natural velocity should be slower but it it strikes me that in 5 years we definitely will be in a world where co where we are co-optimizing the compiler and front end to the actual back end.

It's a balance. I mean this is finding the balance between

optimization and doing things very tricky and writing taking just the standard Ethereum clients that have been battle tested a lot and modifying minimally so that uh you keep the security and it's it's a balance and probably the right place some somewhere in the middle.

I think the proving systems have not matured yet. Um this is a a problem that uh researchers have only been really thinking about for a few years and um I think there's a lot of promise there.

I think our our engineers have already maxed out our GPUs. They're at like near 100% utilization all the time. So there's not much more progress to make there. I think it is like in the cryptography algorithms like new proof systems like maybe multi-linear is better stuff like that will be like the next big innovations. Okay, I think we're at time.

The last thing I'll say is that we uh did a very similar panel on Thursday at the ZISK event with many of the same participants. I noticed that uh you guys are much better behaved and less controversial at an event put on by the Ethereum Foundation. So that makes me quite hopeful at our ability to standardize uh ZVMs and which I think is what we'll hear about next.

Thank you.

Thank you all. [applause]

[cough and clears throat]

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

So, rather than just prove it, it's it's just secure it. So, we're going to hear from from Kev and then after that from the cryptography team, uh, Arancha. And so, uh, welcome to stage, Kev. Uh, we're going to be talking about the how the road to EVMS is paved with good engineering. [applause] Testing, testing.

Can you guys hear me? Cool. Um, yeah, there's going to be a bit of duplication with uh my slides just because of we've talked a bit about them. Some parts are a bit spicy, unfortunately, as I've just learned from the previous panel. Uh, so what do I want to talk about?

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

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

They still need to have the state to re-execute to collect things like logs. Now, for nodes that only want to validate the chain currently, as you increase the gas limits, their resource usage also increases linearly. Once we introduce ZKVMs, they their resource usage becomes roughly constant as we increase the gas limit. And as you can see, there is a point in time where it does make sense to switch to ZKVMs. When this is, we currently don't know.

And one point I want to make is on the gas repricing uh projects that's happening in Ethereum. This makes resource usage efficient but it does but there will be some point in time where we have to where where it makes sense to switch to ZKVM still. Okay. So one important thing that I want to note is that ZKVMs do not solve state growth. The builders and the RPC providers will still need to have the state.

What it does solve is for the nodes that only want to validate the chain. They no longer need the state in order to do this. At at the Ethereum Foundation, we have a specialized team, the stateless team who's also working on solving this problem. So this is a problem that we do want to solve and we do see it as something that's important. Right?

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

A node validates that the payload is correct using their E. And this requires state. Then they attest to the block if it's valid. As we saw in Justin's demo, the beacon block now arrives with the payload header. They wait for the proofs to arrive.

Proofs with a s uh which attests to the payload correctness and then we verify the proofs and attests to the block. So this is the consensus layer and that's sort of the top of the stack. Now let's just look at uh all of the stack. If we start at the bottom, we have the snark prover and the snark verifier. uh for people in the crowd who are not sort of cryptographers, you can think of the snark prover as this component that proves execution for a particular function and the snark verifier as receiving the proof uh attesting uh receiving the proof of uh receiving the proof and if it if the proof returns true or if the verification returns true sorry uh then you can be sure that if you had executed the function yourself this is the output that you would have gotten.

Now on top of the snark verifier I've written the virtual CPU for the ISA. What this means is that there is a function that takes in some bite code risk five bite code was on bite code and this is what the snark prover is proving. So if you have a risk 5 ZKVM, what you have is a ZKVM that allows you to prove execution of a particular bite code, a risk 5 bite code. These three components together is what we usually refer to as a ZKVM. Now on top of this we have the execution layer state transition function and this is what your ref eff client will be uh written in.

This is a function that takes a block and a state proof and executing this uh allows you executing this allows you to know that the state transition function was correct on this particular block. This function gets compiled to risk 5. And this is what the ZKVM's taken. And at the top of the stack, as I wrote before, is the consensus layer. And this is the component that takes proofs uh from the network, verifies the proofs, and if the proofs are valid, they attest to the block.

Uh so this is the whole of the stack. I mean, you can sort of uh go deeper on the snark prover. There are things like polinomial IOPS and PCS's, but I feel like if I start explaining this to this audience, it's probably not going to be super useful. You just need to know that there's a snark prover. There's this component that allows you to create proofs of execution of a particular function.

So let's look at the first component. What do we want now? We want open source open source GPU implementations that achieve real-time proving. What do we want next? We want reliable provers.

This means that your GPU implementation needs to be reliable and where you're hosting the provers needs to be reliable. And what we want later or technically in parallel is to be hardening these implementations. The next component is the snark verifier. What do we want now? We need 100 bits provable security with grinding by Glamsterdam.

What do we want next? 128 bits provable security with grinding by HAR. And in parallel again, we're going to be working on hardening these implementations. You can also see a rancher's talk which comes after mine who will go into more detail as to why we want these things. The next component which is the ISER or the virtual CPU for the ISER.

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

Okay, the next part is the execution layer state transition function. So this goes to the EL's uh the execution layer core devs in the audience. We'd like you to implement a stateless uh state transition function. So this is a function that takes in a block and the MPT MPT witness. The next part we want you to ensure that the STF passes east and this is a minimum requirement.

It needs to pass all of the Ethereum execution spec tests. And again, security hardening is something that we care about. And the last layer at the top is the consensus layer. What we want now is optional proofs on devets and test nets. What we want next is optional proofs on mainets by Gstar.

And later we want to um well, we want to investigate and we want to get to mandatory proofs. Getting to mandator getting to mandatory proofs does require a lot more components and it is the part where we do need to do a lot more investigation. But for optional proofs, we're completely sure that we can do it. You saw Justin's demo. Uh and we want to ship it as soon as possible.

Okay. So what is the path forward? You will not get onto mainet if the ZKVMs are not secure. Like this is the thing that I think we should take away from this talk. Like if your ZKVMs are not secure by the definition that we've said it will not get onto mainet.

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

org? So,

feel free to jump in there or the questions lower.

Uh, what is this question? Uh I think this was just answering that question suggesting that uh those two we could probably hide if you want to look at the one.

Look at this one.

Yep. Okay. Uh how do you envision this new architecture transforming the experience of smart contracts and application developers? How can compilers and dev tooling make developers lives easier in this transition? So I'm not sure I understand the question completely.

I guess one thing to note is that there are two uh similar I guess projects. There's the EVM to risk 5 project and there shipping ZKVMs that use risk 5. EVM to risk 5 is more longer term and we haven't this has nothing to do with my talk. Uh shipping ZKVMs on L1s helps the validators or the testers. Uh so I don't see this affecting smart contract developers.

uh currently I think one thing that might hurt smart contract developers is when we increase uh the gas repricing of certain op codes for example we might want to increase the gas repricing the the gas cost of ketrack for example and solidity uses ketrack a lot so that's the only place that I see ZKVMs possibly um affecting smart contract developers what form of verification standards do you envision I will leave this to Alexander Hicks who's in the he's not in the audience at the moment. Uh he's done bas he's basically the lead of this and yeah I don't want to misquote him. So I'll leave that question to Alexander Hicks. Uh what will you do to make sure ZKVMs actually ship and not get hung up on the research questions and process? This is a good question.

Uh Ethereum is a very special place uh if you want to ship things fast. What we've been doing so far is just trying to integrate into the ACD process or integrate with client core devs as much as possible to make sure that we solve whatever the bottlenecks they think we have. Um, and currently I think it's going well. We know what sort of the questions we know what the blockers will be and we currently have solutions for most of them. I I think this is the only way.

You just have to integrate and yeah when are we going to start thinking in breaking free from CUDA and Nvidia? O yeah [laughter] big O. I'm not sure. Uh I think every ZKVM team uses Nvidia. Uh you guys can correct me if I'm wrong.

I don't think it's a high priority to be honest at the moment. Uh what is the consequence of a ZKVM implementing a different risk 5 flavor? So you can implement the risk 564 IM none was the minimal. You can implement uh whatever you want on top of it as long as we support the minimal. The reason why we do have this standardization process is that is so that such that the ELS and the ZKVMs have a common contract.

So you don't have one ZKVM being slower, but they support everyone and then two another ZKVM being the fastest, but they only support one EL. Can you get onto mainet if you're not secure? [laughter] How will you choose and distribute proof validation systems? H um so I'll rephrase this question. How will the So when an tester receives a proofs there's n uh different proofs there's n different proofs that are registered on the network and they need to receive k of them before they say that the the atestation the payload is valid.

How do we choose this N? We don't currently know. The reason this process is a bit contentious is because the end proof types that you choose, you're basically choosing ELS that become semi-enshrined into the protocol. Whereas right now, if you launch up your Python EL, you can validate uh the execution payload. So there is this sort of permissioned aspect to adding ZKVM proofs.

So, we're not currently sure how we're going to choose N, how we're going to choose K, and we're not quite sure what those values are at the moment. Who is responsible for providing security and how can we help? Uh, currently on our team, we have Cody Gunton. I'd say reach out to Cody Gunton. He's uh right there.

He's putting up his hand. How optimistic are you compared to six months ago? I feel like Justin wrote that question. [laughter] Um, it's not that I'm I'm uh I'm I'm always quoted as being not optimistic. It's just that I I have a lot of questions.

Uh I don't like to I think we know more than we knew six months ago. So I would so yeah I would say I'm more optimistic but I always just have a lot of questions and I like to be very conservative in things that we're going forward with. I like to be very rigorous in the way that we're thinking about this. Um so yeah, I'd say I'm more optimistic now that we've sort of got the proof of concept out that we can do realtime proving. And the thing that we should be focusing on now is security.

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

Um, I do want to say h Yeah. So, one thing I want to say is that I think uh uh uh Sorry, I lost my trailer for [laughter] uh yeah, anyways. Yeah, thank you for having me. Uh, [applause]

all right. Thanks very much, Kev. Um, next up we've got Arancha Zapiko from the cryptography team. And I know she is very excited to have Dev Connect in Buenoseras and in Argentina. Um, I don't need to share.

Okay, welcome. Aranch is going to be talking about soundness.

Did you say Did you say I'm from Buenosares?

No. No. Argentine.

Hello. Uh, well, I'm very excited to be today here for two reasons. First of all, I may be late on the week, but I want to give you a warm welcome to Argentina, to my country. I hope you are enjoying the people, the culture, and the food of course. And second, as a snark person, I am beyond excited to see how and where you guys have taken snarks.

I started working on this like seven years ago. I met snarks seven years ago and in no case I would have ever imagined what is happening with snarks today. So thanks a lot. You really made this like the most exciting field of research. So in this talk we will be talking about the soundness of snarks and we will use that as a path to speak about the security of snacks.

So the idea is that in this talk we can uh discuss a bit how we define measure pro and improve security of the cave. So let's start with how we define a security. So as is like a proof system what in cryptography we call proof system and the CKBMS are in these proof systems. So in a proof system we have two parties a prover and a verifier and they will interact for some time and end this interaction with the prover sending some piece of information that we call the seal law or the proof. The verifier will check this proof with some rules that we set in ambance and if the h this piece of information passes all the verifications the verifier can be convinced that the prover was honest.

The prover was honest by proving that some statement is true. So for a proof system like this we require two security properties. The first one is completeness. If we design a proof system that both the prover and the verifier follow with a statement that is true the verifier will accept. And for sound and the second one and the most important I mean not the most important one but the one we will talk about today is sound is soundness.

So if the prover doesn't have a statement that is true, it should not be able to convince the verifier except with a small probability. So to prove huge things as the ones we are pro proving with very small proofs and fast time we have to give up something and that is a small probability that the prover may cheat. So this epsilon this probability it's called the sound error. uh you may also have heard of knowledge summary res error which is actually uh what we are checking and is the chance that the prover will convince the verifier of a false statement what is more if we speak about MP relations the prover doesn't have a witness for the instance for the relation but is able to convince a verifier knowledge is when the we want to make sure the prover there is not only a witness but the prover knows this witness. So for CKVMs what we are proving is execution of Ethereum blocks right.

So our witness is the block and those the soundest error is the chance that the prover can convince a verifier or the entire network of the correct execution of a block that was never executed. So the summary error here is very important. We have to make it as small as possible because the the consequences of having a cheat improver are huge, right? Like we can actually make billions out of nothing if we are able to break the proof system. So how do we measure this epsilon?

How does it come? How where does it come from? So I think of CKVMs in my like cryptography mine are things like this. The rectangles on the on your left are executions of snark provers that prove error traces and then we have some other provers that aggregate them and probably just wrap to have a small proof but for this talk I will talk only about one of these rectangles. one uh one proof system that proves the execution of an art trace and I will use as an example for our proof system uh an ar trace that is proof using fry a batch fry and deep ali if you don't know what is that don't worry you can still h you will still be able to follow the talk so our pro wants to convince the verifier of the execution of a block of actually the the satisfiability of and air trace and for that they will interrupt for many rounds.

Each of these rounds some of them have more rounds inside but we can divide the proof system in five parts for this. If you are familiar with fry for batch fry we have the fry batching the commitment phase and the query phase. And then for the aggregation of the constraints we can also use deep alley. The knowledge soundness of each of these rounds is a probability that a prover that doesn't have a valid witness convinces the verifier. And for the entire system, we take the soundness error to be the biggest of these ones.

Why? Because if I get lucky in one of the rounds and my piece of information that was not a valid witness becomes a witness that satisfies the the checks of the verifier, then I can just follow an honest prover uh instructions and cheat. So doesn't matter if some of these epsilons are super small. If one of them is big, then the soundest error of my system is big and my system is insecure. So for instance an example if we have a sound error of 2 to the minus 80 meaning a prover gets lucky with a probability one over 2 to the 80 we that means that an adversary a cheating prover will need 200 2 to the 80 operations in order to break my system.

You can think of these operations for today as like just hashes right. So it needs to perform two to the 80 hashes to make sure it will break my system. And we say that such a system has 80 bits of security. Right? Now what happens if I have a system with 80 bits of security?

Let's say that I cannot performing two to the 80 hashes according to my sources takes around a month. But what happen if I can perform two to the 60 hashes? then I still can get lucky and my chances are one over two to the 20 and this is a sound server that we do not accept at all in cryptography. What is more, computing two to the 60 hashes according to my sources takes 40 minutes for instance in an ASIC minor, right? So we went for a month to uh 20 minutes.

The brewer is not sure that we'll win, but the chances are quite big. So 80 bits of security is not enough. What is enough for us? Well, 128 bits of security is the standard set by the National Institute of Standardization in the United States and the consensus in the cryptography community. So 120 bit 128 bits of security is the security that Ethereum deserves.

So if you love Ethereum, give Ethereum this 120 bits of security. So how do we prove how can I prove that my proof system actually has 128 bits of security? So in in my in my mind to prove security I follow the following steps. First of of all you have to know your adversary. What are the resources the time and the incentives it has?

I don't design all system for any adversaries. I hope you don't use the same password for Spotify or for your password manager. Right? But in this case, we have one good thing which is we don't have that much time. The adversary doesn't have that much time to attack our system.

But the incentives are huge. And this is a a problem or something to take into account for the entire blockchain, right? Like the incentives to make money without much effort are huge. And if your incentives are billions of dollar, the resources are also huge because you can buy lot of resources. It's an investment that will pay off, right?

Also, in terms of resources, we can think whether we want an adversary, we want to consider an adversary that is postquantum that is has quantum computers or not. We are aiming for adversaries that have lot of very powerful quantum computers. Step two, analyze your building blocks. Analyze and attack the security of your building blocks. I hope you're aware we have in the etherum foundation a posidon initiative.

So we are putting a lot of resources a lot of effort led by Dimmitri Koratovich on asking people to attack and to study the security of Poseidon which is the hash function we we hope to use in terms of for instance read Solomon codes. We are also h pushing led by Jako offens and coordinated by Justin an initiative on proving conjectures or disproving conjectures that may be used to analyze read solomon goals and I put polinomials here. We already know polomials enough but they are also a main building block of these systems and yeah the nicest of the building blocks of these systems. And once you have your adversary, you have a you know the security of your building blocks, you have to choose what you are going to do. So knowing your adversary, you can choose what kind of security you want to give.

And if you are in you have been inproof calls, if you have been in Twitter or maybe it print these days, this all these words all these phrases may like ring a bell for you. So what is happening here? I'm not getting into the details. I'm not the person to get into the details. But in this fight I would like to like uh highlight two kinds of battles that we can choose.

We can choose to have probable security or conjecture security. Proble means that we can say what the adversary which kind of effort or which amount of effort the adversary has to do to break our system. Conjecture is the same but we do that based on a conjecture. What is a conjecture? Whoa.

A conjecture is something that we believe we hope one day may be proven to be a theory, but it's something that we are not sure about. Right? So why would we use a conjecture? Well, this is a very simplified graph of pro work against security for probable or conjecture security. What does it mean?

Again, in order to to prove an error trace with batch fry and deep alley, if we want to analyze the security of our system with conjectures to achieve 50 bits of security, we need 55 queries. 55 queries is pro work. It's proof size and it's verifier work. I just put it as proer work to simplify stuff. But if I want to do it with pro security, we'll need around 105 queries.

So this is the reason why people want to use conjectctors. We can get more efficient systems with the same security but conjecture, same amount of bits of security. Why wouldn't we use conjectures? Well, there are a couple of reasons that have like uh came to the light for the this all of this happening in the last two weeks. Uh we had some conjectures we thought they were they were true and then they were proven untrue.

They we have new conjectures that we again hope that they are true. And while we still are putting a lot of resources and energy on conjectures from now on in the AF we will only consider probable security. So we'll ask teams to report and we will report only probable security. If conjectures nice conjectures happen to be true that will be amazing. We will report that as probable security.

In the meantime we don't talk anymore about conjectures. So what is happening nowadays and you have heard that from from the teams in the in the panel and in previous talks is that most of the teams have been in this race of speed that we have set from the foundation they have been working a lot on the efficiency of their systems and not that much in the security. So some teams have let's say between 100 128 bits of conjure security. Uh but for probable security the numbers are way lower. I know saxint achieved 100 bits of probable recently but most of the teams are even between 40 and 80 bits of probable security.

So how can we prove this? Um so in this section I will like present what is let's say our discussion inside the crypto team inside the the foundation with the rest of the CKVM teams and a bit of feedback from from some CKVM teams. So let's let's let's see how security how run by ROM security or soundness works h in different settings. So this the soundness and this the security of a system is let's say heavy like heavily relies on two things first the size of the field we are using for our proof system and the size of the extension field we are using because that is from where we sample the elements and the second one is the number of fry queries again if you don't know much about what's the query phase in fry is just there are two things that lead our security. So, uh I for this uh for this graph I use Goldilocks is a field of 64 bits and therefore the second extension which is the first one I will talk about has 128 bits.

So what happens if I do 128 queries using goldilocks to try to prove the art trace using h batch fry and and the valley. Well, it happens something like this. If you see for instance the Ali uh face the Ali um round it's around maybe 110 115 bits of security that's cool again this is only problem we don't talk about conjecture security ever anymore but in the freight query because I'm doing only 128 queries we are at 58 bits of security then that is the security of our system right doesn't matter how high the other bars are the security of our system in this case is 58 bit. So we are bad at queries. Let's double the queries that we do.

And now queries wise we are okay. But all the other faces depend on the size of the field. I'm using a field of 128 bits. Achieving 128 bits of security with a 128 bit field can only be done in very very trivial uh instances. So now we are below uh with the Fry button and we have only 78 bits of security.

So let's now double the size. H sorry let's use one more extension goldilock 3 it will be in orange that has 192 bits. What happen if I do 128 queries? Everything seems very nice but again queries here are the bottleneck. If I don't increase the amount of queries, the security of my system is as 58 bits.

What happen if we do goilocks third extension with uh 256 queries? Well, we are getting there. We have 116 bits of security. And now what happened with the 12 bits that we are missing? We could do more queries.

But as I say before queries comes with brewer work proof size which is right now the bottleneck to achieve 128 bits of security and then verifier work. So there is a technique that we can use it's uh allow to use it's not cheating it's just being smart which is using grinding. Running can buy us some bits of security. For instance, can perfectly buy us 16 bits of probable security and then we can achieve the 128 bits of probable security. What is the bottleneck here?

Why can't we just apply grinding in this 58 bits of security uh case? Well, because this is how prover work uh grows with the bits of security we can gain from grinding, right? So there is a tradeoff and again this is an analysis that we have done with the help of the teams which is very easy to for me to stay here and on stage and say hey this is how you at 228 bits of security but there is a huge amount of engineer work that the teams have to do behind that and we want to uh help them and we want to help Ethereum get the 128 bits of product security that desires. So what is next for us from the EF and from especially from the cryptography team. So as I say before we will only measure probable security.

As Kev mentioned before, we will ask teams to have 100 bits of road security by Glamorum expected to happen end of the second quarter next year. And we hope we hope no we will require 128 bits of security for HAR which is first quarter of 2027. Importantly, these deadlines are like very vague. We don't know when glam is going to be. We don't know when eight star is going to be.

So before the end of the year and hopefully in a couple of weeks, let's see what's the feedback we will receive. We will set hard deadlines for this and also deadlines for uh proof size from the cryptography team and especially uh actually done by Dimmitri and especially George and Ben. We have set a universal soundness calculator where we hope to measure the probable security of the different teams. Um so we can compare apples to apples and everything is measured uh with the same with the same system. What we need in order to integrate your your seavians into this sumless calculator is to please please publish a quite detailed description of the proof system you are using.

Also the parameters and h some engineers improvement that you may have in your code. And again we are aware because of the feedback we have received especially this week that you guys need incentives to do this like this race for speed has been a huge incentive for speed and we need now to promote and to communicate better and to do even some marketing on the pro security. So this is our our new realtime proing 128 bits of pro security. Here is the QR code for the sound calculator. Please do check it.

Give us your feedback. Again, we are only trying to coordinate this. It's easy to stand here and like give a vague details of some vague analysis, but you are the ones that are actually building this. So, please give us your feedback. That's my telegram, my email.

You can reach out. I mean, we are quite easy to reach out uh to anyone in the CKBM team, in the crypto team. you you can also talk to Justin to Alex. So yeah, thank you very much for listening. [applause] Thank you Arancha.

Um so we we have time for one question before lunch. So this is the most upvoted question. What do you think about provers that are postquantum resistant while Ethereum is still using elliptic curve cryptography? What about the trend that NIST is pushing forward that the NIST is pushing forward to postquantum while blockchain is a bit behind?

Well, so h to be honest there is no rush to have provers that are postquantum right now. We are like from the EF we are moving trying to move Ethereum to postquantum as well. You can see the effort on for instance replacing BLS with hashbased signatures. That's also a an effort that is led by by Dimmitri, by Ben, by by Tom and Justin. So, Ethereum will move to postquantum.

I mean, you can decide whether or not to do pre-quantum and then you will anyways have to do a big amount of engineering work to move to postquantum and make it to Ethereum. On the other side, I know that some teams for instance are using a growth 16 wrapper on their proof size on their proof to achieve a better proof size. If you ask me now and I hope no one kills me for this, for me that's okay. As as long as it's something that then you can remove, I would rather go to like 128 bits of security and like do the wrapper to have a small proof. Again, this is something that I need feedback on.

like I don't think I have talen talked to any team that is doing a rapper right now like this week but if you see that this is the only way that you can achieve a small proof and still do the broad security okay Alex says no we don't want rappers well yeah that that part was a personal opinion don't not kill the for me it's not a I mean for a for a couple of months it should be okay but yeah no we are not accepting any kind of rapper we go 100% postqu want to I mean but we are open for feedback. I am very open to receive feedback on that. Thank you very much.

Thanks so much Arancha. [applause]

All right. Um so we're going to take a short break for lunch. So uh if you're one of the first to arrive, I think the first 250 or 300, I forget, um you should have a green wristband. That would get you access to the lunch that's provided. We we kind of underestimated the number of people that would show up and hype hyped [clears throat] this so much that we had more show up.

So, if you got a green wristband, please go grab some lunch. If you don't, um please feel free to go grab lunch at the uh Larule uh vendors. Feel free to sign up for some of these events that we're going to be hosting in can just prior to ETC. Uh seating is going to be very very limited. Uh so yeah, we're taking some applications and we'll see you in 30 minutes.

[music]

Heat. Heat. [music] Heat. Heat. [music]

[music]

Heat. Heat. [music] Heat. Heat.

[music]

Heat. Heat. [music]

[music]

Heat. [music] Heat. [music]

[music]

Hallelujah.

[music]

Heat. Heat.

[music]

Heat. Heat. All right, everyone get some uh protein, carbs, and fat. So, now begins the the meat of the day. Um, so the the rest of the afternoon is broken up where we're going to go we got 90 minutes of lightning talk.

So, boom, boom, boom, boom, boom. Nine lightning talks. Uh we've asked all the lightning talks to be even though it's scheduled for 10 minutes each to keep it to eight minutes so that we got two minutes for Q&A keep it very interactive. um that's going to be sort of uh terminated or that's going to culminate with the the second panel which is on uh formal verification and fuzzing and then we've got a short break and then uh sort of the the the end the uh group three of the day is going to be uh keynotes that you'll see from a lot of the the main uh real-time proving contender uh ZK VMs with the final talk or final panel on uh prover incentives. Who who pays the provers?

Uh so it should be a really fast-paced, fun, information dense uh afternoon. Uh so we're going to start off Maro, you ready? Okay. So hometown hero Maro Tusano from Lambda class going to be speaking about sec security and diversity in in VMs. [applause] Well, hello everyone.

I'm Audano, part of the department of Ethereum alignment or so says my hat uh and lambda class and align um and I'm going to talk a little bit about security in VMs. I'm not going to focus on the cryptography part. I feel like Arancha already did a good job there and there will probably be more speakers that will focus on that. But I want to show you a little bit uh how a VM works and what can be exploited. Um so the the VMs are very complex machines uh to prove like we have uh three at least three kinds of proofs in our VMs.

We prove like what we call like the base layers uh then we compress them with stars protocol then we further compress it with ECC protocols and inside of each proof we have arithmetization cirquial commitment schemes uh we use a protocol that is called f shamir and we have lookup arguments. So a lot of pieces a lot of pieces uh and we an attacker only needs to break one and all the system collapse. If fear is wrong everything collapses immunization is wrong everything collapses. So we need to make to be very sure that everything everything is really really fine. So the other important thing is that okay we have a complex proer that does a good job but we also need to decide what to prove and what what we are interesting in proving is an Ethereum execution client and right now uh there are two alternatives and there are more teams working on more is red or it uh and this means that we have around 35,000 lines of code that should be very very well written we have 60 direct direct dependencies and over 250 transitive dependencies.

And when you convert this to assembly to a compiler, now we have to prove around 700 um,000 lines of assembly. And that's what we are proving. And this 700,000 lines of assembly assembly they need to be once again very very fine, very well written and have no bugs. If there is a bug, then we are in big big problem. So of course like when we want to attack a VM or when an attacker wants to attack a VM uh we will have classical attacks like if the brewers fails with an input like this will lead to an a denial of service and if enough brewers fail like we could halt a network and that's not very good.

Uh we could try to compromise or an opponent could try to compromise uh the machines running the the verifiers. That's probably another big problem, but that's on the classical side. You probably know that uh already uh in CK we also get about two specific types. We call it completeness um and soundness. That means that we have a problem also if a a user cannot prove a statement that is true.

For example, they cannot prove that they own their own wallet. And the worst worst thing is a soundness bug that let's say I can prove that I'm Satoshi. And you probably don't won't believe me if I say that and you will be right in not believing me but if there is a bug uh we we may be able and what we are usually focusing is more on the white hat uh hacking and this is going to be a duel of nights like we will create papers and we will say okay your admiticization circuit is wrong your fear shamir is wrong uh maybe everything is okay maybe a crypto analyst will say you don't have enough bits of security and I can break is but I will argue that we also need to take care with uh black hat uh techniques like because for example let's say that uh we have a VM that is not fully compliant and it has like 250 dependencies and a compiler so can an opponent craft a payload that only affects your VM uh maybe they can and of those 250 dependencies many have one one maintain container and they are all in our code. They are all in the code we are proving is something to be aware of uh in particular when the VMs are not compliant and uh code that works on all machines fail in the CKVMs uh because like of course like the developers of those libraries they don't know about uh CKVMs. Uh what can we do what can we do to make uh safer systems?

I'm a big proponent that the way to make safer systems is just to add redundancy. We need to assume that things will get broken that our prover is broken that the guest program is broken that everything is broken. So what what do we do? We have more checks. We add more provers.

We say okay we have five provers seven provers eight provers. They need to agree. If they don't agree I'm going to start suspecting that something went wrong. Uh one of the key problems that that we still have is like okay we have like around 10 provers maybe some in progress some some some some more developed some less developed they are all proing the same execution client that's probably not good like that there is a single point of failure share between all the proer clients and also many use the same cryptographic libraries so if there is a bug in the start protocol everything collapses too uh and even the compiler one could argue that it might make sense uh to to be careful about the compiler. So that's for me always like the the the right solution is to have redundancy but of course it's important to have robust code and there are some good efforts and and some amazing efforts on formal verification on particular of the VMs uh which is straightforward in the verifiers.

I haven't read much about how to do it with the guest programs and all these lines of assembly. uh maybe someone knows more is seems like something worth exploring. Uh of course fasting might help us to to try to find inputs that makes the the the programs crash. And the last thing is I think we should al try to have to have uh more people watching the code like teach more people don't let's try to not be close because like if only two two people or five know how something works is very hard to find a bug. Uh maybe you know for someone who is in the audience you you don't have time to start reversing chening everything and see if it is fine.

So we should make an effort for people to not have to spend a year to try to understand what's going on and and just take a look and say okay this seem reasonable or not then write simple code uh I think that's something we we focus a lot but try to write simple code don't be fancy uh make things as simple as possible and as I said before like be compliant with specs like I know that sometimes we can get an advantage if we we don't comply with with specs but it starts adding like degrees of freedom. Now, now we you need to think okay like this should be fine but actually we are not fully fulling not we are not fully following specs. So maybe there there is something that can be okay that's the end of my presentation. I hope like you like it. Um yeah we we need to be very serious about this.

Citum is the most important uh financial system for the world. Like we we are going to we have millions and millions of of [laughter] money on it. We need to make sure that everything is really really safe and secure. Uh any questions?

Yeah, we have a couple questions from the audience. So, which part of the ZK VM stack or library is used in the project the most? I.e. What brings the most fragility?

Yes, as I said, I feel like right now the the part that that is everywhere is execution client. The execution client seems to me like the first uh share thing that everyone is using. Everyone is using red living a vendor that they have the their own. Uh so that's probably the first thing to start uh decentralizing a little bit. Uh the second thing is probably the plunky 3 that is amazing but I think like many many many projects are using it.

Uh yes.

Uh the the last question is how many verifiers for the provers uh are going to be embedded in the clients? WASM verifier, EVM verifier.

I think that's more a question that we should ask as a community. I don't have an answer. Uh the more verifiers the better from the point of sense of soundness not from the point of sense of completeness um and denial of service attack because if I require 10 out of 10 uh seek improvers and I can shoot down shut down one then the system doesn't advance. So we will need to to discuss tradeoffs. I think like right now is we are the Ethereum Foundation has been thinking of something about five out of eight out of eight.

Um so that's probably a good number. [applause]

Thank you very much. Thank you. Um next up we have uh Euan from Succinct. Computer's phrasing for a second. Okay, there we go.

Okay. Uh, Yu and Jang from Succinct is gonna be speaking about low latency Ethereum block proving SP1 and subblocks. Welcome to stage Y.

Oh, do I have a clicker? Hey, Will, do I have a clicker?

Uh,

is this thing?

You just use the keyboard to advance.

Oh, yeah.

And then this is here, but really

the pointer.

Yeah, just I don't know how well it works.

Oh, yeah.

All good.

Okay, thanks.

Hello. Everyone hear me?

Great. Um, yeah, my name's Euan. I'm here today to talk to you about uh real-time proving via subblocks. In particular, you might have heard earlier on the panel a lot of the teams were talking about how execution was a bottleneck for low latency proving. And I want to give some more context into that, some other strategies you can do to mitigate that.

In particular, the subblock strategy. So, I know you guys have heard this a couple times today already, but Ethereum needs to scale the L1 gas limit. Uh there's a plan to do this over the next couple years getting to sort of the gigas regime uh gradually and probably the most uh promising avenue towards this is real-time proving and at a super high level. Again, I don't want to spend too much time on this, but Ethereum's gas today is bottlenecked by validator re-execution. And if instead validators could verify succinct proofs of block execution that would uh allow you to pack much more gas in a single block.

So at a high level how do we make an Ethereum block proof using a ZKVM? First you take an existing Ethereum client such as RET. You use SP1 or another ZKVM to compile it down to some bite code. In our case we use Risk 5. And you can execute this bite code inside the ZKVM like and the anatomy of the exact Ethereum block proof well there's some pre-flight checks there's the actual transactions themselves and there's also some post uh execution validation now risk five cycles on their own are not super friendly for zero knowledge proving so what we need is a kind of like intermediate algebraic representation of what happened during these cycles.

So the component of our system responsible for generating this intermediate representation is called the executor and what they do and the intermediate algebraic representation I was talking about we call these traces and traces can be super super big for an entire Ethereum execution the total amount of traces will be hundreds of gigabytes. So what we do we break the traces up into small pieces. We can prove all the pieces individually using some GPU accelerated prover and we can aggregate them together using recursive snark verification into a single constant size proof. Now let's think about this from a low latency point of view. So before you can do anything else in generating your proof, you have to generate the first trace.

And while you're doing that, there's you you cannot utilize any of your proving technology whatsoever. After you generate the first trace, well then you can start proving it, but you can't again you can't do anything else until you generate the second trace and so on and so on. Basically, the point I want to make here is that your parallelism is limited by how many traces you can generate at a time. And in other words, the endto-end latency of your execution, the endto-end latency of your entire proof is at least as long as the time it takes to generate all the traces. So you can see in this naive approach here, it takes so long to prove it doesn't even fit on my slide.

Uh so yes, the basically the most naive uh but effective approach for generating traces quickly is to optimize the out of your executor, which is exactly what we did. Um we took inspiration from the great engineers at CISK who pioneered this sort of raw assembly approach. Uh we improved our executor in from 50 megahertz in May, 50 million risk five cycles per second in May up to 150 million risk five cycles today for our real-time proving demo. Um but and it actually works very well for the 45 million gas limit. But will this scale very well into the future?

Moore's law says no because uh if you want to run a single threaded executor, your speed of light is the e the native performance of your actual hardware's single threaded uh CPU. And that hasn't really gotten any better since 2005. So if we really want to scale Ethereum to a gigas regime, we need to exploit some kind of parallelism. The most like correct uh future proof way of doing this would be incorporate some kind of native parallelism into your into your ZKVM. So that would look something like support for a fork sys call or pthread create sys call and this is a great idea but it's not so simple to implement.

First having a nondeterministic executor can kind of mess with different ZKVMs memory arguments. uh in in other words like proving consistency between uh different risk five cycles. And in another problem you might have is that now your execution client has to reason about transactions data dependencies which is quite tricky and and you need to get it perfectly perfectly correct in order for your proof to be valid. So subblocks are kind of a middle ground. They are quite simple to implement.

uh but they exploit a lot of parallelism. So they're very well suited for the gig gas regime. And the high level idea is quite simple. You just take your block and you split it up into multiple subblocks of different like consecutive transactions. And how do you resolve this transaction data dependency problem I just mentioned?

Outside of the ZKVM, you can have the host hint the output commitment of the first sublock into output state commitment of the first subblock into the input of the second sublock. And you can connect these sublocks in this way. And when you compress all of the individual subblock proofs together into a single constant size proof, you can verify that these hints were in fact consistent. Now just to drive the point home on how sublocks create uh super great like parallelism, you have three executors running at the exact same time. So with after you generate three traces at once, you can have three provers going at the same time generating proofs.

And also note that each subblock is going to be shorter than your original Ethereum block proof. So you're not only do you generate more traces at the same time getting more uh getting more utilization your execution portion of your computation also is much shorter. So using subblocks we were able to achieve 94% of mainet blocks proven in May 2025. Um, this approach has also received some great adoption from other teams such as Brevis who use it today for their zero knowledge for their real-time proving demo. And we estimate that if using this technique with our current executor technology, we can bring the serial bottleneck of our computation down from 4 to 6 seconds all the way to 1 to two.

So this is a really important um latency saving technique that we expect to incorporate well into the future. Um, yes, that's my talk. If you have any questions, please ask. [applause] Thanks, Yan. Yeah, we have a couple of questions here.

So, in order of popularity, uh, have you considered using block access lists, uh, which will be shipped in Glammsterdam to inform your subblock trace generation? Um we have in the past and in fact getting the correct uh like abstraction the correct communication between the host client executor and getting the right inputs into the ZKVM we think is like a super important like uh future direction. Um so yes it is being considered but no not in the short term because our really fast executor is doing a great job.

Yeah.

Great. Uh, next question. Do the sublock subblock access lists also contain Merkel tree nodes? Um, let me go back to my slide. So, yes, basic basically you're asking like what is the composition of like the storage A, storage B and yes, they are like Merkel tree commitments um of of the touch state within each sublock.

I do want this is a great point to mention that the this merkelization step actually does add a lot of overhead for the sublock technique because like you're sort of merkelizing the same stuff in every pre-flight and the same the same stuff in every validation but yeah at a high level that's kind of what's going on.

Uh why 6% of mainet blocks uh have not have not been proven yet through subblocks. Well, actually Brevis did like 99.7 with subblocks, so that's pretty good. But um in May, our problem was that the longest transaction uh would be to take too long to execute. You can sort of think of subblocks as like punting the serial bottleneck from the entire execution down to the longest transaction.

So that was sort of what was keeping most of those 6% from being really low latency.

Excellent. Thank you so much.

Thank you.

I'm going to try and quit a couple of applications so you stop seeing all my notifications, but who knows if it'll work. Okay. Uh, next we've got Leandro talking about Ethics. Okay. expanding Ethereum's uh proving landscape with ethics.

So Leandro Vigno from also from Lambda class aligned. [applause] Okay. Hello. Thank you. Thank you for having me here.

Well, the idea for this talk is to well talk a little bit about the and the idea that we have of expanding the the proven landscape with with another client. If we take a look in the execution client landscape, there are the diversity is quite good. There are many great clients. And when we start looking into the proving side of things, uh most of the teams are most of the team here uses like just one only client getting aside Cync that uses their own like OS. So I I wanted to bring here which is uh the execution client that we have been working over the last year.

Mostly one thing is that we love Rust but besides Rust we have been working in this field for many years and we realized that code bases were quite complex and we have been always talking with different teams struggling with complex code bases. Uh so we decided to okay why not building a new one when why not add some new piece of software to this to the to this like field uh and that's when we came up with withdrex the idea that it should have minimal dependencies uh much much less lines of codes we shouldn't have like clever abstractions all over the place and we should have concurrency only where needed and and I guess at this last this last point is quite essential for for proving uh and well talking about this ecosystem explicitly I've been hearing I've been hearing today that most of you see execution as latency uh that's weird for us but you see us as latency and well I think that uh with this code base that we have there is a great room for improvements and we will be able to gain much more o over this latency that you see is uh we have a share code the L1 and the secret roll app that we're building because it is both for DL1 and and C rollups so we don't have a duplicated code and we ensure consistency everything that we that we do is consistent with CK uh also we have been building this Ethereum brick execution tooling enable to enabling us to execute and prove Ethereum blocks in different CKVMs easily like a separate repo. I will show later a QR. So for everyone like we are we are already integrated with re zero SP1 and CISK and we have been working with with Revies with Pico from Rev and with OpenBM for a while to to include us. But right now this is like our repo and it should be very simple to have your own guest program in this explorment.

We just need to handle the stateless execution for any CKVM that that we want and it should be pretty easy actually with CISK we just did it in this last two couple of days working directly with them and it was super easy to to integrate and exclusively talking about minimalism we really enjoy uh showing this this small graph like okay we are onethird of lines of code and other clients And well, this is uh for us something that we celebrate a lot and and we're always taking care of. It should be easy to change. It should be easy to improve. Also, we have less than half of dependencies. It's not easy to compare dependencies, but with with clients built in the same programming languages, we are above half of of the dependencies than than they have.

and some performance. You won't be much interested looking into those these numbers here in the proving land landscape. But what I wanted to show is that we're working a lot with performance. What you see here on the on your left uh is all the achievement that we have done over the last month. We did a 10x on the last month on the gigas uh by block and well block time reduce by 10x.

Uh this is quite amazing amazing. These are not very good CPUs. With better CPUs we have a better performance of course and we still have a lot of improvements to be done. We're working on that and we are confident that we can achieve much more performance and not only with this but also we like adapting the guest programs for the the different CKBMS that that that you have. These are the numbers that we have and that we have recently uh incorporated with the six team.

And here you can see like for example for SP1 Turbo we are like in from 2 to 12 minutes that that's a lot that's obvious obviously not real time but well yesterday and the day before yesterday but with the help of CIS that um share with us the their their multiple GPU thing uh their their GPU farm with 16 5T90. Well, we achieved proving some blocks in the range between six second to 15 seconds and this is with what we have at the moment. We haven't done anything in particular uh to adapt or to improve. So this is like the starting point and I think that as a starting point is a very exciting starting point and well what I'm asking here we would love to work with with all of the people that are in the room. It's very exciting for us.

We have done a few collaborations as well with different teams with the for the team foundation and the CKBn team. We help them integrate EDRex in their CKVM and we're very grateful with that uh because well that that give us also a place where we can show what we have been doing uh and we are reviewing their standard their standardization proposals for different CKBMs and that that is a great effort not easy to be done and well I think that they are doing a great job over there and we are eager to help them. uh and the idea is for us to become fully compatible with array which is like the this effort of unifying the interface written in Rust. Our future work on this as I said this is just the starting point. We need to lower our proving times with a single CPU.

Those are not great. We have there with 60 33 second or 60 seconds for for 2 minutes for SP1. We need to lower those numbers but we also need to work in mic should be improving also pipelining execution to reduce latency. We need to integrate and we want to integrate with more CKBMS and well we we want to work on the integration with as an alternative for for ERX and this replay which is this this which is this execution uh tool in that dimension. This is a link to the repo but if you cannot scan the QR if you want you can just look for ether replay in in lambda class repositories.

Um well I think I'm just on time. Uh this is us if you want to follow us or give us some love in in inreo. Uh we'll be around we have been around all this week here but we are pretty easy to find. uh and we will love you to reach us out and or or to answer when we reach you out uh for for integrating with with index. Okay, thanks.

Thanks so much, Lander. Uh we've got time for uh one question if you're open to it. So

uh are you looking into doing ZKVM specific optimizations other than using pre-ompiles like using hints or ZK friendly hashmaps?

Yeah. Yeah, that that's a possibility that we are exploring actually. Uh it's something that it would be great to discuss with the specific teams working in CKBMs, but yeah, definitely it's it's something to explore. And then uh final question, how many of your per how much of your performance optimizations are due to SIMD instructions and other CISK and GPU optimizations that aren't available in risk five risk 5 as a

okay to be honest I don't have the answer for that uh but we can discuss later with the team all the CIS integrations has been done in the last two days that I've been like all around the place and we don't understand what my team did.

Okay. But happy to continue later.

Okay. Thank you very much.

Thank you.

Thank you. [applause] Okay. Uh, I was trying to mute my little calendar invite things that keep popping up. I apologize. I can't figure it out.

But, uh, next up is Jim Posen from, uh, Irreducible talking about binary proofs for bitwise operations. Thanks.

Yeah.

[applause]

Let me set my uh stopwatch here. Hey everyone. Uh thanks for being here. I'm Jim. Uh I'm going to talk to you about Binius 64, which is the latest version of the Binas proof system that we've been working on.

And I'm going to I want to talk about basically the journey to get here, some of the learnings along the way. There were a lot of new ideas, but also a lot of discarded ideas. um and uh it's ended up in this this new proof system. So to start with the basics, what is binius? Actually not that easy of a question to answer.

A lot of people think it's this paper that we published uh two years ago which curiously does not have the word binius in the name. Uh and it turns out that that was a good thing that we didn't put it in the name because uh we ended up taking some ideas but actually discarding many of them. So the core contribution of this paper was a polinomial commitment scheme for binary tower fields and we shortly f after this found a better polinomial commitment scheme and actually binius 64 doesn't even use tower fields instead binius 64 still uses binary fields but it's a simple and standard degree 128 extension over uh gf2 that we ended up using. So instead of describing what is binius by like the cryptography techniques that we use, I want to go to like why is binius like what are the founding what are the principles that we're trying to achieve with this system. So when we started profile or when we started profiling the existing ZK snarks that were out there uh proving was very slow and we set out to build a computationally efficient proof system especially targeting custom hardware as in if we could build hardware specifically for ZK proving which is what we were doing.

Um what is the most computationally efficient and we basically found these three bottlenecks. So the first is all proof systems just boil down to like lots of finite field operations. So you need to make your finite field arithmetic really fast. Now it's well known that in custom hardware binary fields are the most efficient. What not everyone does realize is actually on modern CPU processors the fastest 128 bit cryptographically secure finite field available is the G# 128 bit finite field because modern processors have acceleration for this.

The second thing is we termed this uh this phenomenon of embedding overhead which basically all the proof systems suffered from. And in order to emulate bitwise operations which are are common like exor and and you would pay the full cost of a finite field operation to do something on one bit of information. And this is really pronounced when proving classical hash functions which is not uh a niche use case. It's of fundamental importance for backwards compatibility and security. So the way that most proof systems including BSV0 went about this is to throw a lot of arithmetization tools at the problem.

So if you have too many gates then we're going to make some custom gates and uh to handle range checks we'll we'll add some lookup arguments and then to handle control flow uh we're going to build a virtual machine which uh can emulate um program execution and we'll we'll use recursion for memory usage. But then each of these tools sort of creates more uh things that you need. So when you have uh custom gates, you're going to start doing like table layout planning and the virtual machine needs a memory argument now. And uh you might want a custom language for that machine which means you have a compiler. Uh we have some pre-ompiles and now our tables are getting really wide.

And when we have you know custom gates now our our verifier logic is getting dynamic and it's uh maybe so dynamic that our recursion architecture like needs to itself be a virtual machine in order to just handle recursion. And we sort of wound up in this in this tangled mess of complexity. And so Binius original v0ero uh basically took all of these techniques and and tried to throw everything at it and and some more that were specific to our settings. So we had this idea of we were going to arithmetize over multiple binary tower levels that our arithmetization had different data types. Um we have we wanted to leverage derived columns that were not committed because uh if commitments are slow then we can use these sum check based reductions and this sort of um got too complex to handle.

And so we wanted to change to building okay how do we make just a simple zero knowledge proof of a identity credential like a concrete use case that's not block proving and all this stuff was getting in the way. Um and so we for these this client side proving use case that we then wanted to tackle kind of went back to the drawing board and said okay how do we make a much much simpler proof system that's taking the advantages of what we have but otherwise um you know trying to be as simple as possible and we arrived at at bineas 64. So we basically kept these uh these four crucial components. So the first is a polinomial commitment scheme that can efficiently commit to bits without embedding overhead. So we can commit to the individual bits of a system that uh we want to use.

We can very efficiently prove uh the bitwise and relation. So this and we can also prove exory because that's native in binary fields. And the way we prove bitwise and is using uh an idea called the univariate skip. and um sort of optimizing specifically for that use case. We also have a a special integer multiplication accelerator which is a GKR circuit.

So we have a a specific technique for uh doing an integer multiplication check sort of in the exponent of our finite field using a GKR circuit. And the last kind of unique thing about this system is word level wiring. So instead of sort of containing instead of having wiring information per bit, we group all the bits into 64-bit words and um do the wiring that way and that is very natural for programs which are you know a lot of hash functions are are based on 32 or 64-bit words. I will mention that this is not a VM. This is not capable of proving Ethereum blocks.

This is for simpler client side use cases and it's in a circuit model. So this is the like one picture diagram of how things work. So we have a witness on the left and for every witness word which is 64 bits we get to apply some bit shifts. We can exor accumulate as many bitshifted uh things together as we want and then we can either um apply or constrain them with bitwise and relation or the integer multiplication relation. And um this is only a few tools, but it's really powerful and lets us prove a lot of hash functions.

It lets us prove we've uh written circuits for elliptic curve uh signing. We can do Ethereum signature verification um using the the mole constraints and our performance numbers are uh are really good uh compare for on the CPU compared to stew and plon 3. our single threaded and multi-threaded performance for hash functions um are are the best that we benchmarked against. Um so the point I'm trying to make here is with just a few primitives that are sort of carefully distilled out of the research that we did with Binas optimizing specifically for bitwise relations we can have this very powerful uh prover model and um and it's working for for client side proving. Now, as I said, this is not a VM, but this these techniques, I think, could be adapted really well to the VM setting.

And in fact, our bottleneck with this system is is one that was surprising to us, which is uh the wiring argument. And I think that could be optimized away in a VM context. Um, I want to aside from the cryptography here, make one final point about simplicity. So we're building systems and technologies to secure like global financial infrastructure and there's been this explosion of ideas in the space and this process of building BSV0 and then Binia 64 has really enforced um not just the importance of simplicity to me but that simplicity requires sacrifice but it's worth it because the complexity of these systems compounds and um if you you know, that was my experience with this. So, uh, thank you very much.

[applause]

Okay, thanks Jim. I've got a couple questions here.

Um, first question, uh, any future plans roadmap for Binia 64 that you have in mind?

Um, definitely. So, Binia 64 is not zero knowledge yet. uh that is on the road map intended to get it done within a few months and then it will be a zero knowledge proof um with you know proof sizes on the order of 100 couple kilobytes and then beyond that the road map's unclear.

Um is the wiring verifier linear? If so, how do how do you uh plan to address this?

Is the wiring verifier linear? Um the verifier is I mean it's a it could it will be a succinct argument with um so oh sorry the ver the wiring verifier right now is it needs to do a matrix evaluation so it is not succinct but it can be made succinct using the standard spark technique that's in in Spartan. So um it would be a sublinear verifier for wiring once we go and implement that. And personal question, well from me, not a personal question, but have you checked out the new client side proving dashboard on ETH proofs that just launched?

Uh, someone sent me a screenshot of it that needs to go

64 is a top several leaderboards. So

cool.

Interested to see if you have feedback on it. If you do, I'd love to put you in contact with the team.

Absolutely. Thank you.

All right. Thank you very much.

Uh, up next we got Leo Alt from Powder talking about pre auto pre-ompiles. Um, I think maybe I got rid of the pop-ups. So, we'll see. All right,

sounds good.

Yeah, thanks.

Leo from Powder talking about auto pre-ompiles compiler based acceleration for ZKVMs.

Yes, thanks Will for the intro and for the great work on it proofs and this event. Um Zikavm pre-ompiles are fundamental for the performance of ZKVMs. However, they are quite difficult to um write, read, audit, proof correctness off and scale. Um it's not sustainable to hand write these massively complex circuits every time you want to accelerate a gas program. Um this is not a thanks Alex.

It's not a sustainable uh design for ZKVMs. So wouldn't it be great if some form of gas acceleration happened automatically? Um this is already happening. Auto break compiles are automatically synthesized um circuits. This is not some futuristic out of reach um research we're speculating on.

This is something we have code for that works right now and already improves a few major ZVMs. This is obviously a very deep complex topic. This is a short talk. So feel free to reach out with questions or find me later if you have deeper technical questions. These circuits aka pre-ompiles they are generated from the program's basic blocks using old and new techniques such as profile gut optimization hot path analysis something we call hot witness analysis we don't really call it that but for the purpose of this slide I call this this and we're also working on new/ old techniques like branch prediction analysis these kind of things that has been common in the hardware world and seems to apply quite well to zms as Well, after these circuits are generated by a very simple process, they are extremely heavily optimized by lots of optimizers we have in the powder code base such as static analysis, um, compile time constraint solving, loaded germ substitution and lots of other super interesting techniques.

As the name suggests, this is of course fully automated. It is ISA agnostic. We currently work mostly on risk 5, but it is ISA agnostic and it already has comparable performance to handwritten pre-ompiles as you're about to see and the security also scales a lot better than handwritten pre-ompiles. Other pre-mpiles are fully integrated into OpenVM, one of the main zvms out there um already doing real-time proofs on Ethereum. This is a bench a reference benchmark we run often to test the current state of our of the powder auto pre-ompiles.

This benchmark does catch or 10,000 iterations of catch and we have three settings here. The pure software version which just uses the tiny catch rust library. It's just doing catch in Rust. No pre-ompiles involved and it takes about 800 something seconds to prove it on a certain CPU. Um if we use the handwritten pre-ompile that comes with OpenVM, we get a 10x acceleration which is obviously very very good.

Um but if we use auto pre-ompiles, we actually get even more acceleration, 11 times faster than the software version. And so 1.2 times faster than the handwritten pre-ompile. Actually, if we use this for Ethereum, we're not necessarily interested in replacing the pre-ompiles that are already there because they are very performant. So we want to use the current software version plus handwritten pre-ompiles that are already there proving Ethereum and this is um the proof time for some run and you can see that as we add new or more auto pre-ompiles it gets faster and faster.

So currently with OpenVM plus 100 auto pre-ompiles, we got 1.37 times faster end to end proofs including recursion. Um it's important to mention recursion here because in the current way that a lot of ZKVMs and provers are written, there is quite a big penalty for having a lot of circuits or a lot of pre-ompiles in the ZKVM for a certain guest. Um because the verifier is linear in the amount of columns. It goes into details but the more auto pre-ompiles you have the more penalty you're paying off in the recussion layer.

So it it ends up being u being a lot slower but we already get this acceleration even including recursion. So as more approvers maybe move into multilinear settings uh this will get uh faster and faster with this. We have uh integrated powder NVM on proofs as of last week. Um which is great to compare to the state-of-the-art ZKVMs um and be be part of this this race and test our own optimizations with time. What's also interesting is what's after this?

What can we improve on now? So as I mentioned just now, recursion has a pretty big penalty on this. But let's say recussion is solved. Not a problem anymore. What can we do?

How many auto pre-ompiles can we use? Well, if we use even more 500 or 1,000 auto pre-ompiles and we consider only what OpenGM calls app proofs. So this is before recursion starts, we actually got almost 2x um faster proofs already. Um, so if we can actually do even more, so if we could accelerate all the 13,000 plus risk 5 basic blocks that the RET um client has, usually 80% of the trade cells that are in risk 5 right now would simply vanish. So you can maybe see where I'm going with this.

Um, this is some analysis that we do often in our benchmarks, which is what's the effectiveness of an auto pre-ompile. So each risk 5 basic block becomes an auto pre-ompile and not all of them are used because of of current restrictions on approvers but we we know what the effectiveness of another pre-ompile is meaning how many like fewer trace cells do we use if we use that that the approver has to commit to if we use another pre-ompile instead of a risk 5 basic block. So after our new optimizers integration or testing the last two weeks, we actually seen almost seven times average exploration per basic block in the REF benchmark. This is also a pretty fun stat. In some basic blocks in the RAF benchmark, we actually see up to 20 22 21 22 times improvements when you take a risk 5 basic block and transform it into um into a circuit.

And interestingly the EVM interpreter code implementing the op codes later uh less than and greater than for the EVM are actually among such basic blocks that are accelerated almost 21 times when you make a circuit for it. Of course a lot of people ask um how are we going to secure all of this? You can possibly pay enough people to audit and verify this manually. As the whole thing is automatic we also want to do automatic formal verification. So we have two projects going on.

One is our own uh lane four rewrite of the optimizer. We want to have uh fully um pro like correct by construction prover where which you can prove in lane 4 and then a verified checker as well that can check when auto pre-ompiles are um generated. We also have a project with different foundation serora to use SMT based approaches to prove that every single generated auto pre-ompile is semantically equivalent to the risk 5 basic block that it came from. This of course um also propagates to different ZKVMs and S1 HyperCube has an initial integration with auto pre-ompiles that already shows almost uh twice as fast proofs. Um to finalize I wanted to note that auto pre-ompiles are not just a potential replacement for the pre-ompiles we have now in Ethereum.

They're also not just a tool to accelerate Ethereum. um they can be used for any guest to accelerate any basic block that we're not even aware that they could or should be accelerated. Um auto break compiles are bridging the gap between ZKVMs and ZK circuits. They are basically removing the ZKVM overhead and bringing ZK's bringing the performance of ZK circuits to ZKVMs while keeping the best UX and the effects that we already have from ZKVMs. Thank you.

[applause]

All right, thanks Le. We've got a couple questions here. I think perhaps you answered the first one. Uh I'll restate it just in case. Can you give a brief overview of how you plan to formally verify your optimization passes?

What spec do you do you compare against? Yeah. So the most realistic for now, let me go back to this is so every autopilot generated from a risk 5 basic block from the instructions in that basic block and the circuits that verify those instructions. So the first idea here is to take the optimized circuit after all the heavy optimizations and prove that the behavior is semantically equivalent to the risk 5 basic block where it came from. So as long as the original ZKVM is formally verified, we keep the same level of security with auto pre-o compiles as well.

We don't reduce levels of security of the ZKVM itself. Um the other approach the more long-term approach which is we are writing the optimizer in the whole process in lane 4 as well so that we can have proof of correctness of the whole algorithm of the whole codebase um and not just prove auto pre-ompiles as they come out. Hope that makes sense.

Great. Uh last question uh how did you go about defining defining a basic block or is it dynamic?

Um a basic block is pretty easy to identify if you look at risk 5 assembly code or most assembly code you'll have branch instructions jump instructions a basic block is basically a a nonbranching sequence of instructions that ends in a branching instruction. So this is is pretty um it's pretty identifiable from from compiler generated code. Awesome. Thanks very much.

Thank you. [applause]

Okay, next up we have uh Mosen from Zirkit. So we're going to be talking about Rust proof orchestration, proof orchestration and rust scaling proof workflows. Thanks very much.

Thank you.

Hi, I am Mosen and I'm going to talk about proof orchestration. So today we heard a lot about ZKVMs and how fast they become. We heard a lot of great news about how things are advancing. I was very excited to hear about that. This talk is going to be about how are we going to orchestrate the workflow.

So we have this stream of blocks that are being generated very fast every 12 seconds right now and we want to generate proofs for them in a reliable way. So whatever happens from the moment that the block is created until it reaches the point to the um consensus layer to say this block is valid everything that happens in between needs to be managed by a piece of software and that's basically the orchestrator that I'm going to talk about. So we've been at zirket we've been working on orchestrators for some time. It's been a bit more than two years. We have been running our workflows or uh proving workflows inhouse and we have faced a bunch of challenges that we had to fix over time.

And I'm just going to quickly go over that. So one of the challenges is basically being in time. Real time is not that important on L2. But when it comes to L1, we have this real real time requirement that is in place. It's going to be difficult to do everything in real time.

The workflow has to be elastic. It has to scale dynamically with the needs. So we heard about this gigantic blocks. Imagine if you have a lot of them that are being pushed at once or in a certain short period. Then you need a lot more provers to actually deal with those amount of blocks that are coming in.

The third one is my favorite and that's why we all gathered here today is the innovation in the ZK space is moving very fast. Cool new stuff are coming in every day. So we need to build an orchestrator that can change with the pace that the space is moving. Um another thing that we have seen in the production system when we run the orchestrator in production is basically uh the failure that is happening any piece in the system can fail. So a good system a production system need to be able to deal with failures.

And the last one is basically being able to run on different hardware. So what are the requirements? I'm going to quickly go over that because of lack of time. We need something that can do any ZKVM or any prover that comes later. It has to be able to prioritize things when there is limited time.

It needs to have built-in fail failover and be able to retry it. Nothing can be forgotten. So you cannot have a request for approving that is lost or forgotten. Uh it has to have distributed coordination, multi-et network, scale horizontally, vertically, redundancy, failover. It has to be able to time out when it's needed.

It has to be able to report how the progress is going and it needs to do basically real-time proving. So what is the design? This is the part that I'm that I want everyone to take away from this talk. Basically what we have designed is based on map reduce nothing new the architecture itself is well battle tested out there. So what what you need to do every piece of your proving uh pipeline has to become a dispatcher.

So basically like map. So those shapes that you see over there those are my steps that my prover needs to execute in order to compute a proof. Then for any step that needs to wait for other steps. So if you have a multi-step prover like the subblock idea that we heard from the SP1 talk, those subblocks need to be merged back together and you need to compute a recursion proof over them. So that's where you basically need a collector to collect all the proofs that have been computed in the previous step.

You want to make a new message out of that and then you want to do an operation over that. So at the that's basically how the architecture work. Uh in order to fulfill the other requirements that I mentioned, we worked on a basis of a message bus. So any communication that goes through this um workflow of provers needs to go through a message bus. This has to conform to a trait.

Right now we have implemented in NATS but it could be implemented any messaging or gossip based protocol that you want to do. We are implementing it in traits. Uh so what the message bus was needs to do needs to be able to route work and this could be inside the network you are running could be outside the network wherever you want to route it. So the message bus would be in charge of communication between all the services you are running. And then at the bottom you have the workflow runner that decides what kind of workflow you want to execute.

Let me just do a quick very quick example to take this whole this point home. Basically let's say I have the ZKVMX that has three steps. So I have a rectangle, I have a circle and I have a triangle. In order to compute the proof that I'm supposed to compute, I need to do rectangle and um circle first. So those two can be executed in parallel.

So that's that's what I'm going to do. I'm basically going to put two dispatchers together. So I have a dispatcher that starts carrying out the rectangle, a dispatcher that does the circle. Then I put throw in a collector that waits for basically these two types of proof that I require. It would not finalize until the exact two types exact types two types has received and then composes one message for me and forwards this message to the next component that is going to be my dispatcher and carrying out the final operation that in this case is a triangle operation.

So as you can see I can basically with this flexible design that the orchestrator has I can uh design any for any workflow that I need for my proving pipelines. So let's take this basically to ethroofs. We were looking at the ethroofs pipeline. So there are uh multiple provers SP1, cyper cube, zero, all different provers are running there. We don't have visibility on exactly how this these VKVMs are being executed.

What kind of hardware they are using. Uh we hear about how many GPUs are used. We don't know exactly where they're being executed, but we try to imagine how this could be executed if we were to use actually our orchestrator. So the idea would be for any of those workflows that these provers have, we need to design uh using the orchestrator the workflow that that I explained to you. Each piece of this operation could be executed on various hardware.

So basically you could have a piece of your proving pipeline that sits on Kubernetes bare metal. You could have a piece of your operation that sits basically on AWS managed cluster or you could have your special hardware or a machine or a cluster that has so many GPUs thrown at at that. So even the internal steps of your prover could be broken down as long as all the pieces of the uh of the workflow can reach and dial one another um through the message bus that we have everything should be basically manageable. So in the case of running the entire prover pipeline that you have on the same machine it's going to be it's going to be much easier but still um the same idea. So the entire prover sits on one machine all pieces need to communicate you break it down into dispatcher and collector and basically you have everything together.

So for this very example of ETH proof's website, we have put together a demo. You can scan the QR code that you can see on the screen. This takes you to the orchestrator that we have put together and you can try you can see how the demo works. We don't we haven't hooked it up with the uh provers in the background. It's just mock provers but I'm going to show you how you can basically add any provers to this uh orchestrator that we have right now.

The orchestrator the way it's it's working it expects an input that is has to be in JSON format. an output what what is the output of the step and basically if you conform if you put a binary inside the example that I showed you in the demo repository you would be able to um if you put your prover inside with this input and output format that I showed you your prover basically would be part of the orchestrator tool so what are the takeaways so what I showed you here is a universal proof orchestrator it can run any provers on any infrastructure uh and any hardware no limitation on the execution It is battle tested. We have been using this prover in production for a bit more than two years for running our L2 proving needs. Uh it has fall torrent at its core. God knows how many times we had to wake up on call to fix some issue that was in pipeline.

So we have put all those lessons alert in into the design already. It scales automatically. Uh I showed you a mock uh demo of ETH proofs. You can scan the repository. You can take a look.

Uh we what what is on the repository? We have open sourced the images. So the binaries of the orchestrator are are released but we haven't released the source code. We plan to release the source code soon. Uh and we are seeking ecosystem collaboration.

Thank you very much. [applause]

Thanks so much Mosen. U final call for questions. I don't have any queued up.

Very clear presentation. Thank you. Thank you.

All right. So, when we started this whole ETH proof experiment, um we would sort of use a very quick shorthand elevator pitch, I guess, to like uh uh paint the picture with people when we were onboarding and like having conversations and we'd always say, "Eat proofs, think L2B for ZK VMs." So it's really really cool to share the stage with a couple of main contributors to L2 beat. So first of two talks back toback we've got Luca Dono talking about uh native roll-ups. Um hey everyone so I want to talk about native rollups.

uh I don't have enough time to uh discuss the technical details but I just want you to uh I just want to present why I think they make sense from two different perspectives. So the perspective number one is the perspective of uh we want to scale Ethereum right. So if you look you know at everything that has been said and if you're kind of familiar with roll-ups um you can see all this scaling effort uh with ZK on L1 as a way to basically turn um Ethereum into a rollup right um if you look uh in the way that a zik rollup works today. What a developer does is this you know off-chain infrastructure that has its own state uh executes some transactions offchain. it proves those transactions and sends um a state route with a proof to um to L1 to an the execution layer of of Ethereum right and if you look uh on the other side at what L1 does is that you know we're taking the execution layer we make it an offchain components uh we execute transactions we create a proof we send the state route uh with the proof to the consensus layer so um you know I haven't seen this uh narrative very much but in my opinion And again the ZKL1 effort is a way to uh basically turn Ethereum into into a rollup right.

So now uh if we do this uh what's the what's the limit of the scaling and um like probably with this effort we can get to uh the gigas uh but the thing is that you know why stopping at at the gigas maybe we want to get to uh teragas per second right and the only way to do this is with horizontal scaling and we've been discussing uh you know how rollups help with horizontal scaling uh how we can use zk to vertically scale and and roll up to the same. Now d L1 basically becomes a rollup. Uh a way that you could think about this is basically okay what if we run like multiple chains in parallel and then like settle all these like zk execution uh layers uh you know we run them in parallel and we settle them on the consensus layer. So this is like a classic zkar approach. Uh it's kind of complicated in my opinion because now you need to think about a consensus layer that needs to coordinate multiple execution layers.

Um how do they even communicate together? You know, you need to figure out some messaging system. Uh some people might have some uh PTSD from uh sharding uh because of this uh but like some blockchains actually work um do sharding already in production. This might be viable but in my opinion it's complicated. Another way is instead to use uh the rollup infrastructure that we have today.

So uh you have one single zk execution layer. This is a one that gets snarkified and then you have uh on top of the execution layer the ziki roll-ups. And this is basically what is already happening today, right? Um you might say okay but this is not really sharding because they need to provide their own infrastructure, their own proving system. They're a little bit different.

They don't upgrade at the same time. And the solution to that is exactly uh uh introduced by native roll-ups. So the idea behind native roll-ups is okay let's take this zer infrastructure that the one uses it one already uses and let's expose this uh to the rollups to users. So instead of having to deploy your own proof system um you can just use uh the exact same and this can be done by exposing the L1 state transition function to the execution layer uh through a pre-ompile uh which we'll call the execute pre-ompile um and in practice the way that this will work is you know uh on L1 you have an L1 block this L1 block contains transactions this transaction will call a roll of contracts the rollup contract will call the execute pre-ompile And inside the execute pre-ompile there will be this recursive call to the state transition function which is the same one that Ethereum uses. And um what the L1 prover will do is that it will prove everything uh up until like even inside this execute pre-ompile up until this state transition function call and then everything that happens uh afterwards and the transaction sender which is in this case like a rollup operator um will um will provide a zika proof uh when when calling this uh when sending this transaction.

Uh can I toggle this? Yes. Okay. Um the second perspective is a little bit different. So the first perspective was about uh scaling L1.

The second perspectives comes from the rollup, right? Um so what are the issues that existing rollup face today? The first one is that they spend a huge effort in building the proof system and maintaining this proof system versus you know uh like alt-l one competitors that don't don't do this. So if you need to decide today whether you want to deploy an L1 and L2 uh the problem that you might have if you want to deploy L2 is that you have all these additional infrastructure that you wouldn't have as an L1 and this you know uh it's a lot of effort that you are spending toward this that you would rather spend towards user and and products. Uh the second is that this increased complexity uh is a source of bugs and this doesn't allow you to get rid of security council.

So a reason you might want to be an L2 is because you want to be more decentralized, you want to prove your state transition, you want to have a secure bridge. So all good intentions, but at the end of the day uh because of risk of bugs, you might need to have a security council uh that actually make you uh less decentralized. That's what you want to be, right? even less decentralized that alt once potentially and this is you know something that alter ones love to say you know that L2s are bad because of security council I've been talking also with some of the rollup teams here uh and they telling me like stage two may be too realistic um because again it's might be too unsafe to remove the security council I feel like this is super sad uh it's super sad also because I might agree with it uh so uh and and the third problem is now you want to be in an EVM equivalent chain And you need to upgrade every time Ethereum upgrades. You also want to to do the same upgrades.

And this requires dedicated governance systems uh just to maintain feature priority. And then uh you know these governance systems can arbitrarily diverge from L1 potentially rugging funds, right? Uh so this also adds complexity and and trust issues. So again the idea is um what if instead of doing all of this uh you could uh reuse the same infrastructure that one uses um some rollups might uh object because you know uh instead of having to reuse uh the same infrastructure they might like actually building proof system and having their own stuff. Um what I argue is what if instead you know instead of uh everyone that does its own thing we all converge into you know making Ethereum better and you know proving Ethereum blocks and then afterwards uh we let everyone reuse this infrastructure.

Um so again the solution is the same right you take the infrastructure that is on one this is the same slide as before you take this zification uh stack and you expose it to the roll-ups to use as a pre-ompile and this would for example allow uh roll-ups to have uh client diversity uh multiproof systems uh automatically right so again the first issue is solved by reusing L1 components you don't need to maintain your own dedicated stuff uh you don't need security council because uh Again, this is a dependency that you already have on L1. And if there is a bug, uh L1 is going to fix it and you get automatic upgrades with L1. And this is uh an example of how much simpler uh rollup is a native rollup is compared to like for example opt 64 lines of code instead of 10,000. Um I finished my time. Um but if you're interested uh on the details uh there is this native develops book explaining all the details how this work uh customization that is possible and yeah thank you very much.

[applause] All right we've got a couple questions here. So what security concerns are you mo most attentive to by introducing the execute pre-ompile? So the the good news about the pre-ompile is that uh it is possible to reuse the exact same infrastructure that L1 uses at even at the level of the same verification keys. So same verification keys the same the state transition function that the L2s would use is exactly the same uh same exact proven networks. So in principle you know if we implement this correctly uh there wouldn't be um much additional risks compared to 121 itself.

So I wouldn't say there are uh many.

And then uh how does this how does the introduction introduction of native roll-ups reconcile with the fact that roll-up teams are looking to introduce more features that deviate from EVM execution.

Amazing. So this is the slide that I skipped. Um so the trade-off is for native rollups you cannot add new op codes. You cannot add new pre-ompiles because again we you we would be using the same statization function that one uses. Uh but on the other side everything that is outside of the core EVM uh citization function can be personalized.

So you could it is possible to support custom sequencing. It's is possible even to support custom guest tokens. It is even possible to collect the base fee like there is an easy way uh to because you know L1 burns the base fee. L2s actually want to collect it. There is an easy solution to do this even without modifying the state transition function which is super interesting.

Uh so there is some form of customization that is possible. Uh but of course there is a trade-off.

Uh and then finally how confident are you in getting native rollups implemented into a hard fork?

Um I'm pretty confident. The only issue is like timelines. I need L1 to be aware of zik proofs because I need to reuse the same infrastructure. Ideally, I need L1 to use blobs for its blocks because again L2s use uh blobs. Uh so there are a lot of open questions around for example uh gas metering when you're using blobs instead of cold data and uh all this stuff.

The good news is uh basically I'm just uh a native rolloff would just steal or like reuse the same infrastructure L1 users. So, uh, I'm just dependent on the ZKL1 timelines.

Awesome. Thank you very much. And if you guys haven't had a chance, check out ETH proofs call number five where Luca does a very dense deep I think 60-minute long deep dive into the technical details of native roll-ups. Thank you. Okay.

Hey, and the second uh LGB contributor that's speaking is Sergey, who's going to be speaking uh a quick kind of compare uh sorry, my computer's thinking a second. Okay, a quick uh contrasting comparison between the ZK uh the L2 beat ZK catalog and ETH proofs. Uh where do they overlap? Where do they stand alone? Thanks for being here.

Thank you. Thank you. Okay. So, hi guys. I'm Sergey.

I'm a ZK researcher at L2B. And today I'll be speaking about L2B ZK catalog and it proves. So L2 ZK catalog is this page that uh basically tracks all the ZK proving systems that scale L2s and ETH proofs is this um dashboard that has a look at all the ZK proving systems uh that should scale L1 and the natural question you might have is okay why do we have two ZK dashboards so corporate needs us to find the diff between those two let's say the corporate type. I think that's the name of the game for ZK uh for crypto right now. So, and let's have a look at the diff.

I will be using this tool. Um it's a tool created by our wonderful tooling team at a little bit. It actually doesn't let you compare two different websites, but it does let you compare to different smart contracts deploy on chain. Very useful. I'm using this a lot in my research work.

So, um I look at it a lot. I will make you look at it as well. Let's go to the first div. Um, so the first div is that L2B looks at all the ZK proving systems that are deployed on chain and they're actually in production and it proves also track some systems that are under development or you know uh still being modified. And the main insight coming of this uh div is that actually so I had a look at the this tracker by ETH proofs.

It has 37 ZKVMs. Only five I used in ZK catalog and there are two more that are used um in production but are not uh followed on proofs. So the diff number two is that L2BK catalog also tracks nonZK VM snark provers and if proofs focuses only on ZKVM systems. So sometimes they're called snarks and the insight coming from this div is that actually there are projects that continue deploying uh completely snark um system. So um custom circuits in the bottom you can see inmax launched June this year the mainet they um I think they're using their circuits for privacy mainly and later launched in October this year.

I think they are mostly using for performance but they don't use any ZKVM. So diff number two has to uh diff number three has to deal with diff number two. We have to deal with trusted setups because we also look at snarks and this proves doesn't have to deal with trusted setups. That's fair enough for um scaling one. But the learning um coming from this is that actually most projects use um this as recognition trusted setup from you know the old days of 2019 which is quite good but there are some notable outliers.

So mainly I want to highlight growth 16 um trusted setup by SP1 that has only uh seven participants somehow as I understand all affiliated with succinct and interestingly enough used by uh four projects in production including zirkut. So, just wanted to call this out. But, um, also to be fair to them, they also offer the plunk final wrap and they mention in the docs that you can use it if you're not happy with this. And another call out is to Starware, whatever these guys do. Um, they don't um they don't rely on trusted setups.

I think that's great. Um, yeah, I think we should look at them. So diff number four is actually not a diff. This is the same. Um both projects push for transparent, reviewable and reliable ZK systems that can scale Ethereum.

And the insight coming from this div is actually the main insight of my presentation. Everything before was a setup and this is the punch line. It is extremely hard to independently verify the onchain verifiers and that they actually check what is claims to be checked. So basically that there are no back doors in the whole onchain um setup. So for example this is a um circuit uh this is onchain verifier for um flunk I think it's um completely not clear what is exactly being verified here or for example this is um part of tao onchain setup this is the risk zero program hash again just by looking at these things you would be able to know what exactly is being proven and verified so somehow in our industry we have the social norm to not deploy unverified contracts and I think this is great but I want to argue that we should also treat the zk proven systems deployed on chain in the same way and really um be mindful about this.

So this is the PSA. We often talk about this ZK technology as this tech that is secured only by cryptography. And I mean this has merit in it. But this is true only if you have verified the setup and you know which program is being proven and which program is being verified. So this is our call to the projects.

Please be mindful of your setups. So this means if you write circuits please provide the ways to regenerate um some guides how to regenerate the verification keys. If you are a ZQVM project and you use some programs please provide the sources for the programs and how to regenerate onchain commitments. And here is a proposal posted on our LTB forum um to actually add this to as a requirement to stage one projects. So if you're a ZK rollup, you will be um you probably will be required to u publish this information and make this accessible.

And from our side, we are committed to bringing this um information to the public to make it transparent. So here you can see some screenshots from um Zika catalog. We have already um verified the um onchain verifier deployed by uh Ziki prover from Polygon labs. We have already verified some programs um from um these ones are used in S2 prover by starket. So you can uh go go there check out the all the steps and do this yourself.

You don't have to trust us with this green check marks. We also try to put the we also put the verification steps there. So coming back to the diff number four, um this is the the common push of L2BK catalog of ETH proofs to bring the transparence and um and reliability and auditability to ZK setups. But also I think this is the something we should do altogether including all the ZK projects that are in the room right now. So please be mindful of this and then maybe we realize that we are working to the same goal but just move from slightly different directions.

Thank you. [applause] Thank you so much Sergey. Um any questions for Sergey? Not seeing anything in the chat. All right.

Amazing company to keep. So glad that you guys were here. Big another round of applause for LTV. [applause]

All right. Uh the final lightning talk that we have before the the second panel is Ron Rothblum from Succinct with a cheeky titled uh lecture on the insecurity of fiat shamir. Ron Rothblum. Thanks.

Okay. Hi everyone. Um I'm Ron Rothblum. I'm a cryptographer at Succinct and I want to talk to you about uh security today and specifically about one aspect of security that we tend to take uh somewhat for granted and I'm personally a little bit worried about and that's known as Pamir. So I want to kind of start the presentation with this very famous quote by uh Sylvia Mikalli who is a very famous cryptographer who among other things co-invented zero knowledge proofs and uh snarks that cryptographers seldom sleep well and the reason for that is that all of what we do in cryptography almost all of what we do in cryptography relies on assumptions which we believe to be true but we're not sure so we have to keep sort of one eye open when we're asleep to make sure that nothing broke and you know zooming in on ZKVMs we're making uh a few cryptographic assumptions and I want to kind of like highlight what they are and kind of then zoom in on one of them.

So first thing I want to mention is this uh notion of proximity gaps with uh Arancha mentioned earlier in in her talk. Uh this is a conjecture that most teams rely on. I'm happy to report that at succinct as of this week we're uh proving in real time without making this conjecture. So I'm sleeping a little bit better. Uh so kind of happy about that.

Second thing we rely on are hash functions that are collision resistant. Meaning that it's hard to find collisions in these hash functions. This is a very very standard cryptographic assumption. Ethereum relies on it. All of us rely on it on a day-to-day basis.

Not particularly worried about that. The third one is fetchir which I want to talk about today so I won't go into it yet. And the fourth one that which I won't have time to go into is about recursion. Um so if you're interested ask me offline about that. So I want to go into fiat.

So what is fia shamir? So it's this beautiful idea invented by almost fiat and adishamir uh almost 40 years ago in this beautiful paper and what it lets you do is basically design interactive protocols. So back and forth interaction but then magically make them non-interactive which is kind of huge. And their original idea was to do this to construct digital signature schemes. But nowadays we're going uh far beyond that and using them to construct uh snarks.

And almost all snarks rely on this idea. Cool. So what is the idea uh in this transform? So we go from an interactive proof generically into a non-interactive proof. And the idea very briefly is as follows.

So we start off with an interactive protocol say for example something like fry. Um, and you know, so it's we have a prover P and a verifier V and they interact. They send messages back and forth. And we're going to make an assumption here that the messages that the verifier sends are just like uh random random messages. And it turns out that for the protocols that we actually care about, this is indeed the case.

So we have an interactive protocol, but interaction is no good, right? We want to post our proofs on chain. We don't want to go back and forth. And what future lets us do is kind of replace this interaction by a hash function. So the idea is to build a new interactive protocol in which so you can emulate the first prover message easily.

You just run the interactive prover but then rather than wait for the verifier to respond with its random challenge, you derive the random challenge by hashing the message that you just produced. Okay, using that you can generate the next challenge and go so on and so forth and generate all of the challenges and therefore the entire proof. So this is the beautiful fetch mirror transform. It's very simple when I present it this way. actually doing it in code turns out to be more challenging and this is very well known to have a lot of implementation bugs but that's not the focus of my talk so I want to focus on doing fatir uh you know as you're supposed to and what happens then you might say you know if you do feature as you're supposed to then it's really really well battle tested we've been using fatir and in signature schemes for a very long time okay so why am I losing sleep over this well the reason is that the way we use fat shamir nowadays is very different than the traditional way in which it was used to build signature schemes in particular because we're now proving general purpose computations using feature mirror and that worries me and the reason why it okay before the reason why it worries me a word about soundness so why is it intuitively sound well because the verifier's challenges are derived via hash they seem unpredictable to the prover so it seems to emulate the interactive case and you know in cryptography we're not uh satisfied with intuition we want more of an analysis So we've known for about 30 years now that fameir is secure if you uh think of the hash function as purely random function.

Okay. And this is commonly interpreted as saying is you know if you have an attack against fmeir it means your your hash function is not behaving as well as expected. Switch a switch your hash function. So that's a common interpretation but actually this interpretation has been challenged. So sequence of works showed that there are examples of sound interactive protocols but if you apply fetch to them they are totally broken.

So this looks very alarming but for a long time no one really cared so much because the protocols we had here these examples were convoluted. They were sort of um contrived protocols that were intentionally designed to fail. So people were not particularly worried. I think something uh changed a little bit in this work that we had earlier this year. This is with collaborators uh so Dmitri Kovtovich and Lev Suhanov both were at the EF at the time.

I think Lev maybe has left since then. And in this work we showed that there's actually an attack against a real world protocol, a variant of GKR that is very common um and popular and this affects real world systems. So this is an example of a PR by Polyhedra um giving a particular fix or mitigation against our attack. So this is very much real world. So given this attack, where do we stand in terms of of security and what worries me?

So so proximity gaps, you know, we know we can avoid them. Aranch already said we have to, so worried about that. Um, in the worst case, if we are not able to prove stronger bounds, we'll get a 2x improved size. Not ideal, but also not the end of the world. Collision resistance, as I said before, doesn't worry me too much.

In the very unlikely event that someone says finds uh collisions in Poseidon, we'll switch to a different hash function. Um we have a very very good understanding about collision resistance of hash functions. So that again does not worry me so much. Recursion overhead I didn't have a lot of time to to speak about that. Worst case we'll do less recursion.

Maybe we'll do no recursion. We could work with steaming provers. This again is in the worst case in case something is broken. The one place where we don't really have a fix is fumeir. Okay.

So we do know we have examples of real world protocols in which if you do frame they are entirely broken no matter what hash function you use and you know if we had a similar attack against protocols that uh run in ZKVMs we would have a problem. So that worries me. I don't think this event is very likely but you know it's very very risky because we don't have a backup plan. So just to summarize, I really view the fe the fetchir security that we're assuming in snarks to be a new or different uh cryptographic assumption. I don't think we can just rely on the fact that it's famir has been used in a different way for many years.

The fact that we have the random uh oracle analysis is kind of is maybe good but it's not enough because we also know that there are attacks concrete attacks that are not captured by this random oracle analysis. So my conclusion you know fameir is it's it's a it's an assumption and I think we are sort of taking it for granted and we need much more research about it. I can report to you that there's a line of work more of the in the theory community from which I come trying to instantiate future provably and we've made a lot of progress here but there's still a lot more to be done. Um so I think you know there may be some hope in the long run to use this line of work but we still have plenty to do. Okay so I'll I'll end the talk here and happy to take questions.

[applause]

Thank you, Ron. Um, got a question from the audience. So, are there any hardness assumptions on the hash function that make fiat shamir probably secure in a specific real world protocol in specific real world protocols?

Yeah. So, for the way we're using them in ZKVMs, the answer is no. There is an assumption known as correlation and tractability which sort of partially suffices. it would suffice for certain types of protocols which this line of work deals with. But the short answer is no.

The assumption is that fat shamir of this protocol is secure.

Great. Thank you very much.

My pleasure. [applause]

Okay. Uh next we've got a a panel discussion on formal verification and fuzzing. Um and then a 30 minute break. So, we're going to welcome to the stage our esteemed moderator and panelists and apparently my neverending granola popup. Okay, so uh moderating the panel is going to be Alexander Hicks who leads the protocol snarkification team at the EF.

Uh also leads the uh formally verified EVM project, $20 million grant uh program that is doing a lot of amazing research. Uh, also from the EF is Cody Gutton, uh, security lead on the ZKVM team. Uh, Valentin Waf from Diligence Security, Devon Tuma from Succinct, and Costa Ferrellis from Veradise. Um, gentlemen, [applause] Check. Check.

It works. Okay. So, just for the record, I can't see the timer. So, if we go over time, just buzz me. Uh, but yeah, thanks everyone for coming.

It's obviously been a fantastic day of talks so far. We've had formifications has been mentioned a couple times in the more general security uh discussion about security and harding ZKVMs and reliability and all of this. We have a fantastic panel that actually covers a lot of different aspects of formal methods. So we've got Valentine over there who does a lot of fuzzing. Cody has been doing some compliance testing and some fuzzing.

Devon uh does a lot of work in lean. It was uh proof assistance I guess and the manual start of form verification. And then cross tassis uh has been doing a lot of automated verification wizards into solvers. Uh so first maybe everyone on the panel can uh quickly introduce themselves. You have about you know 30 seconds to a minute to shill whatever you want and then we'll get in a chill free discussion.

Right. Should I start? Okay. I'm Costas. I'm the CEO of Veridice.

Uh so we do a lot of auditing. uh but uh more related to this panel, we recently released audit hub which uh has a set of formal method tools that uh already some of the zkdms in this room are using while they develop uh to find bugs. And uh yeah, finally in collaboration with the the foundation we also uh created LLZK, which is an intermediate representation that tries to unify the development of uh ZK circuits. So that way like everybody is benefiting from other people's work and like you know people can get our tools uh if they lower the circuits to LCK.

Uh I'm Devon uh at Succinct. I've been working on uh verifying the circuit logic and I'm also a PhD student at Minnesota and I've been working on formally verified cryptography there and I've gotten involved a lot with Alex's um work to formalize uh the proof systems and the actual underlying cryptographic arguments. Um so both of those things have been uh happening in lean a proof assistant. Uh I think proof assistants are uh the way forward. I think they can do a lot of great things.

Um, so I'm glad that the EF has really invested in this. [clears throat]

I'm Cody Gunen. I'm a member of the ZKVM team at the Ethereum Foundation. Uh, my work has mostly focused on security of these systems. Uh, compliance testing for risk 5 compliance tests. Um, this also sort of tracks progress on ISA's changes to them.

And some fuzzing work. I built a risk 5 fuzzer that some grantees are developing further and I've also built a plunky 3 verifier fuzzer. Um and yeah, I'll be helping to coordinate the efforts for security more more broadly on top of digging into a bit myself.

Uh yeah, I'm Valentin. I'm a researcher at uh Diligent Security. Um, and we've been kind of doing a lot of fuzzing over the last two years. Uh, focusing on various ZK infrastructure projects. Um, so we've built two three different fuzzers.

U one fuzzer um targets kind of languages like Noir and Circum trying to find bugs uh there. So has already found like something like 20 different soundness or completeness bugs in various um tools and um now recently we also started looking at CKVMs. Um we have built another uh fuzzer there uh that has already found u something like 11 uh soundness and complet or completeness bugs. Um three of them were soundness bugs. Um yeah.

Okay. So I think it's quite an interesting time to discuss form verification uh and formal methods and fuzzing and testing and all of this in general first because obviously we have ZKVMs which are hitting big performance milestones. So that means we're getting closer and closer to deploying them which means we should be feeling closer and closer to sleeping well as Ron would put it. uh and because it's quite a huge complex stack where you know most likely the ability of audits to really figure things out is quite limited and we've definitely seen obviously bugs happen to you know fairly heavily audited code bases u but also because we've also reached several milestones in terms of form verification and fuzzing so as Vanathan just mentioned you found several soundness and complet is in ZKVMs uh we've had Devon was part of the first effort to formally verify a ris circuit and they've done so successfully obviously in collaboration with Netamines And then on costas side with Veradise they were obviously I guess one of the first to apply some solvers to some of the pre-ompiles and circuits that you see in ZKVMs and showing determinism you know in a way that can be integrated into CI uh which was with with zero. So I think we can all agree that security is great formation is great we should do it so on and so forth it's extremely bland.

Uh what is probably much more interesting is to try and figure out how do we actually do it and how do we actually try to get coverage over the entire stack because the stack is pretty big. uh as the first panel today hinted you know there were some suggestions that now that we're hitting performance milestones you know the next sprint is going to be about security and it's going to be about trying to solve all of this getting obviously provable security on you know the side of cryptography uh but also more generally about the huge software stack that we have to cover and we have a variety of panelists who are working with a variety of tools that all have different trade-offs and I don't think we want to argue that any tool is best I don't think either of us think that any tool is best even if we have preferences about using ling uh but I do think we want to argue about maybe you know how do we make this complimentary because maybe where there is some friction is both in the fact that we don't have good integration of fuzzing in form verification within uh ZKVM development teams maybe with the exception of succinct who have devon and we also don't have good integration between people using different tools uh so maybe let's you know start on on that angle of you know how do we get a lot of that friction away and actually speed up all of this.

Uh I can start. Yeah. Uh so I guess like you know as you mentioned yeah like there are we all of us cover different parts of the stack right and then like you know each of our tools has kind of like their strong suits and like you know somewhere that they don't work very well. So I think first of all we need all of us to start talking the same language right because as we mentioned earlier LLZK came to kind of like you know uh bring some unity in the fragmented kind of like space of ZK DSLs and ZK languages and I think it's a perfect vehicle for you know our tools to also start like you know uh talking the same language and then like you know start combining techniques like you know fuzzing which like you know I think might also benefit from specifications and also like you know the same for uh theorem like automated theorem proving and like you know uh proof assistance and like you know people in our kind of like branch of academia have kind of like you know been doing that for a long time where like you know you have a part of the system that is kind of like you know being verified like you know automatically and then like you know it gets stuck at some point and then like you know somebody provides an action and like you then the whole thing becames becomes push button again. Yeah, I guess I would mention that yeah, having multiple tools uh even if they overlap in places is also like very useful.

Uh like when we work with [clears throat] Varadise has found bugs in our code at least a specific bug before you know weeks before I even started getting to the actual formal verification in lean proof assistant of that because it moves much slower. Uh so having like automatic tools that can give quick feedback um and then also slower more stronger verification is also I think very helpful. Um I think the tools are additive right you can only make things more secure you can never have besides resource usage and you know being able to actually do it having more tools is is very positive I think. Yeah, I mean my mind goes to where the teams uh spend their time and where they spend their time is determined uh you know by the overall direction of this project the ZK EVM scaling project and you know events like this I mean we've pushed really hard on performance and that means that there's less time toward integrating security tooling building security tooling or you know accepting um external contributions by the Please merge my PRs when they when they come your way.

Who's not merging?

Huh?

Who hasn't merged your PRs?

Call them out.

I'll I'll uh I'll do my third emoji react on their approval but non-merging comment. Um [clears throat] yeah, so I think that yeah, I I would like to just see an overall shift in the emphasis. Um I mean it's good to bounce between different fosi, right? Like you have performance, you have a security sprint, you have a kind of cleanup sprint. So I think that that can help.

Um yeah so I can me maybe mention um how we so as I said we basically started with a fuzzer that was targeting not CKMS uh specifically and there we have a lot of experience working with the linear team um so we used to be in in consensus until a few months ago and there we worked very closely with the linear team in particular with the team um we have been essentially fuzzing uh their um their system for more than a year now um continuously. So and they there we usually try to kind of uh keep basically put as little burden on them as possible. So the way that we use we're doing this um is by essentially running like once a day we kick off a fuzzing job and then every morning or whatever when they wake up they get essentially like um message just telling them you know everything's good and if if not we will kind of try to provide a minimized counter example try to give them a test and that they can use for essentially reproducing the bug and fixing it and this has been uh very successful in my mine and the team also has been yeah very receptive of this kind of way of collaborating with um our team but also with the fuzzer um yeah

and so I think following on this how do you see things going in terms of an end stage of ZKVM security efforts do you see it going where you know are we aiming to get every single line of code of every ZKVM of every guest program, you know, all kind of formally verified in lean, which, you know, if you have an infinity of guest programs, maybe in realistic, uh, you know, same with SMTs with fuzzing, like where do you see the kind of ideal end state of all of this in terms of combinations of tools running on different parts or running on the same parts but on different timelines and different levels of integration with CI, uh, if you if you have, you know, a wish list or something of where you want to see things go,

I mean, I think like from my uh, perspective, I think it's it's quite likely that, you know, we will there will always be some gaps um somewhere um but I think the point should be to h to use the tools that we have in the most effective way to cover like basically have like several nets of of security. So for instance I can say from like our fuzzers we essentially target kind of like the whole system. So we basically we try to cover all the the components. Um but obviously like there can be specialized uh ways to target individual components more more thoroughly than what we're doing for this the entire system. So I think this is really an opportunity to kind of combine different tools and then give us more confidence that these tools are actually ready to to be deployed and to go live.

Um, I place a I mean audits aren't a silver bullet. Nothing is, but I I think they're very valuable still. I mean, things can be missed, but many things are not missed. I mean, the teams do very good jobs auditing. Um, and so I don't know, as an end state, I mean, I imagine you sort of releases uh with periods of open bug bounties and auditing and attention, you know, careful attention to big changes.

um you would know best about the sort of potential realistic scope of these FV tools, but I mean it seems like things are coming along extremely well actually in there. So bullish on that.

Yeah, I mean I think to get the proofs the you know the different verifications to cover everything well. It is also important to acknowledge like the limitations and the trust assumptions you have in everything you do. like there's there's many assumptions we need to make in order to verify our circuits for example and clearly stating those. Also being you know conscious of things you might miss. Uh if we don't know exactly what each tool is covering it can be easy to you know not fully cover the surface.

Uh so I think just being really honest about limitations or strengths of

but I think that's not only from the tools themselves but also from being able to work off of common representations

so that you don't have gap off of whatever representation you're feeding into each tools.

Yes.

Which is a maybe tricky part.

Yeah. And like from my perspective is like I don't know my my ideal world like you know moving forward is that like you know uh have kind of like a very thorough security checklist right and then kind of like assign tools to take as many items as possible from that security checklist. Uh and then like you know of course the end of the day we're going to have like you know some aspects that are formally verified. Uh but like you know we need to kind of like you know push automation as much as possible uh in my opinion and then like you know also auditing like this type of like you know very complex systems manually is a nightmare and internally from like you know our experiences or our experiences from auditing some of these manually before having the the tooling infrastructures. Uh now that we switch to a model where like you know we have a tool to assist us like we feel like you know way better to the extent that like you know if a new tech stack approaches to kind of like you know uh audit their circuits manually.

We offer them initially to kind of like integrate uh our uh formal verifier push to kind of like you know take a huge mental load uh off of the auditor. Uh and then like you know we're also happy that you know we're seeing teams like succinct and like you know risk zero kind of like integrating our tools into their uh CI/CD while they're in develop so they can you know detect like you know bugs as they arise and kind of like you know removing items from like you know the that that checklist. So I think I have I think two points I want to come on the panel stool and one of them follows directly on this uh which is that indeed auditing is very standard as I've already said it's you know with the complexity of what we're looking at it seems very hard to audit it also seems as economically based on numbers that I'm hearing about the cost of auditing uh which I can only you know assume that I'm getting correct numbers and based on the numbers in terms of what it takes to formize something for which I have the very exact numbers it seems to me that also auditing is becoming both economically and timewise inefficient compared to the progress that we're seeing in you know better testing and fuzzing and SMT solvers and proof assistance. So I think maybe you obviously have a view because your business does both and I guess maybe on you know your side as well you have a view where you kind of do both and I think maybe on the successing side you you know have paid for audits so you maybe have a view as well. Do you have I mean do you have a sense of you know not just where audits fit but but also where you think you know we have a lot of this a lot of these audits that are being done with finding critical vulnerabilities in code bases have been audited audits also maybe are not kind of forcing functions if an issue is found.

We've seen this with plunky street and you know the the fry verifier skipping the degree check. Um yeah, what does it look like to try and get more representation of formal methods and you know in places where auditing hasn't been enough? Uh and as part of that you know potentially getting to the point where or we're providing higher assurances in a shorter amount of time in a way that's maybe more robust you know to changes as well. So I mean like the whole thesis of our company is that like you know uh manual auditing like you know it's not enough and like you know we that's why we have been spending so much time like you know building like you know these tools not only for Z but like you know for other uh ecosystems uh as well uh like I agree that like you know auditing like I mean in this industry right like it's a time boxed uh endeavor right like you essentially set up a timeline you set up a scope there is a lot of back and forth. You kind of like you know negotiate both the scope and the duration uh of the audit and then you kind of like you know uh reach to something that is of course suboptimal because there are constraints from both ends right constraints from the client on their budget and constraints from our side uh for like you know how much we can dedicate for like you know a single uh client.

So uh yeah I mean like you know for us like you know going the formal kind of like you know way forward is why we started the company to begin with and we are really excited that like you know they start happening in the ZK space and you know uh specifically in the you know ZKVM uh subword of like you know the ZK development. Yeah, I mean I think it also having the formal verification I would think would make the auditing easier and probably shorter, cheaper. I would I would hope uh like our circuits if the auditor can just look at here's the assumptions in the lean and we have a full proof of all the arithmetic. Ideally they don't need to go through the math proof themselves, right? So even if you can just cut down a lot in that way, I think that's also valuable in in reducing the problems with it.

Uh

I'm not totally clear on the full optimist picture of what formal verification gives. But I mean does it does it cover CUDA kernels?

Not yet.

Yeah. So I mean that's a lot of what that's where all the complexity's gone for the past four months.

But a a lot of audits are not just looking at the CUDA kernels.

Say what?

A lot of audits are not looking at the CUDA.

Well, that's that's really a shame. I think maybe [laughter] maybe they should.

They should.

Yeah. Yeah.

And we should fuzz them.

Yeah. I mean the pessimist case is that you know you build these tools but they're so rigid or they break so frequently that people don't maintain this formal verification and invariant and there's a lag and they don't actually I mean if if we find and we did hear in a conversation earlier that oftentimes the proofs don't break even under what seem like complex changes. So for me, I don't have an opinion until I I have some more personal experience and hear more from teams about but I think that um yeah, I don't I don't back down from the idea that people reading code and teams reading their own code at some point is incredibly important.

Writing tests. Yeah, I mean I think the there's there's a lot of um there's a lot of tools, different approaches um and we yeah we we should we should kind of use them in the way that they they fit best into the the workflow. So from what I've seen um in my in my experience is that you know building a building a fuzzer is not I mean it's it's something you can do in you know like a simple prototype is something you can build in you know maybe a month or something just to kind of and you're getting essentially results like pretty quickly. Um, and I think this is definitely something that, yeah, makes makes a lot of sense and also gives you some, I mean, it doesn't give you the guarantees that you maybe get with formal verification, but it gives you some um reassurance that, you know, at least you're there's no nothing like um yeah, there's nothing completely off in in your system. And um and then afterwards once you know what what properties you actually um want to test uh then you can kind of move further down the the sort of the stack like you can do formal verification you can do audits and so on but I think in many in many cases like even the like the formal properties that you want to check are not like they're yeah the specs are not there usually and they have to be developed and there's obviously also room to have specs that are not quite right.

I mean, this is I mean, I've done formal verification in the past. I mean, this is always the case, right? You you rewrite the specs and in many cases you realize, oh, the spec is actually off in some way. So, you need to go back and fix it. And this is a perfectly normal experience, but it it obviously takes a lot of time to kind of do this iterative process.

Um so yeah that's why I think makes sense to kind of start with things that are more lightweight and then kind of move towards more expensive and more also um yeah more time consuming um yeah sort of safety measures um further down the f further down the line. Right. By the way, just to defend our former verification team, uh like we have like something that like you know can run without giving it a specification. It's like a prof and it's not like like that heavy weight. So I think I agree fuzzing is it is it has its place but like also I think like you know formal tools that like you know combine like you know static analysis and verification that can run kind of like effectively they do also have like you know their position early on in the development cycle.

I mean having shared specs is also very useful. When I first was working on this at Succinct, we were sort of writing our own specs and then Alex, I think it was Cambridge,

Cambridge and Gwa

uh had the back end for sale. So now we can sort of trust the spec more or at least more people using the spec means more eyes on the spec. Things like that I think is also really helpful. Teams writing their own internal specs for everything is probably not good uh at all for anyone. And then so as I guess on this mention of you know iterating and going through the motions a big part of I think integrating any of this successfully is trying to get it to run in tandem with development both for the reasons that you don't want people to be pushing you know performance optimizations but you need to delay deploying them by x amount of time because you need x amount of time to do audits and verification and fuzzing and testing and all of this.

Um, two, also because like you're saying, if you have things that are lightweight, you can actually use them, you know, maybe on every PR whilst you're developing things to catch bugs early to hopefully help actually your development process. If anyone has seen any past talks by me, at some point I always have a slide that references a blog from AWS that goes on about how they're getting they're shipping faster, better code because they've integrated fuzzing and SMTs and manual form verification in their process. That's with the caveat that they have 100 people doing for full verification at AWS where we have less than 100 people doing it in the entire ecosystem. Um but but I think I person there's a big view of form version of this is like you know we have to slow down to be able to do it. I actually quite enjoy taking risk.

I would rather see people do like super sketchy stuff and work really hard to be able to like actually make this not sketchy. So if anything I want people to accelerate even more. Um I think what can we do you know to make these tools that we have and that we're developing you know more robust so that we can actually run them on every PR and instead of just being you know maybe just a security thing seeing we can try to see them as you know ways to actually try to drive performance engineering and we don't have a performance engineer on the panel to like give us feature requests uh but maybe we do have a sense of you know how how we can integrate these to get quick feedback to maybe get clues as to how to make things simpler how to make things faster, how to make things more efficient. Uh, which at the end of the day, I think is what matters first and foremost. It's no point having something secure but slow.

I mean, engineering teams do not want extremely heavyweight CI on every PR and they they shouldn't have it. It's like it's not good. So, I think nightly jobs or

you can do performance engineering on SMG solvers to get faster feedback.

Yeah. Yeah. I mean, it's it all just it depends how heavy it is and how long, you know, how flaky it is, these kinds of things. But also I think what's the kind of feedback that the tools can provide because it's one thing if you have a tool that says okay we caught a bug in this you know PR you're making on this branch I think it's one thing and there's another thing which is you know for example with writing specs a lot of times writing specs you know forces you to try to reason about your code and you just end up finding optimizations as a result right in the same way when you try to write down some idea on paper you know suddenly you figure out you know that you need to think a bit more about your idea and when you try to implement it in code you figure out you need to think a bit more about what you write on paper.

Yeah.

And and then when you try to write specs when you try to run when you try to set up you know tools at a start of your development process maybe rather than that at the end you know is there some gain.

I think just like something granular of course helps here right so if you can just reproof some part of it and you have something built where you kind of just maintain this one proof and then it propagates you don't have to check the rest this is good or like you know when certain files change you run a nightly fuzzer job. Uh that that makes sense to me for sure. But I Yeah.

So, we've got some audience questions here. Uh just letting you guys cook for a little while. We're at time, but um mind if I just throw a couple of these up? Yep. Okay, great.

Um are there any efforts to fully certify compile the compiler pipeline due to concerns of LLVM being the target and op uh being the target and optimization leading to unsoundness of elf binaries?

Uh I have two answers.

Okay. One is that LLVM to risk 5 specifically there is an ongoing form of refiction project around this are happening in Cambridge. I have a draft paper I'm not allowed to share. Uh but it's happening uh not the entire LVM yet but a significant portion of LVMIR. Uh and two I think there's something very interesting to say about compilers in the context of ZKVMs which is that you have you want a general purpose compiler for the guest program.

So if you're running REST as your guest program, you probably want to run this through the Rust compiler. And I don't think we want to try and rewrite the Rust compiler. And formally verifying the Rust compiler was something that at some point DARPA was talking about doing and then Trump happened and so it's not happening. Um but for things like circuits and provers and verifiers, you can probably do with quite a minimal compiler which can both support uh optimizations that are probably not in the Rust compiler because they benefit from representing your program with a high level of structure for any algebraic optimizations or anything like this. and two the range of things that they operate on and a range of operations that they do is very constrained to get compared to everything that is in LVMIR or just mainstream you know kind of monolithic compilers.

So we can I do want to maybe bet that we can write compilers that are quite a minimal to form replication and can produce you know maybe faster verifiers and better circuits potentially even faster provers than we currently have. Uh I want to say maybe 2027 ACE proofs day next year wherever Devcon is I can give an update on that but we we would like to attend this.

Excellent.

I actually have a funny anecdote about this. So the first bug that we found with um with our Argus fuzzer for ZKVMs was actually um it was actually a compiler bug. So we were like very very excited I found the first bug and then we we shared it with the team and they they debugged it. They actually figured out that they've been using a slightly outdated uh Rust version. Uh and there was a bug in that Rust version that the the father actually found.

But yeah. [laughter]

Yeah,

this is the thing that keeps me up at night. It's not bad security. The com the compiler is extremely scary. Yeah.

And then a quick final question. Um why do you have to formally verify the prover isn't having a robust verifier sufficient for safety?

So the verifier gives you soundness, the prover gives you completeness. Technically speaking, completeness of the proof system is deterministic for something like fry. Um but obviously if the prover is not able to generate a valid witness or just you know panics for some reason uh you might then have a livveness issue on the L1 because you won't have you know a proof to be verified and so you would want to avoid that. Uh but obviously as was hinted by uh Cody we're not currently aiming to formally verify handwritten custom CUDA kernels uh because we lack the tooling to do so. So I think for that it will be a lot of yeah testing and hopefully at least fuzzing.

Excellent. Thank you all so much.

Um, we've got a short break now and then the last the last chunk of programming, it's going to be uh keynote presentations from the five real-time proving teams that were up here on stage earlier, plus a really special presentation from Jolt uh the A16Z um ZK VM that's being developed and coming to ETH proof soon. and then our final prover or final panel who pays the provers. Um I'll see you back here at the half hour. Heat. Heat.

[music]

Okay. Heat. Heat. Heat.

[music]

I didn't have Heat. Heat. All right, folks. Everyone that's out there getting coffee, if you could start to make your way back in. Okay.

So, for those of you that uh signed up for using the QR code for the events in Can, thank you very much. We're already receiving a lot of applications. I'm told that I accidentally had the auto approve on. So, I'm going to have to rug a lot of you and move you back to weight list because we're just uh sort of accumulating applications and interest right now. So, a bit more about those.

There's going to be two days. One that's really focused on lean execution and one on lean consensus. Um, so the lean execution, you know, you could think of that as uh like an ETH proof stay really real- time proving probably going to be a strong focus on prover uh provable security. Um, and so there's always going to be a real a uh emphasis on getting uh devs, cl, you know, researchers, uh, cryptographers that are working hands-on with it. The venue is quite small, but really cool.

80, it only seats 80 people. Um and so there'll be two days, one day working uh you know presentations uh primarily on the execution layer, the second day on consensus layer. So a lot of the the PQ interop stuff that we've been doing with uh with uh within lean consensus and then there will be a hacker house. So the the event with the presentation seats 80 both days and then the hacker house is only 40 people. So um the bar is going to be quite hard high in terms of um you know just making sure that we've got uh you know strong alignment with you know very preient topics people that are contributing to these things.

So uh please go through the application process. Uh it'll be in a in a you might get an automatic approval until I change it but uh it'll it'll probably sit in a in a in review stage for quite a little while. Um so this afternoon we're going to start off with we've got uh six talks. Uh we're going to hear sort of an architectural overview of six different uh ZKVMs. We're going to start off with uh OpenVM.

They're going to be uh Y is going to speak about real-time proving for Ethereum L1 the modular approach. Ye thanks for being here.

Hey everyone, my name is Y. I'm one of the co-founders of Axiom and yeah would love to tell you about how we achieved real-time proving for Ethereum using OpenVM. Maybe if the slides will work I can tell you more. Okay.

Oh click. Okay, great. Cool. So, so first of all, OpenVM we call a ZKVM framework um because it is meant to be customizable and extensible. Uh what that means is that although we support certain ISAs, we don't like to bake that into the framework and we want to allow developers the choice to modularly build the ISA that they need for their purposes um while still using the same framework.

Uh so currently we offer a Rust front end and also use what we call a no CPU architecture to enable all of this. Now to talk more about the modularity at the ISA level with OpenVM, we allow developers to build an ISA through what we call VM extensions. These are groups of op codes that interoperate over over common memory spaces and developers can add or modify extensions while importing the core openv as a library. So for example we have risk 5 support through an extension and core openvm does not know about any particular ISA. So out of the box, OpenVM can prove Rust programs, but developers can also customize by creating their own VM extensions for workloads of their choice.

Uh we believe there are some workloads like machine learning inference or particular signature schemes that will require this approach. So now let's talk about what everyone is here for which is how to apply OpenVM to uh Ethereum. So, first of all, we launched uh at the beginning of the year and at that point, OpenVM was frankly not very efficient. Uh we've been able to make about a 3x improvement every 3 months since then. And on a benchmark block, a block 21 million, uh we now have subsent proving and also real-time proving.

Um so overall, we've been able to achieve over 30x performance improvement on both cost and latency. And so as everyone saw in the demo, we're now able to prove Ethereum in real time um on 32 GPUs. Um so in this histogram, you can see that our P50 latency is around 7.7 seconds and we have a P99 latency of a little over 10 seconds. Uh this is on a range of 1,000 recent L1 blocks uh from I believe yesterday.

So in this talk I wanted to talk through three areas of our architecture uh which I thought were particularly relevant to real-time proving. So that's our no CPU architecture which is the way we construct openVM to allow a modular architecture. Uh the optimizations we made to execution through ahead of time compilation and finally our overall distributed proving pipeline. So our perspective at with OpenVM was that existing ZKVM designs really kind of overfit to physical processors. When you design a CPU, of course, there's a physical chip and it's very hard to make it configurable and you must specialize to a specific ISA.

A lot of ZKVM designs kind of emulate this by having a central CPU circuit that knows about every op code and coordinates all of the VM activity. Um, so with OpenVM, we've introduced a what we call a no CPU architecture where we do just that. We remove the CPU. And in ZK, we're actually able to constrain execution consistency without doing it in a single chip. We're somehow distributing it through a consistency check with randomness.

Uh, this has two benefits. Uh, the first is that we're able to just reduce the trace size by removing this large CPU circuit. And the second is that we're able to plug in new op codes into the system without imposing changes to other circuits. And so this makes modularizing the ISA much more straightforward from a development perspective. Okay.

So in our distributed proving pipeline we have roughly three steps. The first is that we actually have to execute the guest program of interest uh the Ethereum state transition function on the CPU. So that's done in serial. After that we execute again in pre-flight execution to prepare for trace generation. And then finally we do GPU proving.

Um so as you can see the only serial step in this process is the CPU execution. And as a result for something latency sensitive like real-time proving it's a pretty critical bottleneck. Um, now the core challenge when proving an ISA um that is not the exact same as the one running on your CPU um is that you essentially need to interpret the ISA. And we went through several phases where we discovered that interpreters are pretty slow. If you implement a naive interpreter, maybe with handwritten Rust, you'll probably achieve something like 20 to 50 megahertz.

Um if you go a little bit deeper and add things like tail calls, you'll get to something like a couple hundred mehz. Uh so we did this previously and we had risk five execution at about 380 MHz. Um, and in our push for real-time proving, we implemented ahead of time compilation of the state transition function, namely transpiling every risk 5 op code to x86 op codes and storing as much as possible in the lower number of registers. Now, one particular difficulty in doing this in our modular design is that we needed to handle extensions that we did not want to translate to x86 assembly. for example, things like the catch hash or elliptic curve uh pre-ompiles.

And for this, we had to support mixing and matching handwritten x86 assembly for risk 5 um and just native Rust that's already optimized for these special operations. So to give a sense of the scale of the results, I said before that with our best interpreter, we're about in the 300s on 300 MHz on execution. uh with ahead of time um execution we're able to achieve uh over two gigahertz uh which is roughly half of native execution. We think this is pretty close to best possible since for every risk 5 cycle we're using approximately two x86 cycles. Um and as you can see on a relatively tail block um in the 23 millions with 43 million gas uh this decreases the execution by about a 3x.

You may ask why it's not a you know adex and the answer is that there's already a significant amount of the execution of the block that is not in uh emulating risk 5 but rather in emulating pre-ompiles. Um so this was a big step in reducing the latency of the only serial component in distributed proving. So after distributed proving or a after execution um the proving process for openvm is fully parallel. Um so we do trace gen fully on the GPU and then we do uh proof generation also fully on the GPU to remove any sort of hosttodevice memory transfer. All right.

So what's next? Um, as everyone has seen in the demo, real-time proving for Ethereum is now a reality. And for ZKVMs in general, we feel like we've reached a point as an industry where performance is on a path to being not an issue for applications. And what we think will be important is actually flexibility and customization for different applications. Uh, so to that end, uh, on the OpenVM side, we plan to add different ISAs and frontends.

uh for example support for things like RV64 or web assembly as well as the ability to synthesize pre-ompiles in a more automated fashion rather than writing them always from hand by hand. Uh moreover we now want to cach in our modular design and have the ability to apply OpenVM to more domain specific computations with extensions that are very outside of a typical ZKVM compute pattern. So look for more from us about that uh next couple months. So if you want to learn more about OpenVM uh you can check out our doc site or our GitHub. And if you're interested in working with the Axium team to implement OpenVM for your application uh you can check out our link on the slide.

Uh so thanks for listening and happy to take any questions. Thanks [snorts] so much, E. Uh, we've got one question here. What is the most exotic and interesting ISA you see people looking to implement in OpenVM's framework?

Feel like the most exotic ones are different ways to implement web assembly. Um and I think the biggest advantages of web assembly are that it offers a more virtualized um embedded systems backend for different languages. Um but there are certain things aspects of web assembly which make it a little bit more difficult to implement it as ZKVM. So people have been trying out different intermediate forms on OpenVM.

Excellent. Uh what does success look like for OpenVM? Yeah, I I would say the broader problem that we wanted to solve with OpenVM is the ability to apply ZK to a range of computations that really matches the type of computations that happen um in the broader world. Uh as an example, if you look at a typical application, there's a database uh which is currently not really a concept in ZK. And if you want to emulate something like that in ZK, we feel you need a more general architectural framework.

So for us, success would be that there's a smooth pathway for developers to combine things which look like ZKVMs which with things that currently look like custom circuits.

Amazing. Thank you very much. And uh yeah, great work.

Thanks. [applause] All right. Next up, a gentleman that needs no introduction, Porter Adams from uh Matter Labs ZKYNC. Speaking about Airbender, uh so welcome to the stage Porter. We're going to talk about ZK Syncs, Airbender, the full stack ZKVM customizations.

Sweet.

Uh you just advance with the keys.

Awesome. Thank you all for having me. I'm super excited to talk about Airbender. We've had some really cool announcements as of yesterday. So I will get right to them.

Um and then I will connect it to ETH proofs initiative and the entire Ethereum ecosystem just talking about full stack ZKVM customizations in general. So we did it yesterday. Ethereum airbender proves Ethereum with basically a toaster. Uh we have our 2GPU benchmark over there on the left and uh just to show that we can get it under 12 seconds, we have our 8GPU benchmark on the right. Um, so we're very very pleased with these numbers.

I know some people I've learned have $100,000 of GPUs at their houses. I do not. So for home proving for me, two GPUs sounds much much more reasonable. And we can also start like scaling Ethereum and raising the gas limits sooner. Uh, thanks to much lower hardware requirements for this.

So yeah, we did it. Now, I do just want to do a little victory lap on stage while I'm here, which is to not underestimate the progress of ZK. Six months ago, there was a very serious post on the Ethereum Magicians forum about relaxing prover hardware requirements for the next few years. And I of course thought this was very silly. I don't know if anyone listened to me back then.

Hopefully, you will understand now. Uh some teams will achieve real-time at home proving before 2025 is over. We've done it. Um and so of course now uh the question is if we scale the gas limit though, ZK performance also needs to get better. And my bet is that like you've seen how far ZK has come in the last like 6 months.

I think the progress is going to keep continuing. And I think CK progress is moving way way faster than these people will get together and raise the gas limit. So it's my challenge to you all Ethereum ecosystem raise the gas limit as fast as you can. Try to keep up with ZK. Um so just to kind of like map out the hardware requirements getting lower.

Um we're trying to shift everybody over to the left side of the screen where we just have two GPUs and keep that proving time down as low as possible. So really great work by the Matter Labs cryptography team. Um especially want to shout out to them. The engineers worked super hard on this and so yeah super proud of their code. U and the basically a toaster is from Justin Drake.

If you don't like that be mad at him he's the one who said it. Okay now I'm going to explain how this was all possible. Uh quick background first on Zayn OS. This is um so previously we had Zikasync's prover and sequencer code bases were two separate things. Uh we kind of wrote like a fully optimized prover and then separately we had to write like our sequencer and every upgrade we had to upgrade the sequencer and then upgrade the prover and then make sure that they still matched and this was a horrible way of doing things and actually limited the number of upgrades we were able to do to zkync which was very painful.

So we've replaced all of that. Now we've worked with sort of like an abstracted execution layer. Uh so the prover and kind of the execution layer are all separate. Uh we will compile the execution layer to x86 and run it for the sequencer. We will compile the execution layer to uh risk 5 for the prover.

This whole sort of architecture here we call zkync os. Uh it includes a bootloadader to start the system. Uh what happens in the system stuff is like input output handling. that's going to be the same regardless of which execution environment you're going to use. Like you're going to need some inputs and outputs.

And uh the slide kind of hints at that we will be able to support multiple execution environments. So if people are interested in like web assembly or other things besides EVM proving uh that is like built in to kind of be a modular codebase. So that ZKSync OS is going to come back again in a couple slides. Airbender. This is our new risk 5 ZKVM.

I don't know if it's still new. I think it's pretty new because it's not quite on mainet yet. But here we are. So anyways, the instruction set risk 5 32 IM arithmetization a proof starks fry commitments mer 31 prime blake du hash and like just a regular permutation argument for the memory argument. And so whenever people come to me and say like porter airbender like great job on all the benchmarks you're super fast you must be using like some crazy cryptography or something.

And then I show them this and everyone says that's the same stuff that everyone else uses and this doesn't really answer any of my questions. So isn't this like kind of the same as everybody else? Like where does the performance really come from? Full stack ZKVM optimizations. Title of the talk I promised.

So I want to start talking about how air bender is like kind of co-designed with the hardware in mind. We really really focus on this uh in like extreme detail of like every aspect of the hardware. How fast can we like pipeline things to the GPU? How much size like what size data structures should we use to fit inside the GPU? And like everything is done with the hardware in mind.

That's kind of vague. So I just want to show you a little example from one of our chats. Uh Alex Blasov, our uh co-founder is asking a question about GPUs. We would like to use 5090s for RAM reasons. That improves recursion area at later stages.

Recursions like how many circuits can we kind of compress down at once? Uh is that fine? 5090 raw computational performance plus 20% top 4090 as I explained. So uh and then Justin Drake turns this down. 5090s are great for cluster proving, but for the single GPU tab on ETH proofs, they want to keep using 4090s.

Alex Lassov says painful. Now, for most people, like it's just a 20% performance hit. Like what's the difference between an RTX 4090 and RTX 5090? Like 20% like big deal. But we've written our code so that it like fully maxes out the space on a 5090.

And when you just take away that 20% space on the 4090, now you have to kind of chop things up and like the maybe it doesn't fit in memory anymore. And so like that's going to slow things down and then like it's going to slow down recursion later on because now you add like Yeah, it's just everything kind of goes wrong. Uh so we we really try to optimize like all of our choices from the beginning have been specifically about the hardware. So uh we also optimize the cryptography a lot. Uh don't waste any circuit variables any risk five cycles.

There is kind of some interesting work there but not everything fits in the presentation. So got to go quick. I think this applies to lean Ethereum a lot because we're going to want eventually probably hardware diversity and ZKVM diversity. Um, and so if we want to run like any ZKVM with any hardware like already air bender takes like a performance hit if you use 4090s instead of 5090s and if you want to use like you know different types of processors besides CUDA or something uh there's probably like a lot of work to do here and my point is just that like you will lose some performance. My like probabilistic outcome is just that everyone's going to wait until ZK is so good that it's okay to take this performance hit and have the diversity.

But it is interesting to note uh as we think about the long term how we're going to match different hardwares with different provers. Uh Zayn OS and Airbender were designed together. So something relatively unique that Justin mentioned this morning and about airbender and zeosynquest is like we don't just take an L1 execution client like ref and compile it and be done. Uh we've written our own kind of execution client within for the EVM within zkync OS. And so this I think has led to like a very optimized kind of simple codebase that is easier to prove.

Uh, I mentioned this in the panel this morning too, but the the regular L1 clients haven't really been written kind of with proving optimizations in mind. And so like they've been written for normal hardware, which makes total sense for them. Uh, but as we switch over to this, uh, probably like the L1 teams and the ZK teams are going to have to kind of collaborate together to make sure that we get all the optimizations across. Uh uh one cool thing to note about ZKYNC uh OS is that we're able to uh do double resource accounting with both the EVM gas costs and the prover gas costs. So a lot of ZK teams will whine about like the gas costs of specific op codes.

I'll still do that at the end of my presentation. We should change them. Uh but it's not a big deal for ZK sync chains because we can just track both costs and like charge appropriately. Um all of this I think is going to be very solved by uh lean Ethereum. Uh there's kind of lots of ways to yeah match the L1 client teams with like all the ZK teams.

Uh risk 5 like native code inside Ethereum feels kind of far off. So I won't really address that. And then yeah repraising the gas costs is going to take like 5 minutes once we decide to do it. So not really worried about any of the things in this slide. Just interesting to think about.

Cool. I will give some suggestions to Ethereum. Uh we strongly request that we change the Merkel Patricia tree to something more ZK friendly. Uh ideally all the values in the tree would be constant like non-variable sized. Uh adjust the gas costs specifically for this these op codes.

Uh we want the explicit code length in the accounts. This is going to help with um like yeah checking the code for smart contracts inside the ZKVM. Uh knowing that is quite nice for proving uh and we don't like the catch hash function. Uh if we switch to binary trees strongly prefer Blake 2s cool just want to say Zikasync is very proud to help Ethereum. Uh million TPS realtime proving home proving believe in something.

this is all coming like the progress in this field every single day is really amazing and it's really cool to be part of this industry and this ETH proofs initiative to help make this all happen so with that thank you very much [applause]

great thanks Porter okay we've got some questions got five minutes to get through this I think you got quite a few um how is 17 seconds average real time with 12 second slots

it's a little low. That's why yeah, the two GPU benchmark is probably not quite there. We probably need four GPUs long term. Uh we did eight cuz obviously we got this kind of ready like yesterday. Uh so eight just shows you like all right, we actually can cross the threshold.

Uh we do have a lot of optimizations still to come.

Both are on ETH proofs, right? The eight and the two.

Yes. Um, so there's still optimizations to come, but I would say it's fair to say that the two is not quite real time proving as of this moment, but by the time people like watch this video on YouTube, we might be there.

Awesome. Okay. Uh, do you think that air bender can forge a false proof? Do you think I can forge a false proof for air bender with a toaster as well? [laughter]

Uh, I think it would be difficult. I I will say like I would challenge like I I know people are still worried about the security and we will like improve the number of bits but I think I could find a bug in any of the ZKVMs faster than someone could do two to the 80 like bits like breaking of security by just using large computers. So yeah. [snorts]

Excellent. Thanks very much.

Thank you. Okay. Um, next we've got Marco Gregorus from A16Z talking about Jolt, uh, the ZKVM that they've been building in house. Welcome to the stage, Marco. Uh, Jolt, a simpler path to high performance ZK VMs.

Thank you. Um, Sounds great. All right. Good afternoon. I'm Marco.

I'm an engineering partner here at A6Z. And it is really my pleasure to be here to tell you all about Jolt. All right, here's some Oh, the key. Uh, the keys aren't working. Oh, I got it.

Okay, quick disclosures. And all right. Um, I have to show you them. Sorry. Um, this talk is really about myths and misconceptions.

So there's been a lot of great progress this year but with this great progress unfortunately a number of myths have appeared about uh the conventional way to design a proof system and so this talk is really about addressing some of these myths and uh pet peeves that we have here at Jolt. Before we get into the myths we will first begin with some context that is very necessary. Now as I alluded to the progress has been quite good this year and uh with this progress seemingly every proof system other than Jolt has converged to a very similar construction and Jolt as we will see is very different but I pose this as the final debate Jolt versus hashbased provers. So here are the metrics today and the the metrics that people care about. So if you take a P99 block today on eighth proofs, a stark prover is performing at about 14 seconds with 165090s.

The proof size today varies a lot for a stock prover anywhere from 220 kilobytes to over 1 megabytes. The memory usage today is bounded but large and when I say large I mean 8 to 10 gigabytes. Jolt today is is about 70 kilobytes proofs and uh we are using 330 bytes per cycle proven. In 2026, we want to be at sub 1 second proofs. Here are the main design choices in uh of ZKVM.

So today, most ZKVMs are designed for succinct blockchains as is Jolt. Jolt will be very effective for that. Jolt is also the only risk 5 ZKVM that I know of that is suitable for client side. Uh Jolt will not use recursion and will not use circuits. And this these two design choices are reflected in the fact that Jolt's core provers implemented in only 40,000 lines of code.

Throughout this talk, I will be talk I will be mentioning a few particular upgrades. So in particular GPU Jolt, streaming jolt and lattice jolt. So just keep an eye out for those as I go through the content. All right, so let's get to the first myth. The first myth is that we can just throw GPUs at the problem and we're going to get a faster proof system.

All right. So to explore this myth, I begin with a fact. Fact. If I give existing ZKVMs today 2,000 GPUs, they are not going to prove ETH in one second. So why is that the case?

Well, the implication is very clear. We have suboptimal parallelization. Jolt on the other hand has this property. I will just call it partition friendly data. It's actually very simple.

All it means is that uh in this case I have an example of polinomial binding. It's a very common operation in Jolt. You can take the data, the coefficients. You can split it into chunks, like four chunks. You put them each onto a GPU and each GPU is very happy and it does its own work and there's very little latency and cross communication overhead.

So, Jolt is very friendly when you take the data structures of proving and you split it across multiple cards. Now, Jolt other than being partition friendly is also the fastest ZKVM today on a CPU. Jolt today is nearing 2 megahertz uh with a 32 core Thread Ripper. You will also notice that Jolt is very workload independent. What that means is that Jolt cares very little about the underlying workload.

What matters to Jolt speed is simply the number of cycles being proven. I will also note that today 31 bit bit start provers are performing at around 3 to six megahertz with a single GPU and Jolt is dangerously close to that territory. Right? So then I say Jolt will prove 1 second with 16 GPUs. The math is very simple.

take a P99 ETH block which is about a billion cycles. Jolt proves at about 2 MHz today and Jolt has this partition friendly uh property and so we expect an 800fold increase and well the math says eth blocks will be proven in under 1 second. With streaming I expect single GPU jolt to also be as fast as today 16 GPU stark provers. All right, let's move on to the second myth. That was all about these very large statements.

Yeah. And uh what about the small things? over the client side. Well, largely that has been neglected by ZKVMs. Um, I have this fun app.

This app is really the simplest possible wrapper that I could make around Jolt. It is literally a simple function call into Jolt's CPU approver. I'm not a mobile dev, so I apologize for the bad UI, but um I'm going to just click this button and we're just going to see what happens. Um, what this button just did is it's proving Jolt on my phone. It's proving 30 cacts just for fun.

Um, and yeah, so the we'll just wait for it to finish. Okay, it's done. So, um, the proof finished in 4.7 seconds. It used, uh, the screenshot's pretty accurate, actually.

Um, this one used exactly 246.6 megabytes of memory. And as far as I know, it's the only ZKVM that's risk 5 based that is anywhere close to these metrics on a phone. So I expect Jolt will be the best uh ZKVM for client side proving and for big statements too. Yeah.

So why do you want this on a phone? Well, okay. Current existing solutions for client side are not adequate. They first of all involve circuits and I want to kill circuits. Be very clear.

I will talk about this shortly. Uh they have proof sizes that are just far too large and sometimes they do not have succinct verification. And sometimes I've heard some ridiculous things like having to download verifier keys that are literally take longer than the actual verification itself which uh Jolt does not have this problem and I yeah I think that's pretty ridiculous we had that in 2025. Okay so I talked I mentioned circuits briefly. Let's talk about why uh why I don't like them.

Um okay Jolt does not use circuits as I mentioned. Um in replace of circuits we have batch evaluation arguments. To be very clear, circuits are just the largest source of bugs. They are. And here on the right, I have a code snippet which shows the auditable surface of a single instruction in Jolt.

So it's like 10 lines of code. You implement the multi-linear extension of the end instruction in this case and that's it. The bottom line is that this is better for your auditor and it's also better for the machine that's going to extract this and do formal verification. So I think we would rather have uh instructions that look like this and circuits. And I hope you agree.

Okay, so the second largest source of bugs arguably is that of recursion. So let's talk about recursion. What do people do today to control memory in a ZKVM? Well, what you do is you have this big execution trace, you chunk it up into a bunch of pieces and then you're going to prove each piece independently. Once you prove each piece independently, you have to aggregate them and then you get this final proof.

You also have the burden of having to prove the memory consistency between each of these chunks. Now, why does this suck? Um there's three main things. Number one, it is very bugprone and at a protocol level it is complex. Uh some ZKVMs today spend twothirds of their time doing this recursion.

So it is very slow and some things some ZKVMs to make this faster have to use curves which defeats the purpose of being hashbased. There is also the minimum high memory requirement of 8 to 10 gigabytes which makes makes these ZKVMs infeasible for for a phone. Okay. So in replace of recursion we use streaming agile. Streaming is when I say streaming I mean a streaming algorithm does not have additional circus does not have an additional pipeline and we are just streaming the trace and the uh the execution trace through the prover.

Uh what's nice about this is you can easily tune uh your proof pipeline depending on the desired RAM and number of threads available. Just to kind of explain how this works. So you have um instead of having to proof each chunk independently, you take one contiguous chunk, you feed it through the proof system, then you take the next chunk, feed it through and you continue until you pass through the trace. Uh in the streaming paradigm, you have to go multiple times over the trace since we are lazily uh evaluating it and particular OGO end times. Um but what is what is nice about this is after the first pass, you can parallelize this process and so um in practice for GPUs especially this is quite cheap.

Okay, to all the people out there who don't like curves and say that you know today Jolt indeed uses curves, we have a good answer for this. Uh, enter lattice jolt. Lattice jolt is basically just curve jolt. It has the same asmtotics and concrete values as dory jolt does today but with module SIS assumption. So lattice jolt we expect to be four times faster than curve jolt today because of the fact that we get to use a 128 bit field.

Um we will talk more about why we use such a big field but the point is here is that we expect lattice uh lattice jolt to have the same concrete values that the nice small 100 kilobyte proof sizes and we expect that the performance of CPU jolt will actually match or exceed current 1GPU provers. Now in the end I actually expect because of Jolt's uniquely modular design that we will be able to support all primitives and the developer will just be able to pick whichever assumption that matches their post uh their postquantum risk appetite. We are still working on hashes but today uh lattises and curves are great options for jolt right okay how we're doing time yeah um we have one more uh point that we will make today so the prevailing approach that a lot of uh that start provers use um is that of 31 bit fields so what I mean is that say you have like a mole rs1 rs2 this instruction um what do stark provers do today well because two 16 uh 16 x 16 bit multiplication overflows a 31- bit field. What you have to do is this bite decomposition. So this like blue line here or this blue layer is uh bite byte decomposing uh each of the 64-bit registers and then now you're going to perform uh bytebyte multiplication and then you're going to concat the result back into the field.

So uh what does Jolt do inside of this? Jolt uses a big field. uh Jolt can directly embed the register values or the RAM values into the field and then do a single field multiplication. Now it turns out that comparing the two approaches so having faster multiplication or having a single field multiplication uh that you come out on top by having one slower multiplication rather than doing the bite decomposition. that bite de composition creates a lot more work and uh this approach is one of the main reasons why Jolt is many times faster on a CPU today than other provers.

All right, so let's do a quick recap here. I threw a lot of information out. So there were six things that we targeted today in this talk and uh yeah I'll just give you the rundown. Jolt today u does not have a GPU prover but we expect Jolt to run at 1 second or under with 16 GPUs. Jolt today is the most performant risk 5 ZKVM on a phone and I expect it to be the choice going forward in 2026 for client side proving.

Batch evaluations are both simpler and faster than circuits. Circuits are bugprone and they should die. And streaming is simpler and faster than recursion which is also a very brittle uh primitive. Jolt today works uh well with curves and will soon work well with lises. And lastly, we avoid this nasty bite by bite decomposition that makes other ZKVM slow.

All right, that's about wraps up my time. Last thing here, here's a nice photo if you want of the two different constructions. This is these are the main ingredients of Jolt for Starks. And yeah, that's it. Thank you very much.

All right, amazing. Marco, uh, got time for a few questions. So, let's see here. Um, why are you currently not first on ETH proofs? How many assumptions do you have in the sub 1second block proof time?

Right? So we don't have a GPU prover when the GPU prover is available or when we are faster than GPUs on the CPU then we will hook up to e proofs. That's the first part to answer your second question. uh remind me

um how many assumptions are you using I guess or

I mean there was just two things that to in this equation. Um I will actually preface this by saying that people traditionally ignore how fast a prover is on a CPU because well we want GPUs for large statements but avoiding this metric which I made very explicit today makes it very hard to reason about how fast these provers are actually proving VM execution. So the two things to the assumptions made here is that number one, Jolt is the fastest prover on a CPU and Jolt is doing the least amount of work per cycle out of any prover system period and second of all Jolt is very friendly when we throw more hardware at it. So I expect because it is the fastest thing like the base amount of work and because it is very parallelizable and friendly when you partition it in a distributed system I expect Jolt will be the fastest prover on GPU.

Great. Um you have you have our are risk 564 iMac right now.

Which ISO will you target in the long run?

Risk uh risk 5. Okay.

We we believe that risk 5 is a is a snark friendly uh um instruction set. Yeah.

Is Jolt planning to do subblocks as well?

Don't think it's necessary.

Nope. Um okay. Why is being the fastest risk five based uh ZK prover on a phone important? If I'm on a phone to prove, why would I not prefer wom?

Well, Jolt will work for W was and for native execution.

Okay.

Yeah.

I think it will be the as far as risk 5 Z KVMs go will be the best for that. I think you can always do better with bespoke provers. Um but in the long run, I don't see this as a maintainable solution.

Let's see here is uh can you give more details on the parallelization of the execution? Uh, which part the streaming or the or or what in particular?

I wish I had the followup.

Uh, was this the was it the beginning or was this the slide?

Uh, that's all I have. Um, maybe we could go to the another question. Yeah. Um, is streaming Jolt also super parallel friendly? You need an initial serial pass similar to other ZKVMs, right?

Yeah. So you have to generate the trace once serially which is known to be fast on GPUs and then afterwards you can basically put these checkpoints and these checkpoints you can save the memory uh layout and then you can now do things in parallel. So yes uh it is quite friendly. Um this streaming laz this lazy evaluation of the of the trace has very little to do with the fact that the rest of the prover and the some checks are already very uh paralyzable.

Great. Thanks again. Uh, round of applause for Marco. [applause] Thank you. Thank you.

Okay, up next we've got Michael from Brevis. Uh, the name of the talk is, I believe, from modularity to real time proving. Just going to hide that because it doesn't really work. I'm just gonna hide the clicker because it doesn't really work.

Oh. Oh, really? Okay. Okay. Sorry.

I can use this. No problem. Thank you. Yeah. Uh well, uh Okay.

Thank you everyone for coming to my talk. Uh I'm Michael. I'm a founder and CEO of Brevis. And uh today we're going to talk about like our journey of building uh Brevis Ple VM and uh you know our approach to kind of uh building this kind of high performance uh ZK VM and push it to the real-time proving for Ethereum uh blocks. So uh you know but before we dive into the details of the ZKVM itself I just want to say that we are actually having this vision to build the infinite compute layer for web3 and I know we're talking about how ZKVM can accelerate and change fundamentally how Ethereum consensus work by replacing this kind of replicated computing method to kind of a proven verify based method.

But I just want to say that today you can already get the benefit of verifiable computing and specifically uh you know from ZKVM by using this kind of a new design pattern your application level as well you know whenever you encounter something that is super complex you don't want to run it on your smart contract you can just let the smart contract offload this kind of a computation in this off-chain verifiable computing box and inside of this box which is now brevis can it can generate a zk proof to show that the computation is actually done correct correctly and then you know send the result back to the blockchain. So the blockchain smart contract can verify the proof easily and with extremely low latency. So you can consume the result of this very complex computation you know as if this happened directly on chain right so this pattern really actually works uh that is like we are today already powering numerous different applications across all the different sectors in you know DAX yield protocols stable tokens like liquid staking lending different chains perpetual DAX and so on so forth so we're actually powering this kind of a whole ecosystem so if you are a developer and actually building something in Ethereum ecosystem you know this kind of a new developer pattern development pattern is something that we want to bring to the table as well in addition to the kind of a improvement on the fundamental layer of the Ethereum execution uh engine. So what is inside this brevis magic box? Well, you know we obviously have the Pico ZK VM which is where I'm going to actually start today.

So Pico uh is a very modern ZK VM with a risk five ISA and a bunch of function level pre-ompiles. So you know we uh introduced we start to kind of building pickle around this time last year like around the divecon time and uh you know we uh you know so we spent about three months is to build the first version of pickle which is a CPU only and when we released it at the time uh we showed the state-of-the-art performance on the CPU proving and uh you know the next uh stuff is of course like a GPU acceleration uh on a single card and we also achieved the state of hard performance on that you know and I'm showing this kind of a very nice sequence graph that you can show uh you can see here that is showing that once we moved a lot of these kind of a heavy lifting parts in the entire proving pipeline to GPU the the the green thing is actually you know how how we actually utilize the GPU and we do very optimal kind of a coordination and scheduling between CPU and the GPU so you can see that even on a single card we're actually taking you know 100% utilization for this entire GPU proving therefore like we can actually achieve a very high performance uh uh you know uh even for like pro uh you know Ethereum blocks with 45minut guesses so you know the next step for us was to basically uh move from like a single GPU construct to multiGPU and uh there we actually did two things one is kind of a looking at this as not only just like a single kind of a GPU scheduling problem but also look at how we can uh you know uh slightly modify the client side of the uh the program as well. So this is something that actually championed and pioneered by SP1 team that they also did uh they used a subblock and uh you know we actually you know uh followed the same kind of a practice there. Uh but first we actually did a lot of optimization on a multi-GPU proving pipeline here that allows you to also kind of you know achieve extremely high performance even with just like a a single machine but you know running this on multiple GPUs. Um the key here again is that we actually kind of do a lot of a coordination between GPU and CPU and also the trace generation is entirely moved onto the GPU land.

So now you know we uh take the next step to essentially have this kind of a capability to run uh you know different subblocks in different servers with like a parallel proving and uh as you can see that again uh you know um each block that right now is actually divided into seven sublocks and proved on seven GPU machines and then aggregated finally on the last one and this is like how the kind of the entire sequence uh um you know of the computation work. uh you know the thing that I want to point again is that you know you can see on the top there like the the entire kind of GPU workload is very tightly uh you know arranged and therefore like we can achieve extremely high performance uh when they when we actually do this so today uh PCO can achieve real time proving performance for Ethereum uh you know we released this last uh we released this in October and you know we can prove 99.6% 6% of a blocks under 12 seconds and 96.8% of blocks under 10 seconds. Uh and we basically publish the entire result and uh it is actually replicable uh and reproducible.

We have like a entire GitHub repo that you can actually follow step-by-step instructions to set up your server cluster and reproduce our experimental result and performance result here. And uh you know um so this is actually where we are hosting our servers. And uh you know um the interesting thing is that we actually so um this current version that we released called pickle prism the biggest bottleneck there is uh the uh on the trace generation side uh sorry on the emulation side. So uh we actually did a lot of work recently on uh the uh you know emulation aspect of this and uh you know basically are able to achieve this kind of additional benefit and additional acceleration in our pickle prism v2. Uh unfortunately we didn't have time to actually ship the servers so we can actually show this uh you know live in today's demo.

uh but we're going to have the server live next week uh to show the performance of pickle prism which is going to be another sort out performance in today's ZKVM land. Uh so how did we kind of be able to how do we able to kind of basically achieve all this uh in such a short period of time like you know within like one year we can build a ZK VM really from an idea to kind of a real-time proving well the trick here is that we actually build this entire ZK VM in a very very modular fashion from the very beginning so like we actually cleanly separate different components into risk five convert combine and compress sending bad and finally kind of you know put that into um the you know EVM uh verification if you need that kind of verification bit capability on chain and in each of these component we actually make it a super modular and you know just like a lago so we have a bunch of different things you can choose from and then finally you can basically say okay even for fields you can choose baby bear or koala bear for hash functions you can use Poseidon or catch or whatever. But you know once you kind of combine these different uh pieces together you actually get the concrete ZKVM that you that you're using. So that's something that you know we did and this really benefited the entire performance optimization process and this is something that I want to share to to you guys uh is that you know this kind of a separation allows us to profile um to very detail that okay this part is actually taking this amount of time that part is actually taking this amount of time so we can quickly iterate and improve the performance um as we build out this entire system. So Pico is now open sourced.

It is a uh you know under one of the the Pico GPU is actually under BSL and it's actually security audit then the performance reproducible and we're working on a formal verification for POE as well. So now what I want to talk about is that we built this very general ZK VM that can you can use to basically prove any software you want. But you know just like any computer systems you know generity comes with a trade-off right. So like we know that if you build very specialized circuits or very specialized system, you'll get higher performance even if you lose kind of some generality. So for PIV as a whole, we want to operate at that point.

We want to operate at the optimal point of the entire trade-off plane. So how do we do that? Well, you know, we do that again with modularity. So we treat the ZKVM that we have as a glue and then we are able to plug in a bunch of what we call application level co-processor to address some very commonly seen use cases uh and accelerate that for further for example we have a co-processor called onching data zk co-processor that allows you to generate proof of historical onching data data such as events states and transactions So the reason this kind of thing is very useful for many applications is because now you can allow your smart contract to actually see into the past and understand what is a user behavior in the past. For example, if you want to build user experience customization applications that allows you to differentiate a different user based on their past interaction with your system or with your application.

You can now do that. This was something that was not possible but only made possible with uh our Ziki data co-processor. So you know we can clearly see the benefit of adding this kind of application level co-processor because once you have this and by the way this is not just a special circuit like a you know kind of a pre-ompile this this by itself is a GPU accelerated system as well to kind of you know have a parallel proving capability to generate individual data points say okay this is a this guy actually swapped this uh you know uh token from that token in the past and you know kind of be able to put that in into our ZKVM. So you can actually compute on these data points effectively. So you know this is precisely the reason why I showed you the in the second slide.

You know PCO has and PIV has so many different use cases touching so many different spaces because we use the ZKVM as a glue to power the infinite amount of computation in your smart contract applications. So some kind of a very simple example is that you can do dynamic fee on your exchanges. Now you know we're launching this with pancake swap sorry we're launching this with unis swap very soon that allows you to essentially do that dynamic fee based on your historical trading volume. you can generate zk proof of your historical trading volume and gather the trading fee discount and we're also working on uh you know we're working with one very kind of high-profile team to enable this kind of a zk powered perpetual swap to have a centralized you know exchange user experience while it can actually settle all the matching engine match result back to the ethereum layer 1 with ethereum layer 1 level security and also with privacy orders and we recently also launched this new thing with uh poly market which is you know one the prediction market uh you know product in Ethereum community to allow Kaiito to generate a proof of their mind share uh you know computation algorithm so you can actually trade mind shares without trusting Kaido as a centralized and independent platform so there are so many kind of different application you can do but I don't have time to talk go through each of them but my key point here is that you know we are actually definitely scaling up the Ethereum layer 1 with ZK VM and ZK proof but on the application side My prediction is that 99% of the computation for blockchain application is actually going to happen offchain and verified hopefully by ZK proof. So with that uh I'm ready to take questions.

All right, thank you Michael. Got a couple questions here.

Y

um any plans for auto pre-ompiles? Do they play well with your proof system?

Uh yeah, we're we're definitely looking at that and uh you know kind of playing with that for sure. So we know there are some very awesome teams that are working on that and uh yeah. Okay. Uh, last question. You are, uh, you're planning to do a 2x with Pico Prism V2.

How many security bits are you targeting right now?

Right now, 100.

And are you taking into consideration moving to 128 bits of provable security in your calculations?

Yeah. So uh you know there are several things we're looking at you know kind of on the short term we're kind of doing further optimization on the emulation process but we are also looking at the things like latis and uh you know but in on in a longer term we are actually as I mentioned in the morning like taking a very hard and long look at the GCR based systems and you know we have already done a bunch of things on that front and you know kind of gonna hopefully release something soon.

Excellent.

Yeah.

Thank you very much Michael.

Thank you. Okay, up next we've got Tamir Hemmo, uh, head of engineering at Succinct. I believe I have the title correct. Um, speaking about SP1 Hyper Cube. Uh, name of the presentation is SP1 Hyper Cube stepping into a higher dimension.

Thanks.

Thank you. Is it like this? All right. Hi everyone. Uh, my name is Tamir.

I'm the head of cryptography at succinct and I'm going to tell you today a little bit about Harper Cube and what makes me excited about it and in general it's a sync we've been running SP1 in production for almost two years maybe even more and we learned a lot from this and hyper cube is kind of like the crystallization of that uh of these lessons so what is important about a ZKVM there's actually three things equally important The first performance it has to be cheap. It has to be fast and you know with it proofs we've achieved real time proving with 16 GPUs but also it has to be secure and I'm going to talk about that later. And another thing I want to talk about is how rich the ZKVM is affects who can use it. So let's start with performance. That's what we gathered here for.

And this week we kind of published the benchmarks around being able to prove 99.7% of blocks uh with under 12 seconds with 16 GPUs and these kind of things are coming down all the time and there's like a lot of improvements in the pipeline. How did we do that? What was the main reason for performance? The main upgrade was our new proving system which is a multilinear system and it was designed by it's kind of like proof system use case code design.

We've optimized our performance by changing the algorithm to fit the problem. We had a research paper on this the jagged PCS which is a polomial commitment scheme for a specific types of polomials or a group of polinomials that appears in a ZKVM execution. Now I'm not going to try to explain all of it but I want you to walk away with maybe this picture and I'm going to try to kind of explain this. So when you prove an execution of a ZKVM, usually you have some sort of circuits or for some people some checks for different op codes. So let's say you have the add instruction that happened a bunch of times.

Usually the biggest one exor load mo each of them is encoded as a polomial. That's basically true for any VM. And the prover has to kind of group all these proofs of validity together somehow. In the univariat land where each of them is kind of like a univariat polinomial of different size, there's not really a way to patch them together. Actually, geometrically, this is actually a very accurate analogy if you kind of know the geometry.

They're kind of like spheres, which is really hard to pack. A famous mathematical problem. And multilinear polinomials are kind of like rectangles or like multi-dimensional rectangles where even though you have to have the area be the same as the corresponding sphere, you can play with the width and the height and pack things together really nicely. And that creates a really efficient proof system for the VM workload. Um, come talk to us about it if you're interested.

Now another lesson which is like a lot of people said oh wow it's hard to sleep at night. We have you know billions of dollars secured by SP1. It really makes you think and it really makes you take this responsibility really seriously. So for hyper cube we really wanted to have the best possible guarantees. The first thing is bits of security.

uh recently there's been a lot of noise about the conjectures and even in SP1 Turbo we kind of we used more queries than the conjectures allow kind of have some sort of like uh buffer but it was not provable for hard cube we realized that performance is good enough we can go to provable security so right now the real time per like the real-time proofs hyper cube is posting are 100 bits of provable security which really is getting rid of these uh proximity gap conjectures that are really something I see as training wheels for hashbased VMs and Arancha is taking our training wheels off so uh I think is a good thing and the other thing is the circuits themselves and we did a lot to work with professionals and hire even hire our own ver uh formally ver formal verication person Devon And really what we have is SP1 lean. The repo is open source. You can see all the proofs and the assumptions and it's mathematical correctness proofs for the risk circuits. It's not the whole VM yet, but it's a really big part of the most risky logic and it's verified and the things that excites me about it is that it's verified against the official risk 5 spec. So there is a social proof which is like what risk 5 means and we prove our thing against that.

And the second thing we did uh something that's more um immediate feedback is integrating with Pyus. And Pyus is this uh system by Veradise that allows you to prove that your circuit is not under constraint. Um, oh, I should have said under constraint in this slide, but it's an automatic tool that you just plug in and it proved the terminism of all our risk 5 circuits and also a few pre-ompiles, which is like much much harder for the lean to do at this moment. So, we're going to keep working on this, but already I sleep a lot better. And the last thing that I wanted to discuss, which is not really discussed today yet because we're really focused on L1 and real time proving, but if we're going to have a VM and the Ethereum ecosystem is going to use it, all the L2s should use it too.

And what do they need or what do other people need? I want to take as a case study arbitum and arbitrum has we've been working with arbitum to zky their stack. And in arbitrum there's a specific feature that actually Ethereum L1 is considering in the long term which is native contracts. Arbitum stylus allow allows you to write a native contract in WASM and the client can execute it with native speeds. So when we are going to prove arbitum we want to preserve that cost model.

Any stylus program has to be proven in the same cost as a native program. The problem is if you have a contract, it's not code you can trust. The code might have bugs. It might be malicious. We don't want a bad contract to to collapse the entire client.

The solution, the VM has to be more [clears throat] complicated. So, SP1 Hyper Cube has the ability to execute untrusted code. What does that mean? It means enforcing memory privileges. If I have an executable portion of memory, I have to make sure nobody writes to it while I execute.

There's memory isolation. If I allocate a piece of uh memory address space for this user program, I need to make sure that even if it um overflows or it has like some some seg fault, I need to have a handling for that in SP1. And finally, it has to be sandboxed. So write SP1 uh when you plug in pre-ompiles in ref you get very like low-level control of circuits you can plug in that's really unsafe for an untrusted contract to have. So all the pre-ompiled calls all the SP1 SIS calls are not able to be called from the stylus contract.

They have to go to the client. Um and that's basically um what we do for that. And that's mostly what I want to talk about. And you know, I'm really excited about Harvard Cube, the soon going to be in production. And um it was really fun working on this new proof system and I hope you will enjoy reading the code.

And yeah, thanks everyone for this event.

All right. Thank you, Tamir. Uh we've got one question here and less. Oh yeah, basically is hyper cube open source? If so, is the code repository available on GitHub or any public repository?

Uh yes. So actually for if proofs the the version on proofs is available in the same repo that we used in May. It's called hyper cube verifier if proofs demo or something like that. uh and very very soon our audits are like about to end very soon and then we will release it on the main repo and in the network and yeah

excellent uh how well will the integration work with non-arbitum programs

um well we haven't exposed this is all uh work in progress and we haven't exposed the native thing yet although you could actually already do it um the nice thing about executing elves is that you don't really have to talk to us if you know what you're doing. Uh for example, the Aragon team building Silkworm, they have a C++ client and they managed to plug into SP1 without even talking to us. We were really like, "Oh, wow. You guys just did it." Like that was nice.

Yeah. They just showed up on ETH one day.

Yeah. They just like, "Oh, we did it."

All right. Thank you very much.

Yeah. Thank you. [applause]

Okay. Our final keynote is Jordi uh from ZISK and he's going to be talking about ZISK and distributed real-time proving.

Okay, welcome to stage, Jordy. Thank you.

So, hello everybody. I'm Jordina. uh from Fisk. um going to go strike uh to the point I mean we have been when we started the project uh our main goal was to reduce latency that's how we started the all the this project and uh here is I think with this what would be more or less a standard block u this is more or less where we are okay as you see uh when when a block is created u then there needs to We broadcast I mean this is sent to the to the block proposer. This is broadcast then it's signet and at some point we get the block and we can actually starting the the the proof time.

Okay. Then we have the input generation. We have the executor, the witness. Then we have a challenge phase. It's computing the challenge.

Uh and then uh once we have this challenge, this we have the second challenge. And then we have the aggregation. And finally, we need to send this to west proof or to the network or whatever it is. Okay. So, and this is you see that the uh the part I mean this uh especially the last two parts these are very parallel double.

So this is where you can reduce a lot and uh uh you can compress a lot just by putting more GPUs and of course there are some optimization spending. The main work uh currently is in the I think we can still uh have a lot of margin to improve is all the all the part I mean every even from the beginning I mean all the initial states until probably until the executor itself this should be compressed. I think here we can pipeline a lot of things and there is a lot of work there. So easily you can see that here we can still earn uh a couple of seconds uh there. So this is very much the the an idea uh rough idea of where we are.

Of course in the aggregation part there is still some optimizations that are pending but uh I mean currently uh well this is the the server I mean this is a cluster that we built in Jirona. uh this is 16 GPUs running in parallel. Um and yeah this is the results that we get. I mean this uh this is with uh uh 24 GPUs in this case and this is uh six uh I mean this is the average time of 647 but uh the interesting part is the second one I mean this is a time to proof this is from the from the time stamp of the block until we get the proof the proof available. So we are at at ready in average of 9.

6 six seconds and uh 92% of them below uh 12 seconds. I mean this is at the end what we are trying uh to reduce and what we are trying to uh compress uh very much. I think we can go much better with the optimizations that we have. But uh yeah uh just um a comment on this um the GPU uh I mean we are combining GPUs and CPUs. Uh as you see there is this part of execution there is a lot of part that's running in in CPU that uh uh you want to go fast.

So these machines um they have a 5 GHz uh speed in the CPU and then have the 5090s okay and combining and coordinating them a little bit the the trick all together. Okay so this is where we are but actually what I wanted to to explain now and I want to talk in this presentation is about um building the proof in a decentralized way. Um in order to do that I need to explain a little bit how I mean how the the the protocol I mean what's the coordination what happens so imagine that we have a a let's say a coordinator okay and then we have a lot of workers uh in general running in different u CPUs and what messages you send so the coordinator starts a proof then of course it passes the input this can be up to 15 megabytes depending on the size of the block but this is all the information by the way this is a proof so It's seen I've seen a lot of the a lot of projects for example um going fast there is a big trick I send this 50 megabytes perfectly generated zero GPUs zero time free but the idea the full point of the systems is to compress this 50 megabytes to something that's uh smaller in our case is 250k okay so that's important to know that this is already a proofy there so what you want to do is actually compress um you get this um input uh this 15 megab um uh of course this is distributed to all the to all the mean the block okay the the block header so this is is is sended to the uh workers the workers actually compute a challenge a challenge is something very small u something that's around couple of kilobytes okay this is then uh broadcast I mean sent to the manager and send it back to all the computations this is where all the computation actually happened the the where the the subroof for the the the the the partial proof is generated and then all this this is about 300 kilobytes the the proof and then this is um of course this is sent to one single uh aggregator that just collects the I mean if you have 24 GPUs you get collect 24 proof and you finally agree this is a very fast way but the important part here is to see that the traffic I mean if you see the quantity of megabytes of coordination that's here is very very very small. I mean workers don't talk each other uh too much. Okay.

So this is very very useful because if these workers instead of being in a big cluster they are distributed uh the proof to build the time to build the proof would not would not change significantly significatively. It will be more more or less should be more or less the same. And this is interesting uh because this allows to I mean this allows not only to build the proof uh c in a decentralized way but also if you replace the coordinator with consensus layer um you can build the proof in a well in a distributed manner. Okay. And I think this is important because um well we'll see later but one of the big problems of u having a big cluster that's running for example Ethereum is that what happen if this cluster stops you say okay you have many okay but what are the incentive to do there so I believe more in a way where the there are some incentive for the proof to be built and this incentive goes to um let's say to validate I mean to validators to uh roles in the network that they have a single GPU okay there are something a domestic uh a domestic uh machine in there okay so how we embed um so who we will have a debate later I didn't when I when I when I pres when I submitted this presentation I didn't know that would be a debate about that but the idea is who we I mean who pays the proof what but it's not who pays the proof what are the incentives for the prover to be generated.

Okay. So well there is one simple solution on that. Okay. Let's I mean it's like you force you sell the validator if you submit the proof or or or you are forced to submit the proof and then you will get some reward for that. The same way that the validators get rewards for a testing or for proposing blocks they may receive some uh rewards for uh generating uh the proof.

The problem of this simple protocol is um it's a pro there's a it's a problem that um so it can happen that one single provider uh generates uh the proof and all the maybe all the all the validators are getting from this proof because it's cheap it's free uh they're getting the proof but what happen if these validators stops or what's even the worst the worst question okay so say you have back up but then what are the incentives is to run a back up if you are not getting anything out of there. So you need to well it's designing a protocol that way is is is not uh that easy but definitively the structure of uh having uh building the proof in a decentralized and you have minimal bandwidth coordinations this helps. So what I want to show you here is an example of uh what a protocol I mean what a decentralizes I mean what a what a protocol could look like uh in order to uh in order to bre to build the proofs um um in a distributed manner. Okay. So of course you need to have uh provers in the network the same way that you have validators.

It can be the same validator. So you can have a new role. You put 32 ethers and then you are a prover. Prover means that you have a CPU with a GPU. So you have a let's say a gaming machine on there and you will get rewards uh for that.

Okay. So the thing is that probably that randomly deterministic the same that we have these committees and that you are selected randomly you will be selected to do some work. Okay, this work would be this could be something like okay you are the chunk number uh 23 you need to do the chunk number 23 of uh of of the proof and this this proofing can be you can you be can be the chunk 23 of the of a of a of a z proof and a chunk 23 of an SP1 proof or other proving systems in there. So you can have even a distributed way and of course maybe in this protocol you would not be the only one it can be some redundancy that can be designed it in that okay so once you assign what's the proof you have well maybe can divide it here in three steps the first step is you generate this phase where you generate you can generate this challenge okay uh you generate this challenge and then you can have an incentive okay if you are approver you you put the challenge and for the fact that you are putting the challenge, you get some reward. Of course, you can you want to add also some reward to the validators in order to incentivize them to include your reward uh to include your reward.

So to include your challenge in the in the block or in the in the consensus. Okay. Um second stage is okay all these challenges are are there should be there um and uh um or the challenge should be computed and then the second phase is okay we have all these challenges and uh we uh generate uh we generate the mean which each one generates the the proof once you have the proof very much the same you get some reward if you are included maybe some penalty if you don't include it or or is uh u or it's an invalid uh s proof and of course the verifiers receive the the proof and in the last um in the last state um well probably all of them can aggregate the proofs and the interesting thing here in this step is that okay you probably get a reward for for submitting this final proof and this is all of them but you can also get a reward for you can also get a reward for your previous to proof being used in the last proof and for also reward for using somebody else proof on this proof. Okay. So the idea is that you can have um a system where I mean uh you are incentivized to use the others one and uh uh uh uh in in order to to to get the proof of course it can be a if this can be a u step 3B or 3C that this is you don't get a proof in there you can extend the time period maybe with lower incentive uh so that uh uh you can you can create this is a simple example I'm not saying that this is perfect this is just an example of a protocol for generating a proof in a decentralized in a decentralized manner.

Okay. Um, of course you can com combine this proof. I mean you can have maybe okay the one that's getting gets the proof and the other gets the I mean you can do incentive for central for a verifier if you meet the full proof and then this is the centralized way of building uh the proof. As I mentioned this I think this kind of protocols has a a lot of advantages. Zisk is prepared for this decentralized uh way and I think that uh this is the way to go.

I think I don't I want to avoid having centralized um actors with uh big uh clusters uh running that are necessary to run the the the network. And that's very much what I wanted to talk about. Thank you for listening and I'm up for questions.

Thank you Jordy. Uh great lead into the panel discussion. So couple questions here. Uh very quickly, what do you think of Jolt?

Well, Jolt Jolt I mean I I'm not have not like deep detail how it works. I know that's something about uh elliptic curves. um need I mean I need to check but what I uh the thing when the few things that I read is that uh uh the interesting part of Jolt is this uh big lookup tables. I think this is something super interesting but uh with Starks we have this look up idea and uh we can do things very very very similar. So when I see the results I will believe I mean I think it's great that there's people trying and we will see at this point there is nothing.

Um a good lead into the next uh panel. So are you considering launching a token for the distributed proof generation?

Right answer uh [applause] what challenges did you experience running an on like setting up the onrem uh proven cluster?

Well we we was fun. I mean the the first well a lot [snorts] of a lot of

would you be willing to speak at an ethof's call on gray market GPU procurement. Look, I I just I I can tell you that uh as an as an anecdote, I mean, just as as a small story, but I I booked all these um GPUs in Switzerland and I went to Jirona, I mean to went to Spain and I just took the FGO of my brother and uh when I was in the customs, I was just okay, I don't know what's going to happen when they [laughter] see me with all these uh things. So, I was a little bit scared on that. That's I mean this is we learn a lot of things about powering about ACS about electricity how to run how to manage uh we learned that the the the providers uh I mean the GPU providers are really bad the fact that Nvidia don't sells gaming machines to the big uh uh to the big cloud systems is is is bad uh it has been a real pain and actually building the the best thing I mean is the the giron was run I mean we built it and was running perfect in the first very much in the in the first uh uh the going with the cloud having to I mean things running on I mean we saw clothes

limiting the the power of the GPUs just to save some money there or uh um running on top of uh [snorts] um dockers and I mean know very strange things that you don't have control sometimes I mean do your software is not uh Perfect. And you need to debug and you cannot trust us the hardware. This is a a pain. So we learned a lot on that and I think we got a very very very good experience.

Great. So stick around the stage. You're on the next panel. Um feel free to bring the chairs up. And so yeah, I'll give them a second to kind of swap that out.

But I wanted to say some thanks. uh this is the last panel and this whole uh event has really been a group effort and required a lot of effort on behalf of a lot of people. So uh I'd first like to thank the dev connect uh team for putting up with a very stressed out um neurotic version of myself. Um, and also to all the dozen or so researchers that reviewed all the speaking applications and really like worked on synthesizing the agenda and making sure that they're preient, timely uh, topics that you guys would all speak about. Specifically, Sophia, shout out really kind of helped crystallize the whole agenda and schedule.

Um, and obviously all the speakers and the teams that it was a very very large uh, ecosystemwide effort to put this together. uh very pleased with how it came out. Okay, so the final panel is going to be moderated by Julian Ma from RIG, researcher on the robust incentives team uh robust incentives group at the EF. Uh and then the panelists, Lucian Stroy from Boundless, Leland Lee from Succinct, Alex Trust, Michael from Ultrasound, Torston Barren from Galaxy Digital, and Jordy from Zisk.

[applause]

Great. Thank you.

Do you want to be in the farthest?

Sorry.

Or do you want to go?

Yeah.

Yeah. Do you want to go?

Ah, yeah. Should I go for the farthest?

Sure.

Thank you.

All right. Do you hear me or is it good? Okay. Well, thank you everyone for being here on Saturday, last day of the night at 5:00 p.m.

Uh, it's great to see that there's such a full audience still and I guess that's a that's a big congrats to the organization. Um, so we're here to talk about who pays approvers, which I think is an important topic that sometimes uh not as clear um in the room. I'd like to start out with just a round of introductions. Um, I'll go first and then we'll head to Jordy. I guess most of you will already know him by now and we'll go uh back here.

So I'm Jillian. I'm a researcher at the EF within the robust incentives group. We look at incentives within Ethereum very broadly and I've been looking at prover incentives. Uh we've been looking at how should provers be integrated within Ethereum systems. So if there's a slot, how much real-time proving time actually is there and how does the protocol architecture work?

And then we've been looking at the incentives directly. So who should pay the provers and how much should they be paid? Um yeah, I guess Jordy maybe if you want to have a word where you can immediately go at it.

Regarding who pays approvers, I mean at the end who pays approvers is the it should be included in the transaction fee. At the end is the users. I mean uh the value is uh in Ethereum is created by the users. So at the end of the chain it should be the users it will be the users who pay there. Okay.

So the the the question is okay what's the mechanism um for the money go from the users to the provers um in the right way. I think this is the right the right quest. I mean I the right the difficult part of uh to solve.

Yeah that makes sense. That makes sense. We we'll dive into that. Uh just maybe Alex if you could introduce yourself as well.

Alex uh from Ultrasound. Uh we run one of the Ethereum relays, one of the bigger ones. Um know somewhat about block building. I mean I know we get a lot of blocks. We get thousands every slot.

Um and I guess by now we have done quite a bit of thinking about the economics of you know how do we get paid? Where's the value with transactions and how does it flow through the entire pipeline. So hope I can contribute a little bit from that perspective even if I'm not a blog builder myself.

Cool. Dorson,

um I'm with Galaxy Digital and also ETH stakers. So I have a bit of a leg in both um the professional staking world and the home and solo staking world. And I think here on this panel, the reason I'm on is to talk about local block builders and home and solo stakers and how that would impact them. I'm Leelin from Succinct. I'm the ecosystem lead, which means I spend most of my time talking to early stage partners on what it's like to use SP1 or ZKVM, but also I talk to them a lot about like how do you actually pay for proving on the network.

Hi, my name is Lucian. I'm with Boundless. Boundless is uh the first distributed um permissionless ZK marketplace and we're live. We launched about two months ago. So yeah, I'm going to talk about what it's like to actually have a onchain marketplace for ZK proofs.

Awesome. Okay, so the setup for the for the the setup for the panel would be is it is it good?

Yeah. Yeah. The setup for the panel would be we'll first go through the costs. So what does it actually take to create these proofs uh and look at the economics of that. So that would be the supply side.

After that we go to the demand side. So where does the money come from and what mechanism routes the money to the provers. uh and later we'll zoom out a little and go into the L2 world and see moving away from real time proving how does the other markets for ZK affects our market. So looking at the cost structure um maybe um Lucian if you could start how would you see the cost for proving for Ethereum blocks and what is it composition is it mostly variable is it mostly fixed costs

yeah so background um is this okay so the background is boundless was actually incubated out of risk zero um doesn't seem to be working but

like this lovely

still those for you.

Thanks. Yeah. So, Boundless was incubated out of Risk Zero, the first Risk 5 ZKVM. So, we have quite a bit of time in production. Um, our first product was a centralized uh GPU compute marketplace.

We called it Bonsai and it's centralized built on AWS and our architecture is essentially using AWS on demand uh to scale up to the proving needs of clusters. So I think the most important thing that we did at Boundless is create a open permissionless participation set and get the hell off AWS, right? And there's certain things that are necessary for us to like, okay, we're proving Ethereum and it is permissionless. It is principled and it matches the livveness guarantees of Ethereum itself. Because if proof requests essentially have a dependency on some kind of centralized entity and that goes down, it's unacceptable to actually have Ethereum halt ever.

That's that's very strong. I don't know if you have anything to add to that.

Yeah, so when it comes to improving Ethereum, the costs really vary depending on which underlying ZKVM you're using as each ZKVM has very different performance characteristics. I think our goal at succinct is we want to make our ZK VM as performant as possible and to cater to home improvers. I think as time goes on and as the gas limit keeps on increasing we want to maintain those same limits where as EF said under 100k of capex under 10,000 kilowatt and so hopefully we can you know scale the gas limit you know 10x 100x while maintaining those limits as time goes on. Okay. Interesting.

And and Thorson, could you maybe say a bit of what you think is acceptable cost toasts as well for proving?

That's a that's an excellent question. Right. So, we're looking at 100,000 in capex right now. Opex depends at 10 kilowatt. Of course, that's the max, not the average.

You're eating anywhere between 7,000 and 25,000 a year just in power depending on where in the world you are. Um, that's not going to work for homestakers, right? That's a hugely centralizing idea. Now, with your idea of we're gonna shove that across, we're going to decentralize that and everybody gets a chunk to prove and then we'll have redundancy. I think that can work.

So, if a homestaker can just say, I'm putting a GPU in here, you know, something small. We're probably not getting away from Nvidia anytime soon. Um, and or we're getting specialized hardware. I think that's going to happen. We're not going to prove on GPU forever.

We already have teams working on things that have like a little risk 5 CPU and a specialized chip and shared memory in between to speed all this up. We could get to the point where someone can spend I don't know 700 to a,000 bucks and be under a,000 watts and help prove I think that would make it very decentralized.

Okay. Uh that's very interesting. Maybe I'll skip Alex for now and we ask Jordi. Do you think something like a,000 bucks would be reasonable? Well, uh I can tell exactly how much uh cost the Jirona cluster, the one that you saw in the previous presentation.

This is 16 16 normal gaming boxes. It's box each about 4K more or less. So all the cluster I mean I can tell you that all the cluster including the GPUs the server the hub the installation the air air condition the electrical installation uh the setup uh all together uh even the installing the installing cost of all that uh the budget it's uh below it's about 90 about 90k so a little bit less than uh 100k and uh regarding energy um I mean I have not paid the first bill and this of course depends on the this I mean this will depend a lot on the energy cost and you know this is depends a lot but I can tell you that the GPUs I mean when when you are doing blocks in that v of six seconds that means that the GPUs are only working around uh 40% 30 40% of the time um these GPUs are about 600k so you can do more or less the the numbers but I expect that it's going to be below 1K a month. Uh, definitively.

Okay. Okay. And do you think it's a problem that the GPUs are only using 40% of the the time?

I Well, it's what I say. I think that I mean I don't like the idea of of even clusters. This is the mean less office clusters. I don't like this idea. I I think that the nice thing of Ethereum is that Ethereum can run with u uh home home machines.

Okay. uh the idea is to lower lower the hardware required lower hardware and for me it's I would say is lowering the hardware required but without having centralized um infrastructure and things for infrastructure I think they are not good I mean at least they are less uh decentralized and they are not good and they are problematic uh at this point for example ME mess and block builders are I that are a little bit problematic for Ethereum because this is a central point uh on there and uh provers could be another um I mean provers could be another centralized uh point in there and if you if you join them together this is even worse uh u but yeah we can talk about that do you want to say something

yeah I did and it was specifically with the the fact that we're optimizing for multiple things at once um we heard a lot of talks about real time improving but the faster your proving cluster goes and it has to be a cluster colllocated uh to go really really fast um you also have higher and higher underutilization of GPUs so like you start having like 160 GPUs to like hit some benchmarks and you actually look at the utilization you're like I probably had 40% utilization that actually greatly contributes to cost and I think that current um problem with ZK adoption currently like the types of customers that we have in production currently. Um the main bottleneck for further adoption is actually cost right now. Um so it ends up actually uh being much more cost-ffective to reduce latency uh requirements in the short term. Um but again once we do optimize for all of these things um we're going to see that actually like oh if the latency requirements are a little bit lower then we can actually get home provers faster. So I actually participated with my gaming PC on our network as well.

Um, my machine did not do more than one megahertz, so I'm not doing real-time proving of Ethereum, but I can do useful work and it could help rollups scale and transition from optimistic roll-ups to ZK roll-ups today. So the it's an incremental process and I think that um there's going to be some steps that we're going to take but we really need to solve the cost problem and yeah the underutilization aspect of it is actually the reason that we had to shut down the AWS cluster like on demand resources on AWS the amount of time spent to like actually spin them down and to spin them back up actually just made it so infeasible that we priced out most use cases. So, we're extremely happy to be sunsetting that product at the end of the year.

Wow, that's super interesting. That's good to know. Um, I guess Alex, maybe you could add a bit to uh like the engineering cost that would actually go into this. Um, if if you have any idea about that, I guess about running the provers.

Yeah, like exactly. Maybe what's interesting to add is like as I hear you speak, you say like the costs seem kind of high and I'm I'm thinking like actually they seem not that high to me. They seem like very reasonable. And if I would say anything like on some level I think it's going to be a trade-off of what we want like decentralization of course is very important but we also need people to be using the network right the other thing that we really want and I think scaling the network is one of the most effective things we can do to bring more transactions on chain and if I very quickly think do some mental math and say like say that we can only we we increase the uh block space massively and we get just twice the amount of total transaction fee volume then this like is way way way worth like running uh what is it K of N like K of these like instances all funded by these entities that are currently involved in the uh block building pipeline and in fact like my very next question would be like why are we holding it back as I understand from people today costs are going down um if they go down we would like to even push further and go for even bigger blocks and I would say in this case especially like we like yeah it'd be a profitable move to make right to say why not push even further we're very very happy to pay more because yeah economically this makes sense for us but I I totally hear your concern

and you can you can scale I mean you have a centralized cluster and the network grows probably have to add more I mean more more more workers there but I like the idea of uh I mean if you have the the workers spread around the network and the incentives are aligned right uh then uh uh I mean if you have more demand uh you will you will have more supply because I you will have more incentive to put more more proverbs there and I think this is something that scales uh could scales better of course if the protocol is designed in the right way which probably is a difficult part here uh on what we are talking about but it's model for me is decentralizing the the decentralizing the the the provers I mean don't do not depend on a single uh server or if you want a small set of uh server or clusters for building the proof

person. Do you have any thoughts about that? Should we just increase the throughput if we can?

I am torn right on the one hand. Um I love the idea of for livveness and for scaling we do decentralization here. I'd also want to say you know we always have to think why are we decentralizing in this case we wouldn't do it for censorship resistance. for censorship resistance. We already have decentralized detesters and we have Fossil.

I'm assuming Fossil goes in. If there's somebody at the EF, please make that happen. Yeah, [laughter] agree. Um, so that gives us our censorship resistance. That's the the broadly set up home and solo stakers now and we still need them for that.

Um, when we then say, "Okay, now put a GPU in there or use your gaming rig when you're not actually actively playing World of Warcraft and do some proofs at that point." On the one hand, that sounds really great. Um, maybe we can scale faster that way. On the other hand, we're now introducing latency. We're introducing complexity.

So, the question is, is it necessary complexity? Can we survive these latencies? Does it does it constrain us in growth where a properly incentivized group of I don't know 10 20 50 provers or whatever can just scale that on an enterprise level potentially much faster or in a more controlled way. Right? We're not saying we hope we have enough GPUs online right now.

We know we have enough GPUs online right now. So I'm I'm torn, you know, I want I want to advocate for home and solar stakers to prove, but I'm also conscious of the technical difficulty to do so.

Yeah, that makes sense. I think many of us are are Thorn in that sense. Um, okay. So Luc, you spoke to it a bit already, but maybe we could hear some more. What do you think are the the vectors of competition among provers?

So you spoke to it because you mentioned that the underutilization, for example, could be something that you need to improve on. Yeah, I think right now the state of ZKVM development uh requires large proving clusters and then it's just a question of incentive and mechanism design to get the largest number online today. Um we also have a bit of a disadvantage right now because I think we do have a a floor. Um there's an opportunity cost because we're in the middle of like the craziest AI bubble and the optimal hardware actually matches the top-of-the-line GPUs. Um so like you had to go to Switzerland to get uh sources of GPUs and that was 16.

And like yeah I mean we're really fortunate in the fact that like we're not actually trying to run infrastructure ourselves currently. Um we're actually just trying to make the incentives correct so that the people who have access to large uh data centers with GPUs already and the lowest cost of electricity get online. So in terms of like driving down cost, I think that's the most important one. Um and then the next step is like what token is used to make the payment. The ticker is still ETH, right?

[laughter] Yeah. So you make proof uh requests in ETH. um you do it on chain and you match the actual livveness guarantee of the chain that you request and once you have that proof request and you either have an option and I read u your uh paper that you sent over you have an option to either have a ton of people racing um and like have a prize pool or you have someone lock in and you only have one person working on one proof request at a time. That's the option that we took because it's going to drive down costs. So if someone doesn't fill it in uh that proof request, then you need slashing and this is effectively like the design decisions that have gone into boundless and that are all live in production today.

Okay, cool. Maybe Leland, you could tell us a bit about your system.

Yeah, I think in our view the best way to reduce cost is just merely making your proof system more performant. So for example in May when we did realtime proving we used 160 GPUs which was tremendously expensive but come today we're only using 6T and the same as this and so when you get this like 10x improvement like your costs like go down like proportionally and so our view is like we should ek out as much algorithmic improvements as possible along with like GPU improvements and try to use as minim as little GPUs as possible and let's say let's say we want to double the block size or 10x the block size and we have to like 10x the GPUs. Sure, like 160 160 GPUs are expensive, but for context, Ethereum gives out like four billion in incentives every year, which seems like very poulry to let's say like a million dollars to build a proving cluster. So if you have like a 100 proving clusters, say hund00 million, it's very not it's like very little compared to 4 billion. So maybe like it's actually okay to have lots of GPU, it's okay to really step on the gas pedal today.

Okay. Okay. Okay. Okay. So in this part of the the the panel I wanted to sketch a bit so like what does it take to create these proofs and what is the supply side of the market.

I think Jordi you've been aiming already at the demand side and I guess you guys have been talking about it a bit as well. Uh you guys are are envisioning the prover market model and I think Jordi you might be envisioning something different. How do you envision the the money actually going through to uh the provers? I mean the easiest part is I mean the same way that there is a budget assigned for validating uh it should be a budget assigned uh by the proverbs this is one way to do it the other is uh maybe uh it could be a percentage of the gas uh that's another way of uh taking at that I'm assuming here that the gas cost of the chain is more or less the same that the proving cost. Uh that's another way to look at it.

But uh but I think that I I believe that needs to be embedded uh somehow in the protocol. So I think that the incentive needs to be uh set in the right way uh so that and the incentive needs to be for having for decentralizing the provers. I mean this is the it's a matter of setting up the the so this is how you collect. Okay. Okay, so you collect probably okay it's part of the gas it's easy okay we already collect there okay but then it's how we distribute them well they distribute to the people that's doing the proof uh here we can play a game in the first come first serve but this is very inefficient probably I believe more in a okay you have a more prayign works maybe redundance uh some redundancy this is a little bit inefficient I mean in general decentralization means uh some sort of inefficiency because you are buying other things.

It also adds some sort of complexity. Uh I mean it's much difficult to run a chain that run an SQL server. We know that. But uh uh finding the right balance and understanding that the centralization is uh important and the centralization have a a cost. Uh it's okay.

I mean I think we need to accept that and uh we need to u set up the incentives in that direction.

Okay. Okay. So what I hear is that at least the collecting money parts should either be transaction fees or I just the pro school issuing some sort of of of money.

These are the I mean these are the two that comes to my mind but maybe there are others but for me it's like a a variable cost or a fixed cost.

Yeah that makes sense. Um so to to pose the the different perspective I've heard that people say uh builders could run provers themselves and they could fund it for example out of me or or some other source. I don't know, Alex, if you have any insight into whether that would be viable.

Yeah, I think that would be very reasonable. Um, in fact, like you still need the the block, right? There's already competition in Ethereum today for the transactions. They already flow through private pools. Um, and you know, you need something to prove.

So, uh, if you have the transactions that are coming from the builder, I imagine there's already an economic relationship between the two. Like if there would be a lot of payment to the approvers but you need the transactions to do it then already you would expect there'd be some kind of back and forth to find a balance of what that split would be um I yeah I don't know where it would uh fall but also to the question of for example efficiency I imagine that yeah if you already have a fight between builders to figure out who has the most valuable block and that auction is uh one so to speak uh from there for a builder it's you know very straightforward like you talk to all the provers you say hey I need this proof this is how much time I have uh what is it going to cost me and you get like a very standard market in which people can offer to uh to deliver the the proof. Of course, it might get like more difficult with no I can imagine that even the networks plug in uh into that model just fine and then maybe one more small addition like to the uh decentralization question that yeah like we have fossil for censorship resistance if lifeeness is a big uh concern which I think is very fair I would sooner expect that there's some kind of like penalty of incentive to do something about that directly although yeah I will recognize like it's it's a very tough question as well

do you think builders will verticalize and how many builders are there in practice Um, yeah, verticalize. I guess I haven't thought enough about like the benefits of verticalizing. I can say that on a day-to-day basis as a relay, it's very clear what the benefits would be of verticalizing. Um, so I feel like that will come down to yeah, what is your mode? What is your unique advantage, right?

And if it's very copyable and if the chart for hardware costs keep going down, then yeah, there's a point where I think builders will say, I think we can do the DevOps. We don't mind buying 16 CPUs. I actually know a guy who loves messing with CPUs. I did a bit of it myself way back in 2015. We'll figure it out.

But yeah, this is my very like take it with a grain of salt.

Eden, what do you think? Can builders just pay it out of me or do we need something?

Uh yeah, I suppose builders can pay out of me. I think what would be more interesting as Jord alluded to like today Ethereum has like execution layer rewards and consensus layer rewards. uh because in the like zk proving paradigm a tester no longer have to do as much work like they don't need to reexecute the entire block in theory the consensus layer rewards can be decreased and so if they're decrease like maybe that money should be shifted directly to the provers to incentivize a more decentralization uh the main reason why I don't like builders paying directly for proof generation because I think it's very likely for builders to become verticalized like you'll reduce like latency and in practice this there's only like three or four like builders that kind of dominate everything and if our goal is to build a really robust system that's like always online like we want to have lots of provers and in order to have lots of provers we need to compensate them accordingly and so having it as an in protocol mechanism I think will establish like a floor of revenue to encourage all provers to participate

okay and and this have you thought about that

I mean all of these proposals just sound like a ton more money into our marketplace so absolutely No, I mean realistically I prefer the idea of transaction fees primarily because um I want client side proving and I think that we can actually if we we can do client side proving easier if uh we do transaction fees based on ZK. So if you start um a ZK computation um then you can potentially have less fees because it's less work for uh the prover clusters and yeah I mean there's like there's things that are great for boundless is bottom line right but then there's also just getting the right mechanism uh mechanism design and mechanism design on L1 I think is really fragile. I'm actually concerned about the idea of MEV and block builders um being the one who uh does proving primarily because MEV becomes more valuable the more latency you add before you actually start proving. So you have this really perverse incentive in which it's like like okay maybe I'll start proving only after 6 seconds 7 seconds and then it just creates like a really kind of strange perverse incentive. It does create like an arms race to who can ZK prove things the fastest, but I'm I'm not necessarily like 100% sure that it's going to be free speed.

That makes sense. Uh Alex, I I see you. Okay, let's let's quickly dive into that, but we don't have much time. So maybe

I I I mean probably it's the most natural in the most in the most natural way of uh I mean who has an incentive to build a uh the proof is the proof builder because I mean they want to I mean the idea here is if you generate the proof probably you will be able to build bigger proofs and and and then you have the incentive to I mean they are going to be validated. So maybe the validators have a limit on how much they can prove by themsel and they okay the the builder will generate bigger proof. So it can be bigger block I mean and this is has a writing I mean it's very easy uh and it's very natural to go that direction. The problem is that this goes against uh the principle and uh I imagine at some point where more block builders are removed uh maybe with because at privacy and then we still have the proof there it's it's um I mean I don't like as a model but I understand that this is probably the the ones that have the incentives are the builders. So uh Maybe unfortunately this is the the easiest path.

Okay. Um moving on from the me Gorson, do you think that paying out of issuance would be um viable for provers?

Oh, I've been told I will get things thrown at me if we pay out of issuance. Um

from who?

The audience. We will not be allowed to raise issuance. We could pay out of issuance if we reduce issuance for testers and then shovel that over to approvers. Can I briefly say something about me? Go ahead.

I fully agree with you that perverse incentives are a problem. I think the perverse incentives also apply to people like you. They apply to cordives. They apply to researchers because now we're enshrining the idea of MEV in the protocol is necessary to pay provers. And then if we have the other push to say but that's bad for users.

We want to reduce ME particularly sandwiching toxic forms of ME. Now we have this force that says but we can't do that. than who pays the provers. Let's not go there. Yeah.

Okay. So out of issuance maybe I currently like your idea better to pay out of the transaction. It's an execution layer function. We're paying the execution layer right now from the TX fees. We're praying the consensus layer from issues issuance.

So why not keep paying the execution layer proving from transaction fees?

Yeah. Maybe if I can very quickly add to that because you're taking me apart from transaction fees. But actually I like the transaction fees idea too. I think today again not a block builder ourselves exploring that direction but even today that does pay a lot to block builders. Blockb builders are just concerned with building the most valuable block and one way they do it is by including as many transactions as possible and then there's you know complex mechanics between orderflow auctions and block builders and who gets exactly how much and what gets refunded to the the auction or maybe even the user through the wallet.

But being paid from from uh uh transaction fees sounds uh great. But I do think we yeah might still have this interaction between the builder and the prover and who ends up with.

Yeah.

And also I just have to say from a principle if we're going all in on ZK like let's actually keep the zero knowledge. Let's do the research to actually have private mess and maybe do away with me entirely if we can.

Okay. Okay.

Encrypted me pools. I like it.

Um Leland maybe you could tell us can we learn anything from how the L2s pay for GK proofs and does that inform how what we can do on the L1?

Yeah that's a great question. So at succinct we have this library called op succinct. It basically turns a ops stack roll up into zk rollup. Uh we currently have three chains live on mainet. And so how these chains pay for uh proving is actually through transaction fees.

Uh so we've upstream the change to opt called like a operator fee. And so every time you send a transaction um some small slice of it goes directly to the prover. And so like yeah, if you look at private literature, like yes, we could use um transaction fees directly. But I will caveat L2s are very different because L2s generally don't have inflation baked into their protocol.

Okay, that makes sense. Um okay, I think we're going to have to round up, but I'd like to hear from each one of you. Is there any takeaway that you'd like the audience to have or any takeaway for yourself from the panel? And maybe we could start with you, Lucian. Um I mean I think the key takeaway is that there are certain principles um that you have to stick with even when we do a massive change in paradigm.

You need to have the right to be able to run your own prover. You need to have the right to be able to like actually just see the entire stack and have it be open source run the cryptography yourself and verify that it's correct. And uh the current state of ZKVMs and its relative maturity also requires at least a two of three verification system. And having worked on the operations side and worked with partners in production, we need to make this very clear. If you are running a production blockchain ZKVM system and you are enabling fast withdrawals from that verification and pro and your actual verifier is also permissionless, you probably need a two of three proof system immediately and it doesn't really matter because you can't just like go all in on one proof system to be like, oh, there won't be any bugs.

Like we haven't figured that out yet. So we have to make sure that we have at least a two of three proof system and that we think about that going forward and how like we actually have the same thing of client diversity with ZKVM diversity is actually not a solved problem. Um do we set up a two or three base proof systems on a per client basis? I think that is actually like the best way to do this. Um so I also want to put that out there.

I think my view is like if you want if we want to optimize for g getting to giga gas as fast as possible we should throw as much money to provers as possible so that the ZQVMs become more and more performant. Hence direct direct incentives.

Okay then any final thoughts?

Um first thank you for spending time with us here instead of at the music stage. I know that [laughter] we're not nearly as exciting. Um I've seen different numbers for where we're going. I've seen 100xing the gas. I've also seen 540xing the gas to 24.

3 gig, I think it was. Um, that's very exciting. I love that. And we need to make sure we keep our soul right while we're uh competing with other chains um that are in that kind of throughput. Can I say Solana?

Um then [snorts] we must not lose of what makes Ethereum Ethereum and that makes decentralization, right? And so we want to bring everyone along here and that means we need to stay decentralized even in parts where we say oh we can centralize this and we still have fossil right then no let's try and keep proving decentralized as well let's make an effort.

Okay great Alex any final thoughts?

Uh no I can like I think wholeheartedly like agree with that. Let's make sure we keep the properties but also let's scale Ethereum and let's scale it a lot. [laughter] My my thoughts is I mean ZK is really important for decentralizing Ethereum but uh for scaling Ethereum. Um today we unplug uh the first client I mean we were I mean we were using for first time uh ZK proof in nor in Ethereum somehow I mean this is I think historical uh thing today and what it means that this goes fast and now that's still early because I mean we just unplug it there uh we are on time to set up the right uh incentives mechanism and to think in the right way. So I think that for me the takeaway is the importance of defining this protocol the having clarity in Ethereum.

Um I think this is an important thing and this is part of a scaling Ethereum. Uh if we don't define uh the right uh incentive the right protocol for how the provers should be plugging in the network uh we risk in changing the values of the network. So I think this is important and it's the biggest takeaway that I'm taking from here.

Okay, awesome. Well, I think we could talk probably for for hours and maybe we should actually. Uh but yeah, I think we have to round it up here. So, thanks a lot to the panelists and thanks to the audience for being here on Saturday. [applause]

Thank you all.

All right, that concludes ETH proof day. We hope to see you all in Can. Uh there is a Dev Connect happy hour happening right now. Um hope to see you there, too.

[applause] [music]