Kevaundray Wedderburn:Beth, welcome to the L1 ZKVM breakout call number 2.
Transcript
Kevaundray Wedderburn:This call will be…
Kevaundray Wedderburn: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.
Kevaundray Wedderburn:So, to start it off, Andrea, can you share your screen?
Andrea Barisani:Yup, hello, everyone.
Andrea Barisani:Oh, one second… I think you need to unshare yours, otherwise it doesn't allow me to, yeah.
Andrea Barisani:Can you see it?
Kevaundray Wedderburn:Yeah.
Andrea Barisani:Okay, yeah.
Andrea Barisani: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.
Andrea Barisani:So basically, TAMAGO is a modification of the regular Go compiler with the aim to be accepted upstream, so there's a proposal
Andrea Barisani:in progress for that, which takes the regular Go runtime, and all of its ecosystem
Andrea Barisani: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.
Andrea Barisani: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.
Andrea Barisani: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.
Andrea Barisani: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.
Andrea Barisani: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
Andrea Barisani:A small but, solid, range of devices, going from physical devices.
Andrea Barisani: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
Andrea Barisani: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.
Andrea Barisani: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.
Andrea Barisani:sort of API, which allows with, few functions, six functions specifically, to enable execution of the runtime in a freestanding, environment.
Andrea Barisani: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.
Andrea Barisani: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.
Andrea Barisani:The same goes for debugging. GoTrace works as expected, PProf, GDB, everything works, as expected.
Andrea Barisani:And so…
Andrea Barisani: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.
Andrea Barisani: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.
Andrea Barisani: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.
Andrea Barisani:Very recently, we made a further experimental branch in Tamago, where we are running on even smaller targets, so now we're capable
Andrea Barisani: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
Andrea Barisani: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.
Andrea Barisani: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.
Andrea Barisani: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
Andrea Barisani: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…
Kevaundray Wedderburn:There is one, but I'll do one very quickly.
Kevaundray Wedderburn:Is there a timeline, or do you expect this to be upstreamed into the Go?
Kevaundray Wedderburn: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,
Andrea Barisani: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?
Kevaundray Wedderburn:higher.
Kevaundray Wedderburn: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.
Andrea Barisani:Which means that the Go compiler patch is agnostic in relation to the specific hardware.
Andrea Barisani:And so, you know, this way the GoCore team doesn't need to worry about errata's and so forth.
Andrea Barisani: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
Andrea Barisani: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.
Andrea Barisani: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…
Andrea Barisani: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.
Kevaundray Wedderburn:Where we showed that it works with, ZISC.
Kevaundray Wedderburn: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.
Kevaundray Wedderburn:I can share the link to what we were working on here.
Kevaundray Wedderburn:Guillaume?
Guillaume:Yeah. Right, so no, you haven't, talked to, to Geth. That was the answer to Lumi, yeah. I had a question.
Guillaume: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: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:Yeah, so… are there other… you know, there are lots of extensions that Go Silently uses.
Guillaume: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,
Andrea Barisani:I think in the end, you can control pretty much everything, because there's a nice separation between the, the intermediate representation
Andrea Barisani: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…
Andrea Barisani:Every time there's a specific instruction that uses a specific extension, it can be, you know, chased down, and it can be changed.
Andrea Barisani: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.
Andrea Barisani: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:Okay, thanks. And by the way, what about F as an option?
Andrea Barisani:F.
Guillaume: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…
Andrea Barisani: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.
Andrea Barisani:For deciding which registers to use, in order to do internal calls and storing data.
Andrea Barisani: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.
Andrea Barisani:But it is possible. It's theoretically impossible. Theoretically, you can do it.
Guillaume: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.
Kevaundray Wedderburn: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.
Andrea Barisani: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.
Andrea Barisani:And… which means that, you know, potentially, you can support any
Andrea Barisani: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.
Kevaundray Wedderburn: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:Yeah, I will show the screen.
ignacio:Give me a second…
ignacio:Can you see my screen?
Kevaundray Wedderburn:Yep.
ignacio:Cool. Let's do this.
ignacio:Yeah, so, we got some updates regarding project number one, which is related to the execution witness for CKVM.
ignacio: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.
ignacio:So, regarding updates here, developer Uche has been exploring, benchmarking this
ignacio:engine new payload with Windows RPC,
ignacio: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.
ignacio: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.
ignacio:So… Basically, the main, results here is that
ignacio: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
ignacio:The root cause of this is mainly EGL haven't really been optimizing this a lot. Some of them use some tricks.
ignacio:That might not be used in others, so…
ignacio:Yeah, there's some difference there in how much utility we can get from it.
ignacio: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
ignacio:Structs that we have to serialize and send as an output.
ignacio:So, he has been exploring using maybe other transports for this, where we can get up to 20x performance improvements in worst cases.
ignacio: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.
ignacio:So this effort is part of a bigger discussion happening today about using SSC in the Engine API to
ignacio:optimize this overhead of using JSON for serializing the output.
ignacio:Some days ago, Julio from the Erigon team has created this ETH research post with some other benchmarks.
ignacio:And also, one of us from the PandaOps team, EDF, has proposed, This more formally in the…
ignacio:in the specs. So I will really encourage people to look into these two links.
ignacio: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.
ignacio:You can find this in the execution specs repo, in the project slash CGBM branch.
ignacio:And this release basically has the first complete specs for this canonical witness generation logic.
ignacio:Plus, around 12,000, field tests, which now has this new execution witness field.
ignacio:That, contains the execution witness
ignacio:for each existing test filled with Amsterdam.
ignacio:So, before making the formal release,
ignacio:And to gain more confidence that it was doing what we wanted, we compared it with RETH, which also has execution with next generation.
ignacio:I already knew that RED has multiple inefficiencies,
ignacio:So it was a good, experiment to compare both, and…
ignacio:Yeah, basically, we found, multiple…
ignacio:changes to be done in red, which resulted in some PRs, so they can evaluate them and…
ignacio: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.
ignacio: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.
ignacio: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.
ignacio: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
ignacio:questions, or do you think that is the case? Please contact some of us, In,
ignacio:in the Discord server.
ignacio: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.
ignacio:And yeah, that's mostly it. I know if there's any question.
ignacio:Yeah, yum.
Guillaume: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: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.
ignacio:So, I already knew that RETH and the specs that I wrote should disagree on multiple cases.
ignacio: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.
ignacio:I wouldn't be giving…
ignacio:a lot of ELs, something that might have a lot of bugs, so it was mainly for hardening the specs.
ignacio: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:And how do you run the fixtures?
ignacio: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
ignacio: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
ignacio:in URL that you think is correct for this block, and you compare it against this new field in the fixture.
ignacio:So it's basically kind of the same of…
ignacio:You run the test, and you calculate the new slate route.
ignacio: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
ignacio:The fixture execution windows.
Guillaume:If that makes sense to you.
Guillaume: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: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:It's like a new field appears in the current fixtures format.
Guillaume: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.
Kevaundray Wedderburn: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:Right, I was going to mention this in the Project 2 update.
Kevaundray Wedderburn:Okay.
ignacio:But, yeah.
ignacio:And just as a last comment for Guillaume, in the release description, we explained a bit more in detail how to use this.
ignacio: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:Okay, so if there's not any other question, I can keep…
ignacio:with giving Project 2 updates. So, project number 2, as a refresher, is, having,
ignacio:A set of specs for what the guest program should do.
ignacio:So, I don't have many slides here, because a lot of work has been happening in the execution specs repo, but…
ignacio:we have, in the same release that I mentioned, just mentioned for the execution witness.
ignacio:In the same, commit, you will see, kind of first draft implementation of the guest program.
ignacio: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.
ignacio:And return the output bytes for the public inputs.
ignacio: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.
ignacio:We still want to polish it a bit further, so you might expect some changes happening in the, in the branch.
ignacio:And we also want to start creating more tests for the guest program, because…
ignacio: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…
ignacio:Release, a first official, version in the next release.
ignacio:But you can start looking at it, and… yeah.
ignacio:If you have any feedback, we were… we are more than interested in hearing that.
ignacio:And related to what Kay was saying, before.
ignacio:In this same release, we already added two extra fields in the fixtures, which are called stateless input and stateless output.
ignacio:So, you can start doing some kind of early experimentation of,
ignacio:At least trying to deserialize, the inputs,
ignacio:testing how this works, because we, in the current specs, we are using SSC for serialization of the inputs.
ignacio:We found this is, like, a neutral choice of encoding for guest programs.
ignacio: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.
ignacio:So yeah, that's everything for project number two. I know if there's any question.
ignacio:Yeah, guillom?
Guillaume:Yep, sorry, it's me again. Why do you pass in the stateless input? Why do you pass the entire chain config?
ignacio:You mean, like, a concrete question about the, segless input, structure?
Guillaume:It's a spec question, yes.
ignacio:Yeah, so this chain config is basically enough information for the, guest program on how to configure the EVM.
ignacio:You can argue that we can avoid this, and simply assume that it's, like, current mainnet configuration, or something like that.
ignacio:But for testing, this is a bit complicated, because the testing framework redefines really custom forks.
ignacio: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,
ignacio: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.
ignacio: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.
ignacio:Sumnet?
Somnath Banerjee:So just a clarification for the test, So, currently, the ESTs… Sort of have this… assumption that…
Somnath Banerjee:the blocks are going to start with the genesis. That is not sufficient to test
Somnath Banerjee:the witness and how it is being handled. For instance, the MPT… Or the stateless processing.
Somnath Banerjee:is going to be different, and I think EEST is still not tested at the moment.
Somnath Banerjee:So you'd need specific tests to verify that rule.
Somnath Banerjee:your MPT is working correctly for the stateless case, because it's a sparse MPT.
Somnath Banerjee:It's, like, different.
ignacio: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.
ignacio: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.
ignacio: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.
ignacio:Guillaume?
Guillaume: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.
Guillaume:I don't…
ignacio:Nope.
Guillaume:Yep.
ignacio:And… and not because… and… When you run these tests, you are just…
ignacio:Let it start in a fold.
ignacio:You don't have to create any… Proof.
ignacio:of these blocks. It is just, like, trying to see if the stateless execution of the block is…
ignacio:Working correctly. It's not about generating proofs are similar, yeah.
Guillaume: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.
Kevaundray Wedderburn:And… I think we just want to go with whatever's more performant here.
Kevaundray Wedderburn:I don't know if you had any thoughts on that.
ignacio:Yeah, I think that the encoding part is something that we have to explore more,
ignacio:from some benchmarks that we did a while ago, it seems like RLP was pretty slow compared to SSC improving, but…
ignacio: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.
Kevaundray Wedderburn:Marching?
Kevaundray Wedderburn:Do you want to share slides?
Marcin Bugaj:Hi everyone.
Marcin Bugaj:So today we're doing a quick recap of Project 3, CKVM Guest API standardization.
Marcin Bugaj:All the standards discussed here, live at CKVM standards repository.
Marcin Bugaj: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
Marcin Bugaj:To handle misaligned memory accesses transparently, which prevents compiler edge cases from making blocks unprovable.
Marcin Bugaj:Second is the I.O. interface.
Marcin Bugaj: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.
Marcin Bugaj:That preload inputs into memory.
Marcin Bugaj:Third is Cryptographic Acceleration C interface. It's a… it's a C header that exposes EVM precompiled equivalent operations.
Marcin Bugaj:through a common CAPI. In this way, guest code doesn't need to know anything about the underlying vendor implementation.
Marcin Bugaj:Yeah, so, a quick reminder on what the standards mean in practice for ZKVM vendors.
Marcin Bugaj:So, if you're currently running 32-bit ZKVM, migration to 64-bit RISC-V is expected.
Marcin Bugaj:The target we standardize is a 64-bit machine, and that's not optional for EF use cases.
Marcin Bugaj:On the Rust side, the Rust target is bare metal, without operating system, and without
Marcin Bugaj:standard library support.
Marcin Bugaj:That's why… as the KPM, SDKs, must be no STD.
Marcin Bugaj: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.
Marcin Bugaj:Yeah, also, the KVMs should provide I.O. and accelerator implementations for… as part of the SDK.
Marcin Bugaj:Now for the standards we still need to close. Execution termination semantics has been already reviewed by many stakeholders.
Marcin Bugaj:And it's ready to accept.
Marcin Bugaj: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.
Marcin Bugaj:This is a security requirement, and also a matter of developer experience.
Marcin Bugaj:We'd like to move to accept this standard as soon as possible. If there are no blockers.
Marcin Bugaj:Please signal your support.
Marcin Bugaj:Finally, memory layout restrictions. This one needs more attention. Very few vendors have reviewed it so far.
Marcin Bugaj:And the core idea of the proposal is that HGCKVM vendor is free to define its own memory layout through vendor-specific linker scripts.
Marcin Bugaj:So, if you haven't read yet the specification, please do, and leave the feedback.
Marcin Bugaj:We also move, we also would like to,
Marcin Bugaj:Accept and merge that standard as soon as possible.
Marcin Bugaj: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.
Kevaundray Wedderburn:I think the way that ZIS supports it right now is just dispatch into some pre-compiled library.
Kevaundray Wedderburn: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.
Kevaundray Wedderburn:Like, the SDF doesn't, require F and D.
Luis Pinto | Besu: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.
Luis Pinto | Besu:Instructions from…
Luis Pinto | Besu: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.
Luis Pinto | Besu:Because it doesn't use the OS anyway, so why being…
Luis Pinto | Besu:Restrictive, instead of being more relaxed.
Luis Pinto | Besu: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.
Kevaundray Wedderburn:But yeah, I definitely got your point.
Kevaundray Wedderburn: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.
Kevaundray Wedderburn: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
Kevaundray Wedderburn:Like, your SDK.
Kevaundray Wedderburn: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.
Francesco Risitano:So in regards to feature completeness, you've got the, kind of.
Francesco Risitano:core features implemented, so proof validity, using this concept of the proof engine, which I introduced in the last, call.
Francesco Risitano: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.
Francesco Risitano:And then around that, we've got reasonably good integration and unit testing. So,
Francesco Risitano:Pretty, happy with the, the code coverage of these new features that we've introduced.
Francesco Risitano:I've… we've… there's a bit of a…
Francesco Risitano: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,
Francesco Risitano: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
Francesco Risitano: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,
Francesco Risitano:But, yeah, I feel like we're making pretty good progress, and we should be feature complete, in the not-too-distant future.
Francesco Risitano:So, a bit more on this execution proof status, RPC. The main problem we have is,
Francesco Risitano:Well, the first problem we have is discoverability. So the kind of… the idea is that
Francesco Risitano:we will, kind of announce or, yeah, announce to the network using our ENR that we are… we support, proofs.
Francesco Risitano:But the problem is, that, ENR is only visible, from what I understand, to the
Francesco Risitano: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.
Francesco Risitano:And in addition to that, we have no awareness of
Francesco Risitano: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.
Francesco Risitano:So the, the kind of the high-level idea is to introduce this execution proof status, RPC.
Francesco Risitano: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.
Francesco Risitano:And, that way, the receiving peer also knows that, you know, the connecting peer supports execution proofs, and this,
Francesco Risitano: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.
Francesco Risitano:So, yeah, high-level idea is that the body of this RPC message is going to be the slot and the block route.
Francesco Risitano: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.
Francesco Risitano:and in terms of one of the benefits, they… the… the peer…
Francesco Risitano: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.
Francesco Risitano: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
Francesco Risitano:Other individuals working on this effort to see, what the opinions are.
Francesco Risitano:And then to proceed… can you see… let me see…
Kevaundray Wedderburn:Yeah. Not sure. Can you see the new diagram?
Kevaundray Wedderburn: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…
Francesco Risitano: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.
Francesco Risitano: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.
Francesco Risitano:And there's a few complexities here. We, kind of assume that
Francesco Risitano:the prover's execution layer is, in sync with the EL. If not, then I guess, with the,
Francesco Risitano: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.
Francesco Risitano:And a nice, A nice, kind of.
Francesco Risitano: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.
Francesco Risitano: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
Francesco Risitano: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,
Francesco Risitano: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.
Francesco Risitano: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.
Kevaundray Wedderburn:Cool, thank you.
Kevaundray Wedderburn:Okay, thanks one, Jessica.
Kevaundray Wedderburn:Han?
Han Jian:Yep.
Han Jian:Can you see my screen now?
Kevaundray Wedderburn:Yep.
Han Jian:Okay, so I'll give some update on the Project 5 proven subject.
Han Jian: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.
Han Jian:And on the ZKVN integration site, we have added the…
Han Jian: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.
Han Jian:And on the ZK attester side, we have drafted the proof node API for the ZK attester to request for execution proof.
Han Jian: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.
Han Jian: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.
Han Jian: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.
Han Jian:And next, I'll be focusing on the cluster integration that allows us to test on our 4x4 cluster, and
Han Jian:And finish the implementation of Proof Node API on the ZKBoost.
Han Jian:And integrate with consensus Layer, and start to experiment the cluster proofing on a 4x4 cluster once it's ready.
Han Jian: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
Han Jian:Use that to reproduce the setup.
Han Jian:Yeah, that's my update.
Kevaundray Wedderburn:Thanks, Han.
Kevaundray Wedderburn:Any questions, and while we're going through that? Ignacio, do you want to share your screen?
ignacio:Yes,
ignacio:There's not any questions for Hans' presentation, I can continue.
Kevaundray Wedderburn:Yep.
ignacio:Okay, cool. So, regarding question number 6, I will go a bit fast, because we don't have much time.
ignacio: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.
ignacio:So this is related to this, for example,
ignacio: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.
ignacio:For computation, for stateful operations, we have all this EL witness generation latency that Developer Lucha has been working with.
ignacio:But apart from proving, we also have to gain more understanding of proof verification, which are the consequences of…
ignacio:these proof purification latencies and proof propagation within the network. So, yeah, this project is basically around benchmarking everything that is relevant.
ignacio:So, we already touched on this a bit in, two serious articles,
ignacio:Mostly regarding improving and repricings.
ignacio:But yeah, there's… this project number 6 is about basically measuring everything that is relevant.
ignacio: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.
ignacio:Which is basically adding support for Fusaka in benchmarks, which is mainly relevant for ModeX's new repricings.
ignacio:So, using this new release, we rerun all these, benchmark, cases in this 8GPU proving…
ignacio:Machine that we have.
ignacio: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.
ignacio:So, but yeah, I mean, the main…
ignacio:The goal here is to have, like, a really polished pipeline to measure…
ignacio:worst-case blocks, for Ethereum, and figure out which is, like, the repricing required to really, support block proving for 100% of the blocks.
ignacio: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.
ignacio:Because at the end of the day, after you do the measurements, the rest…
ignacio:Of the work that you have to do for repricings is to analyze, these measurements and…
ignacio:get to the new repricing. So, the analysis part…
ignacio: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.
ignacio:And as the end result, we have the same analysis results.
ignacio:That we are using for She-star.
ignacio: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.
ignacio: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.
ignacio: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.
ignacio:The dashboard basically does this for two machines that are really close to what the EIP defines as hardware requirements for testers.
ignacio:So, yeah, I invite people to just simply open up the dashboard and see the results. Apart from proving verification latencies.
ignacio:Approved from proof…
ignacio: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…
ignacio: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,
ignacio:The three… the three things are shown. Proof verification latency, proof size, and security bits.
ignacio:And as a final update here,
ignacio:This is coming from Raphael from PandaOps.
ignacio:He added support for, custom RRPC calls after benchmark runs.
ignacio:In Benchmarker.
ignacio:And for us, this is pretty important, because if we want to have a way to capture execution witnesses.
ignacio:for…
ignacio:particular stateful logos, such as balance, store, and store. We need to actually run these benchmarks in stateful environments.
ignacio:And what this feature from Benchmarker allows is to leverage BlogNet to capture the execution witness in these worst cases of…
ignacio:stateful of codes. So, this is great for us, because,
ignacio:We didn't have, like, a good way to do this from the east.
ignacio:Fixtures, because east fixtures don't really have, like, a big state.
ignacio:So yeah, thanks a lot, Rafael, for implementing this feature.
ignacio: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:No questions?
Kevaundray Wedderburn:I think you can go.
cody:Okay, cool.
cody: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.
cody:Oh yeah, I can start this.
cody: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,
cody:tested using this framework, but this name, maybe, I think you pronounce it Riskoff, I'm not sure. But,
cody: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.
cody: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
cody:versions of the various pieces of this. So, yeah, I'm working to integrate that into our test monitor.
cody: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,
cody: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.
cody:It's great work from them. Thanks for everyone who, who contributed there.
cody: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,
cody:found some bugs in, formally verified libraries, including within the formal verification boundary. And, I think this is interesting for us as,
cody: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.
cody:Oh, excuse me, I lost my…
cody:Oh, it's not advancing. Here we go. So yeah, on this final point, I've been trying to create starter
cody:specs for, some of the ZKVMs, including ZISK, or I started with ZISK.
cody: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
cody: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…
cody:Some progress on the value of specs, broadly speaking, how they should be targeted.
cody: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.
Kevaundray Wedderburn:Any questions for Cody?
Kevaundray Wedderburn: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,
Kevaundray Wedderburn:If there's nothing else, yeah, thank you all for coming to the second L1ZKVM breakout call. I'll see you in a month.
Chat Logs
00:12:02
Somnath Banerjee:Are there OS level tweaks built in?
00:12:18
Lumi | Offchain Labs:Have you talked with Go Ethereum team for ZK proving GETH?
00:12:48
Somnath Banerjee:Replying to "Are there OS level..."
*HW/target level
00:13:08
Guillaume:nope
00:13:30
Ruben:any major tradeoffs comapred to regular go?
00:15:22
Łukasz Rozmej:Can you share slides?
00:15:30
Kevaundray Wedderburn:Replying to "Have you talked with..."
https://github.com/eth-act/skunkworks-tama/tree/kw/develop
00:15:54
Andrea Barisani:https://github.com/abarisani/abarisani.github.io/tree/master/research/tamago
00:16:05
Andrea Barisani:Slides
00:17:42
Andrea Barisani:rv64cfimsu
00:19:36
Lumi | Offchain Labs:Any plans to target WASM?
00:19:52
Andrea Barisani:wasm is already supported by Go
00:20:05
Andrea Barisani:https://go.dev/wiki/WebAssembly
00:20:33
Kevaundray Wedderburn:Replying to "Any plans to target ..."
Do you mean wasm32-unknown or with wasi?
00:22:18
Łukasz Rozmej:There is an initiative to move to REST and SSZ on engine API
00:22:21
Kevaundray Wedderburn:Replying to "Any plans to target ..."
We didn’t have time to go into it, but we also tried Go -> WASM -> C -> RISCV64 and Tamago seems to be the most performant
00:22:45
Lumi | Offchain Labs:Replying to "Any plans to target ..."
wasm32-unknown
00:24:33
Trent:See here: https://github.com/ethereum/execution-apis/pull/764
00:24:36
Andrea Barisani:Can you share slides?
I just updated the deck at the link I shared earlier. For any further questions please email me, happy to help.
00:24:44
Guillaume:and bugs
00:25:15
Łukasz Rozmej:Can you review Nethermind implementation?
00:25:33
Kevaundray Wedderburn:Replying to "Can you review Nethe..."
I started looking into it a few days ago
00:28:36
Iván | Lambda:Are you planning on supporting EIPs 7708, 7778, and 7843 in the new spec tests? I’ve been integrating them with ethrex and made ~13 of them pass by “disabling” those EIPs
00:29:09
Łukasz Rozmej:can you post the link to the spec?
00:29:27
Iván | Lambda:https://github.com/ethereum/execution-spec-tests/releases/tag/zkevm%40v0.2.0 if I’m not mistaken
00:31:03
Kevaundray Wedderburn:Replying to "can you post the lin..."
Yep this is correct
00:31:47
Kevaundray Wedderburn:Replying to "can you post the lin..."
We use the projects/zkevm branch on the execution-specs repo: https://github.com/ethereum/execution-specs/tree/projects/zkevm
00:32:12
Gary Schulte:link to guest spec?
00:32:39
Somnath Banerjee:Is there any guest program tests at all, other than EESTs at the moment?
00:32:40
Kevaundray Wedderburn:Replying to "link to guest spec?"
Its in the execution specs repo here: https://github.com/ethereum/execution-specs/blob/1d98b55a4a5d0615bca62ec69b308096059f6c06/src/ethereum/forks/amsterdam/stateless_guest.py#L33
00:32:53
Ruben:@kev i believe all the links to the slides, specs, etc. will be provided after the call like the last time, right?
00:33:29
Gary Schulte:ssz neutral == 😂
00:33:30
Kevaundray Wedderburn:Replying to "Is there any guest p..."
Can you clarify what would need to be added?
00:33:41
Somnath Banerjee:Zilkworm uses RLP
00:34:07
Kevaundray Wedderburn:Replying to "@kev i believe all t..."
Yep, it will be on the issue
00:34:09
Gary Schulte:Replying to "Zilkworm uses RLP"
zevm-stateless, besu zig guest is using rlp also
00:34:50
Kevaundray Wedderburn:Replying to "Zilkworm uses RLP"
What is being RLP’d?
00:34:59
Gary Schulte:Replying to "Zilkworm uses RLP"
stateless_input
00:35:13
Łukasz Rozmej:Replying to "Zilkworm uses RLP"
Nethermind is currently using RLP
00:35:16
Somnath Banerjee:Replying to "Zilkworm uses RLP"
The witness + block data
00:35:19
Luca Donno | L2BEAT:chain id as input helps with native rollups
00:37:14
Kevaundray Wedderburn:Replying to "Zilkworm uses RLP"
We can benchmark concretely with zkVMs,ssz was more performant outside of circuit.
I don’t think we have a strong bias towards ssz or rlp
00:38:31
Gary Schulte:historically ELs do not have a complete-enough SSZ implementation
00:38:52
Łukasz Rozmej:we have to go with something platform/library independent
00:39:00
Somnath Banerjee:Replying to "Zilkworm uses RLP"
RLP should be slower, but it's the EL standard now. We plan on switching to something faster (not ssz)
00:39:12
ignacio:Replying to "historically ELs do ..."
Yes, this is true. Although this other chats of potentially supporting SSZ in EngineAPI might give more reason on maybe trying to support it
00:39:38
Kevaundray Wedderburn:Replying to "Zilkworm uses RLP"
I don’t think we can standardize on something that is not rlp or ssz because every EL will need to support it
00:40:25
Gary Schulte:Replying to "historically ELs do ..."
if ssz engine api makes it into a fork, definitely that should resolve it. I wasn’t expecting that to actually make it into a fork though
00:40:25
Kevaundray Wedderburn:Replying to "Zilkworm uses RLP"
Maybe message pack? But I think we should benchmark because it could be a micro optimization that is not needed
00:40:51
Gary Schulte:Replying to "Zilkworm uses RLP"
https://xkcd.com/927/
00:41:26
Francesco Risitano:Replying to "Zilkworm uses RLP"
Transport protocol doesn’t necessarily have to follow the same encoding as zkvm input, however it may make sense to do so.
00:42:59
Luis Pinto | Besu:How much effort would be for ZKVms to support F and D RISC-V instructions? A big effort? Just curiosity
00:43:11
Somnath Banerjee:Replying to "Zilkworm uses RLP"
We put in RLP, speculating on the standards. But as of today the pre-processing is a reality and we can just do something way faster with the pre-processing. The JSON-RPC can and should be replaced with RLP or ssz and we can tweak it further
00:48:33
Manu:That’s why there is also the info in metadata
00:49:00
Kevaundray Wedderburn:Would we need a MetadataV4 for that?
00:49:18
Manu:Replying to "That’s why there is ..."
It’s already done if I’m not wrong
00:49:46
Manu:Replying to "That’s why there is ..."
here
00:49:47
Manu:Replying to "That’s why there is ..."
https://github.com/ethereum/consensus-specs/pull/4877
00:49:51
Kevaundray Wedderburn:Replying to "That’s why there is ..."
You mean for 8025?
00:49:58
Manu:Replying to "That’s why there is ..."
yes
00:50:26
Kevaundray Wedderburn:Replying to "That’s why there is ..."
Ah yeah, I think the idea is that with ExecutionProofStatus, we would not upgrade the version
00:56:14
Francesco Risitano:Introducing a new version touches pre-existing codepaths and adds complexity because peers would have to use different versions of the existing status type for different peers. I think its cleaner to have things decoupled into a separate rpc @Manu
01:01:57
Andrea Barisani:I need to go, thanks for the opportunity of presenting TamaGo. Again email me for any questions, happy to help, I think it would be a very interesting use case for it. Cheers.
01:01:59
Kevaundray Wedderburn:We also have been analysing what precompiles we can turn into evm bytecode.
Currently doing some analysis to see how often the precompiles are being used.
The main issue right now is modexp imo
01:03:50
cody:https://codygunton.github.io/talks-and-writing/2026-03-11-zkevm-breakout/
01:03:58
ignacio:Slides for Proj 1, 2 and 6: https://docs.google.com/presentation/d/1fmSZYyp8SNl3FHw4JQGAz1Ik0gQlfq6XEYcV1xLPChc/edit?usp=sharing
01:04:45
Han Jian:Slide for project 5 https://docs.google.com/presentation/d/1Iw5RqCIrhvhmAWUl9UjAS9I1zSq1Lr50YVukGMqmqp0/edit?usp=sharing