L1 zkEVM Breakout #7

Transcript

Ignacio Hagiopan: Can you hear me?

Ruben: Hello. Yeah. Cool, do you?

Ignacio Hagiopan: How are you doing?

Ruben: Good, good. You?

Ignacio Hagiopan: Oh, fine, fine, fine.

Ruben: Are you based in Montevideo?

Ignacio Hagiopan: Yes.

Ruben: Quite far from me.

Ignacio Hagiopan: Where are you at?

Ruben: Or so.

Ignacio Hagiopan: Oh, wow, yeah. How do you know that I was in Montevideo? I don't know if I have this in somewhere, my profile somewhere.

Ruben: I don't know, probably I checked somewhere.

Ignacio Hagiopan: Yeah.

Ruben: Maybe on LinkedIn, I don't know, because I was actually considering some relocation, like in Buenos Aires or Montevideo.

Ignacio Hagiopan: Already.

Ruben: Yeah. I hope it's nice.

Ignacio Hagiopan: I think so, yeah. I don't like much the weather, to be honest. Really? It's too windy in winter, I don't like that part, but it's… Yeah, it is fine. Yeah. Yeah, yeah.

Ruben: Because in Warsaw, it's not sunny.

Ignacio Hagiopan: Yeah, I mean, in winter, it's okay, pretty cloudy, somewhat rainy, but… I think, I think it's fine. The only thing that I…

Ruben: No stone?

Ignacio Hagiopan: No snow, no.

Ruben: Wow. Good.

Ignacio Hagiopan: That helps, I guess. Definitely. Okay, let's wait for some 1 or 2 minutes for people to join, and then we can start.

Okay, I will share my screen. Give me a second… Hopefully, you can see my screen. No?

Gary Schulte: Yes, we just emoted. Yep, we can see it.

Ignacio Hagiopan: Okay, cool. Okay, well, welcome everybody. This is, L1 zkVM breakout call number 7, where we share the updates of July 2026. The agenda for today is pretty simple, just some intro and doing some project updates and Q&As. That might suffers from it. The first thing I want to highlight is that after many weeks of work from Francesco. And a bit of, me and Jochem as a reviewer. We have a refreshed… version of EIP 8025. The previous materialized EIP was pretty dynamic in a way, and was missing a lot of details. So, we are really happy to have some, much more complete, specification for this EIP that we pretend to CFI for Hegota. So, please take a look if you want to know more details about it. Now should be…

Much more complete. On a kind of tangent, yesterday, we also merged an update on EIP7709. Which, as a TLDR, is, basically asking for BlockHash to be resolved using EIP 2935 system contract. This is mainly simplifying the stateless input for the guest program. Not requiring this headers fill, for the last 256 parent headers. Or up to 256. So, if guest programs and stateful ELs can simply resolve block hash by doing an SLOAD of the system contract. A lot of things get simpler. Also, yesterday, I did some UX impact analysis around this, because this means that Buga should be reprised.

Because now it means it's doing an SLOAD. In this HackMD document link that I put below. you can see a bit of the impact, which I don't think is that big, but at least we know which projects to ping if we want to understand better if it is… this is a problem for them, or if they have hard-coated gas, or things like that. So, yeah, if you are interested in these details, you can look at the document. In the document, we also have in the execution specs PR, with, the spec changes and extra tests. So, this EIP is pretty much ready for… for CFI requirements, and we'll see what happens. Okay, so coming back to project number… to zkVM projects, the updates for project number 1 and 2, which are execution windows, I guess program, spec, and tests.

Last month, we had 3 releases, which are… B06… 0, 1, and 2. All of them are based on Glamsterdam 7, which has been running for a while. I won't go into much details about what we did here, because pretty… I think most people already know, but… We have been removing some stuff from the chain config, with simplifies things. These releases also fixes some other stuff to be able to fill benchmarks using external ELs, in particular guests, so we can also fill the, East… benchmark fixtures. In these releases, in this, Glamsterdam and DevNet 7 release, we cannot really feel all the benchmarks. For some other reasons, but most of them can already be filled.

