Ethproofs Call #3: Gigagas L1

Transcript

Welcome & Scrolls of Giga

Hello and welcome to Eve Proof's uh call number three. Uh what we usually do is start the recording 3 minutes in to give people time to to come in. But uh we have a special song. So we're going to use the special song uh for the three minutes uh while we wait and we uh we welcome everyone. >> So well any whenever you're ready we can get started. Well, let me know if this is too loud. >> Before the fire of Giga, there were scrolls too brittle to burn.

Disciples of bandwidth wandered the mighty deserts until one found the path of parallel flame. >> Hi, Alex. Hi, Ali. Hi, Alex. >> Code forged in trained in a temple where the other rust 12 ticks per block. No master move fast. We whispered old gas like it came from the past. I knelt in silence where the nodes don't speak read scrolls in would call data harsh and bleak proofs were riddles each circuit of blade shaing compilers in a zero knowledge cascade monks recited gas like scripture and loops told me skill ain't speed it's deep truth roots >> long ago they counted >> welcome everyone we have a special song

today while we wait for everyone to come in >> it's 1 minutes past the hour we have 77 people connected >> not in thousands But in flame in giga [Music] test net ghost haunted my sleep rollups failed while the gas ran deep. Fork chains fell like brittle clay. Node scream truth but couldn't relate. I spar with ZK demons in a pro pit. Learn recursion sharp every layer lit. Carve ops through state with the hexic braid.

Stack trace destiny in the sparks I made. DA broke free but still they crawled. I moved in giger while their throughput stalled. Sharted mind split by modular pride. I unified flame. Let the gas decide. The slow ones feared the scroll said it was unstable, unsafe. But the monk who read it, he proved a billion truths in silence. Now I str with a block gas wells scroll in parallel shells C5 splint can't match the scale 800 chains in a single trail mess vapor latency bends I broadcast

flame through recursive ends they brag TPS I whisper gas scrolls of turn fash The layer rolls >> Sid Sergey Sebastian Rick Riza >> Peter Norbert Nick >> and everyone else that I haven't had an opportunity to welcome. We're going to get started in just a few >> seconds. Flame without smoke.

>> Scroll sealed. >> Good. >> All right. >> Thank you so much. Uh, props to Connor Swan from um from Proof Lab uh for for this uh second song that we're featuring on an EF proofs call. Welcome everyone. This is Eve Proof's uh call number three. Uh we have quite a uh packed agenda. Uh before we get started, I'd like to very very briefly uh share an update uh on the ZK tracker.

Um, where is the CK tracker? Sorry about that. Just a second. And then we'll get started with uh some presentations. Okay. So, here's the the Uh, a few things that I wanted to highlight. Uh, we now have a a new column. Um, uh, sorry, we have a a new column here for for for GPUs. Um, yeah,

Intro & zkVM Tracker Update

congratulations to all of those that have an open-source uh GPU implementation. Um, we we also have ZISK uh that has uh integrated with EF proofs uh just just today. Um and you know we have these these new categories basically trying to uh to highlight towards the top uh those that are uh you know slightly readier for integration into into eofroofs. Uh, and there's been lots of changes. Uh, some that I can remember off the top of my head. We have Zyron that renamed from uh, ZK Mips. Um, and yeah, we also have Valida that has open sourced uh, recently.

Um, and yeah, we also had a couple pivots. Uh so uh the the Kakarot team with KEF uh I think has pivoted to um local uh approving and and and privacy applications and um I believe also the irreducible team uh with with Petra. So things are really starting to to shape out and we're we're seeing here the absolute dominance of of risk 5. Um but uh this this discussion around the ISA is going to be pushed to uh the next calls call four and five. So on call number four we're going to have proponents of risk five uh try and and argue for it as you know potentially the

native ISA within Ethereum and then on call five we're going to have uh those who would like to advocate for alternatives to risk 5 uh to to come forward. Okay. Uh, with that said, uh, let's get started. So, our very first speaker is Morgan from Lita. The floor's yours. >> Um, hi. Thanks, Justin. Can everyone see my screen? >> Yep. >> Great. Um, so I'm here to tell you about the latest release of Valida. This is 010.

zkVM Update: Lita | Valida

Um, so highlights of this release. It's now uh open source. Specifically, the VM including the execution engine, the prover and the verifier are now under Apache 2 and MIT license. And you can find the source code at the GitHub link I've provided there. I will also drop a link to these slides in the chat so that you can later follow all the links. Uh I also want to note that the valida is had a rigorous spec published that's also linked there. Um, we are looking for builders who are interested in creating additional implementations of valida.

Feel free to reach out to me using the contact provided on the previous slide. Uh, uh, other highlights of this release. Um, we've got uh, multi-segment proving now. So now we can prove much longer executions than we could before. Uh, and we have a proof of concept of block proving for Ethereum. Uh just to set expectations here, it's not ready to compete in ETH proofs because we're missing a lot of pre-ompiles that would be required to be competitive on performance. Uh and we also don't have a GPU prover currently.

Um some some other highlights of this release, we're now supporting Rust 1.86 including the Rust standard library. We've got uh re a reasonably comprehensive uh testing for that uh based on the rest standard library unit tests. Um we have we have actually a pretty good user experience. Um I think uh not as far as I'm aware uh nobody is beating us in terms of the amount of ordinary Rust programs we can compile and the ease of which that can be done.

so, uh, yeah. Um, let's see. Uh, yeah, that's all I wanted to hit. Um, thank you for your attention and I'm happy to take any questions. >> Amazing. Thank you, Morgan. Uh, as usual, any questions feel free to raise your hand, ask in the chat, or simply unmute and and ask the question. One question to get us kicked off. um multi-segment proofs is the idea that uh you have one proof per segment or are you aggregating the proofs? >> Uh so I would think of it as um like one proof for all of the segments. Uh each you could it's sort of like a bunch of isolated Stark proofs that together

imply the statement being proven. But what each of those stark proofs proves in isolation is not really an interesting statement. Does that answer the question? Yes. So you do have recursion to fit everything into a single proof. >> Oh um no I mean what we get is one proof but the proof uh grows linearly in size as you add segments. So it's not really succinct proving uh and we do need an additional uh proof compression or recursion layer to make the proofs more succinct.

>> Okay, got it. Any other questions for Morgan? uh since we have this new GPU uh prover column I'm curious if um you've started GPU acceleration and if so is it being done inhouse or with an external team >> so we started an in-house implementation of GPU proving using NIM I think we we've just done some proof of concept work there what I think is interesting about it is that we developed a new method of compiling NIM to CUDA And we can easily retarget that to support various GPU APIs. So it should be a fairly cross-platform approach.

>> Nimuda very very cool, very innovative. Okay, if there's no questions, uh let's uh thank Morgan and oh uh Kev asked why does it say support for Rust 1.86? >> Oh, that's a newer version of Rust than what it supported before. Got it. Okay. Thank you, Morgan. Uh, next up we have uh Alan from Brevis who will share some updates about Picos's open sourcing.

zkVM Update: Brevis | Pico

>> All right. Hi everyone. Uh, this is Alan from Brevis. We are working on this uh uh pick called the ZKVM that we developed inhouse uh based on uh stark proving back ends on koala bear. Um it has been uh pretty fast on CPU. Maybe some of you have already came across this similar figures where we have been working on this CPU acceleration large scale parallelization of the CPU version and we benchmark it on some very standard like Fibonacci tener and the RA brewing some kind of RA blocks uh some very standard workload and we are able to get approximately like two times faster compared to the nearest competitor. Um and since then I think we

have spent like a two months or so to work on a GPU and then just two weeks ago we released our first version uh Pico GPU version 1.0 zero um uh where we are able to prove uh using picle on a single GPU on a single machine. Um and we have run some kind of benchmark and what is very really exciting that compared to uh pure CPU version of Pico which was already pretty fast among all the CPU versions of the ZKVMs. uh we are already boo uh we are actually boosting the uh the performance I mean the efficiency uh by about like tw almost 20 times. Uh so this is a big gain from

using GPU as a actual uh computational resources. And of course we have run this uh pretty standard uh test like taname ra some some other rave blocks and we have got about like 15 to 17 times faster uh up to this these times faster compared to other uh existing ZKVMs. And we just came alive on this ETH proof. If you go to etherroof.org uh you will see us uh showing showing our name there. Uh usually I think for most of us mo most most of the most of the blogs we are actually the fastest compared to the

existing um the listed ZKVMs there. Uh so this is not a cherry picking screenshot because we have collected consecutive hundred blocks and plot their milling gas used versus time and compare it with our nearest comparator. Um so the blue dots is ours and the red dots is uh is SP1. Uh one trend is you can see that along with the milling gas used the more gas we use the more time that we're going to be used to proof. So this is one thing. The other thing is that you can see actually there's a statistical significance for us to actually be better compared to uh compared to um our competitor. So on

average we have calculated is about like 25 to 27 faster uh than nearest competitor. So I think this is a pretty good start which is which we will call as Pico version 2.0. zero. I think uh that will be ready um yeah by the end of August which is like a one and a half month from now. Um we are pretty optimistic that we will achieve this real-time proving by then and then also at that time we will be consider uh we consider try to open source our GPU code as well.

