L1 zkEVM Breakout #2

Transcript

Lumi | Offchain Labs: Jim, Kevin?

Kevaundray Wedderburn: Oop. Hey, how you doing?

Lumi | Offchain Labs: Not too shabby.

Kevaundray Wedderburn: Cool.

Lumi | Offchain Labs: Beating through things today.

Kevaundray Wedderburn: That's good to hear.

Lumi | Offchain Labs: Yeah, I love those productive weeks. This has definitely been one of those.

Kevaundray Wedderburn: Nice.

Lou? Yeah, I think we can wait for one more minute. Thanks. Cool. So, I think we're recording, so let's start now.

Beth, welcome to the L1 ZKVM breakout call number 2. This call will be… We'll have a lot less content than number one, and in particular, we'll go over the Tamago update by Andrea. He'll be presenting, some recent breakthroughs on his Tamago exploration. We'll then go over the project updates from the 7, projects that we have, and then Q&A. So, to start it off, Andrea, can you share your screen?

Andrea Barisani: Yup, hello, everyone. Oh, one second… I think you need to unshare yours, otherwise it doesn't allow me to, yeah. Can you see it?

Kevaundray Wedderburn: Yeah.

Andrea Barisani: Okay, yeah. So, thanks for having me. So, yeah, I've been asked to just give an update, and actually an introduction to anybody that doesn't know what it is about the project that I'm leading called Tamago. So, happy to be able to share that with you. So basically, TAMAGO is a modification of the regular Go compiler with the aim to be accepted upstream, so there's a proposal in progress for that, which takes the regular Go runtime, and all of its ecosystem available for bare metal execution, so execution without supervision from an operating system. So basically, the idea is that we try to take… go at a much lower level, so that we can be, you know, as effective as CO or Rust in controlling hardware.

So, if we look at a regular Go application, which, you know, of course you might be familiar with, you have the Go runtime running in user space of an operating system, making system calls. to the operating system, as you would expect. With Tamago, basically, we don't do system calls anymore, to an outside environment, but we piggyback to regular Go code, which actually implements all of the drivers, and in fact, we don't even need a bootloader, anymore, because we're capable of initializing whatever hardware. we have independently in full Go. So we completely removed the need for the bootloader, the operating system, the kernel space, and even the user space supporting execution of Go binaries. The project has been around for some time, so it reached a fair level of maturity, so we have support for four different architectures. So we have x8664, ARM64, and RISC-564, and we support

A small but, solid, range of devices, going from physical devices. such as, USB Armory, which you will also offer in various NXP development boards, to execution, under, virtual machines on x86, so Cloud Hypervisor, Firecracker, QUMO MicroVM. We can run, bare-metical binaries on things like Google Compute Engine, and we can also run in UFI. So, for instance, my own laptop is booted by a pure Go bootloader, which, replaced, my, my regular, bootloader. So, so this is, basically, we can, we can bring regular Go in different places. We achieved this by defining an abstraction for implementing arbitrary operating system or not support. So, basically, we also reimplemented Linux with this interface. So, we defined a Rosetta Stone.

sort of API, which allows with, few functions, six functions specifically, to enable execution of the runtime in a freestanding, environment. The advantage of this, of course, is that dramatic lines of code reduction and attack service reduction for executing, whether on real hardware or confidential VMs. Developing, building, and running Go applications under Tamago is identical to regular Go applications, so the whole Go ecosystem, Go modules. build reproducibility, all the tools, GoVet, GoFix, everything remains the same. There are just a different, some compilation flags that needs to be passed depending for the architecture, but they don't affect the code, the code itself. The same goes for debugging. GoTrace works as expected, PProf, GDB, everything works, as expected.

And so… yeah, we… this means that one can run on bare metal, whether on a confidential VM or physical hardware, and import any Go library that you want, and as long as it's not a Go library which specifically targets operating system. So, of course, if you're trying to import a library that wants to enumerate Linux processes, of course, that's not going to work. Because we don't have an operating system, but, you know, everything else, cryptographic libraries, formatting libraries, even Tailscale, so this is an example of the Tailscale client running. on one of hardware devices that we support, so we can have, a tailscale Wirecard VPN running in, in bare metal without any operating system, support.

Very recently, we made a further experimental branch in Tamago, where we are running on even smaller targets, so now we're capable We have an experimental branch which allows us to run in as low as 5, 6 megabytes of RAM, and also to target RISC-V architectures that do not support, the D extensions or the A extension, so… which means that we can target even smaller targets by enabling, soft, floating point execution. So this is one of the recent projects that we published, which is called, KOTAM. So, we have… you can find, under the USB Armory repository, because that's the first hardware device that we publish, we have the Tamago repository, and all the different applications that we build.

