L1 zkEVM Breakout #4

Transcript

Ladislaus: Hello, nope.

Kevaundray Wedderburn: Hello. 2… Can you hear me?

Ladislaus: Yep, bit quiet, but other than that…

Kevaundray Wedderburn: Okay, great. Oh, wait, did you say a bit quiet?

Ladislaus: No, no, it's fine. It's fine, actually.

Kevaundray Wedderburn: Okay, great. Ignacio.

Ladislaus: Oh.

Ben, hi, Luca.

Kevaundray Wedderburn: Yeah, Gary, I think it's just quiet.

Gary Schulte: Cool. Need to get some math rock or something in the intro while we wait for people to show up.

Kevaundray Wedderburn: Cool. I think we can give it one more minute before starting. Cool. Okay, we can start now, starting the recording. Welcome to the L1ZKVM breakout call number 4. Today we have two updates to go through, so DevNet updates and project updates. For the project updates, we're going to start with Project 4, which is the CL integration. Manu is going to go first, and then Francesco can follow.

So, Manu, do you want to unmute?

Emmanuel Nalepa: Yes. Okay, I won't reshare my screen. Okay. Sorry for that. Okay, do you see my screen?

Kevaundray Wedderburn: Yep.

Emmanuel Nalepa: Okay, perfect, thank you. So, yes, I just want to share briefly as an optional proofs update on Prysm. So very briefly, we had 3 mods now for Prysm. The first one is when you want to, have a mod to generate… which generates a proof. So, on the VCFI, you just add the general proof flag with the overall West API, which is DK Boost. And just so, yes, basically, you have the BN, gets the block from Gossip, the VC pulls the block from the beacon node, generates new payload requests. and sends it to DKBoost. And then ZK boost pulls the witness from the EL, generates the proof, and the proof, and the VC sends the proof.

and sends it to the BN, and the BN gossip the proof. And so, yes, you have an optional proof, which is now signed and available for other nodes. Okay, so that's for the general proof part. If you want to use the proof as a node, not to generate them, but to verify them, you can use the ZKVM equals execute and verify on the BM node. Not on the VC, but on the BN. And yeah, just basically, it's like, today, the BN gets a block, and the poof… but the proof from gossips. the BN sends the execution payload to the EL, and the proof to ZK boost, and ZKBoost verifies the proof, EL executes the payload. And the more important part is if there is a missing proof, an invalid proof.

Then the block is… Imported optimistically. And then missing proofs can be retrieved by RPC if needed. And there is something which is a little bit out of spec, but I still implemented it, is availability to connect to use a beacon node without any execution client, so in Kurtosis, you have EL type again none, and in the BN, you set ZKVM equals verify only. And in this case, just, yeah, we just totally remove the… resection part of the… of the ejection pallad, and only, you know. the BN, relies on ZKBoost. to verify the proof, and import the proof if… import the block if the proofs are correct, and then… and else consider the block as optimistic. And here, you can see on the right that,

Normally, in code to this, you'll have a number, and then the EL type, and then the CL type, and here you have only the number and the CL type. which is Prysm, and here you can see that we can… Event proposal block. Without any EL. And yes, for sure, here, in this case, you need a builder, because you cannot propose a local blog, because you don't have a… Local execution clients. And, okay, what is remaining to… what is remaining? Yes, basically, I just… you have a lot of conflicts with some developed branch. We need to clean the code, right now it's not really… re… we disabled. We missed unique tests, and yes, important thing, all the optional proof parts are based on the follow-up.

I think we should move on Glossas, soon? And yes, what about DevNets? We have two Kurtosis interoperable implementation, Lighthouse and Prysm. As you can see here, we have Lighthouse and Prysm, yeah. And, yes, we should maybe think about, starting on devnet next week. And everything is available in this tool request here. optional proof branch on Prysm. That's all I had to say.

Kevaundray Wedderburn: Oh, thanks, Manu. Any questions? while folks are typing, I have, like, one question, or two questions. For the EL type none, what happens if the proof never arrives, or it arrives after a finalization checkpoint?