Um uh we I think in two weeks we are also going to be releasing our binaries of GPU version for all the others to try. Uh so that you are free to try out on either E3 or any other um workloads that you are interested in using our Pico uh GPU version 1.1 1.0. Yep, that's all from us. Thanks. >> Excellent. Thank you so much, Alan. Um so yeah the the reason why I invited uh Pico to to speak uh today is because uh I met uh one of the co-founders Mo and K and he mentioned that uh the GPU prover will be open sourced at some point. So this is my main question for you Alan.

Um do you have a a a time frame for open sourcing the the GPU acceleration and do you know under which license it would be licensed? Yeah, I think uh if we open source that it would be dual license the MIT and Abatch license and then speaking of the timeline uh I think we are going to be uh consider open sourcing that after our multiGPU and the multi-achine support has been done. So I think it's at least two months from now we're going to be considered releasing the open source open source the code.

>> Okay, amazing. Thank you so much. So we have some questions from the uh audience. Uh what size Fibonacci is it 32-bit or 64-bit? >> Uh Fibonacci uh we we are proving that Fibonacci with the input size of 300K or so. Yeah. >> Okay. So >> I don't quite understand. So is that the >> Moto? Do you want to clarify the question? Is >> Yeah. Does that answer the question? Uh yeah that was actually the question what I meant by 32-bit 64-bit. Usually when people say Fibonacci it's mod 2 to the 32 or mod 2 to the 64. My guess most of them is mod 2 to the 32. I just wanted to check.

>> Oh I see. I see what I mean. Yeah it is a mod to the two to the 32. >> Thanks. >> Kev is asking the end to end latency is 8 minutes but the proof takes two minutes to make. Uh why is there a discrepancy? Yeah, this is uh yeah, it's something related to our internal machine. So, we are actually using our internal machine with 14090 GPU uh and a bunch of CPUs. uh but I think there's something uh uh something that we are trying to solve there uh which is the network connection is is extremely low to actually connect to any of the uh source of the source of the blocks where we we could compact those

kind of standing in for our program so we are still working on that but that's something that we are uh so for for now we are using AWS machine to receive those blocks and then send those blocks to our internal machine and then do the proof And then for the for the proving time we just recording the proof time for our internal machine but the total time is just a back and forth time included which is why the discrepancy. So we are still working on that to try to reduce that as well. >> Got it. Yeah. This has been a real pain point just to get the data to feed into the the the prover and you have to go through alchemy that will throttle you and that has these networking hops and

whatnot. Um ZKSync uh sorry not ZKSync ZK cloud uh made a massive breakthrough there. So they're using one of the the ref debug API endpoints uh and they got the whole thing under you know one second just a few hundred milliseconds. Uh I will talk about it in in my presentation but uh we may also hear from the CK cloud folks. >> Next question. Um 1.2 orders of magnitude slower than required for maintenance. Does it seem feasible for full pro to to prove in real time?

>> Oh, I see you. You're asking. Oh, because this is only for the one CPU and one GPU version. Uh, so if you look at it, uh, it's uh, yeah, it's uh, two it's it's about like 200 seconds, right? It's like one 10 times slower than 12 seconds. uh but the thing is that this is only for one GPU and then we are expecting to uh because more or less speaking uh this is something like inversely parallelizable where we are just chunking uh or splitting the whole uh block into a bunch of chunks. It's like tens of chunks and we uh if we only have one GPU then we are just approving them serial serializely. But then if we

have like a more GPUs like 4 GPU or 16 or 32 GPUs then we can just prove them uh parallelizely uh until we need to combine them together but combine the com combination process can also be to some extent parallelizable. So we are expecting that the with more GPUs we are able to achieve the real time proving >> makes sense. That's the usual uh way forward to have a cluster of GPUs. Thank you for the question, Daniel. >> So, um what we're going to do just before, uh having the next speaker, something I forgot to do is a a group picture. So, uh for those who are comfortable turning on, uh your cameras, uh we're going to take a group picture.

There's 126 of us here on the call, a huge community. Uh and we'll be uh posting uh those uh those screenshots on the on on the on the Twitter account. Wow, great to see so many uh so many familiar faces. That's amazing. Okay, so next up uh we have um some um EF updates. So um one of the things that has happened recently is that there's been a bunch of reorgs within the EF. We have this new protocol team. Actually, I should say it's a cluster of teams of which now there's a new dedicated team called the ZKVM team. It's quite a large team, maybe six people or so. And um I believe yesterday uh was announced

another reorg to the foundation this time on the echoev. So if you look at the org chart which might be affirm.foundation/people uh you you you'll see uh something very very different than uh than even a few weeks ago. And I'd like to invite Kev, who is the team lead for the ZKVM team, to to share some some updates about uh about his team and to introduce it. Kev, the floor is yours if you can hear us.

Okay, he's having some technical difficulties. Hey, Kev, are you there? >> Yeah, sorry. I don't think I can share my screen. Uh, I'm having some issues. Sorry. Uh, yeah. Sorry. Maybe if you come back to me, I'll try to fix this. >> Okay, sounds good. So next up we have Sophia who is part of the ZKVM team and uh just today I believe published a blog post. So Sophia, the floor is yours. >> Um yeah, hi everyone. Um so yeah u published this blog post yesterday on the EF blog. Um uh it gives a brief overview um of our plans for uh shipping

EF Update: zkEVM Team | Intro (Sophia)

a ZK VM on L1. Uh effectively we'd like to have ZK clients optionally verifying execution proofs uh soon after Glamsterdam goes live next year. Um as the first stage in uh getting ready for this um we're proposing a um uh essentially um a bunch of requirements for what would um for ZKVMs that would be used in this. Uh these include security guidelines uh mainly coming from our cryptography team. Um, but I think the the real um salient part of it is um effectively um we're fixing something like reference hardware for real-time proving uh with

the idea that uh multiGPU machines that can run uh on under 10 kilowatts of power um so that they can be uh run in um uh outside of data centers and even in some residential homes uh that have circuits used to run electric appliances or uh charge electric vehicles. Um so this works out to uh if you factor in like high pee cooling something like about 165090s. Um and we think that especially with a lot of the recent advances in real-time proving uh that we've seen um uh you know over the past like month or so um that several ZKVMs could reach this before dev connect uh in November. Um yeah so um happy if there are any

questions based on this >> any questions for Sophia? Um there is a link in the chat to >> um with the link to the blog post. Um so Maris is asking an unrelated question. What prover killers do you see most critical important to address in the future? Uh actually that probably a question for the next uh speaker. Okay, thank you so much uh Sophia. Super exciting. Um yeah, DF is going big. Uh we have a dedicated team. I actually counted it's seven people, not six in the ZKVM team and we're also using the blog to make some noise. Um Sergey asks,

"Do you not allow uh trusted setups?" Um so unless it's universal no trusted setup um and in usually uh well the status quo nowadays is is to use hashbased systems that don't don't have trusted setups. Anyway, thank you for the question Sergey. So next up we have Ignasio from the ZKVM team who will be talking about benchmarks. >> Hey thanks. Uh let me share the screen. Can you see my screen?

EF Update: zkEVM Team | Benchmarking (Ignacio)

>> Cool. Uh I have a minute so I will be rushing a bit. Um seconds. Yeah. So I just wanted to give a brief uh update on CDV and benchmarking the work that we are doing in the team. So as to give a bit of a refresh on which are the goals uh our benchmarking is focused on the Ethereum use case. We are not interesting in doing some kind of random benchmarking of CGVMs. Uh we are not interesting in Fibonacci programs and things like that. We are interesting in uh testing uh EL clients as guest programs and uh benchmark uh E3 blocks.

So the fixtures that we are targeting for the benchmarking are prover killers that I think most people already know about. Uh we are also benchmarking blocks uh that use the full cast limit to run single op codes and pre-ompiles. So we can have some understanding on the performance per op code or pre-ompile on different configurations. Um we are also interested in uh benchmarking upcoming forks to understand the upcoming protocol changes and how they affect uh proving blocks and of course we are interested in also benchmarking mainet blocks. So the main goal here is to have more understanding on the average and worst case uh proving

times. Uh understand which kind of potential gas repricings we have to do to help proving times. Um understanding the relationship between proving time and gas limits. Uh in theory should be linear but we have to double check that. Uh there are also other things that are relevant such uh like uh the guest program memory usage is something that is not really discussed much and many CGVMs have a cap on the amount of memory the guest program can use and if you use more memory than that well the program will crash. Uh we already identify some of these cases and also we are uh want to understand better the hardware

trade-offs. So how proving times uh behave on under different GPUs, CPUs and things like that. Uh the important part here for us is that these are benchmark that anyone can reproduce. Uh the inputs uh the tools and the analysis are meant to be transparent. So yeah uh the idea is to uh to to make this very very clear. So the highle um picture of how all this pipeline works is quite simple actually. We have the inputs here of the benchmarking which is basically three parts. One of them is the cigm that we want to benchmark. So here you have like SP1 r