around this ecosystem. We have, again, bootloader, we have witnesses for transparency ecosystem, we have a trusted… trust and execution environment, hypervisor, so there's a variety of examples, that show the way Tamago works. So, yeah, basically, this is it, and I would love to take any questions on this, if there are, if there are any.

Kevaundray Wedderburn: Thank you, Andre. Are there any questions? I have one… There is one, but I'll do one very quickly. Is there a timeline, or do you expect this to be upstreamed into the Go? The Golang compiler.

Andrea Barisani: So, the proposal that is up there, there's been a hint by the Go Core team that this is going to be considered for 1.27, which is the next major release. So, yeah, my hope would be that in Go 1.27, we have, we have, this functionality baked in. I'm actively following any concern or feedback on that proposal, so, you know, I'm pretty speedy on responding to that, so yeah, that would be my hope. Of course, there's no guarantee, but, you know, there was a hint that they were considering it for 127.

Kevaundray Wedderburn: Okay, thank you. Some said, are there OS-level tweaks built in? higher. Okay, level.

Andrea Barisani: I'm not sure what that means, so… but basically, the way we frame this, the Go compiler modifications, they do… they do not touch, hardware, hardware drivers or hardware initialization. So, everything is laid out so specific hardware, drivers and also initialization can be implemented outside by different, by different libraries. Which means that the Go compiler patch is agnostic in relation to the specific hardware. And so, you know, this way the GoCore team doesn't need to worry about errata's and so forth. As far as major trade-offs compared to regular go, I would say, that there are… there are none, in the sense that the runtime, the scheduling, everything works in an identical way. We also have S&P support

on multi-core. So, the only restriction is that if you try to import a library which is specifically using system calls, so a library that is specifically designed for operating system interaction, it won't compile. So, for instance, if you're importing a terminal application that… a terminal library that's designed to send I.O. control to the Linux kernel. Of course, it won't work. But, you know, by definition, that's not a portable library. But everything else, can be imported just, just as regular, and it runs at equivalent speed, if not faster, than under Linux, because you don't have the overhead of, of, of… of Linux managing other processes for you. So, personally, I don't see any particular trade-offs compared to regular Go. We're using the same compiler, the same runtime, so it's not like TinyGo, where it's actually a different implementation, it's just the same Go code running, just without system call support.

Kevaundray Wedderburn: Cool. Lumi says, have you talked with GEF for ZKVM proving? Last year… I can answer this. Last year, we reached out to Andrea, about using Tamago for ZK Proving, and we have an experimental repository. Where we showed that it works with, ZISC. We did have to… OSIST did have to add in the D, the floating point extensions and atomics, which is why I'm pretty excited for this newer experimental branch that removes both A and D. I can share the link to what we were working on here. Guillaume?

Guillaume Ballet: Yeah. Right, so no, you haven't, talked to, to Geth. That was the answer to Lumi, yeah. I had a question. Actually, two questions. The first one, you said it's considered for 127, right? It's not scheduled.

Andrea Barisani: Yeah, it's been considered, not scheduled, yes.

Guillaume Ballet: Okay, thank you. The other question I had, so you have this branch with, removing, what do you say, AND?

Andrea Barisani: Oh, yes, we remove atomics and double flowing point, yes.

Guillaume Ballet: Yeah, so… are there other… you know, there are lots of extensions that Go Silently uses. What about those? Are they still… first of all, can you remove them, or do you… are you even looking into removing them? Is that an… is that going to become optional? Yeah, what control do we have on the output binary?

Andrea Barisani: So, it all depends on, on the, the instruction set which has been, which has been, which is being created by Go. So, I think in the end, you can control pretty much everything, because there's a nice separation between the, the intermediate representation of the operations in Go, and the actual assembly that comes out. So you have different points where you can hijack that. Then Go also has its own Go assembly for, you know, the math library has its own Go assembly, so… Every time there's a specific instruction that uses a specific extension, it can be, you know, chased down, and it can be changed. Of course, it could be fiddly, right? I only looked at A and D, and that was reasonable. The patch is pretty reasonable. But, for instance, if you ask me about C flag compression.

I would assume that's a little bit more complicated, so I would say it highly… it highly depends on the specific flag that we're… that we're… that we're talking about.

Guillaume Ballet: Okay, thanks. And by the way, what about F as an option?

Andrea Barisani: F.

Guillaume Ballet: Central.

Andrea Barisani: So I just pointed out the chat the flags that we support now. F, I think it can be done. I think… I think it… I think it's possible. I… you might lose some types, I… I'm… but… but I think it could be… I could be… I think it could be possible. Goal has an internal, abstraction. For deciding which registers to use, in order to do internal calls and storing data. And I think that abstraction supports not having floating point at all, because I think it does that at least for one ARM implementation that I know of. So, in principle, I think it's fiddly, more fiddly than the patch that I did now, which I think is fairly compact.

But it is possible. It's theoretically impossible. Theoretically, you can do it.

Guillaume Ballet: Okay, thank you.