Emmanuel Nalepa: Yes. So, is the proof… is it the same for the, yellow again, or, you know… Or even when you need the EL and the proof. So, if there is no proof, then the node, the block, sorry, is optimistic. not as, optimistic as if… The ELR did not catch up, yet. The same behavior, optimistic behavior, and especially if you have to propose a block, and if some blocks… Are missing some proofs, then you cannot propose a block. And then, there is two choices. Either you retrieve the missing pool via RPC. And if you cannot, for some reason, Until the proof with missing blocks. Sorry, until the block with missing proofs is not finalized, then you are optimistic, and when the block is finalized, then you can… Proposal blocks.

Kevaundray Wedderburn: Okay, I see. So when I have an EL, even if the proof is late, I don't fall back to the EL, I still need to wait for proofs to arrive?

Emmanuel Nalepa: Yes.

Kevaundray Wedderburn: Okay.

Emmanuel Nalepa: It's actually what the specer is saying now. Currently, the spec is saying, you know, you need both, you need both the Yale and both the proofs. If you choose to activate the ZKVM flag, of course.

Kevaundray Wedderburn: Okay, great, yeah. Thank you, Monty. You know, this is where it, If no questions, Francesco, did you want to go next?

Francesco Risitano: Yep. Can you see my screen?

Kevaundray Wedderburn: Yep.

Francesco Risitano: Cool. Okay, cool. Yeah, I'll just speedrun, these updates. So, first of all, myself and Ignacio are working on a rewrite of the EIP, so that's in progress. I've got a link to the PR And yeah, we're iterating on that at the moment, in preparation for proposal, for consideration. in, H-star. In addition to that, we've made some, general modifications to the consensus layer specs, and we've got those merged in. a few modifications to the, the, the, this should actually be the proof engine, Proof Engine API. I mistyped there. And in addition to that, this, capability where you… where nodes can kind of dynamically advertise… advertise which proof types they support. So the, the ambition here is, we should be able to, Nodes should be able to kind of negotiate which proofs, they both support, and thus, you know, kind of select, those proof types when

gossiping between each other, and now this could be useful, potentially, for iterating on guests and, ZKVMs. So, that can be done kind of dynamically, via, via gossip. We had to make some… we had to make a change to the max proof size, which is defined in the CR specs. We bumped it to 400, KI… KIB. We likely will bump this once again, probably higher… above, 1MB. Now this is just an interim change. The issue is that currently the proof… the provers are not, kind of, optimized, so proof sizes are pretty big. Of course, we do have our, like, ambitious targets of below 300, kilobytes, but in the interim, I don't want, you know, we probably want to avoid

CL, implementers, or, from implementing 300KB, and then, you know, kind of running into this, running into an issue where, all proofs are just being rejected. I know that I lost maybe, I don't know, an hour or so, but just to have it, clearly defined, and then we can reduce that as, as we proceed. I wrote up the issue, or kind of some context in regards to this validator proof re-signing proposal. But after discussion with… with the maintainers of the CL specs, we decided that, this, you know, we should deprecate this idea, essentially. The idea with this was for, DOS prevention. But the conclusion is that it's probably sufficient to just use peer scoring as opposed to needing, this mechanism.

There has been some open question about, supporting, like, optional execution, an optional execution engine. So, kind of as Manu just, presented, the idea where you can run a, a beacon node in absence of the execution engine, there's a bit of contention here about whether this should be supported at the protocol level or not, like the specs level or not. In any case, I wanted… I did open a PR, which is, kind of an alternative to the PR that Barnabas opened, just to say that if this is the direction we're going in, maybe, you know, this is a clean way we can represent that in the specs, but, I'm not sure if we should. Maybe we should keep it out of the specs and just, you know, if client teams do want to support

this, then that they can kind of provide a fork, for that functionality. made some updates to the Beacon APIs, to reflect, kind of, the latest, the latest state. I opened a proposal on the execution APIs, and this is around the witness retrieval. I'm actually uncertain what the latest status is on that, but if I'm not mistaken, when this was proposed previously, there was some concern around introducing, like, the withWitness endpoints. So the idea here is that, you embed a, like, require witness boolean in the arguments of the pre-existing engine API methods, and then you also introduce a execution witness field in the return types, and yeah, essentially kind of communicate the witnesses via that mechanism.