zero cis and all the rest. Uh the other configuration is which guest program we want to use. uh that might be get red never mind or whatever EL client that we can compile to risk five uh which is the target that we are having now and the other thing is the scenario that we want to benchmark and this can be today uh the execution spec test that we have been working for a while um for the killers and testing up cost and pre-ompiles using all the gas limit or uh benchmarking mainet or devet blocks so the idea is that you configure that uh which are basically JSON files. Uh you run the benchmarker which is this

repo which is open source. Uh maybe you can take a look at at it if you want and it outputs some uh JSON files with basically the outputs of the benchmarks. Basically uh the most important part is the proving time in seconds. uh with this JSON files you can build whatever website you want or analysis tool to have some conclusions. So I will do a quick demo of um uh a local uh website that we have for uh having a a more visual representation of the benchmarks that uh we have been doing.

So uh this website will be uploaded uh to some repo at some point. So you can use it as a tool for interpreting the JSON files. Um so for example you have we have been doing like three kind of benchmarks. The one is network benchmarks uh in this case for mainet blocks. Um these benchmarks are for a pro with a single GPU. Here are the the hardware which is automatically detected by the tool. And basically you can see um yeah for network benchmarks uh which blocks were uh proven which were which was the proving time. You have some stats here about proving time percentiles uh which

is pretty important to understand correctly. Uh you have also the gas per second percentiles um which is also important to understand because not every block in mainet has the same gas usage. So uh yeah the gas throughput is basically the the main metric that we want to understand better. The other tab that we have here is test benchmarks which are these proer killers and kind of related benchmarks. So basically we run all these blocks that were specially crafted to test some particular scenario and you can see that some of them made the prover crash for some reason. I won't go into details

here. uh then you can have all these test cases which today are about like 400 um and how much time it take to prove that particular block and which was the gas throughput uh for that. So for example here you can see that yeah mod x is clearly the uh one of the worst cases. Uh here we also have this point evaluation pre-ompile which is the the opening of kg proofs um which I don't think many people have uh mentioned this before uh another maybe interesting one is the lake two pre-ompile which is incredibly

cheap um so yeah uh we are kind of starting with doing these benchmarks these things that I'm showing here is for a particular cigm Uh but the idea is to run it for many and start understanding better how things uh look like. And the third tab here is basically uh trying to gain understanding on how proving times evolve with increasing the gas limit which is another thing that we have to understand correctly. Um so for example here this is like just a subset of the benchmark suite. Um but yeah here you can see like um how the proving time for a particular case which

is a full full of a block full of ketchup codes uh is linear with the gas limit and the gas per second is constant. So that makes sense. Um maybe for other cases it isn't. uh or we will discover that with higher um gas limit the the guest program will crash because it's using too much memory. So this is our like the early days. Uh we are kind of working a lot on the tooling but we are getting a lot of useful signal here.

And for the last slide some upcoming things that we will we will be doing is um yeah uh having a complete benchmark uh sweet run because a lot of these things are very take a lot of time to prove in a single GPU. So a lot of the results that I presented are like subset of the whole thing. Uh we want to do this multi GPU benchmarks. We want to understand also the CPU requirements for realtime brewing. Uh because CPU is also very important for fast risk 5 emulation. We want to understand um with real metrics uh the GPU power utilization and efficiency of CGVMs

and uh also running this benchmarks for the current devets. So we are a bit one step ahead on what's happening. So yeah that's that's all from my side. >> Amazing. Thank you so much Ignasio. Uh one of the things that's already implemented on the efroofs.org site is the killers uh tab or page. Uh but it's it hasn't been populated for for many weeks uh because it's just been much much harder than we expected to benchmark the killers because you know the the programs will crash and we can't get numbers and and things like that. Um one question that we have uh from Marius is um what are the most uh important uh prover killers? I I uh we saw modex for

that um and but he's also asking about BN256. Is that one that you see as a killer? >> Yeah. So, usually the cryptography pre-ompiles are at the top of the list. Uh I want to wait a bit for uh benchmarking all cy VMs because unless we run the benchmark for at least the top three or something like that, um the definition of what is a poorer killer might change. But for for now, for the data that we have, it seems pretty clear that ModX um is in yeah quite uh bad. The Blake 2 pre-ompile is also I think it will need

a repricing. Uh the KCG pre-ompile uh for verifying openings, it feels like it will need a reprice too. But yeah, I want you to be careful there because until we run more CGBM uh on these benchmarks, uh we won't really know for sure because we won't kind of know the worst case for the top three or the top five or something like that. >> Okay, got it. Thank you so much. Uh Ignasio, uh Kev, have you been able to uh sort out your your setup? If you if you want the floor is yours.

EF Update: zkEVM Team | Mission (Kev)

>> Um I could just talk without this the the screen being shared. >> Okay, sounds good. >> Um yeah, so the EF has uh recently um done a reorg and out of it out of it has come the ZKVM team which I'm currently leading. Uh the scope of the team is essentially the end-to-end pipeline from like your high level guest program to the proof being verified on uh on a validator and the people in our team Sophia is doing the coordination of the ZKVM teams. Uh we're collaborating with the robust incentives group which is another team inside of the EF on proven

incentives. Uh this is led by Julian Mah. Uh we're working on standardization of the guest programs and the compilation targets if you're targeting a specific compilation target like risk 5. Um we're also writing the guest programs if we need to and testing them. We're benchmarking them which you just saw Ignashio presenting on and we're writing the sort of proof of concept ZK stateless plane that will uh receive proofs uh verify the proofs that basically attest to the execution payload being correct. Uh and we're also integrating uh different ZKVMs into our pipeline. Uh checking the relationship between like single GPU

benchmarks and multiGPU benchmarks. uh investigating the security of ZKVMs as well uh which is led by Kodi on our team. Uh so essentially we're doing everything it takes to ship ZKV ZKVMs on L1. Um yeah that's the short short summary of it. I don't know if anyone has any questions. >> Lumi is asking uh can you share the the slides? Uh maybe a link in the chat. Yeah, sure. Um, it was just one slide. I can share it.

But yes, I can attest to the fact that uh we are going very big on ZKVM. Um, and uh, you know, we also have this stockification team. Um, we have uh, I'll talk about this in my presentation actually. Cool. Thank you so much, Kev. Um, next up we have Cody who will talk about ZKVM security. >> Hello. All right. >> Hi. Should be it. Says I'm sharing. Um, yeah. So, uh, thank you.

EF Update: zkEVM Team | Security (Cody)

Yeah. So uh my goal is to collaborate with our security team and uh you know work in tandem with the formal verification project and work with all of you to get not just scaling Ethereum but very secure scaling of Ethereum. I think the security is absolutely paramount to uh to our success. Um and so yeah these are the phases of my work approaching it in in this order. So there's currently I'm doing sort of research and proof of concept work on like security tooling you know what we should build when we should build it how to build these things um you know things are moving really fast is it the right time to assess this or that uh DKVM or this or that proving system these kinds

of questions and I'm also looking to identify uh gaps generally that's something we want to do at the or the EF um you know where are there what are the high impact components we could build. Um, yeah. So, so that's that's what I'm working on now. And then there will be a buildout phase where we build some, you know, really high quality security tools and hopefully some components we can we can share with all of you. Um, maybe we can't share all of the tools uh publicly. Um, and then probably a coordination and tracking responsibility while we um work with many entities to bring these things live and uh have be sure they're secure. And then later I guess there's just a lot of bug hunting, patching, and more of this sort of

coordination and tracking work to do. Uh so yeah, here's what I've worked on in this first phase. Um there there are these architectural tests uh these risk five architectural tests that not all projects uh actually run. So, I I looked into how how these work and um I've run them on some projects and I'm not ready to share results yet there, but uh there's some something interesting to say and um it gives us some interesting insights about compliance and where we're at and and how useful the general ecosystem of tools for risk 5 are for our use case. And then very recently I finished this uh first proof of concept fuzzer based on a paper called cascade which I call it cascade there. Um, you

can have a look. It's it's a simple I tried a few different things though that it had some false starts and and this is I think a reasonable approach. And next up will be a plunky 3 verifier fuzzer. Um, and to to say what sort of general components might come out of this. Um, you know, I'm interested to know if people think these would be useful. Uh for instance, maybe we should build a easy to integrate, you know, good performance uh risk 5 program generator or some general kind of like proof mutation library for doing um verifier fuzzing and you know maybe we could also build some general circuit analysis tooling centered around LLCK. So that's where

we're at. Um I'm very excited to work with all of you and I'm happy to say that my days are not full of meetings. I have plenty of time to to meet you and uh and you know be in touch on Telegram or even take a call and I' I'd love to hear from you and to know what you think is uh useful security work for us to do. Thank you. >> Amazing. Thank you so much. Uh Cody, any questions? >> Hey Cody, can you hear me? >> Yes, >> I can.

