L1 zkEVM Breakout #6

Transcript

Ignacio Hagiopan: Hello?

Hey. Can you hear me?

Chetany Bhardwaj: Hello, yes, hi, how are you?

Ignacio Hagiopan: Nice. Fine, you?

Chetany Bhardwaj: I'm I'm good as well. Thanks for.

Ignacio Hagiopan: Hey, Omer.

Ladislaus: Hello, hello.

Ignacio Hagiopan: Okay.

Chetany Bhardwaj: Hello.

Ladislaus: Nice. Audio works.

Ignacio Hagiopan: It looks like.

Ladislaus: Recording also works, so it seems… wait, let's see… Let me quickly make you co-host… Nice. Okay.

Ignacio Hagiopan: Cool. Let's wait maybe one or two minutes for people to join and we can start.

Okay, let's start, I will share my screen. Hold on a second. Can you see my screen?

Ladislaus: Yep.

Ignacio Hagiopan: Cool. Okay, so welcome everyone to CGE VM breakout call number six. Today we have a pretty simple agenda, We have mainly project updates as usual, and then Ben, which is our intern in the CGA VM project, will do some presentation. First of all, I want to highlight an ETH research post made by Mike Nueder. It's a very cool exploration on how zkEVM not only helps on the computational side of Block verification, but also on the bandwidth side, which is something that maybe is not usually, sold enough. So yeah, I highly recommend people to take a look. It's very well written, and it also connects with Other upcoming proposals regarding blocking blobs and things like that.

So, yeah, I want to thank Mike for writing this. Probably a lot of people here already recognize him from… from working in DF some time ago. I will start with the updates for projects number one and two, which are related to the execution witness against program specs and tests. okay, so first of all, the main, spec and test update is the release of CGVM… Version 0.50, which is basically a rebase on top of Glamsterdam and WebNet6. Which is a .NET that was launched some days ago. Apart from these rebates, This release also supports using external transition tools for filling yeast fixtures.

The main intention we have with this is being able to fill benchmarks. Fixtures in East using Geth. Because you cannot really do that today with Python, with the Python implementation. This is simply something that Already happens in Glamsterdam benchmark filling. It always uses an external EL for that. And we are simply sticking to that reality. So the whole idea here is that in each CGVM release, apart from Publishing normal tests as fixtures. We can also publish benchmark fixtures, and I will talk a bit more on that later. On spec changes, I kind of refined a bit some of the SSZ max length. In some lists in the guest input. And I did some refactor and simplifications, which shouldn't affect guest programs, but, these SSZ changes are important to…

To take a look for you to adjust, because it will clearly change the hash tree root calculations of of things. The release description has a link to the PR so you can simply look there the PR concretely and you will see there the changes so it should be pretty easy to find what you should change. Apart from that, I added some extra tests which are mainly related to invalid Guest Program inputs. So for example, malformer SSZ input bytes, wrong schema IDs, or adding trailing bytes and things like that. Apart from that, I added some extra tests for the chain config part of the stateless input. So, for example, providing a chain config which doesn't match the block being validated. So, let's say…

Oh! That the chain config signals that you are in a fork. Which doesn't match the timestamp of the block that you are evaluating, and things like that. And finally, some extra tests regarding public key validation. As you remember, stateless input has public keys for speeding up signature verification in transactions. But there's a special quirk regarding doing a parity check. Oh. This is related to ECDSA. And it's very easy to forget about this check, so basically I just created a test that's making sure that people Are validating this this provided public keys correctly. So if you pass the test, you should be fine. If you don't pass the test, You will know why now. So, apart from that,

In the CKVM Benchmark Workflow repo, I created a new CLI tool, which allows to use RPCs from CLs and ELs in a devnet. to create the stateless input. Bytes. So what this basically means is that we can join existing DevNets from Glamsterdam, and… Publish in an R2 bucket. the stateless input bytes that would be used by Guest Programs for these blocks. And yeah, this is already working pretty well. There are already two Guest Programs that used this before, and this was pretty useful to them because they found Some bugs. So those bugs that were found were upstream as, for example, Glamsterdam new tests. So these are, like, new tests in the base default branch for Mist.

