L1 zkEVM Breakout #5

Transcript

Ladislaus: Hello, hello!

Ignacio Hagiopan: Hey, is this… is this thing working?

Ladislaus: Could be working.

Ignacio Hagiopan: Okay, cool, cool. How are you doing?

Ladislaus: Alicia, it says, recording in progress. I'm great, how are you too?

Ignacio Hagiopan: Pretty well. Is, like, all these things being recorded also being uploaded to YouTube, or is some kind of cutoff at some point whenever we start?

Ladislaus: I believe there's, like, the bot who… Who does the automation? Cuts… cuts off once they hear a certain trigger word. Okay. I generally wouldn't… I generally wouldn't consider this conversation private right now.

Ignacio Hagiopan: Okay, sounds good.

Ladislaus: But, Yeah, I can… I can ask, Mark from Protocol Support, he… He does all the automation. Hi, Ivan! Careful also here. Nice.

Kevaundray Wedderburn: Okay.

Ladislaus: Ivan, isn't that the swallbutt, in the background?

Alright, so let's wait a couple more minutes, and then…

Ignacio Hagiopan: Yeah, maybe let's wait 30 seconds, and we can start. Okay, let's start. Welcome, everyone, to L1 CKVM breakout number 5. This is for the progress that we have made on May 2026. So, before starting with the agenda and usual updates and things like that, I just wanted to highlight that, some weeks ago, we… proposed EIP 8025, for Hegota with Francesco. Basically, what we did is a brief summary of

what the CIP means for the CL on the AEL. And yeah, basically going through the formal process of proposing the AP for Hyota. If you are interested in this presentation, I'm leaving here the YouTube link. I will later share the link to the slides, so you can look… Add this in more detail. And there's also a forecast Q&A section about the CAP. Because there's, like, a lot of questions regarding how all this would work. Mostly regarding, this is an EIP proposing an optional feature in the protocol. And there's no much, kind of, precedence about what this even means, and how this fits into a new fork, or something like that. We actually had a really good question regarding

this particular topic in the ACDC presentation. That you can see in the YouTube link, but yeah, just wanted to say that we officially propose, optional proofs for Hegota. So, the agenda today, it's basically, yeah, just this intro, where I mentioned this proposal that we made with Francesco. We'll go through the usual project updates. We'll try to be on time for each of them. We can have some Q&A after each project presentation, if there's any question. And then we will have three presentations, one from Derek about EVM ASM progress. We will have some updates from Ben about some work he has been doing regarding input deserialization for CKVMs. And we will also have some updates from Peter about, blocking blob progress, so… some cool stuff today.

So, I will start with updates for project number 1, 2, and 6, as usual, so we can pack them together and… Go through all this pretty fast. As an update, project number 1 and 2 is related to the execution witness against program spec and tests. The TLDR on this front is that we have made two releases, We have released 040, which basically included some pretty structural changes into the guest program input. The first one is, schema ID, Prefix bytes, which basically allows To have some future-proof encoding of the guest inputs, such that if in the future we realize that it's a good idea to include a new field, or use a different encoding, yeah, we can have some kind of flexibility on this front.

We enrich the chain config existing field that we already had before. But now it has a bit more information, should be self-sufficient, or be more, like, self-describing on how the guest program should behave for the blog that is being validated. and, properly filled the public keys field that already existed in the guest program input. This field, wasn't properly filled by the specs. And this is a field that is basically used to speed up, transaction validation in the guest program. The specs have a bit more information in comments, But yeah, you can start using this field if you think it's a good idea. You don't have to use it, it's something, like, more like a hint that you can use to speed up stuff.

It's just something that you must… At least validate, but usually also leverage for speeding up the transaction. signature verification. And on the next release, that we did, this is more like infrastructure stuff related to adding a new simulator for Hive. I will explain more about this in a moment. And also, as part of the release, apart from releasing the usual blockchain test. fixture format. We are also releasing blockchain test engine format. Which is also related to HYBE. We have a lot of stuff in the pipeline already ready for the next release, it's… mostly, not… I mean, there's some interesting stuff here, but mainly it's the, allowing filling fixtures with an outside EL, such as GET. This is really relevant for being able to fill benchmark