>> Hi, this is Christian from um a question. Do you consider such channel attacks in your security assessment? >> Not at all. Not yet. Nope. >> Do you plan to? >> Uh yeah, I think those are important. Um this is not something I understand very well at all though. So I'll be looking for people to uh to help with that effort. Can I can I reach out to you? >> Okay, thanks. I mean my mental model is that uh side channel attacks are relevant in the context of privacy where you don't want to leak information for ZKVM specifically for scaling. I don't think we have uh uh any any secrets uh but uh maybe there's some other use case that

that I'm not thinking about. >> Makes sense. >> Okay. Um, yeah, Kev says in the chat, uh, there's there's no private data, so it shouldn't be an issue with side channel attacks. Um, next up we have Thank you so much, Cody. Next up, we have Farah from Ephroof, who will give us an update on some developments on on the website. >> Cody, would you mind stopping your screen share?

Ethproofs Update (Fara)

You have to try again. Farah. >> Okay. Hey everybody. Um, I just wanted to say thank you to the athereum.org team and to both Justin and Will uh for helping me over the past month as I've started to work on some initial improvements to ETH Bruce, which we hope will help teams onboard more easily to both staging and production. Let me move my video here. So yeah, basically if you come to the ETH proof GitHub repository, um we've created a new issues template called team onboarding here. So teams can request to start the onboarding process and have us track it publicly. Once that's been created, um it will be

populated on this um public project board where all the teams that are currently kind of being tracked through different stages of that process um are shown and right now like Zisk just went live to production today. So, you know, we can track that and move it now on to production. And the way that that manifests itself now onto Eru directly is on the ZKVM page, we have this coming soon tab now. So basically this will list out all the teams that are in the final stages of that process. Um this tab kind of surfaces all the information being tracked on Justin's CKVM tracker um spreadsheet. So it's kind of meant to migrate much of that information on to

Eru directly. Um we've pre-generated API keys for everyone listed on both staging and production. So reach out to me or to Will on Telegram if that's something that you need from us right now. Um and a couple other minor improvements um on the blocks page. Basically, we're ordering proofs now by the fastest proving time. And we've made sure to kind of distinguish that the single machine is 14090 and the multi-achine is a multiGPU which you see Z now just onboarded today um and is proving on ETH Bruce and we've just made some minor improvements to the UI with the download button giving some feedback. Um, so yeah, I mean if there is any new team

that feels they're ready to begin onboarding, definitely open an issue in the ETH proofs repo using that new template. And I'm monitoring the repo activity daily. So if anyone has new features they'd like to request, you know, feel free to open an issue and we'll look at prioritizing it. Thanks. >> Wow, thank you so much. Uh that that's great to see all the improvements. Um yeah, we've uh Farah has has received an EF grant and uh you know over the last few weeks has been on on on boarding and I think now she's uh close to to fully on boarded. So uh feel free to to throw at her lots of suggestions, open issues on in the GitHub repo and and you know let's let's make this website as as good

as we can. Um and yeah, if you'd like an introduction on Telegram or whatever, happy to facilitate that. Okay. Um so one of the questions in the chat is uh did you manage to use GE as a guest program? And S Sophia said uh GVM guest program soon. I don't know if anyone wants to talk about uh this.

Uh >> possibly Guiam Gom at at one point um the stateless team was potentially going to focus on uh GE as a guest um gag. Y >> is that is that something that you guys are working on? >> Yeah, absolutely. Uh I think soon is very optimistic but yeah that's something we are working on. >> Perfect. And how many people uh from the stateless team are working on this effort? >> Uh just me. >> Just you. Got it. Okay. Question from John of KDEITE. Is there a place on the approved to follow the upcoming benchmarks per from teams to bridge the lag from what's announced to what's there?

Um we hear ZISK is real time. Um we do have uh the provers which right now is all like soon TM. Um, one of the things that I initially was thinking of doing to onboard the teams is to um to have them prove one in every 10 blocks after the one in every hundred and then go to one in every basically prove every block. Um, but now I'm thinking, you know, with all of the improvements that we have, if you're going to invest in a a GPU cluster, then you might as well just prove every block in in in real time. So that's what we're going to be encouraging the ZKVM teams to do in the next few weeks and months.

Um basically set up a cluster and just prove every single block. The FM foundation will pay for your cluster. So so yeah do do get in touch. Uh we especially want to encourage um onrem clusters. So if you have an office that's that's ideal. uh if you um if you have a home that has the the the the uh the support for that that that's that's even better. Uh but yeah, definitely hoping for real-time proofing on e proofs uh by by next month.

Cool. So next up uh we have basically a discussion on uh how to bring uh EL1 to a gigas per second and I will be uh presenting some slides. And again just feel free to to ask questions and and interrupt anytime. So this presentation is meant to be a deep dive and if you're watching the video on YouTube uh we do have an eve proofs uh telegram uh group as well that you're welcome to join

Gigagas L1: Part 1 - Zero to One: Latency (Justin)

and um just a few days ago at ECC I gave a talk of the same title but very different content uh it was uh much less uh technical content. Okay. So, um the goal of course is to um have the validators verify proofs instead of executing blocks and to have both scale and decentralization of the of the validator set. And the the meme uh that uh you know is being brought forward is that we can have even more extreme decentralization than what what we were previously targeting. So,

previously we were hoping to have all of the validators run on Raspberry Pies, which is a roughly speaking $100 of hardware, especially when you get to the external hard drive. And we want to get it down to uh basically under $10 with the Raspberry Pi Pico, uh where you can run a fully validating execution layer client on on minimal hardware. And of course this is relevant in the context of uh mobile phones and mobile wallets and and also uh trustless bridges to to other ones. So the talk will be in in three parts. Um parts one, two, four parts. Parts one, two and three will be about um getting the chain from a traditional L1 chain to to a ZKL1 focusing on latency,

safety and livveness. And then a fourth part basically going from this this foundational infrastructure of the ZK1 to uh to something to a chain that that is extremely scalable. So um one of the key uh ideas for latency is to have the um this notion of of delayed proving. So right now if you propose a block you're expected uh to to provide a a state route for it immediately. We can delay the state route and allow for a whole slot uh to for the for the proof time. And actually see actually I should say it's not

exactly a whole slot. Um there's there's a little delta here. So you have a little bit less than than a whole slot uh to to to generate the proof. And um there's a couple of variants of of delay proving here. There's same slot and previous slot. And uh what I'm advocating for here in this talk is same slot. So the proof here that is being uh produced is for the block uh here in in in in the in the same slot. And if you'd like to to learn more about the specific construction, uh it's called the proof killers killer. Um and uh there's various ways to implement it.

either either through what's called delayed execution or enshrined PBS. Now the um the it's good to have a look at the uh ZKEL pipeline to understand where latency uh comes in. So on the prover side of things we have all of these different steps. We have to fetch the data from the L1 block. Uh we have to split uh the workload across multiple uh subblocks. Um, for each sublock we have to trace it, meaning that we have to execute it and have all of the information necessary to feed it into a prover. Uh, we need to do the actual heavyduty crunching, lots of FFTs and things like that that's done on the on

the GPUs. Then once we have lots of small proofs for every little segment, we can aggregate the proofs and then finally we can wrap it. And then um once we have the proofs, we need to gossip it over the network. And then on the v verify side of things, we're going to be verifying the the various proofs that are generated. And the good news is that almost all of these things um scale very very well with the amount of of gas used. So it's constant amount of of latency with uh with the exception of of of of aggregation. And then the reason is that um you have the more chunks that you have the the deeper the the the binary tree that you have in order to uh

aggregate everything to into one proof. And the the the places in red here in my opinion are going to dictate um you know how small we can make the the slot. So there's been some some talks about significantly reducing the slot durations and I think we need to be uh a little careful to not make them too small otherwise uh we won't be able to uh to have enough time to to to do these these three steps and uh yeah the tracing here for example is for the for the the the worst case uh transaction. So possibly a 30 million gas transaction that just uh uses, you know, the worst case um up codes and pre-ompiles and is

effectively a killer. That's going to be a lower bound to uh to how big or how small we can we can make the slots. Now um there's been some fantastic uh breakthroughs in the last few few weeks and months uh related to various parts of this pipeline. So on the data fetching side of things, we have this uh this trick that ZK cloud has has has used which is the debug execution witness um uh API endpoint on on ref and um Zcloud has really amazing numbers. They can do what takes multiple minutes uh on uh on most setups uh takes less than than one

second for for them. So the if you click here on this link uh by the way the slides are shared in the telegram group uh then there's a tweet explaining uh what what is going on and ZK cloud will be open sourcing this uh shortly. Another fantastic idea uh is to um basically split the block into subblocks. And this is a trick that uh SP1 has has brought forward when they announced their real-time proving on the 160 GPUs. And the great news is that we can basically cap the the worst case uh size of of transaction and and spread the load. On the tracing side of things, ZISK has done some amazing work uh

basically with this ahead of time compilation. Um again like all much more information in in the tweets that are linked. Uh they've reached 1.5 GHz. Airbender can do the crunching part on the GPUs extremely fast 15 uh megahertz. And um we also have ris zero that has uh you know really excellent times for the final wrapping and for the aggregation. Um and there's also work uh done by the FM foundation on the the gossiping of these proofs and the the checking within within the various clients.