Kevaundray Wedderburn: Yeah, I think most of the floating point, the fiddly parts are to do with the assembly, like, floating point move. So when we looked at it, it did seem very tractable, it's just, yeah, a bit fiddly.

Andrea Barisani: Yeah, I think the major… the major issue is that there are a lot of intrinsics. So there are some basic rules for generating assembly, but then there are some intrinsics where Go just takes over and provides optimization, like min, max. and other things. So that's… that's where it can become tricky. But, you know, I had friends that implemented entirely different architectures using, using this abstraction from scratch. And… which means that, you know, potentially, you can support any complete instruction set, as long as it's touring complete, you can do it. So, I have no doubt it's not a theoretical problem, it's just a… it's just a matter of, you know, putting the effort into it.

Kevaundray Wedderburn: Cool. Great. Alright, thank you very much for this. Yeah, and thanks for presenting.

Andrea Barisani: My pleasure. Thank you for the opportunity.

Kevaundray Wedderburn: Thank you. To move on to the project updates, Ignacio… Are you here?

Ignacio Hagiopan: Yeah, I will show the screen. Give me a second… Can you see my screen?

Kevaundray Wedderburn: Yep.

Ignacio Hagiopan: Cool. Let's do this. Yeah, so, we got some updates regarding project number one, which is related to the execution witness for CKVM. As a quick refresher, what is the execution witness? It's basically the information we have to pass through the guest program in order to allow it to execute statelessly. So, regarding updates here, developer Uche has been exploring, benchmarking this engine new payload with Windows RPC, That is already implemented in some ELs, but the main idea here for the exploration is trying to understand how much using this RPC can help into improving the proverb performance pipeline. Because if we don't use this RPC, the way we have to resolve proving blocks is basically doing a separate call to the bug execution witness, and this basically means having to re-execute the block twice.

So… Basically, the main, results here is that how much this RPC helps into the proving pipeline seems to differ a bit, depending on which EL is being used, but this is mostly The root cause of this is mainly EGL haven't really been optimizing this a lot. Some of them use some tricks. That might not be used in others, so… Yeah, there's some difference there in how much utility we can get from it. But the big insight is that, the main bottleneck seems to be the transport layer used, in the RPC. So the way the engine API works today is that you use JSON RPC, and for the worst cases in the execution witness, we have pretty big

Structs that we have to serialize and send as an output. So, he has been exploring using maybe other transports for this, where we can get up to 20x performance improvements in worst cases. So, if you are more interested in understanding more about his work, there are two, reports that he wrote. I will share the slides later. So, yeah, you can look more into it. So this effort is part of a bigger discussion happening today about using SSC in the Engine API to optimize this overhead of using JSON for serializing the output. Some days ago, Julio from the Erigon team has created this ETH research post with some other benchmarks. And also, one of us from the PandaOps team, EDF, has proposed, This more formally in the…

in the specs. So I will really encourage people to look into these two links. And as a last update for, this project, we are very happy to announce that, we have been working and released the first execution with this generation specs. You can find this in the execution specs repo, in the project slash CGBM branch. And this release basically has the first complete specs for this canonical witness generation logic. Plus, around 12,000, field tests, which now has this new execution witness field. That, contains the execution witness for each existing test filled with Amsterdam. So, before making the formal release,

And to gain more confidence that it was doing what we wanted, we compared it with RETH, which also has execution with next generation. I already knew that RED has multiple inefficiencies, So it was a good, experiment to compare both, and… Yeah, basically, we found, multiple… changes to be done in red, which resulted in some PRs, so they can evaluate them and… fixed red to be, to generate canonical execution witness. And also, this allowed us to find bugs in the specs, too. So this basically means that we have more confidence on inviting our ELs to… to, start comparing with the specs. So, the concrete ask for action here, for all RELs is basically to run all these fixtures in the release in stateful mode, as usual.

You make the EL generate the execution witness for the test block, and you compare it against the execution witness field from the fixture to see if your EL is generating the execution witness in the same way that the specs. Of course, since this is the first release, there might be cases where there might be bugs in the specs, so if you have any questions, or do you think that is the case? Please contact some of us, In, in the Discord server. So, the next steps regarding this are basically start creating more tests for the execution witness for their cases, so we can keep hardening the implementation. And yeah, that's mostly it. I know if there's any question.

Yeah, yum.

Guillaume Ballet: Yeah, why didn't you focus on REST knowing… I mean, okay, let me rephrase the question. Did you test with guest at all? Because guest and REST are incompatible, and I would argue REST is buggy. So, why pick the one client that is no longer concerned with Ethereum?