Fixtures, so that we can… Release. benchmark fixtures from the East repo. Because we cannot really fill them with the Python implementation, because benchmark fixtures are pretty heavy. I added a couple of more tests regarding, yeah, embedded cases that the guest program should recheck, like embodied SEC encodings. Really weird corner cases regarding these public key hints, regarding parity checks and things like that. So, overall, let's say, like, more, more testings, That we will release soon, probably based on, Glamsterdam DevNet 5 or 6, I'm not sure yet, but it will be probably based on a new DevNet.

Another update on this front is that I worked on, adapting Hive into running Both execution witness compliance tests. So, stateful ELs, like passing all these execution wind generation tests, and also stateless block validator, or guest programs compliance, which is basically using the stateless input Bytes and stateless output bytes. I had to do a bit of magic here to be able to adapt Hive to all this, because… high-vis wasn't really kind of designed, at least for running stateless programs. Through CGVMs and all that, but I think I came up with something somewhat reasonable. At some point, this would be upstream. I just wanted to have something that we have, like, a public dashboard where people can simply see how different ELs and guest programs are passing the official tests.

I think that's usually a good motivation for people, to, to keep pushing for stuff. Today, the only one that I have in the dashboard is Ethrex for execution witness compliance runs. The only thing that is needed for you to integrate into this is to have this, engine new… payload with witness, version 5. Just like their usual JSON RPC is fine, I also have support for SSZ, but SSZ support in the Asian APIs is still something in flux. So, to not really be blocked by that, if you, if you just support the usual engine, new payload with, with NES version 5, that's everything that I need. I also, like, an expectation here is that it's, it should be a branch.

available on an official repo from the AEL, so we don't, like, we prefer not really to accept forks, Because if not, yeah, things get a bit messy on, like, what is official and what isn't. So, if there's a branch that you think is… can be used to pass… to run all these fixtures, and that branch lives on an official EL repo, that's everything that we need. This is pretty new, so yeah, if you have anything to try, just let me know, and we can try it out. Really quickly, as something, like, side… side-channel stuff that happened, too, I was… Just spending some time learning about some code bases out there. And turned out that I found two security bugs, one in CISC, that is already sold, in version 0.18. This was a soundness bug, related to the constraints of some operations, and another thing was,

a potential out-of-memory critical bug in Libby SSE, from… from Lambda class. I think this is just, something that I would encourage people just to jump into repos and wonder about stuff, and… You can find a lot of bugs, because things today move pretty fast, for reasons that we already understand, of using a lot of technology for writing code faster, which is awesome. But we also need to keep an eye on things and just wonder about stuff and see what we might find. Regarding EL progress on stuff, I will go pretty fast here, because I don't want to spend a lot of time. On the ethrex front, there was a lot of progress, implementing this, new engine APIs that are required for the Hive dashboard.

Ben has done a lot of, Whoops. a lot of progress on multiple fronts that he will present later. Nethermind is also doing a lot of progress on passing all the spec tests and things like that, and also helping with the design of the stateless, guest inputs. Res is doing some progress on trying to compile to the targets that we decided. I did some work in Geth to also try to make Geth be integrated into the execution witness fixture runs, so they also required to support this engine RPC, and some extra fixes. Silkworm has been integrated into the workload repo as a first step to be able to run fixtures, too.

And developer Ruche has been also helping on that front, you know, in a new repo. I'm just leaving links here that you can look later. And Besu has also been doing a lot of work in, also supporting this JSON RPC for being integrated in the Hive dashboard. And on… on the CESU part, which is the newest program they are writing, they are making a lot of progress. Okay, so regarding project number 6, which is benchmarking and metrics, Ben has also been doing some interesting experiments, based on a paper, on how much flexibility we can have on LLM… on LLVM flags to compile guest programs in a more… suitable way for performance, because the execution environments between a normal CPU and a CDVMs are pretty different, so things like inlining or things like that, have a great influence on performance, so you can… probably he will touch on that on his, presentation.

And I've been doing some work on a new repository from Maria that she's trying to build from scratch, a bit, like, a… A fresh take. On a repo that can help to… Come up with repricings. From benchmark runs, So, yeah, ideally we can use her work to come up with repricings for CKVMs after we do the benchmarking stuff. And finally, the Ethereum Foundation has the probing cluster ready. This is some… heavy work done by the DevOps team and PandaOps teams from DEF, so, yeah, thanks a lot to them for all this effort. Probably… Maybe Han will be touching a bit more on this, but just wanted to mention it. And yeah, that's all from my side.