Now one of the tricks that I mentioned is the the subblock uh trick and here we have an EIP7825 which has been scheduled for inclusion. So that's what SFI stands for in Fusaka which is the next fork that should happen in 2025. And the proposed gas limit cap is is is 30 million. But what happened a few days ago is that Tony and Vitalik co- offered another EIP which might go for example in Amsterdam where they're advocating for a slightly lower cap something like uh like 16 or 17 uh million gas.

So that is going to be a great bo for the for the various CKVMs. Now on the proof wrapping side of things um one of the possibilities is just to do no wrapping whatsoever and uh that has uh a great uh performance uh except for the for the for the for the for the proof size and there's a whole design space here um but basically what I think the the ERM foundation will be advocating for is just to optimize uh the the no wrapping basically just try and and and keep your proof sizes relatively small. And the good news is that mo multiple ZKVMs already have um

proof sizes that are under 300 kilobytes, which is what we're we're advocating for. Um now this is a bit of a side note, but the one of the observations is that um in the designs that we're considering, an attacker only has a whole slot to produce a bad proof. they only have a few seconds. And therefore, because we're dealing with essentially ephemeral proofs that are only relevant for a small time window, it's possible that we can dramatically reduce the the bit size, maybe as low as as 64 bits. But yeah, this is more of a crazy idea than something that we're advocating for.

Okay, I'm going to pause here to check the the chat and also open it up to to So Peter asks why does it take multiple minutes to fetch uh data? So I believe historically um people have been using services like Alchemy. So this is a remote service that's running a a full node or an archive node for you. And um depending on how stale the block is, you know, they have to to do a bunch of work and then the the witnesses are extremely big like many many megabytes or tens of megabytes if not hundreds of megabytes.

um and you have to download that over the wire and then you have to process them and and things like that. Now we have a much better endpoint. So you can just run ref in the in you know not as an archive node but just as a normal for node and there's this uh debug endpoint but even once you've done that there's a bunch of work that needs to be done and um Andre from from ZK cloud is actually answering some of some of those Um question from a uh silly question but can we increase the slot times to give provers more time? what is the current proving time goal?

Um, so in general, we're we're not looking to increase, we're looking to decrease the slot times. Uh, there's a specific proposal from Barnab to go from 12 to 6 seconds. Um, there there are advantages to having longer block time. So for example, you can amotize the uh aggregation cost um a little bit and you can also amotize the the overhead of gossiping and and all sorts of other overheads. Uh but in in in general um several seconds is uh is totally doable uh for for real-time proving and you know a lot of the time spent is actually um very much paralyzable and prorata of of of uh of

the workload. So roughly speaking at first approximation if you reduce by two the workload you can reduce by two the the the slot duration and and basically have twice as many slots and everything works out pretty good. Okay, Peter is also asking why does it take multiple minutes to fetch data? Um, any reason why 256 kilobytes? Um, so the number that we have actually is 300 kilobytes. The reason why it's 256 in my slides is because I try to pick powers of two to avoid uh too much um bike shedding. But uh yeah the basically 256 is fine. Uh twice that 512 is a little

bit too much. And the rationale here is that we're expecting the validators to download three proofs. And so three times 300 kilobytes is less than than 1 megabyte. And that's u an amount of data that is that is reasonable to to download for for the validators per per slot. Okay. I will continue. So the part two is about uh safety. How do we ensure uh safety? So the the solution here that we're leaning on is uh diversity. This is very very similar to what we're doing with the uh execution layer clients and the consensus layer clients. We're assuming

Gigagas L1: Part 2 - Zero to One: Safety (Justin)

that every single client is buggy. And here we're also assuming that every single ZKVM is buggy. But they're buggy in different ways. And when you combine these buggy clients, uh, you end up with something which is actually extremely robust. Um, and from a diversity standpoint, we have nine ZKVMs that are considered mainet ready or at least largely uh mainet ready. And we have uh 10 ZKVMs that should be ready to to prove mainet blocks uh soon in in in 2025.

And uh of of these 19 ZKVMs, 13 of them I believe are t are actually targeting publicly um real-time proving in the context of Ethereum uh layer 1. And so um you know my hope is that many of those 13 ZKVM teams uh will uh reach production grade uh for for our use case. Now um in addition to the ZKVN diversity, we also want to have diversity of the execution layer clients and the terminology that we use um is a guest. So this is terminology from ZKVMs where we have the guest program which is being proven and this host program

around it that feeds the guest program um you know some some inputs like non nondeterministic witnesses. Um and basically this this guest program is in the form of bite code. So there's some usually there's a high level uh uh language that's used to um to write the client that's compiled to bite code and you feed the bite code as one of the inputs uh to the ZKVM. Now um one of the things that's been successful so far is to take revm written in rust and to target multiple backends through LLVM.

So risk 532 was and myips and recently with ZK sync they have a new EVM implementation which I'm calling ZVM because it's coming from ZK sync um and they also targeting they're also going through LLM LLVM sorry uh but the good news is that there's all sorts of other combinations that that become possible so for example there's an effort to try and run GVM from from in go from from the GE team to run it on on MIPS. There's also EVM1 which might we may be able to feed through LLVM. And one of the things that I wanted to highlight is that once we support risk 5 uh 64-bit uh which is a relatively small variant of the 32-bit v um implement uh

ISA uh then we'll be unlocking uh quite a quite a few um guests and I believe that ZISK is already implemented the the 64-bit and teams like risk zero are also considering it. So this is never mind EVM and and and Bessu uh EVM and Eric on EVM. But there I also wanted to to say that there is another approach which is to not have these um these these compiled high level languages but also to use uh kind of custom low-level uh languages. So in in in you can either implement the circuits yourself manually. Um that's what the linear team

did. You can also use uh lean um as your ISA or or Cairo as your ISA. Now, one of the the problems that we have with uh this combination of pairs of EVM guest programs and ZK VMs is that the there's a quadratic blowup. So, if you have whatever like five EVM guests and five ZKVMs, there's 25 different combinations. So, how do you deal with this quadratic blowup? We basically have two ideas. So idea one which I'll talk about in the next slide is what I'm calling slow fast pairs. And idea number two is what I call uh multiVM proofs. So multiVM proof would be that every ZKVM

is responsible for multi- uh multiple uh EVM guest programs and it's kind of the concatenation of programs and it's essentially the aggregate the aggregation of of of multiple pairs. But the the downside of this is that there's quite a bit of of proving overhead because now the ZKVMs are responsible for proving uh multiple EVMs. They can do so in parallel but it it it it has an impact for example on um on the power budget that that that you have. So the f the my favorite uh approach is what I call slow fast uh pairing where you take the ZKVMs you rank them by speed and here there's a there's a little bit of a

competition going on. So you go from the fastest to the slowest and then you do the opposite for the E clients. You put the the slowest one first and then the fastest one last and then that's how you do the pairing. And then the hope is that every pair is fast enough kind of on average where the the performance balance balances out between the left side and the right side so that you can achieve uh real-time proving for sufficiently many pairs. And it's possible that you know just because of of performance constraints uh we might have to lose some of these uh some you know some some of the ER clients just because they're they're finally too slow to work with any of the of the ZKVMs.

Now one of the things that uh needs to be done is that um we need to somehow communicate these multiple proofs o over the network. So the idea is to have n different gossip channels per pair. Um and then the validators the testers will only attest if uh if k out of the n proofs are valid and timely. Timely meaning that they arrived uh on time. And basically with this setup uh we have uh what I call ZK vouch. So if you're not familiar with vouch this uh kind of institutional uh tool that allows the validators to run multiple clients and uh basically the the diversity is is

internal to an operator. A single operator has multiple execution layer clients. And this becomes accessible to home um validators if you have the the ZK version because it's so cheap to verify K proofs. And in terms of the the numbers that I'm I'm suggesting is basically to have k equals three uh so that you only have to download uh three proofs as a validator and that's less than 1 megabyte and n uh to be five because that that basically maintains the amount of diversity that we have in the execution uh layer client uh landscape. But there's diffring opinions on this. So for example, Sophia

Gold who presented earlier today uh believes that we should be like slightly more um restrictive on uh on the number n of uh of of possible pairs and and gossip channels and proofs. Okay, so just to close out the the security uh side of things, I think everyone knows by now that we have this this very big formal verification effort, $20 million spent over three years. It's led by Alex Hicks. And one thing that I wanted to highlight as a a really pleasant surprise that I did I didn't see coming is basically uh this tool called Pyus from from Veradise which has been extremely effective

seemingly at finding uh unconstrained circuits. Uh so that's a very specific uh class of bugs. Uh but it it turns out that unconstrained circuits is the majority of of the of the bugs. Um, so there's this uh study that's been done and uh ZK security has a dedicated website kind of listing all of the ZKVM all the ZK bugs that that have been found uh and are available publicly and 86 out of 89 of these bugs are under constrained uh bugs that potentially what that would be found basically by by this tool pers. So I'm um I'm very very pleased with this development and uh I