And we did some other bug fixes regarding EIP8282. That we're missing, in some early releases for… for Glamsterdam DevD7. What's coming up soon, it's more interesting changes, more simplifications on the chain config side of the story for the guest program. Mainly we are, including the schema ID as part of public input. We are completely removing the chain config part. And simply leaving the CHAINID field. We are using now Progressive SSZ for the state code and public keys. This is a big simplification, you not really have to justify maximum length on many SSZ lists, depending on the gas limit. I've done some tentative, experiments, and now I think we can fill all the benchmarks using S.

for guest programs, which is great. And yeah, the main goal is that probably today or tomorrow, I will cut a new release. V070, which is going to be supporting Glamsterdam DevNet 8. Which is not yet launched. So maybe I will wait a bit more, but everything is pretty much ready to do that. So, that's pretty nice. Regarding Glamsterdam devnet 7, as we did with the Glamsterdam DevDev5, we have this R2 bucket. Where we publish, stateless input for the net blocks. This R2 bucket has been working… Much better than the previous one, because we have made some improvements. And here you have a lot of… more than 50K DevNet blocks. to running your CI as a guest program, and yeah, this is really helpful to keep measuring things and trying things out.

Also, I'm happy to show this Hive UI dashboard that we have been working on. On the previous call, I showed the dashboard with less boxes. Now we have, like, two main groups. We have the Consume EngineWitness. Which are basically stateful ELs. Running, execution witness construction fixtures compliance. And now we have Besu, ethrex, GetH, Nethermind, and Nimbus. running these, fixtures and showing a bit, failures and things like that. We are not really diving into the failures yet. We wanted just to have the correct, wiring to put everything together into a single dashboard. I want to thank, FLCL and Rubo and Demi for some last-minute changes in their codebases to be included in this dashboard.

Which was mainly supporting Engine new payload with witness, APIs. And on the bottom group, which is stateless validators, we have combinations of guest programs and zkVMs running the fixtures for guest programs that we have in East. So basically, in the same dashboard, we have what is called, kind of, the correctness, runs, of tests. So, hopefully, we can keep adding more stuff here, and at some point we can dive more into the failures, and this can provide a quick feedback loop to keep improving things. Probably won't… it will make sense to do this whenever the last DevNet for Glamsterdam arrives, which is hopefully number 8. And after that gets settled, we can start looking in more details about failures, because maybe some failures are because of guest programs.

Or… or the specs, even. So… but we can look at this later on. Also, get some insight about… Why some things are failing in one combination and not the others, and things like that. We are also happy to say that we have published a document. Sorry, I put here the wrong link. This should say guest handbook. In any case, both are in the same folder. So, the guest program handbook is basically a document… it's kind of a landing page document for guest program teams. To understand what we are expecting for them, to get a bit of our attention for all the work that we are doing regarding… Running the tests, running the benchmarks, been included in dashboards, and…

Considerations that we think are important regarding licensing and things like that. We have already shared this with many of you, but we wanted to just Be more clear, public about How we are thinking about this, so you can read this in more detail later if you want. The most, well, everything is important, but one of the important parts is that we want to push a bit more, some guest programs to, publish the ELF themselves, so they can fully sign, define an ELF for different zkVMs. So we stopped doing this in our guests. This was already the case for CESU, so if Rex and Reth, I know they are both working on doing this too, another mind too, so, we can give, like, full ownership of ELF generation.

to each guest program team. And of course, area guests and Aria will provide scripts and tooling to simplify your life into Going through this process. But, yeah, we just want to put things in the right place and not really say that, you know, some areas repo will be responsible for compiling stuff that will be running. in mainnet, Okay, so regarding project number 6, I will provide some updates, because Han has been working on some other stuff, so he will also talk about this later. The only thing to say here is that we have been simplifying a lot our tooling, I think that's the main… summary of it. So, in zkVM benchmark workload, we have now a single fixture format for running everything, being tests, benchmarks, or DevNet blocks, or mainnet blocks.

Everything uses East Fixtures format. We thought this was useful to simplify a lot of stuff. In all the tooling, So that's pretty nice. We have made some improvements in the R2 bucket collector that generate this, this thing that you see here, so it's a bit much more reliant, and it also uses EAST fixture formats, so guest programs don't have to support, like, some custom new format. We have been also trying to add more metadata into the results of the, runs. In particular, the opCode count and target opcode. for the East benchmark fixtures, the logic here is that we can… Use the results of these runs. Into the EVM gas feed.