Ignacio Hagiopan: Right, so the specs were written for first principles, so the specs aren't really based on any EL at all. The reason why I chose red is because I already knew it has many bugs from my perspective, regarding what I think is the correct way of generating the execution witness. So, I already knew that RETH and the specs that I wrote should disagree on multiple cases. So that's mainly the main reason why I chose RET, not really because of anything else. I created, actually, these PRs to fix these inefficiencies, and they aren't really merged yet, so… but in any case, what I wanted to do is harden the specs, and be sure that in this first release.

I wouldn't be giving… a lot of ELs, something that might have a lot of bugs, so it was mainly for hardening the specs. But I'm more than happy to help Geth or any other Yelp client to run these fixtures and see if we find anything else.

Guillaume Ballet: And how do you run the fixtures?

Ignacio Hagiopan: Right, so the fixtures are exactly the same as you run today in Yelts, but the fixtures have an extra field called Execution Witness, which has basically the execution witness that the specs consider to be canonical. So the way you have to do this is you run the test as usual, but you also generate the execution witness in URL that you think is correct for this block, and you compare it against this new field in the fixture. So it's basically kind of the same of… You run the test, and you calculate the new slate route. and you compare it to the fixture state route, well, this is kind of the same. You run the test, you generate the execution witness that URL thinks is correct, and you compare it against the

The fixture execution windows.

Guillaume Ballet: If that makes sense to you. Well, kind of. Do you… do you have, like, something like block tests? Like, does the client need to write some kind of specific binary to be able to execute all that stuff, and is it documented anywhere?

Ignacio Hagiopan: No, you don't have to run anything new, apart from supporting generating execution witnesses. There's no new binary needed, or anything like that.

Guillaume Ballet: It's like a new field appears in the current fixtures format. Okay, okay, okay, thank you.

Kevaundray Wedderburn: Maybe a question for Francesco when he gets to his update. It would be good to sort of elaborate on the difference between debug execution witness and engine new payload with witness, because I imagine most of the ZKVM teams are calling debug execution Witness at the moment, and yeah, just specifying how it would change. Ignacio, on this, I guess, would it be useful for the ELs to also experiment with the status input bytes and status output bytes?

Ignacio Hagiopan: Right, I was going to mention this in the Project 2 update.

Kevaundray Wedderburn: Okay.

Ignacio Hagiopan: But, yeah. And just as a last comment for Guillaume, in the release description, we explained a bit more in detail how to use this. So, if you are going to try… give it a try, just read that, and if it's not really clear, just let me know, and we can keep improving.

Kevaundray Wedderburn: Makes sense. Yeah, I guess to clarify, none of this should be new to the EL teams. If you're already testing using EAST, this is just adding in execution witness to your blockchain fixtures, however you ingest them currently.

Ignacio Hagiopan: Okay, so if there's not any other question, I can keep… with giving Project 2 updates. So, project number 2, as a refresher, is, having, A set of specs for what the guest program should do. So, I don't have many slides here, because a lot of work has been happening in the execution specs repo, but… we have, in the same release that I mentioned, just mentioned for the execution witness. In the same, commit, you will see, kind of first draft implementation of the guest program. Here I have, like, a screenshot of this, like, entry point for the guest program, where, it gets the input bytes, and basically executes all the logic. And return the output bytes for the public inputs.

So, I would say that if you are an EL working in guest programs, it might be interesting to start looking at these, current draft specs. We still want to polish it a bit further, so you might expect some changes happening in the, in the branch. And we also want to start creating more tests for the guest program, because… we need to, yeah, cover a lot of cases of invalid inputs, missing information, and things like that. So, probably we'll make, like, an official first… Release, a first official, version in the next release. But you can start looking at it, and… yeah. If you have any feedback, we were… we are more than interested in hearing that.

And related to what Kay was saying, before. In this same release, we already added two extra fields in the fixtures, which are called stateless input and stateless output. So, you can start doing some kind of early experimentation of, At least trying to deserialize, the inputs, testing how this works, because we, in the current specs, we are using SSC for serialization of the inputs. We found this is, like, a neutral choice of encoding for guest programs. But we also know that currently ELs don't have, like, a formal need for having a SCC library. So, as a first step, at least just trying out SCC visualization with whatever library that you might be planning to use in DL might be, like, a good first step.

So yeah, that's everything for project number two. I know if there's any question. Yeah, guillom?

Guillaume Ballet: Yep, sorry, it's me again. Why do you pass in the stateless input? Why do you pass the entire chain config?

Ignacio Hagiopan: You mean, like, a concrete question about the, segless input, structure?

Guillaume Ballet: It's a spec question, yes.

Ignacio Hagiopan: Yeah, so this chain config is basically enough information for the, guest program on how to configure the EVM. You can argue that we can avoid this, and simply assume that it's, like, current mainnet configuration, or something like that. But for testing, this is a bit complicated, because the testing framework redefines really custom forks. So, we think that the most flexible style is to simply provide the chain configuration as inputs, so the same guest program can actually execute, Multiple chain configurations, because it might be… it might be required for running tests with really weird setups, apart from, like, the main use case, which is running mainnet blocks. But yeah, I mean, this is something that we have been discussing a bit, and we are still open to, like, thinking if there are other better options, or similar. But that's kind of the main thinking.