Which weren't really covered before, so this turned out to be pretty useful. So the idea here is that we can keep mounting on the next DevNet from Glamsterdam and keep just kind of assuming that AD25 is kind of. Lamb's are done ready in a way. And all this is infrastructure that we can continue to use whenever Hegota starts. So we are kind of front-running a lot of Tooling and, and yeah, useful, Testing here, apart from EAST tests. Apart from that, in the previous call I mentioned that I was working on this Hive dashboard to Kind of have a single place to see how much. Stateful yells and guest programs. Pass the tests. And, yeah, so at that point in time, so in the previous call, I had, like, only,

I think it was ethrex, Runs regarding execution witness generation compliance. And now we have ethrex and Besu, Execution Witness Compliance. runs, and also the first Guest Program test running, which is pretty nice. So, now in a single dashboard, we can see both, yeah, stateful ELs constructing the execution witness correctly. And also, being able to see if guest programs Using the stateless input bytes, are passing the tests. So the idea now is to continue working on this, for this next… for this, new release that we did. Keep track of things in a single dashboard, hopefully. I also did some experimental benchmark.

fixture filling using Geth, and this turned out to be pretty useful. I share these benchmarks. In the Discord channel, and Omer used them to try to see if things were working correctly. And we found some problems and yes, this ended up in me fixing a bug in Geth regarding execution witness generation. Which is already merged, so thanks Gary from the Guest team for matching that pretty fast. And after fixing this, I refilled the benchmark fixtures. And it seems to be working pretty well. So what this means is that probably in the next release, I will be including or trying to include benchmark fixtures using Geth. So it will contain both test fixtures and benchmark fixtures.

Not sure yet for which gas limits, but we can start with some number and we can go on from there because. Maybe for big numbers we will have some CI issues on filling them, which are already a challenge in the East repo. And apart from that, some kind of updates that I've seen out there might not be complete. Han has done some really nice Updates on Reth regarding, Yeah, some, some overall, like, fixes that are required, On ethrex, he has also done some optimizations regarding how the execution witness is verified. So the execution of witness verification has a 2x speedup, which is really nice. And on the CISO side, I know they have been also working on trying the CISC Accelerators regarding

256 bits integers. This is some precompiles that CISC has. Marci has already experimented a bit with this and the Besu team has done experiments on their side and have found some results. It looks like it's still not having a lot of return on investment. But yeah, just wanted to mention that there was, like, some external experimentation apart from our team on this side. Okay, so regarding project number 6, which is regarding benchmarking and metrics… I just want to highlight two articles that were published this last month. One is from SOM, from the SYSWARM team. Where he's explaining a bit more how he's exploring potential new execution witness redesigns. Mainly regarding, how to validate the provided state.

So yeah, take a look at that article, it's pretty nice. I think he's planning to do a second part soon. So he's still in exploration mode. And Ben, which is our intern, has done some comparison between HIPAA locators in CISC. This turned out to be a pretty important topic because Depending on which allocator you use is how much risk you have of having an out-of-memory situation. Which would be a liveness issue. But he will be talking about this in a separate presentation later in the call, so I will leave the details to him. And that's it from my side. You know, if there's any question… I see, how do we add Nethermind to the dashboard? I will share later in the, in the chat the link of the repo. It's very easy, it's basically adding some

branch in a JSON file in a repo, and simply run in the CI. So, I can coordinate with you, and we can, We can add our mining the execution witness completeness. Oh. Brands. And the same applies for everyone, of course. Okay, there's no any other questions. Maybe project number 3. Can't give updates. Thing is marching.

Marcin Bugaj: Yes.

Ignacio Hagiopan: Oops.

Marcin Bugaj: So, hi everyone. update on Project 3, which is CKVM Guest API standardization. Today we are doing a recap on the standards that are accepted and that are in review. And discuss to… Vendor results… So we now have 8 accepted standards. They cover Isa input output crypto accelerators. Termination, memory ownership, safety traps. And, accepted since the last call, the static library and tinker script. Two standards are open for your review at the amber ones at the bottom of the page. Health loading and accelerated memory operations. I'll go deeper on health loading now, because it changed the most since it was announced on the last call.