So, let me see if there's any question here… Instead of the engine API, we're just running the fixture from CKVM test releases, PL, and temperature to the dashboard. Right. So, the engine API, is basically used only for the execution witness building conformant tests. Mainly because, that's kind of the most natural way to really get the execution witness. For the guest program runs. the engine API is not really used at all. The only thing that we need is basically an ELF. That accepts the stateless input bytes. And outputs the stately… stateless I would whites. And the tooling basically simply spin-ups everything, spin-ups the ELF, spin-ups the CDVM, sends the input bytes, runs the guest program through the emulation.

And basically checks that the output is what it expects. So, I haven't still a good success case for integrating, I guess, program into this Hive dashboard, but if you are interested, Homer, in giving it a try, we can coordinate a sync and see how it works. Yeah, I don't see any other questions, so maybe we can jump to… Project number 3. I will stop sharing… I think I already stopped sharing my screen. I think it's Marcin, right? You know, Marcin, if you have any slice? Okay, thanks.

Marcin Bugaj: Okay, can you hear me?

Ignacio Hagiopan: Yes.

Marcin Bugaj: Okay, can you see my slides?

Ignacio Hagiopan: Yes.

Marcin Bugaj: Okay, great. No more technical issues. So, hi everyone. A quick project… a quick update on the project tree. the KVM guest API standardization. We now have… we now have 7, standards accepted. Here's the list. One standard is in review. It has been heavily discussed, the static library and linker script. There are two new drafts, That I'll introduce in a moment. The new one, in review, defines the runtime each vendor ships. It's two things, static library and the linker script. The library holds everything the KVM-specific, the entry point, I.O, the accelerators, and early hook. The boot flow is on the right, start runs, gives the guest an optional early hook, as was requested by Nethermind.

Sets up the stack and global pointer, does the vendor's own the KVM-specific setup, so that I.O. is ready. and then call Termin. The value mine returns. Besides success or all failure. There was one open question during review, how a guest takes ownership of the hip. And we landed on a simple approach. Two standard symbols, heap start and heap end, are exported by the linker script, and the ownership the sole ownership over, HIP is taken by, the guest program. The update is that ZISK has agreed to that proposal, so, this proposal is moving toward March, hopefully next week. The first new draft is about loading the program.

The guest executable is shipped as an ELF file. And the ELF format is flexible, and today, different ZKVMs load ELF files in slightly different ways. What the standard pins down is the interpretation of ELF. It gives one precise, deterministic way to turn it into the initial state of the RISC-V machine. It does that by disambiguating two choices that CKVMs made differently. The first is where the loaded image actually comes from. An elf describes its contents in two places. The program header and the section header. And right now, some ZKVMs read one, and some read the other, so the very same file could… potentially produce different memory content depending on the interpretation.

The standard settles this on the program headers, and that's exactly what they are for. It's also what real RISC-V hardware and hardware in general, and emulators already use. One nice consequence is that, if a binary is stripped from, for example, from section headers, from other unnecessary metadata, then the ELF will, still load correctly. The second is what I'll call, the code as data problem. Some ZKVMs transpile the program's code into their own internal form. And that breaks when data is embedded in the code, like JAMP tables, the compiler, Could place next to the instructions. The standard fixes this by keeping code and treat-only data in separate segments. It's a compiler thing, but,

it's mostly controlled by, the way script… linker script is written, so the, standard mandates that, The linker script, separates the executable section, which… Must not contain anything but, instructions. On top of that, the loader validates the ELF metadata, making sure that a file is really the kind of, of program this KPM can run. An invite ELF is required to be rejected up front. With no proof produced and no execution, Happening. The second draft is about speeding up… speeding up memory copies. The idea is that vendors can ship faster versions of a few memory functions. Right inside the static runtime library from slide 3.

The one… The guest already links against. Yeah, so we have memcopy, memmove, mem-set, and memcompare. These are abandoned in real Ethereum workloads, and the compiler can emit them everywhere, often implicitly. That happens, for example, in struct moves in Rust, when growing vector in all programming languages, or during serialization. Because they already live in that library, you accelerate them once. And all guest code gets faster with zero source changes, so that happens at the linking stage symbol resolution. Acceleration is optional, but whatever a vendor does, the behavior has to match. the standard C, semantics for these functions.

One more draft. This one is from, is an external contribution from Ruben. it adds a single function to the IO interface, write log. The key point is that, it's purely for diagnostic purposes. it doesn't contribute to the public output, it's not part of the statement being proven, it just shows up on the KKVM console. For, the developers to see. And, to close the loop. I put together a proof of concept of the static library model, from the last breakout call. So, this runtime. was compiled into the static library. The same happened to the guest code. Both artifacts were linked to form the final executable. And it was run on the disk emulator, and the guest was REF-based validation.