Sumnet?

Somnath Banerjee: So just a clarification for the test, So, currently, the ESTs… Sort of have this… assumption that… the blocks are going to start with the genesis. That is not sufficient to test the witness and how it is being handled. For instance, the MPT… Or the stateless processing. is going to be different, and I think EEST is still not tested at the moment. So you'd need specific tests to verify that rule. your MPT is working correctly for the stateless case, because it's a sparse MPT. It's, like, different.

Ignacio Hagiopan: Right, yeah, so this is… this is related with all these new tests that we are planning to include, in the next weeks, because there are a lot of new cases that are important for the guest program verification step. Yes, regarding the MPT, because you have, like, a partial view of the MPT, and you have to check that the provided information is correct. And also for the other fields, so yeah, I mean, there are a lot of new test cases that should be added to cover all this. Guillaume?

Guillaume Ballet: Yeah, just a question, because from what I understand, to run those tests, you're going to need some pretty beefy backend, right? Like, those guest programs are going to need some setup with, with, like, graphics cards and things, otherwise it's going to take forever. I don't…

Ignacio Hagiopan: Nope.

Guillaume Ballet: Yep.

Ignacio Hagiopan: And… and not because… and… When you run these tests, you are just… Let it start in a fold. You don't have to create any… Proof. of these blocks. It is just, like, trying to see if the stateless execution of the block is… Working correctly. It's not about generating proofs are similar, yeah.

Guillaume Ballet: Okay, stop.

Kevaundray Wedderburn: Ignatio, there are some questions RLP and SSZ. My thinking is that we can only choose between RLP and SSZ. I know some ZKVMs use, like, VIN code or archive. And… I think we just want to go with whatever's more performant here. I don't know if you had any thoughts on that.

Ignacio Hagiopan: Yeah, I think that the encoding part is something that we have to explore more, from some benchmarks that we did a while ago, it seems like RLP was pretty slow compared to SSC improving, but… I know this is something that we can change and keep exploring. This is not, like, something set in stone at this point.

Kevaundray Wedderburn: Okay, sounds good. Marching? Do you want to share slides?

Marcin Bugaj: Hi everyone. So today we're doing a quick recap of Project 3, CKVM Guest API standardization. All the standards discussed here, live at CKVM standards repository. We accepted 3 standards so far. First is the RISC-V target triple. This defines the minimal 64-bit ISA for approving Ethereum blocks. RV64IM is for efficient arithmetic, plus the extension To handle misaligned memory accesses transparently, which prevents compiler edge cases from making blocks unprovable. Second is the I.O. interface. It consists of two functions, read input and writeOutput. This gives guest programs a portable and ZKVM-independent way to receive private inputs and emit private outputs with zero copy support for VMs.

That preload inputs into memory. Third is Cryptographic Acceleration C interface. It's a… it's a C header that exposes EVM precompiled equivalent operations. through a common CAPI. In this way, guest code doesn't need to know anything about the underlying vendor implementation. Yeah, so, a quick reminder on what the standards mean in practice for ZKVM vendors. So, if you're currently running 32-bit ZKVM, migration to 64-bit RISC-V is expected. The target we standardize is a 64-bit machine, and that's not optional for EF use cases. On the Rust side, the Rust target is bare metal, without operating system, and without

standard library support. That's why… as the KPM, SDKs, must be no STD. Must be no STD compatible. If any code in the runtime of the KVM depends on STD, it simply won't compile against this target. Yeah, also, the KVMs should provide I.O. and accelerator implementations for… as part of the SDK. Now for the standards we still need to close. Execution termination semantics has been already reviewed by many stakeholders. And it's ready to accept. In short, it standardizes what happens when a guest program terminates, either cleanly or abnormally. Successful termination may generate a valid proof, but proofs of failed executions must fail verification. This is a security requirement, and also a matter of developer experience.

We'd like to move to accept this standard as soon as possible. If there are no blockers. Please signal your support. Finally, memory layout restrictions. This one needs more attention. Very few vendors have reviewed it so far. And the core idea of the proposal is that HGCKVM vendor is free to define its own memory layout through vendor-specific linker scripts. So, if you haven't read yet the specification, please do, and leave the feedback. We also move, we also would like to, Accept and merge that standard as soon as possible. And that's basically all from my side. Are there any questions?

Kevaundray Wedderburn: Louis said, how much effort would it be for ZKVMs to support F and D RISC-V instructions? A big 5… sorry, a big effort? Just curious. I think the way that ZIS supports it right now is just dispatch into some pre-compiled library. My opinion is that to support F&D, there should be some, like, motivation to support it, and not, like, just because, like, it's… it extends the capabilities of what the ZKVMs can do. Like, the SDF doesn't, require F and D.