know that there's RZero has started work with with Pyus and SP1 as well and and and I'm expecting many many other teams to to follow suit. Okay, I'll pause here. Feel free to unmute yourself to ask any questions. so question from Mu. Will Eve proofs care about the proof having zero knowledge property for any future privacy considerations or just validity? Uh yeah, so Sophia said uh unlikely and I would agree uh just uh we only care about the scalability for now and sickness.

Uh but the amazing thing is that all of this infrastructure will be reused indirectly by the broader e ecosystem. um and I believe it will be used um at the application layer in the context of privacy. Many pro many institutions are kind of knocking the doors of different foundation for and kind of begging for privacy. Um and you know there's there's other other projects out there like Etherealize you know they're hiring uh privacy experts uh for to target institutions.

Um and also all of the tooling can be reused in in the or a lot of it can be reused in the context of the the beam chain and the consensus layer where we'd be snarkifying uh the uh the consensus state transition function. Okay, correct URL is bugs.zk.xyz. Apologies. Thank you John for the correction of the of the URL. Um, Jako asks, "A point again there being much diversity is that most of these ZKVMs possibly all rely on conjectures on read solven codes. Is there a plan to move away to the proven bounds?" That's a great question. So, one thing that we could do that just came to mind is we

could have the fastest ZKVM kind of not rely on these conjectures. Um so that you know they suffer a little performance uh degradation but it doesn't really matter because there's there's a performance margin there. Um and that could something that we should uh probably look into. But again you know the the proper uh in my opinion um model to to view these proofs is the the timebounded attack model where the attacker only has 12 seconds or so to to generate a proof. Um and um you know you could you could look at the the maximum power like you know across the world we only generate something like uh 5,000 gawatt and so basically how much work

can you do within 12 seconds on on five 5,000 gawatt. It's it's it's not that much and that can give us uh confidence on you know with uh with a reduced number of of bits of security. Okay. Guam asks, "In terms of market perspective, how could the client diversity be forced in case everyone wants to use the faster ZKVM?" Uhhuh. So um the in some sense it's ultimately the the op the validator operators uh that are uh opting in uh to uh to to verify proofs and um they don't really care like which one is the fastest EKVM. what

what what they care about is that the the proofs arrived in real time. So within within one slot and uh you know you could be if it arrives within half a slot or threequarters of a slot, it doesn't really make a difference. It just needs to arrive within one slot. But one thing they they do really care about is is diversity. Uh because we are assuming especially in the early days that every single ZKVM is buggy and so you want to have a plurality of proofs uh that that you're checking. And uh the good news is that diversity is not at odds with uh with uh with performance.

And the reason is that there isn't really a race as soon as you reach this uh this 12 second threshold. Okay. Emil is asking about the idea of 64 bits of security because proofs are ephemeral. Um which I guess would mean in in practice reducing the number of fryware queries. This would require that every air table in the ZKVM is partially unpredictable before knowing the block to prove otherwise an attacker can mount an attack in advance. Yes, exactly. So you need to uh basically have the input to the proof be completely unpredictable and you can mix in some some entropy some randomness for example the the hash of well for example like randal or something or the hash of the previous block and and uh yes that's definitely a

good point. Marius asked, "Do you think there are more classes of bugs like unconstrained circuits than that we are not testing for yet?" Um, so the two classes of bugs are under constrained and over constrained and um kind of almost definitionally these are the only two that that you can kind of have um you know for the arithmetization. There's all sorts of uh you know mathematical bugs that we can have on on the back end. You know is fry secure? Is where secure? of these things. We're relying on conjectures most of the time.

Uh and then there's also a class of bugs on the on the prover side of things. Um which I'll talk about in in part three. You know, things like prover crashes. If everyone's prover crashes, then that's that's really really bad because that's that's a livveness failure. Um so I will I will talk about this in in the livveness section part three. >> flag aside from under constrained and over constrained, you could technically have it be wrongly constrained. Like you could have an output just be wrong for some outputs which would uh maybe you could call that over constraint but I think it is technically >> kind of a nit.

>> Yeah. Yeah. Depending on the definition of over constraints. Yeah. Uh but yeah and yeah. Okay. Jako asks a point against there being much diverse. Okay. Yeah. We already answered that. And Motu asks, uh, "The 12-cond limit for the attacker assumes the pre-processing does not help. Uh, it would be risky to make this assumption unless you can provably show pre-processing does not help." Yeah, maybe a good research question. Yes, sorry, I didn't mean to like open a can of worms with this crazy idea of ephemeral proofs. But if someone wants to look into it, uh, then I'd be happy to to chat with you. Okay. Uh, let's move to part three, livveness.

Gigagas L1: Part 3 - Zero to One: Liveness (Justin)

So one of the um kind of concepts uh I guess is this notion of mandatory proofs. What is a mandatory proof is one which must be submitted with the current block otherwise the the block is just considered invalid and the attesters will not um uh attest uh attest for it. So yeah you basically we we need a fork for this where we change the fork choice rule and we need the validators to to all be opted in. And when you combine same slot proving with mandatory proofs then you get this this really strong form of livveness uh with a with a big asterics which I'll talk about. So what are the potential uh cases of livveness um that I've identified? So the first

one is that there's insufficient fees where there's just not enough transaction fees to incentivize someone to do the proof in this case you know the the entity that that is producing the block. And the good news here is that if you go to Eve proofs, you'll see that the the cost of proving is extremely extremely like quite a bit less than uh one um one cent per per mega gas. So a mega gas is a million gas that's you know on the order of you know 10 to 100 transactions or something like that like dozens of transactions and and we're talking about less than than one cent and this number should should go down. So so long as uh fees are willing to pay at least that then u we should

have uh livveness and um yeah one important thing to note is that if if there are transactions that are economically you know unsustainable then they should just be filtered out in the same way that they're filtered out today. It's just that the the barrier to entry to having transactions go on chain goes up a little bit because they need to pay for their own cost of proving. The other issue is is is is prover and and this is also kind of solved by these by these the combination of these two ideas. The reason is that I as the block producer have have no incentive to generate a prover killer because otherwise then I'm dossing myself

because I'm responsible for the proof otherwise my block is invalid. Um and so again what will happen is that you would you would filter the provers in the in the same way or very similarly to the way that you filter the transactions that don't pay sufficiently sufficient fees. um you know that requires a little bit of sophistication on the block builder side of things to identify what is a proof of killer. Uh but in general we we are assuming um at least in the context of fossil uh that the the builders are are are quite sophisticated. Another class of liveness failures which I mentioned is the the the prover crashes. So here um again like if if you if you pick a block

that causes your prover to crash then the worst case is basically just an empty slot uh which has no no block. It it doesn't cause um anything uh bad for for for anyone else. In contrast to the previous designs where the proof was for the the previous block block at uh at at slot n minus one and basically an evil proposer at n minus one could could propose a a prover killer or prover crasher um and um and basically force the the chain to stall. that because you have this this idea of same slot proving then these crashes actually uh can be filtered out uh in the same way and a

similar thing can be said about completeness bugs. Um so this is the over constrained class of bugs. Um and and you know these are are really really nasty because actually you would need all of the validators to upgrade. So for prover crashes, you know, you need to fix your prover and that's kind of one entity in some sense or a small number of entities that need to fix their provers. But completeness bugs are fundamental issues with the proof system where all of the validators need to update the notion of the the verifier. Um and uh the good news is that this doesn't really affect uh us uh except for this one big asterics which is around around fossil. So with fossil you

can basically have uh adversarial actors force include transactions that the builder didn't want to have included in that block and those can be prover killers and and and and transaction that pay insufficient fees. So all of the work that we're doing to harden the system including to have um you know a a a a diversity of ZKVMs is very important. And this is in my opinion like one of the big reasons why um we this is this is important very important for n to be greater than k because if n is equal to k and you you end up with um with a a completeness bug and you you can't move

forward then then then uh things things are are very bad especially in the context of of fossil. Now in order to have uh strong livveness on on the on the prover side of things we um we want to have um no reliance on the on the data center. So it's okay for for the sophisticated builders to use data centers if they want but it should always be possible for someone to do the proving on prem um you know on your own premises. And uh the constraints that we're using are very similar to those of of an electric

car. So you know millions of people have electric cars and um you know they cost about 100k and um the the home chargers will draw uh 10 about 10 kilowatt. Actually the Tesla home charger will will draw up to 11.5 kW. And the bottleneck is is most likely the right hand side here the power draw not the the price tag. Now there's some good news regarding uh power which is that on e proofs today on a 4090 a proof will take about uh 16 16 slots. So uh five slots is is 5 * 12 six 60 seconds. So 1 minute so that's 3

minutes and and 12 seconds for and it's actually going down. So, so this is kind of a Yeah. And if we have perfect parallelism, what we can do is basically flip these two numbers, put the 16 here and put the one here, and we should b basically be able to build systems that roughly speaking use 16 4090s uh and only take uh one one slot. And the good news is that with mort law this number 16 uh gets closer to something like 10 when you have 5090s and 10 1590s is something actually reasonable to have on on prem and and have some sort of a home cluster. So here there's a picture of someone with a home cluster with with