Yeah, so there is an open PR. PR for that is basically a proof of concept. I also wanted to acknowledge a similar work done by developer Uche, And Ignacio, I think? They achieved that for, something similar for Z-Core on both ZISK and SP1. Link to, mine and their work is on the slide. And, yeah, so that's… It from my side. Three standards are open, so, I want to encourage you to review them. Elf loading, which is, which is, Which is… which has been quite, quite a long under review, but well, it got commented only, like, 2 days ago. Or 3 days ago. There is two new standard… there are two new standards, accelerated memory operations and the logging function.

Yeah, so… Please leave comments to the PRs. And that's it. Thank you. Any questions?

Ladislaus: Luca was asking if, I believe on a couple of slides earlier, if this is different than standardizing program LF hashes used as input to the verifier.

Marcin Bugaj: ELF hashes. No, I think it's different, because if you verify the execution trace of a RISC-V machine, you have to specify the program. And, I think that ZKVM solve it twofolds. There are two approaches to that problem. One is a verifier key that is specific to, to the program being proven, and the other approach is passing the hash of, Of the code. as part of, public input. But the health standard is a separate topic. It basically tries to standardize how the program, how the memory is, initialized. With, you know, uninitialized data, initialized data, like, from data sections, and what is the code being loaded, and where it comes from. Because it should really come from,

the program headers, not the sections, because the sections can be removed from the file. It's, It's mainly needed by linkers to resolve symbols and link… to form the final executable.

Ignacio Hagiopan: Cool. Well, thanks a lot, Martin, for all this presentation. Next, we have project number 4. I know, Francesco, if you're ready.

Francesco Risitano: Yep. If you could stop sharing, please, and then I can share mine. Thank you very much. Cool. Can you see my screen?

Ignacio Hagiopan: Yes.

Francesco Risitano: Awesome. So, yeah, there's a few updates, the first of which Is related to, weak subjectivity sync. So, essentially, when a node initially joins the network, it needs to sync from the weak subjectivity checkpoint to the tip of the chain. And in the naive model, where we fetch a… pay of n proofs per block, to assert that the, the payload execution was conducted correctly, that accounts to around 50… 54 gigabytes of data, assuming K is 2. And working under the assumption that, where is it? It's around, 3… yeah, 3.5 thousand epochs, based on the current validator staking properties. So… The proposal is essentially to introduce a… recursive proof.

Such that, sinking from a checkpoint to the head would, be… just K proofs for the head block that you're trying to sync. So this is a pretty nice property. I mean, of course, now you would still need to sync all of the beacon blocks, but they're… probably an order of magnitude or more smaller than the, than the execution payloads, but looking to the future with lean consensus, ideally we can get sync to the tip of the chain you know, just essentially one consensus proof, one execution proof, and… or K execution proofs, and, yeah, we can validate the tip of the chain. But that is, that still needs review, so, this is speculative at this point, but yeah, it'd be great if people could review the PR and the write-up and provide any, feedback on that front.

On the lighthouse… I guess, yeah, before we jump into the lighthouse, I'd also mention that Manu from Prysm has, updated the consensus specs and rebased on Gloas. So, so now, yeah, I'm essentially kind of actioning that migration in Lighthouse. I have… rebased the Lighthouse, lighthouse repo on Upstream Unstable, which is essentially where they're building Gloas, And, and I'm also in the process of extracting exclusively the proof engine and the gossip, components. leaving the, kind of request-response P2P stuff out of scope for the initial, for the initial branch, which is what we're going… what we're targeting upstream with. So we want to just ship, the proof engine and gosip upstream, which is like a… an MVP, or minimum feature set, so to speak, and then we can,

Yeah, reconsider the, the… request-response stuff. I'm curious if… the recursive proofs can actually improve the profile, or maybe kind of mitigate the requirement for some of the request-response protocol, which would be nice, because from the discussions we've had with clients, that's generally the most sensitive part of the codebase, and kind of inherits the most complexity. So, yeah, it'd be great if we could, evaluate to see if the recursive proofs can, resolve some of that. so then, moving on, I did a small experiment in regards to the definition, or the specification of the execution layer. So TLDR, currently the specs… we have… we have the Python specs. And then we have the EVM specification. So the EVM is specified primarily using opcodes, but the kind of host, so to speak, that invokes the EVM