Luis Pinto: Yeah, yeah, that's a good point. I'm just, worried about, like, some compilers that might need extra work to… to remove these extensions. Instructions from… from the compiling process, and we might also create the… create… be creating more… a bigger burden on the compiler side, Java… the language compiler side. Because it doesn't use the OS anyway, so why being… Restrictive, instead of being more relaxed. If it doesn't introduce entropy in the system.

Kevaundray Wedderburn: Right, yeah. Yeah, I think that makes sense. I think the main one was actually Go, which was why Andrea's presentation was really good, because he showed that, possibly we can just remove the F and the RISC-V instructions with TomagoGo. But yeah, I definitely got your point. I guess one thing maybe to call out on March and slides is the part about the Rust SDK, meaning that even if your ZKVM supports RV64IM, a lot of the SDKs currently, because they're using forked, because the compilers are forked. you can have an SDK that is the stud library, but once you move to RV64AM, the SDK also needs to be no STD, unless you create another one, because all of the guest programs will be relying on

Like, your SDK. If there are no questions, I think we can move to the next project. Thanks, Martin.

Marcin Bugaj: Thanks.

Kevaundray Wedderburn: Francesco?

Francesco Risitano: Cool. So, I've been working on the Lighthouse implementation. So in regards to feature completeness, you've got the, kind of. core features implemented, so proof validity, using this concept of the proof engine, which I introduced in the last, call. And then, in addition to that, we've got the network, proof sync protocol implemented as well, using the RPCs which are defined in the spec. And then around that, we've got reasonably good integration and unit testing. So, Pretty, happy with the, the code coverage of these new features that we've introduced. I've… we've… there's a bit of a… challenge in regards to, kind of the networking layer around, proof-capable peer discovery, and this was flagged by Manu, but I've got a proposal of how we can address this using,

a new RPC method, and I'll talk a bit more about that in the next slide. But I've opened a PR which essentially uses this RPC And kind of optimizes the naive, proof sync protocol. We've got a few, small features to implement, these shouldn't be too difficult. And then, kurtosis support is kind of the final task, But, yeah, I feel like we're making pretty good progress, and we should be feature complete, in the not-too-distant future. So, a bit more on this execution proof status, RPC. The main problem we have is, Well, the first problem we have is discoverability. So the kind of… the idea is that we will, kind of announce or, yeah, announce to the network using our ENR that we are… we support, proofs.

But the problem is, that, ENR is only visible, from what I understand, to the node which is initiating the connection. So the node that receives the inbound, connection request will not know that the node connecting to them supports, execution proofs, so there's this asymmetry. And in addition to that, we have no awareness of the proof… the kind of… the sync status of proof-capable peers that we're connected to. So we don't know, which peers have validated up to which slot, using… essentially. So we don't know which peers are good to attempt to sync from. So the, the kind of the high-level idea is to introduce this execution proof status, RPC. And this will be invoked eagerly on connection, by the peer who is making connection if they see that the, target peer is advertising the, you know, the execution proof support on their ENR.

And, that way, the receiving peer also knows that, you know, the connecting peer supports execution proofs, and this, I mean, we may be able to do this, you know, with kind of deeper modifications to pre-existing code, but to keep this forkless, you know, we don't require any forks or any changes to kind of pre-existing RPCs or data types, I suspect this is going to be the cleanest solution. So, yeah, high-level idea is that the body of this RPC message is going to be the slot and the block route. That the peer sending the message has, managed to verify using execution proofs, and then, you know, the receiving peer will cache this result, and it can kind of strategically, direct requests based on this information.

and in terms of one of the benefits, they… the… the peer… who receives this status update will be able to determine if, like, a range sync, is gonna be more efficient than doing a by-root sync, where by route is essentially by block or by slot. Whereas ranges, you know, you can sync a range in a single… a range of block proofs in a single request. So, that's the core idea. This isn't finalized or added to the specs. I'd like to speak with Manu and Other individuals working on this effort to see, what the opinions are. And then to proceed… can you see… let me see…

Kevaundray Wedderburn: Yeah. Not sure. Can you see the new diagram? Yep.

Francesco Risitano: Okay, cool. Yeah, I just, threw this together at the last minute, so apologies, that it's not very pretty, but I just wanted to add some context in regards to what Pev, asked. So, this at the top is essentially the current flow that we have for, proving, so… We have some consensus layer validator, they're connected to an execution layer, they invoke, the engine new payload method and receive the result from the execution layer. They then subsequently take that payload and include it in an engine request proofs, essentially just a proof request to the prover, who then has to, kind of enrich or, fetch the execution witness from an execution layer that they, that they maintain. And there's a few complexities here. We, kind of assume that