12 uh I believe 1490s and yeah this is something that I'm hoping to do uh this year basically to prove every single Ethereum block uh most of which 99% of which in real time and to do it uh from from my home. Now um one of the things that we need obviously is is is is GPU proving um to achieve real-time uh performance and succinct made this bit big announcement uh a few weeks ago but since then we've had multiple other teams so we had risk zero uh zisk and airbender and uh the amazing thing is that uh you know these uh these have uh open source

GPU provers and it's kind of a requirement for us to have open source GPU provers so that if something goes wrong, for example, if there's a prover crash, then it can be it can be it can be fixed. And so, uh, yeah, really looking forward to, um, to setting a standard where these, uh, these prover implementations are open source. Um, and, uh, yeah, it they don't necessarily have to be Apache and MIT licensed. You know, there's there's all sorts of of alternatives available from a licensing standpoint.

So here is the um the the requirements that have been outlined by Sophia in in her blog post that was published today. Um so yeah we're hoping to have these on-prem friendly requirements 100k 10 kilow uh latency less than 10 seconds for 99% of blocks. Um and uh yeah I've I've talked about most of these things. One thing which I guess is a little new is that the the cryptography team basically put a lot of pressure for this requirement and I think Jordi from this will be very very happy. So um there's right now the industry is is is is leaning towards 100 bits of of security

uh you know for practical reasons because the proofs are a little bit shorter and and the provers are a little bit faster. uh but um you know I guess in the context of Ethereum what we're hoping will happen is that you can have customiz customizable security and we would uh encourage 128 bits as as as as a northstar and and again ZISK has already achieved that in in production. And this is my my last slide for this section is basically this this idea that um it will take time for us to have all of the uh all all of the infrastructure in place uh to to reach the the the endgame. And basically I have this this four phases zero to three early adopters delayed proving mandatory proofs and

showing proofs. And the the the way that I see it is basically that um you one of the big advantages of delayed proving is that it's going to um sorry one of the advantages of mandatory proofs is that it's going to mean that the the prover is no longer altruistic right because the prover and the builder you know are the same entity they have to produce the proofs and it's rational for them to provide the proofs otherwise the the block is missed. So this is going to be a significant uh update. Um same with delayed proving is going to make attesting uh much more rational because in the early adopters phase which is basically crazy people like me

in 2025 moving to uh to Raspberry Pi Pico is that we're we're going to suffer a financial loss. And the financial loss is that because we have to wait for the proofs to arrive about one slot, we're not going to receive the timeliness reward for attestations. Uh but in my case, I'm only running one validator with 32 E. And the money that I'm saving from not having to buy a new hard drive and not having to spend so much on electricity is is worth the the loss of the the timeliness rewards. But still you know with delayed proving it becomes rational you know 99% of the time to uh to uh to attest uh as soon as the the the

proof has arrived and then I don't want to spend too much time on this but uh there's also this proposal to have native rollups um and uh you know these native rollups become better and better and better uh with with every every single phase in this gradual enshrinement and the the the endgame I guess the best case scenario is that we have these enshrined proofs and that we unlock native validiums in addition to native rollups and native optimums. Okay, I will pause here again in case there are any questions.

So, so Peter asks um with mandatory proofs there will be no additional incentive for proving existing fees and mev should cover the cost. Yes, exactly. So there's been some people out there, for example, Giorgios, who, you know, have been quite loud about using issuance to incentivize proving. I don't think it's necessary at all. Uh, and the reason is that we're talking about fractions of a cent. Um, you know, about 1% of of a scent to uh to prove a single transaction. So uh it it should not be uh necessary. And one thing we can do actually is kind of this this nice idea that instead of using a carrot of of additional in issuance, we can use a stick of slashing. So if you miss your slot as a sophisticated

uh execution proposer, you could lose one ETH for example. And one E is way way way way more than than the cost of proving. And so, um, basically, if you if you won the the auction to be the the prover and you you just didn't participate because you deem the cost of proving to be too high, well, you're going to be slashed something that is more than the cost of proving. Will it ever be possible for proving on a single slot to be possible on a single GPU? Um, probably no. And the reason is that as soon as the requirements and the proof systems improve that's an opportunity to increase the gas limit.

Um and uh basically we would we would keep increasing the gas limit and I think a single GPU would be difficult. What might be possible is a single ASIC. So there's various companies out there for example fabric and sciC and um ponos and various others that are um designing and manufacturing um snog proving as6 and it's possible that a single such rig uh could be sufficient for real-time proving that is at least the claim made by Michael Gao the the founder of of fabric um and then Sophia says it's much much cheaper even now to run a prover in the builder and Han asked why is this the

case? Um, so the sophisticated uh builders, there's only, you know, so many. There's mostly BeaverBuild and there's there's Titan. Like my understanding is that they pay an enormous amount of uh of cloud bills. You know, potentially, you know, like high five figures or even six figures per month of cloud bills. And uh it's uh yeah yeah yeah it should be you proving every single block in real time should be on the order of of thousands of dollars per per month of electricity costs not not tens of thousands or or hundreds of thousands.

Okay great. Um let's move to the the final part. Apologies for such a a a long presentation. Uh so once we have all of this uh ZK infrastructure like what is the plan to go to one one gig of gas um so the the rough uh goal is to to get three 3x per year. So this is Tomas the new um co-executive director of the Foundation. He's pushing internally for a 300 million gas limit by the end of 2026.

Gigagas L1: Part 4 - One to Gigagas (Justin)

And uh you know this is roughly a 3x per year schedule versus where we are uh right now. And uh um Dankrat has this EIP 7938 where he's basically suggesting that the default behavior of clients is to exponentially increase um by uh by roughly 3x per per per per year. And the the important word here is automatically whereby right now there's an enormous kind of social coordination cost to to increase the gas limit from 30 uh to 36 to 45 to 60 to 100. Um and it would be much much better if if it was just done

automatically. Of course at any time at any point in time any individual operator can override the default and opt out of this of voting for for an increase. But uh I think this is this is a great suggestion by by Dankrat um and I think we should we should put it in place eventually. Uh but what I'm saying is that we shouldn't stop after four years. There's actually an opportunity to extend the 3x per year by another two years and get to this um kind of meme number of of you know it's a meme backed by fundamentals uh a meme number of one gigas uh per second.

So uh this is the EAP that uh Dankrat has has written and the advantages are that it's it's a steady increase. There's no like big jumps that we have right now. So the the fee market will be a bit smoother. It's very predictable. So if you're a block uh sorry an application developer, you can know ahead of time that uh you know you can expect that there's going to be more capacity for your applications and you so you can you can plan ahead. It's ambitious. um something which uh Ethereum people uh and the Ethereum community love and it's very low touch for the operators right there isn't this this social cost that I was talking about now the the rough kind of handwavy

argument here is that uh we today we've reached we've essentially reached real time proving parity meaning that with the current gas limit the ZKVMs can catch up uh you know on a 10 kilowatt um budget you to the ZKVMs to mature a little bit and to grab the best ideas from each other, but in in in general, we're we're almost there. And what we've seen historically is that the ZKVMs will progress extremely fast on the order of 10x per year. And so a 3x per year is kind of relatively easy compared to um to to what has happened historically.

Now the the main bottleneck that we have here is power. So let's try and and and and build a little mental model for for the the power overhead and the opportunity to improve power. So as I mentioned we have ZISK that can do execution at 1.5 GHz. We have Airbender that can do proving at 15 megahertz. And so basically in order to keep up you're going to need 100 of these, right? Because 100* 15 MHz is 1.5 GHz. And um here each of these provers is a GPU uh which consumes about 400 watt and this is you know essentially the equivalent of a CPU that consumes 4

watt. And so the overhead is is 10,000x. Um and so that is in some sense the opportunity that we have uh to to to improve things. And what I expect will happen is that we're going to have software and hardware improvements each of which individually are going to lead to at least 10x. And so combined we're going to have at least uh 100x but we need more than 100x. And so one option is to have you know something like 30x here and 30x here. But um the good news is that we have a few aces in our pockets in case the the software and the hardware don't work out. So the the the two cars that we have in our pocket number one this idea of multi- premises.

So if each premise is is limited at 10K um what's that's fine because we can have multiple premises with collaborative um block proving and the other idea which is kind of longer term is that when we move to a ZK ISA underneath the EVM well effectively that is that is like a gas limit increase and and an efficiency improvement. Um and if you know if we were to enshrine something like risk 5 then we can have a very simple gas schedule which is one risk five cycle one gas and that would give us like very high alignment and and and and help address some of the the provers and and and and and current um you know issues that we have with the

the gas schedule. So overall, you know, I'm extremely optimistic that we can grow at least 3x per year uh with the with the ZKVMs over the next six years, which is a thousandx improvement. Um and again, I'm I'm hoping we have at least 100x from software and hardware, but we can be uh we can be more clever as well. Now, if the ZKVMs are no longer bottleneck, what is the bottleneck? Well, there's two types of nodes, right? There's the the weak nodes here that are unsophisticated validators, wallets and and includers and we have the sophisticated nodes, builders, explorers, RPCs and traditionally the primary bottleneck has been this because we were just so opinionated on you know validators running on Raspberry Pies for