there has been some discussion around the proof type encoding, so internally, in kind of the EIP-8025 effort, we've kind of been aware that proof… the encoding probably isn't, you know. comprehensive enough to represent different guests, different versions, different, ZKVMs, etc, and kind of future iteration. But in addition to that, I believe, the community are also interested in ensuring that, we also provide, capability to represent more generic guest, and ZKVM combinations, for example, I believe it was L2B, are proposing this for kind of the native roll-up construction, So, yeah, where it's not necessarily using the EVM STF guests. So, I've opened an issue for that, and I invite, the community to kind of contribute and discuss on that front.

I've written up some of the considerations for proof gossip, so at the minute, we kind of eagerly gossip proofs, but the idea is that we should, we should consider using libp2P. I have Messages with some appended metadata, and then have, peers that require that message pulled. Instead of having just kind of this eager, dissemination of proofs, because, it's possible that the kind of target peer already has a proof of that type, so we want to kind of reduce network bandwidth and redundancy. We've, we've landed, we've landed the GPU airprover support in, in the main of the Ethereum package, so, yeah, it should be pretty seamless now to spin up, the GPU network. or a network with GPU prover support, with multiple clients, Lighthouse and, and Prysm.

We managed to run, the, Lighthouse and Prysm Interop DevNet, so, very similar to what, Manu just, just presented. I wrote up a document which details the general, kind of, software architecture of the Lighthouse implementation. The, ambition of this was to communicate the architecture to the maintainers of Lighthouse, because ultimately we want to upstream this, upstream these components, so maybe that's going to be an effort that I'll push a bit harder over the next… over the coming weeks. But yeah, that's available for people to review, maybe if people want to just get a general idea of the implementation. And then similarly, I have, removed, deprecated the validator re-signing logic to align with, the conclusion of the, specs discussion… discussion.

So yeah, that's all from… that's all from me.

Kevaundray Wedderburn: Thanks, Francesco. There is one question by Gary, he said, ETH P2P, question mark.

Francesco Risitano: So this is the, consensus layer, P2P. Yep.

Gary Schulte: Right, if we were… looking for, lower bandwidth and better propagation. I was just… and it's going to be a different channel. ETHP2P might be an option that would be… perform even better than LibP2P.

Francesco Risitano: Right. What is the status of, EP2P? Is that, kind of production ready? Is that… is that deployed on the, on the network?

Gary Schulte: you know, I don't know the status of it at the moment. I think that it's got a, a DevNet that's been running for a significant amount of time, but, Yeah, depending on how far out we're looking at, optional proofs, ETHP2P could very well be… Ready and more optimal than… Continue with lib pttp.

Francesco Risitano: Yeah, yeah, I certainly think that's, something that we should, consider. Yeah, certainly see value there in using that. I guess we need to review, kind of, timelines, and alignment of, of the two. But at least in terms of initiating discussions to ensure that, kind of. the execution-proof dissemination is considered in the context of P2P would be good, because ultimately that seems to be the direction we're, we're moving in. But there is an open source contributor that has offered to, kind of spec out the lib p2P side of things, and yeah, I intend to kind of support them on that effort, but yeah, certainly interested in the P2P stuff as well.

Kevaundray Wedderburn: Great. Thanks, Francesca. If that's all… Ignacio, do you want to start?

Ignacio Hagiopan: Yeah, let me shut the screen… Huh. Can you see my screen?

Kevaundray Wedderburn: Yes.

Ignacio Hagiopan: Okay, I will go through the updates for projects number 1 and 2. I bundled them because, yeah, that's, I think, much easier. Project number 1 and 2 are related to the execution witness and guest program spec and tests. So, on the spec and test side, the latest release is, 0.34. This was done a couple of days ago, I think 2 weeks ago. The main changes here are supporting the block test engine format. This is mainly in preparation to be able to run execution witness fixtures using Hype, potentially. So we have a dashboard for execution witness compliance in state full deals. And we did another bunch of, fixes, mainly regarding types, in the guest input, stateless.