the prover's execution layer is, in sync with the EL. If not, then I guess, with the, with the peer who is requesting the proofs, is not… if not, then I guess they could, you know, just kind of engine new payload, the payload which they receive from the validator, but that adds re-execution, and it's inefficient, ultimately. And a nice, A nice, kind of. way to address these complexities is to include the witness in the response from the EL. So, new payload with witness essentially sends back the witness, in addition to the result, and then the witness can be included in the request to the prover. Via, yeah, in the request to the prover. So, yeah, in this construct, the prover can be stateless, which is a pretty nice property. There's still some open questions, because

We don't know if, you know, if we're communicating, worst case, hundred… over, you know, on the order of hundreds of megabytes of witness data over the network between remote peers, it may not be efficient. So there's still a number of open questions, but on a high level, this kind of, illustrates the, you know, the changes, that Ignacio touched on, that developer Uche has been working on. Does that cover, enough, Kev? Or do you have some context to add?

Kevaundray Wedderburn: Oh, no, I think this is… this is perfect. We can discuss, like, the rest of it async, I think. Cool, thank you. Okay, thanks one, Jessica. Han?

Han Jian: Yep. Can you see my screen now?

Kevaundray Wedderburn: Yep.

Han Jian: Okay, so I'll give some update on the Project 5 proven subject. So, we have our DIY build tower in preparation. Once it's ready, we can start to use it for our benchmark. It's a 4x4 cluster, so 16, 15, 19 total. And big thanks to EF DevOps team, and Panda Upstein's work on this. And on the ZKVN integration site, we have added the… disk proving cluster integrated, which allows us to test on our 4x4 machine with 16 GPU in the future, and we'll upgrade the SP1 to V6, and publish the proof image with CUDA enabled. And on the ZK attester side, we have drafted the proof node API for the ZK attester to request for execution proof.

And basically, there are just three APIs. One is the request proof with the new payload request in SSD, and with the proof type that the attester would like, and asynchronously, and the attester can use the server send event to subscribe to the proof result. And once the proof is ready, it can use the deterministic endpoint to get a proof that is parameterized by the root and the proof type. And any feedback appreciated on the Proof Node API, that will be used in the chart as the API to communicate with the consensus layer that Francisco just shared. And next, I'll be focusing on the cluster integration that allows us to test on our 4x4 cluster, and

And finish the implementation of Proof Node API on the ZKBoost. And integrate with consensus Layer, and start to experiment the cluster proofing on a 4x4 cluster once it's ready. And here is the, server, per server space spec, and I guess we will have to experiment… experiment a bit to get the optimal performance for the provers, and hopefully, eventually we can make a document that is, be able to, people can Use that to reproduce the setup. Yeah, that's my update.

Kevaundray Wedderburn: Thanks, Han. Any questions, and while we're going through that? Ignacio, do you want to share your screen?

Ignacio Hagiopan: Yes, There's not any questions for Hans' presentation, I can continue.

Kevaundray Wedderburn: Yep.

Ignacio Hagiopan: Okay, cool. So, regarding question number 6, I will go a bit fast, because we don't have much time. Project number 6 is basically around benchmarking everything that is relevant that might have consequences for the protocol. So the most obvious one is proving stuff, how fast we can create the proofs, and if that's within the bounds that we have for within the protocol. So this is related to this, for example, the CAPEX and OPEX, how much money do we have to spin up these pruning clusters, which is the optimal configuration of the cluster for each CKVM. Then we need all these datasets to really know which are worst cases blocks. For computation, for stateful operations, we have all this EL witness generation latency that Developer Lucha has been working with.

But apart from proving, we also have to gain more understanding of proof verification, which are the consequences of… these proof purification latencies and proof propagation within the network. So, yeah, this project is basically around benchmarking everything that is relevant. So, we already touched on this a bit in, two serious articles, Mostly regarding improving and repricings. But yeah, there's… this project number 6 is about basically measuring everything that is relevant. So, as updates for this month, we released, oh, so, I'm sorry. So, there was, like, a new release in these, tests, for benchmarks. Which is basically adding support for Fusaka in benchmarks, which is mainly relevant for ModeX's new repricings. So, using this new release, we rerun all these, benchmark, cases in this 8GPU proving…

Machine that we have. And we publish the results in the dashboard, which… here I have the link, I will share the slides later if you want to take a look. This proving machine is not optimized for CISC. This is mainly all this work that Han and PandaOffice is working on now, by building their own cluster. So, but yeah, I mean, the main… The goal here is to have, like, a really polished pipeline to measure… worst-case blocks, for Ethereum, and figure out which is, like, the repricing required to really, support block proving for 100% of the blocks. So, the next steps around this is I will try to see… to integrate Maria's analysis pipeline that she's using for she-style repricings.