tool that Maria has worked on for Glamsterdam repricings. So, we can use exactly the same regression models, to come up with potential repricings for zkVMs in the future. So we are trying to have some kind of smooth integration into existing, work that has been done, so we don't have to reinvent the wheel for things. And in AeroGuest, as I mentioned before, we are trying to keep leveraging simplifying stuff. Supporting single unified fixture formats, moving area more into being an ELF hub, pulling releases from Official guest program repositories. and having a stronger, CI that runs a lot of different fixtures, like EAST fixtures, DevNet fixtures, sorry, DevNet blocks and mainnet blocks. For the elves that we pulled from somewhere else, because now that we are starting to pull elves, we have much visibility on what's going on, so…

we encourage teams to have their own CI, to test their guest programs, but… Airgest will still have, like, a last line of… checking on, on, on the ELF that is importing. And as a last slide, I just wanted to republish, or just raise awareness about this blog post about OpenVM 2.1 preview. They have been doing great work on, moving closer to the zkVM standards that we expect. They have a pretty, impressive, performance improvements, and they have been doing a lot of… exceptional work on the RISC-V emulation part, so… Yeah, just wanted to share a bit here the link, for people to take a look if they… if you are interested. And that's pretty much it from my side. I know if there's any question.

If not, we can move for the next project. I will share the link to the slides in a minute in the chat. Okay, if there's no other question, Marcin, maybe you want to go next. We can't see your slides, but… I'm not hearing you. I'm not sure if I'm the only one.

Gary Schulte: Same.

Marcin Bugaj: Okay, can you see my slides and can you hear my voice?

Ignacio Hagiopan: Yeah. Yes. Yeah.

Marcin Bugaj: Okay, great. So, hi. A short update on Project 3, which is zkVM guest API standardization. Today it's a recap, one new proposal. And a handover. We have now 10 accepted standards. They cover the ISA, input and output, crypto accelerators, termination, memory layout. The safety traps, the static library, and two standards accepted since the last call. ELF loading and validation, and accelerated memory operations. One standard is open for your review. That is the one in amber. Four standards are on hold and are not mentioned on this, on this board. I can come back to them, later.

The new one is proving cost estimation. Proving is slow, far too slow to run, after every change in the client program. But the emulator already visits every instruction. So it can add up the work the prover would have to do. And the result could be a single number, we call it C. And the expectation is that, proving time is linear to C, as reported by the emulator. When C goes down, proving gets faster, and that holds on any hardware, CPU, or GPU, because C measures work rather than time. The second feature of that standard is cost scopes, which narrow the measurement to one region of a program. So the cost of that region can be read on its own.

Yeah, and some people raised a concern that there must be a linear relationship between this number, C, and the proving time, so I think that it It can be semi-linear in the sense that it approximately has to be linear for the practical purposes of judging whether a change improved the approving time, or improved the performance, or the performance deteriorated as a result of… Changes in the code. So please review the standard. It's quite a massive one, and requires a lot of work from the KVMs, so yeah. Yeah, and the fourth slide is Hanover. I'm leaving the ethereum Foundation at the end of the month, and ownership of the standards, goes to cody. My personal email is on the slide, please feel free to reach out.

Yep. And the next, thing is, Standard, which is in the draft mode, minimum memory resources. it sets a floor on how much stack and heap a zkVM must give to the guest. Without those numbers, a guest that runs on one ZKVM can run out of memory on another. The standard is blocked on one thing. Nobody has profiled a demanding guest against a large mainnet block, so the numbers are still blank. I've heard that Han performed some benchmarks, so maybe we would be able to fill in The missing numbers soon. U256 acceleration. In April, I benchmarked this on zk and saw little or no advantage.

But a few weeks ago, ZSK provided its own benchmarks with a malmod opcode acceleration, and that gave about 40% better proving on some blocks. And those two results don't contradict each other, We need, basically, to do more measurements. The acceleration has to be compared against a really well-optimized software implementation, and over a large number of blocks. So, the Ethereum Foundation should rerun the benchmarks across a few hundred blocks. Until then, we don't know whether the standard is valid or should be discarded. Logging function. It's a small one. Every kVM has logging, but its own interface for it. The standard introduces a common prototype for a logging function, which is, basically a calling convention function for, for logging purposes.