Input type, Yeah, mainly the release has the details, so you can look there. There are some upcoming changes that are kind of ready, so I'm planning to cut a new release probably today or tomorrow. And just as a… Quick. a shot of what this is about. We are including some schema ID prefix into the bytes of the guest program input. This is mainly to be able to signal to the guest program which is the target type to deserialize the types into, because SSZ is not really self-describing encoding format. We are also including the chain config as part of the stateless input, which allows you to use the same guest program, for a lot of execution environments, been running the tests in IST, which creates some custom forks, running the same guess we're running in mainnet or Debnets.

So that, simplifies a lot of infrastructure regarding, using a single guest program. And also, filling the public keys field in the stateless input. This field is already there for quite a while, but we didn't really fill them properly. So, I will explain all this in more detail in the new release details description, and you can also read some kind of discussions around these things in the Discord channel that we had some days ago. On the EL front side, I had a lot of progress from a lot of ELs. From the Ethrec side, they work on running a more comprehensive set of the East releases, and not only the 8025, custom fixtures, but also leveraging all the rest of forks that we also, generate the execution witness.

I made a PR to, allow, eTrex to be, like, closer to accepting raw SSZ, bytes as inputs, In the same shape of the current specs. And then is, work on multiple changes, that improve performance on the eFrex side. He will be doing a presentation later in this call, so, we want to share mainly these things, if maybe something that everybody else can leverage or have in mind. On the Nethermind side, they will be also presenting their progress later in the call, but they have been doing work on many fronts, and they published a nice blog post with these updates. And Ruben also has been, collaborating with me on some of these, upcoming changes in the next release regarding improvements in the stateless inputs, next iteration.

On the red side, it was MRSA change that I proposed around February, so it's like a long DPR. To allow Reth also to generate canonical execution witnesses. And they have been also working on supporting official, East releases, instead of, like, some really old custom fork, that, I created some months ago. So, yeah, good progress there. Nimbus has also been doing a lot of progress, on the Silcworm side, Some is experimented with some potential alternative guest input design, and this is really useful for us, because maybe we'll… Let's start to, signal maybe other… Further iterations of the guest programmer input that can allow the guest program to be more performant. Developer Ruche has proposed a PR in our guests to include Silcworm as a spec-compliant guest program.

This is… this will be a great milestone, because it will be, like, the third cache program that we support in that repo, and actually the first non-Rust one. And on the vessel side, I've been doing great progress on guests, runs of fixtures. They help us, identify many spec, Problems that were already fixed, but yeah, amazing progress on their side, too. As a last extra mentionings, on the last ACDE, I proposed 7709. For Hegota, this is something that, as a side effect, we allow to simplify The execution witness part, regarding how BlogHash is resolved and verified, and, Also, as, like, while Nimbus was running the execution witness fixtures that we created, our fixtures actually found a bug.

in their BAL implementation, which is really nice to see that, at least The work that we have done has helped other, Other changes that are coming in the next fork. And this is, like, a link of something that Tav already mentioned in his presentation, which is a new potential proposal for how to use semantic versioning for test programs and CQVMs, so maybe if you want to take a look there and leave your comments. On the project number 6, which is benchmark and metrics, I will go through this very quickly. I did a fresh run on, 6… 6, .161, for the erects and Reth programs, so things look much better now, because in this release, they…

Mainly remove this cycle limit that made a lot of our fixtures scratch. So, things look much better now. I also included a new dashboard, which I call SISC Profiling, which is basically showing all the SISC profiles for all the fixtures in these tests. An idea is a bunch of improvements in the repression dashboard, that maybe you want to take a look. And on the east side of things, I found a bug and implemented a fix in a tool that is called Worst Case Miner. This is used for East to create tests related to deep branches. This is used for Glamsterdam, some… some Glamsterdam fixtures regarding… Deep ST store that are considering… being considered for repricing tasks in Glamsterdam.