Because at the end of the day, after you do the measurements, the rest… Of the work that you have to do for repricings is to analyze, these measurements and… get to the new repricing. So, the analysis part… can be shared with the same methodology that we are using today for She-star. So, I will be exploring this more in detail next, so we can have, like, an end-to-end pipeline where we do the measurements in the proving cluster. And as the end result, we have the same analysis results. That we are using for She-star. Apart from that, we also released a new dashboard, which is the proof verification dashboard. This is, formally measuring the proof verification latency for each CKE VM.

This is pretty relevant for network propagation of the proofs, if we are assuming that proof verification is required before key propagating the proofs within the network. So, the way we are doing this benchmarking is basically running the proof verification in machines that comply with the IP7870, which are the hardware specs that we expect from validators. The dashboard basically does this for two machines that are really close to what the EIP defines as hardware requirements for testers. So, yeah, I invite people to just simply open up the dashboard and see the results. Apart from proving verification latencies. Approved from proof… verification latency, I also… I also show the proof size of each CKVM, and also the current security bits pulled from the SAMCALC project from the cryptography team in DF, so…

trying to show all the angles here, because, of course, the more security bits you have, that might influence the proof verification latency. So in order to have, like, a fair comparison here, The three… the three things are shown. Proof verification latency, proof size, and security bits. And as a final update here, This is coming from Raphael from PandaOps. He added support for, custom RRPC calls after benchmark runs. In Benchmarker. And for us, this is pretty important, because if we want to have a way to capture execution witnesses. for… particular stateful logos, such as balance, store, and store. We need to actually run these benchmarks in stateful environments. And what this feature from Benchmarker allows is to leverage BlogNet to capture the execution witness in these worst cases of…

stateful of codes. So, this is great for us, because, We didn't have, like, a good way to do this from the east. Fixtures, because east fixtures don't really have, like, a big state. So yeah, thanks a lot, Rafael, for implementing this feature. And that's all from project number 6. I don't know if there's any question.

Kevaundray Wedderburn: While we look for questions, Cody, do you want to share your screen?

Cody Gunton: No questions?

Kevaundray Wedderburn: I think you can go.

Cody Gunton: Okay, cool. Well, yeah, thanks everyone for making it this far. This is a quick update on security, project number 7. I posted a link to these slides because they have some links in them you might be interested in in the Zoom chat. Oh yeah, I can start this. So yeah, first of all is on RISC-V compliance testing. There are these standard architecture tests here, that are used, you know, across hardware, the hardware industry for testing RISC-V, and that's, tested using this framework, but this name, maybe, I think you pronounce it Riskoff, I'm not sure. But, you know, it's kind of a weird, messy framework that was a little hard to integrate, but and I'm happy to say that they've gotten rid of that. So now there's something called Act 4, which is being announced here on the forums, the RISC-V forums.

And, it's easier to integrate, and it also has some new tests, and they're going to have a better, like, schedule of releasing these things and making it clear what are the canonical versions of the various pieces of this. So, yeah, I'm working to integrate that into our test monitor. Soundcalc, I'm speaking here a little on the behalf of the cryptography team, so they had asked, teams to integrate into SoundCalc, which is this Python tool that they use to, carefully, clearly write down the, like, security analysis in terms of number of bits of security of the protocols, the ZK protocols. They have finished these integrations, and you can see a summary of the results at the link here.

It's great work from them. Thanks for everyone who, who contributed there. There's this interesting paper that got, a lot of attention, maybe a month ago, about formal verification, where this author, Nadeem Kobasi, I think is how you pronounce it, found some bugs in, formally verified libraries, including within the formal verification boundary. And, I think this is interesting for us as, sort of, like, level setting about what we can expect from the methods. Not to say that we expect to find bugs, but rather, it helps us to know what to look for. There's a very explicitly written down framework for describing the formal verification boundary and some, you know, helpful tips about how to audit these things in this, so that'll be useful for us as things move forward.

Oh, excuse me, I lost my… Oh, it's not advancing. Here we go. So yeah, on this final point, I've been trying to create starter specs for, some of the ZKVMs, including ZISK, or I started with ZISK. So I used AI to translate the implementation to Python, and then it's all reinforced by test vectors, and I, yeah, this has been reviewed by some of the teams, and I'm getting positive responses on the results there, so maybe we have some progress on creating specs for the protocols. And also, I've had a lot of conversations about what the value of the specs are, like, who they're for, and, where they… should they go in the consensus layer specs. That was a proposal that I think most people agree is, doesn't make sense, so…

Some progress on the value of specs, broadly speaking, how they should be targeted. And that's all for me. Thank you.

Kevaundray Wedderburn: Any questions? We did Q&A sort of interleaved, so, there's not gonna be a massive Q&A part at the end. Any questions for Cody? Okay, cool. I mean, yeah, we can also take questions async as well in the Discord channel, and as time goes by, I believe Project 1 and 2 should be… have very shorter updates, If there's nothing else, yeah, thank you all for coming to the second L1ZKVM breakout call. I'll see you in a month.

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