How to reach real time proving for Ethereum in 2025

Transcript

Almost there. Oh, that's my queue. Hey guys, my name is Elas. I'm one of the co-founders of at Kakarot and today we're going to talk about uh how to reach real time proving for Etherum in 2025. Um just a quick reminder the reason for realtime proving at least for Ethereum is mostly scaling uh scaling the L1 and it's um right in the road map of Ether want to to scale and become a ZKL1 and um real time proving just means being able to prove a Ethereum block in less than a slot time. So today that

means in less than 12 seconds maybe 10 and in the future because they're going to reduce the slot time to six and then three and then one second it means proving a lot of compute in less than one second. So this is a moving target and just a quick reminder the last talk was about ZKVM so maybe you're already aware but when you want to to prove in real time you need to do all these things. So you need to generate proof of inputs uh run the straits transition function generate the stark and um broadcast the proof. But today we're mostly going to focus on I think the state transition function.

Um so in May 2025 16 released that they have uh reached real-time proving and so we're done. That's it. It's it is reached. No actually I going on a tangent but um so let's take the vitalic requirements to be real time what you need is um real time worst case which means that uh succin did a amazing fit by proving I think 95 and today maybe 98 or 99% of blocks in real time but the 1% is the thing that matters most is because you cannot you should you can never slow down the consensus of of Ether and you should

always in 100% of cases be below the 10 seconds for proving it should be doable at home which means that you probably don't want a data center with thousands of GPUs uh mainly at least for Ethern for decentralization purposes you could also argue for uh money reasons because electricity might become increasingly more expensive especially if you compete with AI for data centers and you have to bear in mind that the gas limit on Ethereum today is quite and people want to go for giggas. So taking all of this into account um oops you have you have a you have a systemic problem which is that today you can prove 99% of block in real time and we want to divide the slot

time by five or six and we want to uh increase the guys by 100fold and today this takes 100 GPUs. So doing corner table math you end up having uh open AAI data center which is probably not uh desirable. The good the good part is that everyone is working to make those numbers better. Um, ZISK, I see Zisk before 6 in many people are working to um, speed everything up and among those people Zikasync did an announcement this week of uh, their new stack for proving airbender which allows them to prove I think they didn't try to prove Etherm in real time I think but they showed that they can prove it in fast time like 15 seconds or 30 seconds on one or a few GPUs which is very impressive. It's

we're talking 5x I think improvements in in two or three months compared to the latest state-of-the-art and I think today ZISK released that I just updated my slides so today Zisk and I don't want to spoil the Vina talk so I won't say too much but um they have also uh gone the further and u reached their real time proving in the 5% worst cases which is very cool and interesting. uh so everyone is trying to push forward with this. So the good news is no one is taking the current status of the I would call it status quo of having hundreds of GPUs as a end goal and everyone's trying to optimize.

Um but yeah so if we have this doable at home so everyone's trying to reduce the number of GPUs you still have the problem of real-time worst case which has not been solved and you still have the moving target of the slots time being soon at least in the beam chain 1 second and then the gas limit extremely high. So actually I presented this slide I think last year um in I think maybe Bangkok or maybe E Denver so beginning of the year and back then you could not fit an entire proof in the slot time and what's really nice is today you can so the trace generation uh step has been improved tremendously we went from I think risk zero had 100ish 150 MHz on a huge machine for trace generation and

this released 1 ghahz so we're talking for trace generation, we're talking 30% of a real GPU uh sorry, real CPU capabilities and I think that's that's pretty cool. Um so what about Kakarot? because I am at Kakarat and we've been building a ZKVM for the past two years and a half and our goal this year was to prove L1 is to prove L1 in real time and we do it by using Cairo and um Stew and so as we released our ZKVM so our full fully working Cairo L1 execution client so I would call it Klemon calls it a ZK native execution layer um we found that

there were some things things that we needed to address to reach real time and those are continuations uh like native speed VM and uh improve the trace generation speed. So yeah to prove large programs in real time we need we found out that it would be preferable to modify the ko ISA um for I think maybe I mean a few reasons the ones I mentioned so TLDDR it turns out that it's always better to optimize a stack for a specific purpose and kairo today is optimized for smart contracts it is not so much optimized for a systems programming language uh in which you would want arbitrarily long traces and um verify stress trace generation So today stocknet proves a block I mean