This standard defines one precise deterministic way to turn a guest elf into the initial machine state. how to validate the header, load the segments and check the entry point. The big change since the last time is what an executable segment actually means. The executable and readable flags were left open to the interpretation. The ABI document for RISC-V and in general doesn't say what these flags imply in practice, and we nailed that down. There are two clear options how to interpret readable and executable flags. So… Execute flag, execute only means that segments holds instructions and nothing else. If the program tries to read it as data, That is an abnormal termination. And the second interpretation is execute and read.

which is that bytes can be both run and read. And a load returns the real bytes. Here, read-only data can safely sit next to the code. zkVMs can support only one of those. So that's an inherent property of a zkVM. And our recommendation is to accept the latter, execute and read. Because no toolchain can promise you a clean instruction-only code section. And a stray jump table can always slip in to the executable segment. Yeah. That didn't happen when we compiled Reth and other programs which can execute successfully on Zisk. And Zisk implements the first interpretation, in which case the executable segment cannot be read.

So, that didn't happen, but in general, the compilers There is no such guarantee that compiler emits text section without data incorporated in it. So there are flags to control it. But in general It's it's it's just it's discouraged. to, to have a Zkvm. That is, that cannot read. the executable segment. Now the 2 results. 1st output. The I/O standard says that public output can be of arbitrary length. You can call write output as many times as you want. and the bytes will just be concatenated. BLA, M I implemented that on this in this Pr.

As the bytes are written to write outputs, they are hashed on the fly into a running digest. And only that digest is committed to the proof. The output bytes travel alongside the proof. So the verifier can rehash them. and check that they match the committed digest. You know, So, the takeaway is on the right. Today, only SP1 and Zisk support, support standard compliant arbitrary length outputs, other ZKVMs don't. second result. is that the standard gives the whole heap to the application. That has a consequence that a vendor can miss. The precompiles in your static library must not allocate in the guest heap.

As on the top bar, that's a collision to fix, shown on the bottom bar. A separate isolated scratch region is needed to implement dynamic allocation for precompiles. On this, that's a small bump allocator reset on every call to a precompile. Other vendors should check whether the same collision affects them. Last, a direction that we want to flag, and it may become a standard. Ethereum Guests should be built with a stock on unmodified toolchains. The reason is trust. A modified compiler grows the trusted computing base, and even small patch to the compiler puts the correctness of all the emitted code in question. Yes, a modified compiler could produce better code tuned for a ZKVM.

We give that up on the purpose. A ZKVM can absorb those cost differences, and correctness matters more than speed. So two standards are open for review, offloading and accelerated memory operations. Please comment them, and, as always, if you, if any engineering Help is needed. Ethereum Foundation is happy to support ZkVM vendors. That's it. Thank you Any questions.

Ignacio Hagiopan: I don't see any questions for Marcin, so maybe we can move for project number four.

Marcin Bugaj: I know.

Ignacio Hagiopan: Francesco is here.

Francesco Risitano: Hello. So… And you smell.

Ignacio Hagiopan: So we can see, yes.

Francesco Risitano: Cool. Okay, yeah, so, a pretty quick update, but I'm gonna focus on the… The sync protocol, so, Essentially, when a node joins the network, there's a requirement to validate payloads from the weak subjectivity checkpoint up to the head of the chain. And this can be up to 113,000 slots based on The, the Elektra, Reference period. So… Ultimately, this, This accumulates up to 26.9 gigabytes, just in terms of proof content. Based on a one proof per payload policy. But for EIP-8025, we intend to do KOVEN. So… Ultimately, the implications is there's gonna be a lot of proofs that need to be synced.

There's a few questions here, because we do intend to have an EL For optional proofs, so, you know, because we're re-executing payloads in any case, The… the requirement for… kind of full… Range sync and, validity from the proofs themselves isn't… isn't critical, but certainly for mandatory proofs, it will be. So, essentially, we're exploring ways in which we could, we could address this problem. And one potential approach is to use recursive execution proofs. So essentially what that entails is to, take the execution proof as we currently have it, and, build a guest program on top of that, which does recursion, and adds the execution proof to some Data structure, so there's a few open questions here around what data structures may make sense, so.

I suppose the simplest solution is to use an SSZ-based, Merkle tree. So, for each new slot, you would add an execution proof To the Merkle tree at the index, you know, based on that slot, essentially. So that's one idea. There's also the potential to use an MMR. Which is an append-only data structure, which would arguably be a little bit more efficient, but, in the context of, kind of, payload proving at large, it wouldn't account for a huge relative cost saving, So if we had either the Merkle root or the MMR, we would essentially be able to validate the full prefix. the full chain prefix from the head block, which we're, trying to sync to, all the way back to the, the weak, subjectivity period, checkpoint, sorry. I mean, potentially even before that,