is, is kind of defined using Python, so it's almost a reference implementation of sorts, so… The suggestion here is to introduce an intermediate representation which defines the behaviors which are actioned by the host. So… kind of, you know, reading stuff from… from state, invoking, invoking, transaction… starts and ends for frames, calls, etc. So, the idea is, essentially, we introduce this block IR, which describes the block kernel, and that subsequently invokes the transaction kernel. And yeah, I suspect this is going to be a more This is more conducive to, formal verification and, just more interpretable in general. But, yeah, I'd defer to the, the FV guys. We presented this yesterday, so, maybe there's some promotion of this, or some derivative of it, I'm not sure. But yeah, just a heads up on that.

And then finally, Peter, has kindly volunteered to contribute to Blocking Blobs, so, that process is kicked off. And, I'll leave it to him to give an update in a few minutes' time. But, yeah, that's all from me.

Ignacio Hagiopan: Cool. Thanks, Francesco, for this. I don't think there's any question… At least yet. So, yeah, maybe we can move on to the next… project, which is project number 5 for pro-infrastructure. I know if Han You are here, and want to present something.

Han Jian: Yeah, so… can you see my screen?

Ignacio Hagiopan: Yes.

Han Jian: Cool. I'll give a quick update on the Prover Infra. So, as Ignatio said, the EF cluster is now up, and thanks again to the Tevasting and the Pandaf team for their great effort. And so far, the cluster performs very stable while doing the benchmark. And we have set up the RISC-V Distributed Proverbenchmark tools. and did a small set of mand blocks and a small set of the EST blocks benchmark, and so far the numbers looks nice. But, before we, like… I will share a concrete number next time, after we have done a larger set of blocks and ES… full set of EST blocks benchmarks. And that's about the cluster. And next is, now in the DKBoost, we can use the cluster client to request for proof, which means that we can spin up a disk, cluster and then request proof from that.

And also, we have had the verified binding for CNGO. So, for example, the Prism consensus client can use the verifier directly in process, and avoid dependency of the ZK boost. And next, I will focus in on the disk distribute prover fine-tuning to make sure that all GPU are kept busy. And do a more… a larger set of minute blocks and full EST benchmark, and share the concrete number next time. And that's, the update for me. Thank you.

Ignacio Hagiopan: Cool. Thanks, Han. Excellent work on all this. This is… this part of the infrastructure is super complex, and figuring all this out is out of work, so… I think… I think we will need a bit of experimentation of using the cluster to really understand pain points and things like that, because Probably we will be the first ones to really understand the complexity of This new role in the network of proof generation, so… yeah. it will take some time to really polish things up and figure out what is a reasonable setup for managing this new infrastructure. So, yeah. Thanks for all your work. I don't think there is any question about this, so maybe we can move to project number 7, which is security from Cody. I don't know if you're ready.

Cody Gunton: Yep, ready to go. Yeah, so I, published a blog post, since the past call on the formal verification effort for Sp1, which was, completed and then published in, the fall last year, October or November, I'm forgetting now. And, that achieved a significant formal verification invariant, but the blog post is trying to articulate, the work that remains, And trying to kind of ground our, reading of these formal verification efforts concretely and where additional work is needed. So, I found, for instance, through testing, that there was a bug, in terms of RISC-V compliance, and that's formal verification of the RISC-V compliance that we're speaking about here. You could also find

consider formally verifying the SNARC, STARC protocols, which, something we're working on, we'll talk about more in a little bit. But, for instance, there was a bug that, certain valid jump instructions could not be processed by SP1, and it's sort of a matter of, perspective on… what these formal verifications are here. So, the, sort of… the perspective of the effort was to… to model a SP1 hypercube, which I see I have a typo on, and and then prove that, sort of, it's… processing of instructions is always… agrees with the spec, but it doesn't show that every instruction can be processed, every valid instruction that could come out of a compliant compiler. So… we have this kind of bug. We also found, some issues in the actual formal proving itself, where, we had proofs that were, or at least one proof that was, empty due to, sort of accidentally introducing contradictory hypotheses,

So that… that was fixed, and there was no issue, it wasn't covering over a bug or anything, but, Yeah, and then there's more, I mean, to say. One of the takeaways is that compliance is not established for 11 of the, base instructions in, RV. 64 IM. And, the conclusion is that we need to, focus on spec compliance, because that's what, You know, that's, like, the compilers give us conformant programs, and we need to be able to process those. And we should also… work to communicate very precisely, in all communications, I think, what the, sort of… you know, like, highlighting, like, the remaining work in these efforts. Which is not to say that it's not valuable, I think it's a very valuable effort, because… evidence of…