catch-up. We already accelerate the whole catch-ac function. This proposal asks for the Kak permutation, which is finer granularity than, just the CHAK function that takes a buffer and Computes a hash of it. Francesco had ideas for using, online hashing in the state transition function, which is what would need it. Whether that finer granularity is really needed is still an open question. And last, a direction. So, ethereum guests should be built with stock unmodified compiler. That's basically a reminder, because that slide already appeared on the previous presentation. Patched compiler, grows the trusted computing base, and even a small patch Puts all the emitted code in question. Yeah, so that's all from my side. Any questions?

Ignacio Hagiopan: I don't think there's any question. Gary had some questions, but I think it was already answered by me. Right, right, right. So…

Cody Gunton: I mean, I… I would… Yes, Colin? Can you hear me? Yeah, yeah. I would just add that, actually, even asymptotic linearity of the provers for, like, a growing guest is not, true in general. We have, like, n log n asymptotics for.

Marcin Bugaj: parts of…

Cody Gunton: So, yeah, without, without continuations, yeah, I still see value, and I… I think with modifications, the proposal, is reasonable, but I just wanted to say that.

Ignacio Hagiopan: Cool. Thanks, Marcin. We will… Miss you a lot in the team, And you have been doing amazing work, and just also wanted to say that in the call.

Marcin Bugaj: Yeah, thank you very much. I will miss you too.

Ignacio Hagiopan: Okay, so let's move forward with project number 4. Is Francesco here?

Francesco Risitano: Yep, I'm here. Could I steal the screen, please?

Ignacio Hagiopan: I think that Marcin needs to stop sharing first.

Marcin Bugaj: Right, right, right, I don't know how to stop because the button disappeared. I just exit.

Francesco Risitano: Cool, thank you very much. Okay, can you guys see my screen?

Ignacio Hagiopan: Yes.

Francesco Risitano: Okay, cool. So… yeah, I've essentially… studied work on defining, the recursive guest client. And the core premise of this idea is essentially to, It's to reduce the, reduce the need to, to essentially sync a sequence of execution payloads, for each block. And instead, you can just sync an execution payload Sorry, an execution proof for the head block, and that will attest to the validity of the head and, the chain prefix going back to some origin. So, in practice, the origin is trusted, so to speak. But, you know, ultimately, we will essentially use the same arguments that the consensus layer currently uses of having this weak subjectivity checkpoint.

So, maybe I can just dive into the specs. Can you see the… Yes, you can see the specs. Okay, I'm just gonna, dive into some of the changes that have been made. So first of all is the introduction of this execution-proof claim. This was previously referred to as the public input. But I've, I've slightly changed the name, maybe this will change again, but, ultimately, this, this is composed of, two, two fields. The origin, which is this execution checkpoint. Composed of a slot and a block route. So we have the origin, and then we have the head. So the origin is the trust base, so to speak, so this will be the weak subjectivity checkpoint, and the head is, the head of the chain that this,

this proof attests to. And, as I say, the kind of… the claim, the validity claim is… is recursive, so it attests to the validity of the, of the full chain from the origin to the… to the head. Other than that, there's no changes on the… on the Beacon chain, Types. But, what's very nice here is that we can essentially remove a bunch of the P2P stuff, so, there's, essentially no requirement for a request-response protocol, which is typically the more fiddly, And, complex side of things, because if you miss… if you miss an execution proof, then you can just wait till the next slot, for the next proof to be gossiped, and you know, ultimately, that's gonna… that's gonna attest to the prior slot, if you've missed it. So, it makes the… the protocol much, much simpler, and,

Yeah, just, simplification, ultimately. In regards to the, to the guest program, maybe I can just give a high-level overview. of, of what we have. So, the guest public input is, essentially just the execution-proof claim plus the chain config route, I suppose, with the changes that, were just presented, this will become the chain ID. We don't gossip that because it's static and can be populated by the, by the client itself. We have the block bid witness, so this is essentially the, the, This essentially kind of commits to a specific execution payload in the beacon block. We have a Beacon state witness, so this, is essentially just a witness that we need to authenticate the different, the different data, data types, that we have on the Beacon chain side of things.