Now, there are some open questions if we actually want to prove the full prefix, or if there's some kind of trust basis, so we only prove from the weak subjectivity checkpoint to the head. These are some open questions. What's nice about this as well is, it simplifies consensus clients, so, currently a lot of the complexity in the consensus client is around The fact that we have to sync the full kind of proof prefix to ensure that the chain prefix is valid. Which is, pretty complex. I mean, it sounds simple in practice… in… in theory, but in… in practice, the… the… the request-response protocol is… is quite fiddly, so ideally, we would just have gossip. And then based on those gossiped proofs, we're able to authenticate the full chain prefix.

So that's the general direction and idea in regards to progress. I guess the next step would be kind of speccing this out and doing an experiment to evaluate. The feasibility because there, there certainly are some open questions around, performance and complexity because. What this entails is either introducing a new guest which sits on top of the pre-existing execution proof or modifying the current guest and adding this data structure which allows us to do chain prefix authentication. I'm hoping to do that in the… in the coming days, and, yeah, potentially, push forwards on a proof-of-concept implementation, so we have a… a basis to, to reason about the feasibility of this… this approach. In theory, it… My opinion is it's viable and a very nice property to have.

But you know. The devil's in the details when we actually get around to implementing this, I'm sure there will be some rough edges that surface, but nonetheless, I… I think it's, justified to do a spike in this direction to… to see if we can, provide this property, for… for, optional proofs from… from day one, essentially. So, If we are able to make this practical, that would be great because, for client, consensus client implementations, they wouldn't have to, worry about the, The request response stuff. And in addition to that, reasoning about whether the block of interest is valid is much simpler because the proof itself attests to validity of all. Ancestors, essentially, so you don't need separate proofs. So that's, essentially the main update.

As I say, the kind of specification is… Is, the next step, and then subsequently a proof of concept implementation. Yeah, short update from me this week.

Ignacio Hagiopan: Thanks, Francesco. I don't see any questions regarding your presentation. So maybe we can move to project number five, which is proper infrastructure. I don't know if Jan is here.

Han Jian: Hello? Can you see my screen?

Ignacio Hagiopan: It's saying that it's sharing, but I don't see anything yet. Let's wait a second. Yes, now I can see your screen.

Han Jian: Hello? I'll keep an update to project number 5. So we have done a scalability check on the EF cluster. We benchmark on 500 minute blocks with disk. With different number of GPUs. And overall, it scales pretty nice, except that from 2 GPUs to 4 GPUs. we see it is CPU bounded. But from single machine to full machine, it scales almost linearly, especially on the big blocks. And you can find more details in this note. And we also run some benchmarks on mainnet blocks and EST 6 million blocks. with the cast, east, wrecks, and risk. And you can find the result here. But eventually we will want to integrate the benchmark result into

other tools, for example, the Evian gas fit, so it can be used as the input as like repricing And during the run of the EST 6 million blocks, we still see many blocks that makes the prover to be out of memory, out of memory killed. So we will have to figure out, investigate. Why? With the cluster, the… The clock still mixed up. Rover out of memory killed. And a new release of ZK-Boost is created. In this version, it adapts to the That compatible input. But it requires some API changes, especially the proof request and the verification API. Now, it requires an additional chain config as the inner body, which will be used as the public input of approving and verifying.

And also the proof type enum is also updated. So next I will try to make a request to consensus layer at the optional proof branch. to adapt to the new Api and also to the Eastern Package. And that's the update, thank you.

Ignacio Hagiopan: Thanks, Helen. Francesco asks if there's any stats on CPU saturation over time the block is proven.

Han Jian: And mostly it's observed from the GPU idling. because the memory is for the for the for the average blocks. The memory is roughly sufficient, but the GPU is most idling when scaling from 2 to 4 GPUs, but from the CPU stats, it's usually not Well, even it's like one CPU to one GPU. That's how I couldn't… That part I couldn't find a strong evidence. From the CPU stat, but from the GPU stat, it seems that. The GPU is idling much more from 2 to 4.