My enthusiasm is that I'm now trying to do the same thing for ZISC. I reported on this a bit last month. It's… it's pretty far along. I'm not ready to, encourage others to read it yet, but it is working at least to find significant bugs, in… in ZISC, which are… have been patched. By… by the team there. So… on… more on RISC-V compliance, you'll remember that we established this as the target, as a community late last year, early this year. And, we have some significant progress on that, on implementing this, so teams have been close. Last month, I reported that this, unaligned access is ex- extension had been… had been implemented for ZIST, but… now we have a fully compliant VM and Lambda VM, and ZISK is very close, it's been…

You know, effectively, they are, but it is possible to omit some fence instructions that would cause this to… It's a panic. These wouldn't show up in practice, but, you know, that's with an asterisk, because it is valid, and we should comply with the standards. And OpenVM is close to, releasing a compliant, next version as well, as I understand. So this is great to remind you for proving, programs written not in, say, like, Rust, C++, or ZIG. This… this seems to be… something that's quite hard to work around. So this is going to open up proving, and already has opened up proving Nethermine state transition, and And also maybe Geth and other such non-Rust-based clients. So then, just briefly on some highlights from the formal verification efforts, we have a library called Comp Poly, it's been around for a while now, which is about making computable polynomials, because we want our specs to be executable. I mean, the best would be if we had these specs in Lean that had

formal proofs that they were, you know, secure, and then we could… those were also good enough to execute, that would be really nice. And this is a step toward that, maybe a more… modest goal is that when we have executable specifications, we can use them for differential testing. And so, for instance, we have polynomials that are giving us, NTT-based multiplication and Comp Poly, which is a big step toward our ability to have very high-quality differential testing. And, we, you know, KZG's not, like, part of the mix, for our, for our L1 proving, currently. We're going post-quantum and avoiding these trusted setups, but it's still, I think, impressive to… point out that we now have, like, a good KZG spec in ArcLib, and it also uses Comp Poly, so, I don't know if it's, like, executable, like, if you could do a, you know, KZG…

proving and verification in, in Arclib, but, I suspect it's close, and I think it, bodes well for our ability to Make use of, very high quality, proven specifications. So that's all for me. Thank you for your attention.

Ignacio Hagiopan: Cool, amazing. Thanks, Cody, for your updates. I don't see any question… So, maybe we can move to our next speakers. We have, We have Derek, we have Ben, and we have Peter, and we have around 30 minutes. So, maybe if… suits well. Each of you might use around 3 or 4 minutes, if that's fine, or maybe if you would prefer to leave your talk to the next breakout call with a bit more time and priority, as you want. So maybe, Derek, you want to start?

Derek Sorensen: Yep, 3 minutes is good for me. Let me just share… Let's see… Oh, shoot, okay. We may have some system settings. Okay, in order to share, I need to, I guess, Zoom updated, so I need to quit and reopen, so maybe, if someone wants to go right in front of me, I can go next, or I'll be back in, like, a second.

Ignacio Hagiopan: Yeah, cool, sounds good. Maybe Ben can start now, and whenever he finishes, maybe you will be ready.

ben: Yeah, great. I hope you can hear me.

Ignacio Hagiopan: Yep.

ben: And I'll also share my screen. Which should be visible right now.

Ignacio Hagiopan: Yep.

ben: Okay, cool. Yeah, so, There are two lines of work, for the past month that I was looking into. The first one was looking into how guest programs use memory, and we've observed, then, on some fixtures on EAST, Some of them were crushing, and this was not due to logic reasons, but… Due to, hitting the memory limit, so the memory is purposefully small, and also disk… Default allocator is not freeing, and as a result for this, I was able to fix 13 of these tests that were up to 60 million gas. And then I looked into, some continuation of work from previous month, which was more on optimization of the… Guest program. So, the first change, that I did, which is already merged.

better uses the memory that is allocated in the call frame in ethrex. This is not a problem in the standard execution model, and the allocator handles this optimally. However, in the ZKVM, we need to reuse it, and this was, able to clear up around 11 of the failing tests, and then the second case… This was a… this was a special… special fixture that was targeting contracts that were full of job instructions. And I changed encoding instead of the indices of the jump destinations into a bit vector. This is already an approach that is used by REF and GEF. And this was able to fix the… fix the tests, and also uses around 10% less memory on the average maintenance blocks, but depends on which block you take, look. Some of them used more.