settles every few hours and when you want to be below 10 seconds or even below a second every single millisecond counts and memory count. So you need you have a different mindset. So that led us to kind of do a wish list Amazon wish list of all the things you would want for a ZKVM if you were to build one today with the learnings of the past four years which have been extremely rich in research. So you want fast trace generation. This was never a problem for ZK roll-ups. uh they didn't care that they could generate their witness very fast. But today, this is one of the main bottlenecks. And that's pretty cool that uh you guys went to uh the gigahertz. So, it's safe to say that if you're in the gigahertz land, it's no longer a problem. But it it takes some work to get there. So, the barrier is

pretty high. You need 30% of a real CPU capabilities to be real time and you need to push the the boundary faster recursion. So this means that you must be you must have a proof system that is able to verify itself and produce proofs of proofs extremely fast. We're talking below second uh even below 200 or maybe you guys are maybe 500 millcond. I forgot Jordy mentioned it in um the ETH poof talk. But what you need is to be able to recurse hundreds of chunks of blocks into one single proof in under a few seconds.

And you want so what we call a native speed. So this is um you want your VM to be in the same field as your prover. We don't have to go into the details for it. And in that side quest we found out that um you could optimize for constraint devices if you want to get twoin one which is um the local proving uh side quest. So just a quick quick um mention of the Fambushi ZKVM benchmark because they benchmarked all the ZKVM ZKVM sorry one thing that is really interesting I think in the mod modern VMs is the ability to completely break into modular chunks your prover what does that mean it means that before the design was uh one CPU

that you emulate with your prover and this CPU has a design like let's say risk Today what people are building is modular provers in which you can add as many op codes as you want at no cost for runtime. So it's really they call it alakart which is funny because we're in can uh in this French but um some other people called it peace meal as in pick what you want from any ISA and add it. Um you can see it as like an extension module where you can add as many things as you want. So we've been strong pushers of Kairo for three years. When we started actually Kairo was the only touring complete ZKVM that uh allowed anyone to write uh high level language code and generate proofs.

And when we started there was no other ZKVM that used uh general papa ZKVM. There were only secrets. So there was scroll using Halo 2. There was Elina who started and back then it was a novel idea to use a ZKVM. Today it's the go-to. And when I mentioned that uh we ran into some issues, we didn't stop there. We thought, okay, what if we can um take all those issues, make them into a bundle, and just create a new ZKVM that's inspired by Kairo, changes a few things, but keeps in mind this minimal aspect and optimize for proving and build this new stack. And that's a tweet

from Clemon. And it took us 22 calendar days to ship the V 0ero. And uh and we're very very bullish, very confident and quite surprised at the numbers. So we're extremely happy at what you can build actually with the new new types of prover that allow you to add as many op codes as you want as you see fit. So that's two for us. So the the learning is that you want a minimal and modular ISA. um you want actually minimal emphasis on DSL. Turns out you really want to compile from other languages and we want to our next step is to compile from both WASM and Noir.

Um that's the and and and then maybe risk 5. We're thinking about it. So if you want to run on mobile phone, turns out that you should not uh you should um have minimal memory consumption. So we're talking one or two GB. Uh today we can run a proof a fry stark proof on a mobile phone on my mobile phone for Fibonacci 100,000 with a memory spike at 1.3 GB which is okay should go lower um but we're able to prove it as fast as a succin GPU which is very encouraging and you want extremely high prover frequency on consumer laptop and that's very much aligned with the beam chain uh initiative. So we were at

the beam chain day yesterday and the the goal is that every single proof should run on consumer laptop grade. So this is very much aligned with the KOM project. So KOM M actually the the meme is that we don't I mean everyone has a different reason for why it's called M. I was talking to some people yesterday and they called it KO Max. Found it fun. KMO I think calls it KO mobile or call it sometimes KO minimal. But what we're targeting is 10 mehz on mobile, optimal recursion, and continuations from the start. This is kind of the the ultimate wish list that you want if you want to even be able to you could prove maybe a Etherum block on a mobile phone in real time by end of year.

Demo time. So actually time does not permit but uh so we shipped we thought it would be fun to take um the FBushi benchmark um which is Fibonacci SHA and then Ethernet blocks and just take the Fibonacci part and run Fibonacci 100,000 death on phone and see where it goes. And for now we have very encouraging results that are aligned with the GPU benchmarks. So turns out you can just do things and um I'm taking the the end of slide because when I when I wanted to do the talk I wanted to present uh our real-time proving engine um and for Ether blocks. Now that um we've we've taken this side quest of building

a new ZQVM with the help of Starware. Uh I'd like to shout out all the people who have already implemented kind of the state-of-the-art things that you would want in a modern ZKVM. So you want um what we called alakart or pismill prover. So you want zero runtime overhead for adding as many pre-ompiles or up codes as you want. This allows people like open VM to have the risk 5 instruction set and add any instruction set that they want on top of it and mix and match as many languages as they want. Yeah, you want high level compilation. So risk zero on that were very visionaries. Um because you the the upside of being able to compile rust to your prover is is enormous. And it turns out that the c the price you pay is