example um that you know this infrastructure didn't feel the need to optimize but now things are are flipping and it's good because the solution here for to address the primary bottleneck is this crazy moon math uh snock engineering, but the we we've solved the moon math or at least it's a we're in a in a fantastic position. And so all that needs to be done right now is just traditional engineering just boring like database stuff, you know, stuff that that that's already been understood and and is totally uh solvable. So on the topic of databases we we have um basically off-the-shelf databases which are used for so for example GE uses label DV and ref uses u

MDBX and now we have just much better databases that are uh that have been uh built. So for example Coinbase has built uh Try DB which is custom to the Ethereum uh state tree and and so has layer zero with with QMDB. And basically the advantage is that they they scale much better. So if you look at level DB for example, it has a tree within the database. And so you're building a tree view in a tree and then you have these log squared um scaling factors that that so and so as the state grows you have this this unnecessary degradation of of performance.

And so we should be moving away from these LSM and B trees and instead um have have solutions that are much more performant. And these are some of the numbers that I have. So basically right now if you want to do a tree traversal it's 50 disk operations and this can be reduced to something like 4 48 uh operations. And another thing that happened is that there's been this cultural shift I guess within the the developers where uh you know they're looking at the the best case performance on on so-cal perf nets which are performance test nets and this is a screenshot where uh you know never mind reached a six gigas per second uh which is uh which is really really cool

and so now really what we're trying to do is look at what is possible in the best case and try and close the gap uh between the worst case and and and and and the best case and the gap between the two is on the order of 10,000x. So so yeah, there's a lot of juice to squeeze just with uh traditional engineering and um this is a number that I hadn't seen until very recently which is basically layer zero which is a very serious project is claiming they can do uh 1 million transactions uh per second and they're mercuralizing the the state every every block. um you know they're doing this with uh you know one CPU um and uh yeah it's a a big CPU with 96 cores uh but you

know still kind of um shows what is potentially doable and 1 million CPS is much much it's about 100 times more than than than one gig of gas. It's about 100 gig of gas. So, uh, it's not something that I would advocate for at L1, but it basically gives me at least confidence that, uh, we can have the the worst case be only 100x less than the the best Okay, final slide. Um, so here we are today 1.5 megs per second. We want to get to one gigas. At a minimum, we need to do two things. While off offchain we need to have real-time proving check mark. Onchain we need to have delayed

proving. This is something that Sophia and others are are working to push and um you know that is just the first step these uh these pink boxes but there's a lot more to be done uh on chain. So we need to uh have uh gas repricing. Uh we need to have uh multi-dimensional EIP1559 so that you know the state doesn't grow too fast. Basically there's a the separate limits for for state growth. Uh we need to put the L1 blocks and transactions in blobs. Uh because right now all of the validators have to naively download the blocks and that's not sustainable. We need to do data sampling on it. We could change the tree, the state tree to be much more ZK

friendly. And uh the the Airbender folks have done fantastic uh R&D there. And we also need to improve fossil uh well we need to ship fossil uh because if we have you know very high requirements on on the on the builders to build these big blocks. Well, we don't want to have um the includers uh require the same amount of hardware. the includ small amounts of of hardware for for for best-in-class censorship resistance. And then offchain, we need to do all of these improvements, right?

We need to have better sync, better DBs, as I talked about. We need to have history expiry. Uh there's actually been a a mini breakthrough recently where all of the execution layer clients now support expiring premerge um history. We need to have things like access list and at the peer-to-peer networking level, we need to do erasia coding. In in summary, there's a lot of work to do, but we know we have six six years to do this and um you know the the different foundation and and and and the ecosystem of consensus and execution like layer clients are firing on all cylinders. So uh yeah very generally very optimistic and that's it. Happy to take more questions and open up even further for

discussion. So um asks will it ever be possible? Oh no, Kev asks what does EVM compatible transaction mean? Uh I don't know the context. Maybe you could share which slide that was. Uh Dono asks Z uh LZ limitation. I don't know what LZ stands for here in my opinion is that >> uh it's layer zero. Oh yeah. If I have a paper >> lay your zero limitation here is in my opinion they didn't benchmark against adversarial transactions. Yes, of course they took the best case transfers uh given that they use some optimistic.

Yes, exactly. So yeah, we also need better benchmarks but you know they claim 1 million transactions in the best case scenario. I'm hoping that we can get to 10k transactions in in in the worst case. Um Han asks if we want to do tree change for example binary tree sometime in the future I'm not sure how effective these custommade Merkel petition tree databases since they have to be rebuilt the whole thing again. Aha great question. So um there's two things that we can do for the trees like one is we can change the hash function um for example to paid on and that doesn't change the database. is kind of a oneline change in some sense. Um, and

that could already be like a massive unlock. The second thing that we're, you know, considering what that we want to do, for example, is uh code chunking. So, it doesn't really affect like the whole tree. It just affects the leaves where and also just like when we have bite code. Um, that will be a massive change that uh that shouldn't dramatically change databases. Um and then a third thing that we're considering doing as you said is change the arity go from a hexary tree to a binary tree. Um and here there might be like significant changes but you know in some sense it's just one parameter change from 16 to two. And so I'm I'm hopeful that it's it's not too bad but you know this is the optimistic

researcher speaking not the engineer. But if it can be done with a hex tree it can also be done with a binary G. There's no fundamental uh reason why it can't be done. Uh we just need to avoid this log squared degradation. Daniel asks uh how is one gigas related to real world needs. Eg complete payment sector blah blah blah. Um so I have a bit of a slide here for that question. So the way that I I see it is that 1 gig of gas per second is just in some sense the the tip of the iceberg for what we need. Um 10,000 TPS is is nothing for the whole uh world. Like we need

something like 10 million transactions per second, one teragas per second. How do we achieve that? Well, L2 is horizontal scaling and this is necessary. there's no way that we can get uh the VM to uh to 10 million transactions per second in the worst case. And and so roughly speaking, my mental model is that each of these L2 would be roughly one gig of gas itself. And you know, there'd be about a thousand of them. And so a thousand times 1 gigas is a terra gas. And the L1 is basically used as the hub for like the highest value transactions. Um and in the context of L2s it would be for uh settlement for minting assets for handling deposits for handling bridging

for verifying proofs and and and and and things like that. Um so yeah there would be like some transactions that are not relevant to L2s. So for example, if you want to, you know, renew your your root ENS domain name on L1 or if you want to do a very large trade or or whatever, then then then you have the option to use the L1. But the vast majority of users, at least in my mental model, will be using L2s just because of throughput constraints.

there will be a thousand times more throughput on L2 and so therefore a thousand times more transactions on L2 and therefore you know one only one in a thousand transactions will happen on L1 for you know those who have the the use case to justify it okay um how about peer-to-peer ratio coding for the execution a yes exactly that's what I'm talking about great. Uh, that that's all of the questions. Uh, happy to open it up to the to the broader group if the if anyone

wants to to bring up any any point. If not, um, then we can just wrap it here. I see a few people uh clapping in as a reaction or you have a a point you'd like to bring up. >> Yeah, just a quick question. When talking about one teragas, are you still having this aspiration of going uh synchronously composable for here or is this async?

>> Yeah. Yeah, great question. So, um there's a lot of confusion around synchronous composability. Um by default everything is asynchronous. it only becomes a synchronous if there is a use case backing it. So if if you know for example you have a super transaction which cross which is over multiple L2s let's say these three L2s here um then what you would do is that you would buy a virtual lock over the very the tiny subset of state that's relevant to these three L2s and you you would basically execute your your synchronous transaction in in that context but it would be like a minuscule sub the the part that is synchronous This is a

minuscule subset of the overall state and so everything else can you know happen fully in parallel asynchronously non-blocking you know millions of of TPS and so it's basically you could call it dynamic synchronous composability where for every super transaction there's a different subset of the of the state uh that is uh that is locked. So we would need to design some sort of right logs for sharedly sequencing those and some sort of transaction limits that would allow for super transactions. All those things are kind of like research material.

>> No, it's it's not in practice. So so it it's it's kind of what the the the builders do do today. Um so um but they do it at at a different layer of abstraction. So they do it across um across smart contracts with bundles, right? So you have like three different smart contracts. There's an arbitrage across the three. You acquire virtual lock basically for this piece of state and you can still process all of the transactions like transfers and whatnot uh fully in parallel and and these are optimizations that are I believe are already implemented uh by the block builders and they need to do this because you know they require extremely low latency and things like that.

And again like this is just traditional engineering like there's nothing magical about synchronous composability. Uh we're not talking about crazy moon math Okay. Uh we've been at it for almost two hours. I'm going to close it here. Uh thank you so much to the 96 people who've made it uh this far. Congratulations and see you all for e proofs call number four. Thanks guys. Bye. >> Thank you. Bye-bye.