Specifically for the state, and then we have, the Beacon chain witness, so we have a Beacon state witness for each slot, and then, yeah, the Beacon chain witness is essentially an aggregate over that. So… yeah, the guest essentially borrows a lot of types from the execution specs. It's… you can consider it just like an aggregate over the, an aggregator over the, execution specs, stateless, stateless verifier. So, yeah, we have methods for, verifying the execution proof, which is, you know, the prior proof that we want to recurse, and also for verifying the stateless new payload. So we don't comprehensively define them here and just inherit those definitions from the execution specs. I don't think we need to dive into the details of the logic.

But, yeah, on a high level, that's kind of the idea. I've… I've, yeah, I've implement… I've implemented most of that in the specs. Probably still needs to, have a few iterations and refinements, and I've got, an initial implementation in, array guests for ethrex and Reth, but, CI is not green. I've introduced most of the, the kind of required data types. As I said, that's subject to change. Yeah, that's all from me.

Ignacio Hagiopan: Cool, thanks, Francesco. I don't know if there's any question about this? Okay? Yeah, I mean, we will keep iterating on this idea, because it will simplify a lot of things in DCL. We just need to understand a bit better, like, the changes that we have to do in other parts, but… This is a line of the… A line of work that probably will happen eventually, so we're starting to explore it early as possible. Next project is Ruben Infrastructure. It's found here.

Han Jian: Hello, can you see my screens?

Ignacio Hagiopan: Yes.

Han Jian: Cool. So, I will keep my update to prover infrastructure. So we have done benchmark on OpenVM VP 2.1, with mainnet and EST blocks, and the result can be found in the link here. And the nice thing is that we can reproduce similar number on… reported on east proofs, which is the 2.4 second mean proofing time, for the same 1,000 blocks. And as Ignacio said, we integrate the EVM benchmark workflow matrix into EVM Gasfit, meaning that the matrix now are standalone and containing all of the metadata that can be consumed by the EVM gas fleet directly. And also, we implemented the prover as a target client for the benchmark. Benchmarker. The idea is that, we can use Prover to act as, like, a new execution layer, but actually it…

forwards the request to the proving cluster. So, the flow… the usage flow will be, like. The user will use Prover to… Deploy or destroy the distributed prover cluster? And then use the usual way to run the benchmarker. And when benchmarker… when rounding the benchmarker, we will config the client to be the approver, and it will forward all of the requests to the actual cluster, and then Benchmarker will do what it usually does to collect the result. And in the end, we can generate the UI from the resource and publish to GitHub page. And now it supports OpenVM and disk. And the nice thing to reuse the framework is that, Benchmarker already has a very nice UI, to display the… all of the matrix that the test suites, have.

So we can see, which test case is the slowest, and which one is okay once. And for individual tests, we can also see all of the metadata and metrics here. Which is very nice. And next is, I'll try to improve the prover and do more benchmarks for all of the gas that we have so far. And also, we'll try to integrate the cost estimator into Array, and create a dashboard for guest performance tracking. And which the value can be used to do correlation analysis with the actual proving time we got from the cluster. And if the correlation is strong, we might get more confidence that we can use the estimator to do the guest optimization.

matrix. And that's it from my side.

Ignacio Hagiopan: Thanks, Han. This is amazing. The integration with Benchmark for… This is going to be an awesome, thing to announce more broadly at some point, whenever it's more mature. But all this orchestration, for running benchmarks with the proving cluster is… It's really, really, really nice. You know, if there's any question for Han, and if not, we can switch to… security project with cody, whenever you're ready.

Cody Gunton: Hey, sorry to ask this, but I am having some kind of sharing permissions issue I haven't had before. Could you share… I just put the link and just advance for me, please.

Ignacio Hagiopan: Yeah, I can share it for you. Larry, give me a second…

Cody Gunton: I don't know what. This is a new… Okay. Okay, yeah. Thanks. So, yeah, next slide, please. Yes, right. So, as you've heard, there's a new OpenVM 2.1 preview out, so I added that to the compliance testing dashboard and ran the tests and saw that it is fully compliant, which is great. I also added, proving support for SP1, and, it has… I didn't upgrade the version, but we can see every test that passes execution also passes proving and verification for SP1, and there are some gaps, primarily the, ZIC CLSM part of it. And I also upgraded zk to the 1.0.0 alpha, and there is a single gap, which should be patched in the next release. So, next slide, please.