Ignacio Hagiopan: Cool, thanks. Yeah, I think also with time as we start using more and more DF cluster. We can have better metrics and start understanding better all these, all these things, I think. Your exploration has been great. Oh. So if there's no other question, we can move to project number seven, which is security. I know we've got this here. I can see your screen.

Cody Gunton: You said you can, yeah?

Ignacio Hagiopan: I can, I can.

Cody Gunton: Yeah, yeah, good. Cool. So, yeah, on the RISC-V Compliance Testing. project, I upgraded the test suite to this major version 4.0, and that found some more bugs, and those have been reported. On the formal verification of RISC-V compliance, I've mentioned in previous calls that I'm working on this for Zisk. Following, some work by Nethermind and other teams on, on other ZKVMs. And, yeah, I mean, I had some good, progress. early on with AI and now sort of the gap between, you know, it's clearly working because it's finding bugs and I think this is something we can rely on is very large. So, I'm working to close that. It's sort of technical, but I wrote this issue, or I mean, I had AI-generated an issue

summarizing the past month of pull requests for those who are interested. But, you know, for a flavor, there's, like, kind of trusted, you know, connections between verified components, and I'm working to sort of, to… to make those untrusted and proven. And also, you know, you have a model, say, of a Zisk trace, but, we, you know, in the past, we had never instantiated such a trace, from real data, so it's not clear that that model models reality. These are the kind of things that you have to… Deal with. And I also recently met with Hector of Zisk, who's ramping up to, work on this with me, to review from Zisk expertise standpoint and contribute to the effort.

We have a fuzzing project, through a grant, and that has finished, and, some final campaign runs are happening, and so I won't front-run the grantees too much, but we have, we'll have some nice infrastructure built For fuzzing on array and, with a few different, options for program generation. a good initial seed corpus, and yeah, in the next call, I plan to present that a bit more, or at least point to a blog post. There was a big innovation worth mentioning from a security standpoint this past month. The flock proving system was released and there's some promise there to maybe remove our dependence on algebraic hashing. which would be nice, but, you know, more engineering work is needed to validate that, it's viable, like, a lot more. But it's interesting to note that ArcLib had some innovation, or some, improvements

In the meantime, that could help with Flock, formalization, so there's a sum-check result, Flock uses sum-checks, and there's also this ring-switching formalism, which, has been brought in, and both of those would be useful for Flock, so… sort of advocating for ArcLib as a general place for the building blocks of SNARK formal verification work. And finally, we have a special guest in the Project 7 presentation today, Tao, who presented earlier. will, has been working on an EVM spec in this language called SAIL. Sail is, is behind the RISC-V formal verification efforts, because the RISC-V community has been building, an executable formal specification in SAIL. And we've been using it to, to build, lean specifications using this backend,

I expect this backend to be there more and more, meaning we can use Lean, or be in use more and more, meaning we can use Lean to make proofs about RISC-V compliance. We'd like to do the same for EVM implementation, so a first step would be to build an EVM sale spec. And, since the last call, Tao has done this. He's made use of this SAIL2C compilation, which I'm also using, actually, on my first slide, because when I do differential testing of the compliance, RISC-V compliance, I'm using the golden model, it's called, which is the C… Translation of sale. And actually, last I heard, all of the tests were passing in a matter of weeks, which I am very excited about.

And my dream is that with this specification, we can eventually achieve feature parity with Python, where, I mean, by feature, I mean, like, the usability features of the Python specs that allow them to be a very, very valuable resource for collaboration of client teams. So, if we can do everything, that the Python specs can do. You know, have the same or better ergonomics, you know, for filling tests and so on. Then eventually, all of the expertise that the client, the core devs bring, to the Python specs as they develop, their clients can filter in instead directly to a single formal specification, which we can use for formal verification. So we avoid this bifurcation, that could happen if we're not, yeah, if we don't pursue this sale direction. So with that, I'll, invite, Tao to give a little overview of this project.

Trying to stop sharing. Can somebody evict me? Okay, cool.

Francesco Risitano: Can you see my screen?

Cody Gunton: I can. Yeah.