And I created a new benchmark for deep branch S loads. This is not super relevant for re-execution, because usually, you know, the stateful deals have a flat database for doing S loads. But for guest programs, this case is pretty… relevant, because guest progress. have to verify Merkel Patricia tree proofs. of S-loads, so we really need this taste to be covered. And yeah, that's it from my side.

Kevaundray Wedderburn: Thanks, Ignacio. Gabrielle said, will the next release be bal-devnet-7 specs, or built on top of bal-devnet-7?

Ignacio Hagiopan: Yes, correct. That's correct.

Kevaundray Wedderburn: Hmm… Okay, cool. I think Ben also wanted to give a small, update.

ben: Yeah, can you hear me?

Kevaundray Wedderburn: Yep.

ben: Yeah, I hope yes. Okay. Yeah, cool. Okay, so, can you see the screen also?

Kevaundray Wedderburn: Yep.

ben: I hope, yeah. Okay, cool. Yeah, so I joined the ZKVM team last month, and generally my goal is to make the guest programs more friendly towards ZKVMs, and Specifically for past month, I looked at the pair eFrex and ZISK, and this has really nice tooling for profiling that lets you analyze the ZISK costs. For the… for the specific functions. And this helped me to… to make free PRs, which combined reduced the air costs up to 26%. So, the first one was a relatively easy win, when there were, some Hash function calls, which weren't utilizing precompiles. So, this, gave us massive 21% reduction in the air costs. And the second two are still in review, they're related. So the first one removes the round dependency for the parallel iterators, and since the execution is strictly single-threaded.

This is just posing pure overhead, and the second one does something very similar for… for the sink. So these are the locks and atomics. And, yeah, there is… the improvement there is slightly better, or slightly worse, only… 0.5%. But this is, basically pure overhead, so there is no reason for not including this. And as the next steps, I'm currently looking into some of the crashing EST tests. So I hope I can figure this out, and I also want to continue on the optimization of the guest program. And there I have 3 ideas, so I'll cover also the remaining hash function calls that aren't using the precompiles, hopefully this should be easy. Then I want to, rewrite the execution witness such that it uses SSD serialization instead of archive. I also tried it last month, but hopefully this month I will have better luck on that.

And the last thing, I noticed that there are some calls to large bit arithmetic, which might not be super efficient. There is some native, 256-bit arithmetic in ZISK, and I'll see if I can port this directly into eFrex, and if it actually makes any improvement. So yeah, if you have any other suggestions for further optimizations. please reach out, and I'll be also happy to help your team. Thanks.

Kevaundray Wedderburn: Thanks, Ben. Yeah, that looks great. No questions… for discs… Martin, if you want to start sharing your screen. Luca, I see the question on if there's interest in making the program hashes independent. I'd probably ask ZKVM teams to chime in when available. Oh, sorry, Martin? Yeah.

Marcin Bugaj: Yep. So, hi everyone. Quick update on Project 3, the KVM Guest API standardization. We now have 5 accepted standards. Quick recap. The RISC-V target defines the ISA RV64IM. with unaligned data accesses, the I.O. interface gives guest programs a portable way to read private inputs and write public outputs. We have Cryptographic Accelerator's API, which is a C header for calling pre-compiled equivalent operations. Execution termination semantics says that successful execution may produce a proof. And failed ones cannot. And memory layout restrictions, which lets each vendor own their linker script, while source-level portability is preserved through The other standards. There are, currently,

3 more are currently in review, Memory Safety Guard Regions, and two new ones that I will cover next. So the first new standard is about what happens when a jump lands on a non-aligned address. Without a compressed instruction extension, RISC-V requires instructions to be 4-byte aligned. If a jump targets an unaligned access, the ISAR should raise an exception. The problem is that different ZKVMs, handle that exception differently. Common divergence from, The standard is rounding the address down to 4 bytes boundary, which could produce a valid proof. of a broken execution, so the standard closes that gap. It says that misaligned jumps must cause abnormal termination, no recovery, and no rounding. is permitted.