And then, in the third PR, I… did a refactor of the codebase such that almost all of the hash function calls that are in the guest program are now routed through the precompiles to the respective ZKVM instead of the software implementation. So, this produces speedup at around 1.5% of the mainnet blocks that I tested. And then, in the following PR, I did a continuation of the previous work on serialization for the execution witness. So now, the tree is not encoded recursively, but instead, we encode flat notes using SSD. And this aligns closer with the specification that we have, but we also need to keep in mind that this is slightly more complicated, and the guests also need to reconstruct the tree.

And as for the final work, I looked into a paper that was recently presented at the ZK Proof Rome on evaluating the compiler optimization impacts. And here I tried… different, different options to… to speed up the guest program, and I limited myself to only adjusting the arguments and not doing any patches to LLVM. So we agreed that to keep the LLVM standardized and not change the compiler. And with applying an optimizer to the arguments, I was able to get around 10.5% improvement with no changes to the source code. Which is… which is pretty decent. And I also have my write-up, which you can check, I will send the link to the chat. And following, I want to look into comparing the allocators for this. Currently, there are four versions.

I want to check, what are the… what are the trade-offs there, and do some more profiling on the ethrex, and see where that leads. That's all for me.

Ignacio Hagiopan: Awesome. This is, this is great. I know if there's any question… While we are waiting, I must say that, yeah, I think that ethrex is very fortunate that you are taking a close look at all these details. I think that the idea here is that we can, yeah, learn some lessons that probably can be applied to other ELs. So, yeah, maybe eventually we will try to do some kind of Whole summary of everything you have done, and we can give some kind of hints to other people to apply, to other codebases, or similar.

ben: Yeah, exactly.

Ignacio Hagiopan: Well, if there's no particular question, I know if, Derek, you are back.

Derek Sorensen: Yes, all good.

Ignacio Hagiopan: Cool.

Derek Sorensen: Right, can you see my slides?

Ignacio Hagiopan: Yes.

Derek Sorensen: Okay, right, I'll give a quick update on where EVASM is. If you don't have context, EVM ASM is an assembly-level implementation of the EVM. in lean, we're doing it for a few reasons, including possible big wins in efficiency, using formal verification, and, and so we can… the idea is that we can, kind of pin, Gen AI between two formal specs. One of them is of RISC-V, and the other of the EVM, and have it write assembly directly. And then we can extract… we can… we can… get this RISC-V and put it in an ELF and run it in ZKVMs in the wild. So that's the idea. I'll give an update on… on three kind of levels, on the EVM opcode, level, then the state transition function, and the code gem.

So… Currently, we have 110 opcodes that have… that run, they have formal specs, they have formal proofs. These are the, kind of, most basic ones, arithmetic, bitwise, shifts, comparisons, byte, stack family. We have, almost all of the other opcodes are at varying stages of executable and able to kind of extract and run in their own environment. And they're a little bit more complicated, so these include mol mod, SMOD, X, etc. There are only 3 opcodes that have not been done yet, and these are the Cancun ones, so they're kind of on… On the to-do list… to-do list. So we have, we can formally prove, these opcodes correct with regards to a spec, and we can also extract most of them, and run them in,

And I guess I'll talk about that in a second. So outside of the, kind of, execution, I guess, the state transition function. We're modeling, we're making rapid progress on this, modeling, global state with accounts, storage lots, slots. A lot of this is pretty new and, still kind of underspecified. Francesco, and we mentioned, his project ELIR. That may help us to have a more rigorous, concrete definition of, sorry, formal spec to work with here. Transactions have an EIP1559, kind of interface, that size implemented, we can do validation of transactions, we can… we have some start on gas, not super mature right now. Message calls, we have call frames as of the last couple of days, preconditioned gates.

And there are… there's some, there's a beginning of, contract creation, like, being able to generate new addresses and things like that. So, a lot of these on the STF are still… Kind of models and aren't kind of running yet, but this is the… this is the main place that's being worked on right now. And then from here, we can, the code gen, extracting EVM… I guess the goal is to be able to take the entire EVM, put it into an ELF, and then run it in, we're targeting first the ZISC emulator. Right now, what we can do is we can individually take opcodes, or small groups of opcodes, and kind of package them together and test them. We have these round-trip tests that, extract the RISC-V… the code,