Francesco Risitano: Cool. So yeah. I will… so, yeah, essentially what SEL intends to be is the formal specification of the EVM. As Cody mentioned, we leverage SAIL, which is a very good language for defining ISAs, which the EVM is. In terms of how it's structured, we essentially have EVM core. So this encapsulates opcodes, gas frames and other kind of EVM centric components. And then we have a kernel interface and the kernel interface is essentially. what we use to interact with the host. So, to fetch balances, to fetch nonce, to set slots, to get storage slots, and there's a few other components as well. What's nice about this is it's, it's feature-rich, and it has a lot of utility in regards to its integration, so it's very easy to extract, to various backends, Lean, which is… which Cody mentioned.

There's also, Isleris, which is a symbolic execution engine combined with Iris, which allows us to essentially, prove compliance of compiled binaries with the specification. So, for example, we can compile down to RISC-V, and then we can prove that that RISC-V code is compliant with the specification. So there's ideas about, you know, kind of proving, proving some of these guest programs, using this stack. We can compile to C and RISC-V itself, and also to ROC as well. So just to give an overview of, some of the features. Can you guys see the sale? Not sure if my screen is updated.

Cody Gunton: Yes.

Francesco Risitano: Yeah, okay, cool. So yeah, this is just an overview of, like, the cell ecosystem, so… There's a lot of formal specifications of different targets, in SAIL, which is super useful, because it means that we can do binary analysis on binaries defined in various different, ISAs, including RISC-V, which is of primary significance for us. And, you know, you can… you can also extract to various different, proof assistants and backends. So maybe we can dive dive into the code. So, as I mentioned, we've got the EVM, we've got the host, and we've got some kind of libraries which encapsulate things like RLP and and the MPT, etc. So maybe I can just give a quick example of.

a quick overview of how the EVM opcodes are structured. So, essentially, define an abstract syntax tree, and this encapsulates all of the operations that we have Inside of the, the, the EVM. And then we have, an execute function, which takes an operation. And essentially defines its semantics. So in this instance, for ad, we charge some gas. Which is very low. This is defined in the in the specification. We pop two words off the stack, and then we use an ALU add, so an algebraic logic unit to do an addition, and then we push the resultant word back onto the stack. So it's, you know, the idea is that it should be legible, maintainable, and extensible.

So, we have 100% compliance with the EAST tests. I'm currently doing a bit of a refactor to, To align the kind of state model more closely with execution specs so that if. You know, this is adopted by the spec team. You know, they can dive into an environment that looks somewhat familiar. So, that's kind of where we're at. There's also some ambitions of, you know, using this for… Guest, like, RISC-V Guest Program, verification. So, I've done a few experiments using Isleris, and it looks quite promising. And we're hoping to collaborate with the EVM ASM team However, in addition to that, I think it would be cool if the community could also explore potentials here and maybe come up with your own ideas and seeing how we can leverage this tool to harden the security argument for some of these guest programs.

Yep, that's all for me.

Ignacio Hagiopan: Nice. Thanks, Colby and Francesco, for the presentations. Very exciting. New tools, that we can consider for stuff. I'm looking if there's anyone with questions regarding this. I don't think so. So maybe we can switch to Ben. He's going to present his work on syscallocators. I don't know if Ben is here.

ben: Yeah, right. I hope you can see my screen.

Ignacio Hagiopan: Yeah, I can.

ben: Okay, cool. So I'll 1st do like a short wrap up for for the internship, and then continue to the analyst for the allocators. So, my plan was to look into… optimizing zkVMs, but treat them more as a black box, and instead trying to make some changes in the Guest program so that they are more suitable. So I fixed on specific pair, which was ethrex and Zisk. And then I'm planning to… hopefully make some generalizations, and how this can be extended to other combinations. So the method that I used for this was simply comparing the proving cost, and for this, Zisk was very helpful. What I got was about 42% of combined speed up for all of the changes, plus some other side quests that I worked on.

So what I noticed that worked was really making sure that applying all of the hash precompiles works correctly and all of the instances. are… are… We're calling that. This was one of the… one of the biggest speed-up. And then also making sure that we are using only the things that are necessary. So things like parallelism and locks. are adding just some overheads to the Guest Programs, which is completely unnecessary. And finally, also being more cautious about how we handle memory, how we store types, and… If we do not allocate unreasonably. The last one, which I didn't count to the combined speedup, is applying some zkVM specific instructions. So as Ignacio mentioned. There has been already some effort for comparing the 256 Arithmetic and CISC