The second new standard defines the runtime that vendors must ship alongside their ZKVMs. Two pieces, a single static library, and a linker script. The static library must contain start symbol, the I.O. functions, and the crypto accelerator implementation. Start function is responsible for setting up the stack. zeroing BSS section, preparing I.O, and then calling, main. On the application side, guest programs implement the main function. The value returned by the main must be translated to successful or abnormal termination. Consistently with the standard termination semantics. Standard. The linker script must be provided and must be compatible with both LD and LLVM's LLD. And must expose at least two standardized symbols, heap start and heap end.

Those symbols are needed so that, The application can define its own memory allocator. We're also looking at whether to standardize U256. interface. We benchmarked 12 U-256 operations from one of these KVMs in isolation. And the summary is on the screen on the left. And the results are mixed. Multiplication delivers strong gains, 2 to even 6 times, depending on the operand size. Addition and subtractions are more modest, and several subtraction variants are actually slower than the software implementation. And assuming that performance profile, we then measured the impact on 500 realm minor blocks using only multiplication, division, and remainder accelerators.

with a Reth-based Ethereum client. So the result is a very small, so to speak, negligible improvement. So that is, not settled. We need more investigation before proposing a standard, in particular, whether these poor numbers would hold with improved acceleration for addition and subtraction. And with the presence of acceleration for, beatwise operations. And, a reminder to vendors, So, all the KVMs are expected to migrate to RV64. Rust SDK must be no STD. And as it was mentioned, the I.O. and accelerator interfaces have to be bundled into the static library. Actually, there was some progress on the standard implementation in ZISK, so they… there's an implementation of no STD

SDK, and also there is progress, on SP1's side. both links are on the screen. Yeah, also, if you need any help implementing those standards, Ethereum Foundation can provide engineering support. That's it for my site.

Kevaundray Wedderburn: Great. Thanks, Martin. No questions. For the U256 acceleration interface, which ZKVM did you use?

Marcin Bugaj: Whoa. I don't know if I want to disclose. It was, it was Zisk. Yeah.

Kevaundray Wedderburn: Okay, makes sense. And that's RV64, versus, like, something that's RV32, where the performance might be different because it's, like, Freddy2 versus 64 bits?

Marcin Bugaj: Yeah, so, yeah, as I said, those results, and experiments were conducted quite thoroughly, but, I want to double-check and… Yeah, perform some additional checks, like, using maybe Bitwise, Operations acceleration, and to see how it goes.

Kevaundray Wedderburn: Okay, cool. And on the issue, Ruben mentions two open PRs that, we could potentially take async. One of them is to add the catchACF permutation instead of using the catchAC function itself. Or possibly both. The other is just standard output capabilities, so just being able to write, debug logs, for example.

Marcin Bugaj: Yeah, I've seen those.

Kevaundray Wedderburn: Yeah, so…

Marcin Bugaj: Ruben also raised some concern, about, read input, function from the I.O. standard. So I hope that he would open a GitHub issue, and we could continue discussion there.

Kevaundray Wedderburn: Okay, that makes sense. For the cat check F permutation, I think it might be useful for ZKVM teams to, opine their, Just because it's a different interface versus the catch track function itself. Cool. Alright, thanks, Margin. Thank you. on… If you're here…

Han Jian: Hello? Can you see my screen?

Kevaundray Wedderburn: Yep.

Han Jian: Sure, I'll… I will give, go through the project approval updates. So, we have simplified the ZKBoost configuration in the ECRM package. Previously, we have to assign the prover image and the gas program links manually, but now it resolves them automatically, so we only have to set the GPU count for the prover now.

Luca Donno: I looked in. Dark, fizzy, animal coloured.

Han Jian: And we also have, in Nexus, we have separated the verifier crate from the prover, so any verifier now given the program and verification key can verify proofs. And so… so… so we have also released the program verification key with the ELF in the array guest repo. And with these two, now we also integrated the verifier into the DK Boost directly. So, previously, when the proofs… when the proof verification flow looks like this, when the consensus layer receives a proof, it sends a request to ZKBoost, but ZKBoost forwards that to the prover to do the verification, actually. For now, we… we have integrated the Verify in DKBoost directly, so… the verifier mode of the cables doesn't have to spin up the prover container anymore, and thanks to Stefan to start this effort.