And then… and then bring back, look… look at the opcode, look at the extracted RISC-V and make sure that it, it, is what was expected. So, as, as of now, Yeah, we can… we can kind of… with opcodes before finishing the formal proofs, we can test them, so we don't waste time on formal proofs, and there are still, there are still some to-dos on CodeGen to make sure it's formally verified and we don't have, any problems there. So, what's next on EVMASM? We… I, I think… The state transition function is, of course, very, very big. We need to finish off the opcodes. We need to have a stronger sense of what the formal spec that we're working with is going to be for the EVM.

And this is a whole… a big discussion that I'm happy to, you know, take to another setting. And also, we've had a lot of success with the EST, and we're hoping to, in some sense, integrate it into CI and, and grow CodeGen so that we can extract the whole Of the EVM, but that is… That's a speedrun update.

Ignacio Hagiopan: Cool. Amazing, Derek. Thanks for the update. I mean, there's a lot… a lot to say about this project. I think at some point, maybe whenever you feel there's, like, a good milestone. we can make a separate call to maybe only discuss about these projects, because I can imagine there are a lot of people wondering what this is all about, and… I think will be useful for everyone.

Derek Sorensen: Definitely.

Ignacio Hagiopan: Yeah, they sell.

Derek Sorensen: Yeah, very happy, to have a call like that, and if you're interested, please reach out. We have a Telegram channel and regular calls, so…

Ignacio Hagiopan: Cool.

Derek Sorensen: EVM, you'll lean. Yeah, I'm happy to talk… maybe right now isn't, What… I guess the shortest answer to that is that it's not up to date. But there are more reasons, but I'm… but… Sorry, I'm responding to the question in the chat. Yeah, I'm happy to talk about this a little bit more, maybe offline.

Ignacio Hagiopan: Cool, yeah, maybe let's continue about that, I think. Peter, I don't know if, like, maybe spending 2 or 2 minutes is okay for you, or if you prefer to maybe do your presentation in the next breakout call with a bit more priority, wherever you prefer.

Peter: Yeah, 2 minutes is okay. Thanks, everyone, for staying overtime. I don't have any slides, either. Yeah, so hey everyone, I'm Peter, I do program engineering at Scroll. I've also been keeping an eye on the ZKVM developments and the blocking blobs proposal. And after some discussion with Francesco, I recently started doing a prototype implementation of blocking blobs. So maybe just a quick, quick context for those of you who might not be familiar with this EIP. The idea is that once we have ZK testers. well, our testers can attest without downloading the payload, so we don't have this implicit data availability guarantee anymore. That might be an issue. So, what is suggested here is that we take the payloads, we encode it into one or more blobs, and then use the existing data availability,

functionality of Ethereum to ensure that the data is available for anyone to download and re-execute if they want. So, this is orthogonal to 8025, but… Quite related to it. There's two variants. There's a native variant, and there's a KBM variant, so the native variant is, in the EL. So, from the engine API perspective, when we produce the payloads. We do an additional step of encoding the payload into blobs, and then we pass these blobs to the CL, and we also set the number of the blobs in the block header, or the payload header. And in the ZK variant. When we produce the payloads and the witness, we also produce KZG commitments and proofs for these payload blobs, and in the gas program, during proving, we verified these proofs.

So that's kind of the high-level idea. I've been working on… a prototype implementation in ethrex and Lighthouse, and I guess the goal is… Primarily to find any spec issues or any blockers. And secondary, to have reference implementation and have some kind of a DevNet to have the end-to-end flow running here. So, so far, I've found some small spec issues. I have a draft PR to the EIP, submitted. I also ran into some complexities with the KZG libraries, because this, blobKZG proof verifier and batch verifier is not fully available, but I think for now there's workarounds for this. So that's been the progress so far, and I continue to test this, and then… Hopefully have an answer on DevNet soon.

Ignacio Hagiopan: Cool, amazing. I mean, thanks a lot for contributing to all this work, because we don't have enough bandwidth to really make progress on this yet, so… You're already finding, this… this fix, problems, and just making progress is very helpful. So, yeah, thanks a lot for that. Yeah, Ivan is doing… he's saying that he might be also contributing to this effort, so that would be awesome, yeah. So, I think that's everything for today. Thanks, everyone, for joining, and see you next time.

Kevaundray Wedderburn: Great. Thank you, honey.

Ladislaus: See you around, guys.

Marcin Bugaj: Right?

ben: True.

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