I also need to do some more measurements on this. And as for the other things that I worked on was standardizing the serialization for for ethrex, which makes it much closer to the specifications. And additionally looking into relatively new paper for. how compiler optimizations affect the performance on zkVMs. So this turned out to be quite important, and for a change that doesn't require any edits in the source code. This was possible to speed up the mainland pooling by like 10%, 10 and a half percent. And yeah, there is also write-up on the previous one. And then the stuff that I want to present in the second half of the presentation is the comparison for the allocators that are available in Zisk.

I'll share the presentation so that you can find the links. So I tested it on the mainnet blocks and also EST fixtures, and I believe the EST results are more interesting here. So what we have here is there are brewing costs on the y-axis. And then here you can see different types of allocators. So there is BAM, BLMalloc, TALC, and TLFS. And we can already see the first instance for OM on some of the just few selected tests. And also the second thing to notice is that for almost all of the tests that I run is that BAM is naturally the most efficient because it doesn't free. And then all of the other allocators are arranged more or less in this order.

Then we can also evaluate what is the highest address that is touched by the memory. Unsurprisingly, bump is consuming much more of the memory. Here we can see that this one that is touching the threshold is the one that OMs. And then there are two other tests that are dangerously close. And as for the usage for all of the other allocators. They are having more or less the same performance on what is the highest memory address that they touch. Yeah, so… And then when we push this further, we can notice that two of these tests that are close. for 200 million gas limits. These are the ones that, fail. So… considering higher gas limits, there can be more problems. And one thing that we can tackle this problem is that we can increase the memory that's given to the bump allocator from around half gigabyte, which is currently

to one and a half. So this is the blue column that we have here. And these are, again, the proving costs. On… on the tests. And… Once we increase the memory for the BAM allocator, we can see that we bypass the problem. And also that for the DL malloc and the increased bump, the proving costs are more or less similar. But then, looking again at the highest memory address touched. You can see that there's, again, a big difference, so… Yeah, I'm not sure how far in the guest limit are we targeting for the upcoming protocol changes, but definitely, like, if there is only one block that results in failed proving, that this can be used as an attack vector, so…

Even though we are able to bypass the problem by increasing memory, I think it's important to consider… using some more sophisticated allocator, like the analog, for the safety reasons. So… Yeah, that was all that I wanted to cover. More information is on the write-up. And yeah, thanks for all the support in the zkVF team and Ignacio. This was a really nice experience for me. And I would like to continue also on working in the sublab proving. In a bit slower pace during the rest of the summer. Thanks.

Ignacio Hagiopan: Thanks, Ben. Yeah, it has been a pleasure working with you. And honestly, you have been doing amazing work. So yeah, thanks a lot.

ben: Thank you.

Ignacio Hagiopan: Umm. Yeah, Marcian mentioned that he's not sure that CKVMs can provide more than one gigabyte of memory. I think apart from this question, I share the conclusion that using the bump allocator sounds like a really bad idea. it can backfire in so many ways, depending on the implementation of the Guest Program, that Maybe the safest option is just not recommending using this at all. Because, yeah, Unless we can, like, formally prove how much… how much is the maximum memory the Guest Program is… can potentially use. It sounds like a really tight, Situation to being using a Bamba allocation with low. Maximum memory. If we… if we can't standardize, like, a big memory limit for all CKVMs.

So yeah, I know.

ben: Yeah. You have any.

Ignacio Hagiopan: Any further comments?

ben: Yeah, for the comment. There is a fork that I used for profiling. I think that the one and a half gigabytes was the maximum that I was able to set. Due to the, due to the word sizes that were on the disk, maybe in the new version, it's, it is different. Yeah, okay. But to me, yeah, using some more sophisticated approach is definitely worth it. the way to assure the safety here. Because even for all of the tests, we are not sure if there is some test case that we are not covering. And yeah, having this would be a problem because this could stall proving for, For… for the server.

Ignacio Hagiopan: Cool. Yeah. Makes sense to me. Yeah, thanks for sharing the slides because I think people will find there all your work that you have been doing plus this extra exploration. Francesco also shared his slides, so I think that's all for today. Thanks everyone for joining and yeah, see you next time.

Ladislaus: Thanks, guys. See you around.

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