Yeah, so, we made a grant to, Stefanos, Martin, and Varun to make a, RISC-V fuzzer, and, that has been released. For use by the public, it found a good number of bugs, which were reported, and And are either in the process of being patched or were already patched. Some of the main contributions are a nice seed corpus, some, two different, program generation pads. And, yeah, a fuzzer that covers several… sorry, covers several different zkVM provers, including GPU proving. And, I can recommend this blog post, shared here as a very nice overview of that. And then here are the links to the, Repositories, if you'd like to use this. Next slide, please.

As Ignacio mentioned, we publish these handbooks, which are a first draft of our, framework for evaluating zkVMs and guests, there's one handbook for each category. For recommendation for use and optional proofs. But a TLDR is that, you know, we want conformance with the standards, passing tests. Reproducible performance on reference hardware, reasonable proof sizes, and then conformance with, cryptographic and formal verification requirements, which are still, influx, but where we have some good indications already of what those will look like. And of course, permissive licensing, which is critical for all of what we want in Ethereum. Next, please. Yes, so I'm still working on formally proving RISC-V compliance of ZSK. I found a couple more bugs since our last update,

important, circuit bugs, and that takes the count actually up to 5, with a 6-1 discovered kind of peripherally. And if you want to see those, I've added, actually, a section to the README of the zkFV library, Where you can see the patches. And I'm still winding this down, I've put in a lot of, a lot of PRs on very technical points. One thing just to give a flavor, is that there were still some constraints being dropped, and those were sort of baked into an overly broad hypothesis, and that was discovered by, like, round-tripping the constraint extractor. So I believe now that all of the relevant constraints are being used. But yeah, working, working on that. Next slide, please. Sorry for going over to…

Yeah, and finally, just, I like to update on these, that I don't… these libraries in the Verified zkVM org that I don't follow as closely. So just a flavor of what's going on over there is that Comp Poly is shifting some pre-built artifacts for faster development, these pre-built OLEANs, that's very nice, and we have, arithmetic improvements, like performance improvements for these, important fields, the two BLS12 fields listed there in the… BN254, and also support for additional QualBear extensions and for binary fields going in in these PRs. And there's a series of works, the first sort of taking out some existing work on WER and then rebuilding, and making progress on the WER formalization and rclib. But there's much more happening in both of these libraries, this is just a quick slice of that.

And I believe that's the last slide, next slide, please.

Ignacio Hagiopan: Yeah, no more slides.

Cody Gunton: Okay, okay, yeah. Yeah, thanks for that.

Ignacio Hagiopan: Cool. Thanks a lot, Cody. Is there any questions? No? Okay. So, that was our last point in the agenda. So… See you next time.

Gary Schulte: Real quick, Ignacio, a lot of the topics that Francesco brought up were new to me. I was wondering if he could share those slide decks so that I could kind of offline dig into some of the… especially the recursive consensus and recursive guests. Topics.

Francesco Risitano: Let me share the links to the specs. I haven't posted the slides, but I'll do that shortly. So there's the specs there, and the… Wait, what did I send? Let's send you this.

Gary Schulte: Congratulations.

Francesco Risitano: Okay, yeah, here's the guest as well.

Gary Schulte: Great, thanks.

Francesco Risitano: Yeah, I would… I would just say that this is, yeah, still pretty early research, so things are likely to change. Rapidly, so just keep that in mind.

Gary Schulte: Certainly. Yeah, I just… since it was entirely new, I just kind of wanted to have some time to… to get my head wrapped around it.

Francesco Risitano: Bishop, yep.

Ignacio Hagiopan: Cool. I will include all the slides links in the Ethereum PM issue for the call, so, you can also will be able to find all the slides there. Okay? So, thanks, everyone. See you next time.

Francesco Risitano: Cheers.

Derek Sorensen: Thanks.

Gary Schulte: Thanks.

Transcript adapted from ethereum/pm, CC BY-SA 3.0.