Lightning Talk: SP1 and Subblocks: Low Latency Ethereum Block Proving by Yuwen Zhang, Succinct

Transcript

Okay. Uh, Yuan Jang from Succinct is going to be speaking about low latency Ethereum block proving SP1 and subblocks. Welcome to the stage, Yuan. Hello. Everyone hear me? Great. Um, yeah, my name's Euan. I'm here today to talk to you about uh real time proving via subblocks. In particular, you might have heard earlier on the panel a lot of teams were talking about how execution was a bottleneck for low latency proving. And I want to give some more context into that, some other strategies you can do to mitigate that. In particular, the subblock strategy.

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

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

system responsible for generating this intermediate representation is called the executor. And what they do and the intermediate algebraic representation I was talking about we call these traces and traces can be super super big for an entire Ethereum execution. The total amount of traces will be hundreds of gigabytes. So what we do we break the traces up into small pieces. We can prove all the pieces individually using some GPU accelerated prover and we can aggregate them together using recursive snark verification into a single constant size proof.

Now let's think about this from a low latency point of view. So before you can do anything else in generating your proof, you have to generate the first trace. And while you're doing that there's you you cannot utilize any of your proving technology whatsoever. after you generate the first trace well then you can start proving it but you can't again you can't do anything else until you generate the second trace and so on and so on basically the point I want to make here is that your parallelism is limited by how many traces you can generate at a time and in other words the endto-end latency of your execution the endto-end latency of

your entire proof is at least as long as the time it takes to generate all the traces So you can see in this naive approach here, it takes so long to prove it doesn't even fit on my slide. Uh so yes, the basically the most naive uh but effective approach for generating traces quickly is to optimize the out of your executor, which is exactly what we did. Um we took inspiration from the great engineers at CISK who pioneered this sort of raw assembly approach. Uh we improved our executor in from 50 megahertz in May, 50 million risk five cycles per second in May up to 150 million risk five cycles today for our

real-time proving demo. Um but and it actually works very well for the 45 million gas limit. But will this scale very well into the future? Moore's law says no because uh if you want to run a single threaded executor, your speed of light is the e the native performance of your actual hardware's single threaded uh CPU. And that hasn't really gotten any better since 2005. So if we really want to scale Ethereum to a gigas regime, we need to exploit some kind of parallelism. The most like correct uh future proof way of doing this would be incorporate some kind of

native parallelism into your into your ZKVM. So that would look something like support for a fork sys call or pthread create sys call and this is a great idea but it's not so simple to implement. First having a nondeterministic executor can kind of mess with different zkms memory arguments. uh in in other words like proving consistency between uh different risk five cycles. And in another problem you might have is that now your execution client has to reason about transactions data dependencies which is quite tricky and and you need to get it perfectly

perfectly correct in order for your proof to be valid. So subblocks are kind of a middle ground. They are quite simple to implement. uh but they exploit a lot of parallelism. So they're very well suited for the gig gas regime. And the high level idea is quite simple. You just take your block and you split it up into multiple subblocks of different like consecutive transactions. And how do you resolve this transaction data dependency problem I just mentioned? Outside the ZKVM, you can have the host hint the output commitment of the first sublock into output state commitment of the first subblock into the input of the second sublock. And you

can connect these sublocks in this way. And when you compress all of the individual subblock proofs together into a single constant size proof, you can verify that these hints were in fact consistent. Now just to drive the point home on how sublocks create uh super great like parallelism, you have three executors running at the exact same time. So with after you generate three traces at once, you can have three provers going at the same time generating proofs. And also note that each subblock is going to be shorter than your original Ethereum block proof. So you're not only do you generate more traces at the same time getting more uh getting more utilization

your execution portion of your computation also is much shorter. So using subblocks we were able to achieve 94% of mainet blocks proven in May 2025. Um, this approach has also received some great adoption from other teams such as Brevis who use it today for their zero knowledge for their real-time proving demo. And we estimate that if using this technique with our current executor technology, we can bring the serial bottleneck of our computation down from 4 to 6 seconds all the way to 1 to two.

So this is a really important um latency saving technique that we expect to incorporate well into the future. Um, yes, that's my talk. If you have any questions, please ask. Thanks, Yan. Yeah, we have a couple of questions here. So, in order of popularity, uh, have you considered using block access lists, uh, which will be shipped in Glamsterdam to inform your subblock trace generation?

Um we have in the past and in fact getting the correct uh like abstraction the correct communication between the host client executor and getting the right inputs in the ZKVM we think is like a super important like uh future direction. Um so yes it is being considered but no not in the short term because our really fast executor is doing a great job. >> Yeah. >> Great. Uh, next question. Do the sublock subblock access lists also contain Merkel tree nodes? Um, let me go back to my slide.

So, yes, basic basically you're asking like what is the composition of like the storage A storage B and yes they are like miracle tree commitments um of of the touch state within each sublock. I do want this is a great point to mention that these this merkelization step actually does add a lot of overhead for the subblock technique because like you're sort of merkelizing the same stuff in every pre-flight and the same the same stuff in every validation but yeah at a high level that's kind of what's going on.

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

>> Excellent. Thank you so much. >> Thank you,