And next is to add binding of the verifier crate in different language. So, ideally, the consensus layer can verify the proof, like, locally, and it doesn't even need to start the CK boost. And… but currently, some of the verifier crates are very huge, because, some SDKs have their verifier, with their prevert together, and I also look into… If I can try to, separate land on upstring. And to make the verified library eventually smaller. Oh, so… try to finish the disk 0.17 update and the cluster client integration in DKBoost, so we can be ready when our on-premise cluster is ready. That's all from me. Thanks.

Kevaundray Wedderburn: Thanks, Han. No questions. One thing which might be interesting, I know Eve Proofs is, have verifiers in the browser, and that's done by compiling, the verifier library to WASM. if the difference between verifying in WASM versus verifying natively is not too big, it might make sense to also just reuse a WASM crit, or a WASM library.

Han Jian: Yeah, I will be looking into that soon, but my concern is the… Versioning might be a bit annoying to coordinate, but, like, ideally, every… should provide the verifier for its proof to use directly. Right. But I have to figure out the proof, serialization things first to… to make sure the thing works together.

Kevaundray Wedderburn: Right, makes sense. Francesca asked, how big is the size of the standalone verifier binary? I guess this is… these are the ones that do not have the prover embedded with it.

Han Jian: For… folder… Yeah, I don't have a number now, but I think that the… I will try to get some number and get that here soon.

Kevaundray Wedderburn: Cool. Thanks, Han no other questions. Cody, are you here?

Cody Gunton: Yeah. Right. Oops, I'm on… Alright, so… This, past month, lots happened. We have some grantees working on fuzzing, and they've been finding bugs and have some novel test cases that aren't covered by the RISC-V compliance test suite, that they've been using. I'll let them, finish patching those and write their disclosures. There'll be a blog post, though, so look out for that later in the year. I don't think too long. I have work in progress to formally RISC- formally verify the RISC-V semantics of the ZISK proving system, and that's all on its way. I'm hoping, I can seek external review, within a couple of weeks.

And this is based heavily on the OpenVM effort by another mine. I took that example and ran with it. The cryptography team has asked for architecture white paper drafts from the ZKVM vendors, and they got a good response there, so thank you to everybody who wrote up these descriptions of their proving systems, it's very helpful. We have… formal verification highlights that I am pulling from the ArcLib rep repo. That's, that's here, arclib. where, Yeah, this is… there's a lot going on there, but just to give a flavor, we have progress on, making the FRI spec computable, improving soundness of FRI, formally. And here are some PRs, in that vein. And we also have, work on the SumCheck Protocol, which is coming along.

I also… I know that that work, Kuang mentioned in his talk this past weekend at ArcLib Day, which maybe I should have had a reference here, but we had a conference this past weekend on ArcLib, and more broadly on the suite of formal verification. libraries that are being produced by the formerly verified DKVM project. There are some great talks to see from this past weekend for those who are interested in that. And yeah, Kuang Dao gave a, gave a talk on Some of this work. Looks like I can recommend. Also, it's been alluded to, but there… Nethermind has, has expanded the coverage of… or expanded the capabilities of the proving system a bit, so I ran some tests, which I haven't pushed to the monitor yet, to see whether it's actually meeting the requirements of this extension.

that Martin just mentioned, and it looks like it does, so it would be the first ZKVM To fully comply with our standard from the testing perspective. Except for a very small, gap, so this is adding on the lined axes, as I'm saying here. And there's a very small gap, which is not covering certain cases of an instruction that's just a no-op, so it's effectively compliant, with this nether mind work. That's very exciting. This is the branch where that's happening. Yeah, that's a… that's a brief flavor. Thank you, everyone.

Kevaundray Wedderburn: Thank you, Cody. I'm checking for questions… No questions, it seems. Okay, are there any, sort of, open questions that people have? If not, I guess, yeah, we can finish early, for once. Yeah, thank you guys for joining the call. We can continue discussions async on Discord if anyone else has any questions that do come up. And I'll see you guys in one month.

ben: Bye.

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