sometimes okay. So we're thinking whether you can actually compile just rust to kom and we're investigating this with our team continuations. I guess rezero and succent were also visionaries on this. Um it's in a sense it's weird and in crypto we accept it because we have to work around systems that are not ready but it's weird that when you write a program you should bear in mind that at some point it will stop to run. So one example is noir. So who here is familiar with noir. So in noir there's like um there's a sweet spot in number of gates where above this sweet spot the app will just crash on the phone. So I was told this by Zika passport. So when you write your

noir you have to compile it and ask the bantenburg back end how many gates your program is taking and if it's above two to the^ 20 you have to applicatively split your programs into multiple programs and recurse it but it is not taken uh it is not taken care of by the VM you have to as a dev think okay my program will not fit anymore in a mobile phone for proving I have to split it and I think that this applicative break can be interesting in some cases where you're really trying to optimize but for normal devs it's it's not desirable. So lightning lightning fast recursion turns out it's probably the most important thing that is the flip side of continuations. If you have continuations that means that for a single Ethereum block you might have 100 subproofs that

are little proofs of little parts of the block. And what you want is extremely fast bundle them into a single proof. And if you have 10 seconds but soon you're going to have 1 second. You need this to be extremely fast. And in some sense this is okay to be written as a circuit. So when we try to do this trade-off uh should I use a rust or should I use circuits this is one of the instances where you probably should use circuits. So f small field mastery I know this is a this is um this is a I don't know tribal subject. We're trying to find tribalism everywhere we can say is the choose the the choice of your prime number. Uh we chose N31. I mean two is over N31 for circle stock. I know some other people at the EF have chosen Kola

Bear for their research. To be fair, I'm not experienced enough to know the real difference. Uh I am told that M31 gives you a 30% in like bump in performance over any second best. Whether that has been verified for Ether blocks uh remains um to be proven, but I think it's at the end of the day, you want a prime that is around 32 bits. uh GPU acceleration. Um I am not an expert but seeing every day that people are rewriting their provers in GPU is is encouraging especially for the scaling part of proving uh as opposed to the privacy because in some sense when you're a user and you want to keep privacy preserving apps you do not want to send a bundle to be proven to a data

center you want to prove locally on your machine and I think this is also why we're building Kom but for all things uh Ethereum proving if you can send your proof to one or two GPUs maybe five at most not 1,00 That's okay and that's pretty it makes sense that people are using GPUs and then advanced research. These are the moonshots. So client side proving for us I we think that it's one of the most uh disruptive things that we can have as a community in ZK. Uh that's the next frontier in our opinion because once you can do client side proving you can add privacy on top of your proving uh stack and you can prove any statements that lies on your on your computer. So we're talking ZKYC.

Um you you really reduce the intrus like the cost of GDPR because you no longer need trusted intermediate to hold your data. You can hold it in your data wallet and produce proofs of it. And weirdly this is also what big fangs are doing as Google just announced that their wallet is going to use I think some derivative of liatron for proving statements of your things that reside in your Google account. Um, in that sense, you won't need to send your entire bank statement to, I don't know, a home owner if you want to to go to their place. And you, we're I think the way I put it is we finally respect the concept of lift privilege in real life, which I think is pretty cool, especially in a world where there's going to be tons of agents

everywhere. Uh, memory optimization. We can take one minute in this and I'm almost done. Uh it's fun because ko started as a write only sorry read only nondeterministic memory and the risk five people started as v right I know this is bit technical but funnily enough ko m is now read write memory and I was talking to the powder labs people and they're moving towards uh write once me read only memory so there's this is still an open debate on whether uh which one is more optimized for approver and people are actually excited on new polomial commitment schemes I think this is the the type of research that is extremely extremely important for Starks. Um one the most important aspect is that today's starks are the proofs

that have the biggest um size over the network. So there we're talking few MBs and this is really bad. So people countered it by wrapping starks into gross 16 proofs that are very small so that they can prove them put them on chain. But tomorrow if first of all you want to be postquantum secure which cross 16 is not and uh you want to broadcast proofs extremely fast over the network you would want to get starks to the KB uh line and this is done by investigating new PCSS. So I think I think this is a very interesting war is one of them and I think it would be very cool to implement war ons and that concludes my talk. Thank you very much and expect us to have more news over KRM in the coming months.

We have a booth uh in this floor so you can come by and test the Fibonacci 100,000 on a mobile phone. [Music]