Kevaundray Wedderburn:Welcome to L1ZKVM, breakout tool number one.
Transcript
Kevaundray Wedderburn:For the newcomers, breakout calls are used in Ethereum to give a dedicated space to projects that are going to be shipped. Once the project is scheduled to be shipped in a hardcore…
Justin Drake:to be recording, sorry to interrupt.
Kevaundray Wedderburn:I believe we are recording.
Justin Drake:Okay, perfect.
Kevaundray Wedderburn:Oh, yeah, thank you. Yeah, so once the… once the project is scheduled to be shipped, during a hard fork, the breakout call then usually gets merged into the main governance call, which is known as All Core Devs.
Kevaundray Wedderburn:So, the goal of this breakout call is to advance the roadmap that we set out earlier this year, that you all saw in the planning document. Let us know if you could put a link in the chat for people that want to look at it.
Kevaundray Wedderburn:This call in particular will just be used to give an overview of the different work streams in the planning document, and we're going to give space for each person who's been working on each individual workstream, about 3 to 5 minutes to just explain, like, what's happening.
Kevaundray Wedderburn:On shipping, we're aiming to have the work done by Glamsterdam, just because the main thing that's blocking is, ePBS, and we're aiming to also ship it, or propose it to be shipped in Hegota.
Kevaundray Wedderburn:So, on that, I will start…
Kevaundray Wedderburn:So, for logistics, we're aiming to have a monthly call on the second Wednesday of the month, 3pm UTC, all async discussions. Please put them inside of the ETH R&D channel. We have two, channels for this.
Kevaundray Wedderburn:And on an announcement, the stateless team is hosting a Stateless Summit at EVCC.
Kevaundray Wedderburn:On April the 1st, if you want to find out more details about this, just please scan the QR code.
Kevaundray Wedderburn:So, just zooming out a bit, to explain the difference between mandatory and optional proofs.
Kevaundray Wedderburn:So, with mandatory proofs, all the attesters are required, all the attesters require proofs in order to deem a block as valid. Re-execution by then will likely not be possible if you want to keep up with the chain.
Kevaundray Wedderburn:this is a massive change to Ethereum, and so we're sort of doing it… we're sort of doing this intermediate step known as optional proofs, which front-loads a lot of the work and allows us to test it in a safer way.
Kevaundray Wedderburn:With optional proofs, only some attesters need to… can opt into accepting proofs, but the majority of the attesters on the network will continue to re-execute as normal.
Kevaundray Wedderburn:this breakout call, just to be explicit, will be for optional proofs. We may touch on some mandatory proof topics, but the main goal is for optional proofs.
Kevaundray Wedderburn:Okay, so let's look at, sort of, what happened within a slot post-Glamsterdam, but pre-ZK, and we're using this to sort of motivate the workstream breakdown that we saw in the planning document.
Kevaundray Wedderburn:I've split it into two phases. So, phase one involves the builder, proposer, and a tester.
Kevaundray Wedderburn:The builder proposes an execution payload, which is a block, or EL block.
Kevaundray Wedderburn:They then submit something known as a bid, and a bid commits to the execution payload, plus some value that the builder is putting on the execution payload.
Kevaundray Wedderburn:the proposer for that, slot, then selects a bid. It can… because multiple builders will be publishing bids.
Kevaundray Wedderburn:They produce a beacon block, And they submit this beacon block to the network.
Kevaundray Wedderburn:The attesters then validate the beacon block, produce attestations, and submit these attestations to the network. So this is the first phase.
Kevaundray Wedderburn:One minor note that might be interesting to folks who've never seen ePBS before is that once the attester validates the block.
Kevaundray Wedderburn:the builder's balance is unconditionally reduced, so if he says that he's bidding 5 ETH, 5 ETH is unconditionally taken from the builder's balance.
Kevaundray Wedderburn:The second phase, if you have seen ePBS, you can see that I've, like, massively simplified this part by removing the PTC, but the second phase
Kevaundray Wedderburn:For our purposes, the builder then submits the execution payload to the network, the attesters then validate the execution payload, and for this, they obviously need an execution layer client.
Kevaundray Wedderburn:I'll be taking questions at the end, by the way, I can't see the chat.
Kevaundray Wedderburn:Okay, so what's the problem with this? The main problem is that the attester needs an execution layer client in order to validate the execution payload.
Kevaundray Wedderburn:What this means is that as the gas limit increases, it's gonna take a lot longer to validate that the execution payload is correct, which means the attester's hardware requirements have to rise in order to do it in the same amount of time.
Kevaundray Wedderburn:Which obviously leads to centralization pressure. Like, as you increase the hardware requirements and the bandwidth requirements, it becomes harder to be in a tester.
Kevaundray Wedderburn:Okay, so how does… how do ZKVMs actually solve this issue?
Kevaundray Wedderburn:Let's go back to Phase 1. Everything is the same, apart from this new object called an execution witness.
Kevaundray Wedderburn:Phase 2 changes massively, And I'll give the caveat that
Kevaundray Wedderburn:there are many design decisions that we can make here, like, if the builder is the prover, you can imagine there's just one box here. If the prover is now a known entity in the protocol, you can imagine the prover sort of sending to the attester directly. But with this current design, I'll explain how it goes. So the builder selects guest programs.
Kevaundray Wedderburn:Ignacio will say what these are.
Kevaundray Wedderburn:They then submit an execution witness that they produced in Phase 1, the execution payload, and the guest programs, to this new entity called approver.
Kevaundray Wedderburn:The prover then creates proofs, based on the guest programs, execution witness, and the execution payloads.
Kevaundray Wedderburn:he submits the ZK EVM proofs to the builder, and then the builder then forwards it to the attesters.
Kevaundray Wedderburn:The attester then selects guest programs independently. If the guest programs that the attester selects and the guest programs that the builder selects are different, then the proof would not… will not verify.
Kevaundray Wedderburn:So, the attester selects the guest programs, they then use the bid that they received from Phase 1, and verify all of the ZKVM proofs.
Kevaundray Wedderburn:So, the guarantees that they get here are more cryptographical, but essentially, if they verify the ZKVM proofs, it's…
Kevaundray Wedderburn:Roughly equivalent to them validating the execution payload by re-executing.
Kevaundray Wedderburn:Okay.
Kevaundray Wedderburn:So…
Kevaundray Wedderburn:Now, these are the… if you've read the document, these are the 8, projects that we've split, or 8 work streams that we've split the work into.
Kevaundray Wedderburn:The first is this execution witness object. We want to spec it out and optimize it.
Kevaundray Wedderburn:So this is the, the first object that the builder produces in Phase 1 and submits to the prover.
Kevaundray Wedderburn:The second is the guest program. That needs to be proven.
Kevaundray Wedderburn:Deferred is this API boundary between the ZKVM and the guest program, and standardizing it, and Martin will talk a lot more about this.
Kevaundray Wedderburn:The fourth is the consensus layer, so we need to make changes on the consensus layer in order to accept proofs and other sort of infrastructure changes.
Kevaundray Wedderburn:The fifth is the prover infrastructure, so the actual software that's creating the proofs.
Kevaundray Wedderburn:The 6 is benchmarking and metrics, so this is related to RTP, but also it's metrics and benchmarks for the consensus layer. Like, if we submit these proofs on the network, how long does it take for the 66% of the network to actually see these proofs, since they are quite big at the moment?
Kevaundray Wedderburn:And the seventh is security, which Cody will go into more details about.
Kevaundray Wedderburn:The eighth is, like, an external project, that we're not focusing on, which is ePBS. The reason is because we can't actually do this without ePBS. We need enough time to create these proofs. Currently in Fulu, which is what we've currently… which is what we currently have on Ethereum, it's about roughly 2 to 4 seconds, which is obviously not enough time.
Kevaundray Wedderburn:Okay, so with that, I will start taking questions before we go to Ignacio, who will talk about the execution Witness and the ZKVM guest program.
Kevaundray Wedderburn:I'll just check the chat.
Kevaundray Wedderburn:Oh, thanks, bro.
Kevaundray Wedderburn:Oh yeah, sorry, also Eve Bruce is at Eve CCC. Yeah, sorry, I didn't put it in my slides. There's a link in the description for…
Kevaundray Wedderburn:for how you can register for Beast Merd.
Kevaundray Wedderburn:Okay, so the first question is, what is the expected size of the ZKVM proofs? So currently, we're looking, the current,
Kevaundray Wedderburn:The best case is it's 128 kilobytes. We're currently focusing on 300 kilobyte proofs, but I believe some ZKVMs are well above it, within the 600 kilobyte to 1MB size, though this is expected to go down.
Kevaundray Wedderburn:Is there any incentive mechanisms for provers? So with optional proofs, because the majority of attesters won't be… won't need proofs, there is no incentives for optional
Kevaundray Wedderburn:on the optional proof regime. With mandatory proofs, we're still going over, sort of, what the incentive mechanisms will be for provers, as in whether they should be in the protocol, or…
Emiliano | Boundless:Still…
Kevaundray Wedderburn:Amelie, I don't know, could you mute?
Emiliano | Boundless:Sorry if…
Kevaundray Wedderburn:Thank you.
Kevaundray Wedderburn:Yeah, so the incentive mechanisms for provers, we're still going over. Julian is the one that's focusing on this, Julian Ma from RIG.
Kevaundray Wedderburn:It really depends on how we think provers are going to be integrated into the protocol.
Kevaundray Wedderburn:What do you expect the average proof verification time to be? Currently, so far, it's done a lot of measurements on this, and currently it's about 70 milliseconds to 100 milliseconds.
Kevaundray Wedderburn:Okay, cool. Ignacio, do you want to get set up?
ignacio:Yeah, sure.
ignacio:Let me share my screen.
ignacio:Can you see my screen?
ignacio:Cool. I will go pretty fast, because we have much time, so sorry for that.
ignacio:So, I will give a brief update, on project number one, which is this execution witness that we have mentioned before.
ignacio:So, before giving any updates, let's go through a brief review about this is… what this is about. So here we have, like, the guest program that we are proving, and this guest program can be thought as a function.
ignacio:So, all the information that is required should be received by parameters.
ignacio:These parameters, are basically the new payload request, which is basically the execution payload.
ignacio:Then we have this execution witness that we are focused on.
ignacio:We have the chain configuration.
ignacio:So, basically, the execution witness is all the information, apart from the blog, that the guest program needs to verify, the…
ignacio:The block, right?
ignacio:So, this execution witness basically, contains all the, state tree access states.
ignacio:With, MPT proofs, because we cannot really trust this input.
ignacio:So, for example, if a block contains a niche transfer, and it's low.
ignacio:We need to provide NPK routes for the balance and the storage lock value.
ignacio:Apart from that, we also need to provide the bike codes that were accessed in that blog, because bike codes are not part of the C3 today.
ignacio:This is going to be changed whenever we do call junking, probably binary trees.
ignacio:And we also need to provide, some set of ancestor headers, because we have EAP2935.
ignacio:And also for Blue Cash upgrade solution.
ignacio:So, the idea here is that,
ignacio:we need… we want to standardize this execution witness and how is it generated, because ideally, we want any EL client to be able to generate this execution witness for a blog.
ignacio:this should work in any other guest program. So, the situation that we want to avoid is only execution witnesses generated by guests.
ignacio:are only usable by Agath, this program.
ignacio:Because, ideally, if in production, for whatever reason, a specific EL has some bug or problem generating an execution witness, we want any other EL
ignacio:Being able to generate a buddy's one.
ignacio:That can use… can be used for any orgas program.
ignacio:Also, this execution witness has many other, border cases that we should, properly test, so the only way to really create tests for this that all
ignacio:guest program, can use is by having a standardized form.
ignacio:So, here I have a really rough roadmap-ish of how we…
ignacio:going to approach this at the spec level. I won't go into details, but I can share the slides later if you are interested.
ignacio:So, the updates on this font are basically, Peter from the Steel team.
ignacio:He's working on a generalized state tracker.
ignacio:This state tracker is required for the execution witness, because whenever the block is executed, we need to track all the state that was accessed.
ignacio:This type tracker was already created for Vals, so we are trying to reuse it and generalize it.
ignacio:The state tracker used for balls do not really track the successor headers and byposts that I mentioned before, so I already created some PR on top of his work to extend it.
ignacio:And I also did, like, a full end-to-end spec implementation of the Windows generation.
ignacio:Mainly to identify all the blockers that we might have whenever we try to merge all these
ignacio:In steps.
ignacio:And finally, I wrote a quick document explaining, how OpenVM had another, kind of.
ignacio:Way of expressing this execution witness that might be more optimal, that maybe we can use in the future in a later version.
ignacio:Cool. Sis… The next project is project number two, and we'll move on with that.
ignacio:So, this project number 3 is basically about, having a standardized test program in the stack that all the else can use as a reference to implement… to do their implementation.
ignacio:In the previous project, I put this guest program as a kind of black box here, but we need… we really need to define what's going on here.
ignacio:Because I think there might be some confusions that it's only, like, the state transition function, but we actually need to include more stuff here.
ignacio:So, as a brief overview, you can think of the guest program in this way.
ignacio:So here we have the state transition function that people already assumed it would be part of the logic.
ignacio:But we also need to include, some other stuff, like…
ignacio:the engine API, lawship and validations that today exist in ELs. This should be part of the best program.
ignacio:Because the entity that will be consuming these proofs would be the CL.
ignacio:and the CL today, like, API boundary for the… for the EL, is the engine API.
ignacio:So, we have to include logic here, whenever we do login blobs, which is EIP8142,
ignacio:We also need to do some extra work inside this program.
ignacio:And we also, need to do some extra work regarding the, output commitments, that
ignacio:That are needed for the verifier.
ignacio:As part of the stage transition function, we need to do the execution witness validations. This is related to project number one, because, as mentioned before, the execution witness is not trusted data.
ignacio:So, for example, all the NPT proofs that were provided should be validated, all the bycodes should be checked against the cold hash in the country's leaf nodes.
ignacio:And the assessor has to be checked.
ignacio:Using the, parent hash in the blockchain.
ignacio:So, apart from defining this case program in the specs, which is the bulk of the work of this project, we also need to have reproducible steps to transform guest program source codes into the standardized targets.
ignacio:This is not only, like, the compilation steps, but ideally having a way to,
ignacio:reproduce exactly the same ELF binary that Yelp clients will publish.
ignacio:Because this is directly linked with the verification key that will be used by CLS. So, ideally, we want anyone to reproduce this verification key.
ignacio:from the guest program source code.
ignacio:So, regarding the guest program, in the specs, Mario and Peter from the skill team are organizing a bit the steps that we have to do in the specs for this. There's a bunch of refactoring that should be done in
ignacio:Today, because the way that the specs were
ignacio:assume that the EL client is stable, or has a database.
ignacio:So, this should be generalized such that any state access can be set by a database, or by your execution witness, or something specific.
ignacio:So there are some steps to be done there.
ignacio:Then there were some progress by developer Uche regarding,
ignacio:Gaining more confidence that the current guest programs that we,
ignacio:How today are reproducible in the population?
ignacio:And also include some, signature inclusion, because this will be part of the distribution, process.
ignacio:In the future.
ignacio:And regarding client updates, Ivan from YouthRex have also, made progress on the health distribution pipeline.
ignacio:And they have been doing also some guest program refactors. All these things are links that you can click on them, and…
ignacio:Whenever I share the slides in the chat.
ignacio:And finally, I implemented this EIP825 for ethics and REST, mainly because
ignacio:all these, engine API stuff.
ignacio:required for the checks, is done in Rust, and both clients are in Rust, so there's kind of some synergy there. This is a pretty big VIP, to implement.
ignacio:But I left some comments in the PR that maybe all the other clients might want to look at,
ignacio:So yeah, that's the end of project number two. I will come back again whenever I share progress about project number 6.
Kevaundray Wedderburn:Any questions for Ignacio?
Kevaundray Wedderburn:And while that's happening, Marcin, if you could, start sharing your screen.
Kevaundray Wedderburn:For project number 3…
Marcin Bugaj:Okay, can you hear me?
Marcin Bugaj:So, hi everyone. Today, I'll share
Marcin Bugaj:two threads of work that I've been focusing on. The main one is ZKVM interface standards. We just released version 0.
Marcin Bugaj:This is about creating a common foundation for how ZKVMs integrate with execution clients.
Marcin Bugaj:The second smaller project is exploring whether
Marcin Bugaj:We can enable languages like Go and C Sharp to compile to bare-metal ZKVM targets via WebAssembly.
Marcin Bugaj:So let me paint the picture of what execution client teams were facing before we created those standards.
Marcin Bugaj:Imagine your execution client team preparing for ZKVM-based proving. You look at the landscape and see multiple VMs, SP1, ZISK, RISC-0, OpenVM, and so on.
Marcin Bugaj:Each one requires custom compilation targets, each has different pre-compiled interfaces, Each handles I.O. differently.
Marcin Bugaj:This means if you want to support 3 ZKVMs, you're potentially looking at 3 completely separate integrations.
Marcin Bugaj:That's a lot of duplicated work and maintenance burden.
Marcin Bugaj:So, to address these fragmentation.
Marcin Bugaj:We've created 3 initial standards in collaboration with multiple ZKVM teams.
Marcin Bugaj:The first standard standardizes… the first standard standardizes the RISC-V target triple for ZKVMs being used on Ethereum. The second introduces a C interface for precompiles.
Marcin Bugaj:And the third is a C interface for doing input and output.
Marcin Bugaj:Let me dive a bit deeper Into the first standard.
Marcin Bugaj:So, RV64IM is the 64-bit RISC-V instruction set with integer multiplication
Marcin Bugaj:And division, and that will be a baseline, for our architecture.
Marcin Bugaj:On top of that, there is a requirement for, unaligned access extension, and that's interesting.
Marcin Bugaj:Now, you may ask why we care about misaligned accesses.
Marcin Bugaj:And it's a pragmatic safety net. So if a compiler mistakenly produces misaligned accesses.
Marcin Bugaj:Execution remains correct.
Marcin Bugaj:Possibly just slower with that extension.
Marcin Bugaj:This prevents subtle toolchain differences from being…
Marcin Bugaj:Becoming consensus and liveness issues.
Marcin Bugaj:The second standard addresses the issue of calling precompiles. Ethereum's EVM has precompiles which are expensive to prove using standard RISC-V instructions, so ZKVMs implement them as optimized ZKVM-specific circuits.
Marcin Bugaj:Without the standard, HCKVM has a different way of calling those precompiles.
Marcin Bugaj:Our C-based API solves this problem. Execution client teams can write their pre-compiled calling code once.
Marcin Bugaj:And then switch between CKVM backends without invasive refactors.
Marcin Bugaj:The third standard is about I.O, how guest programs communicate with the outside world.
Marcin Bugaj:They need to receive private input data from the host.
Marcin Bugaj:And also commit to public outputs that verifier can check.
Marcin Bugaj:The C-based API provides two simple functions for this task.
Marcin Bugaj:Those functions are tailored for ZKVM needs and optimized for performance.
Marcin Bugaj:Now let me switch to the second work thread, which is about expanding language support. Right now, if you want to write code that runs in the ZKVM, you're basically limited to Rust and C++.
Marcin Bugaj:Languages that can compile directly to bare-metal RISC-V.
Marcin Bugaj:But what about Go and C Sharp? These languages are also used by client implementations.
Marcin Bugaj:We're exploring one possible way of bringing these languages to bare metal platform.
Marcin Bugaj:We compiled those high-level languages to WebAssembly first.
Marcin Bugaj:Then compile that WebAssembly files into RISC-V bare metal.
Marcin Bugaj:The question is whether the performance penalty of that intermediate step is acceptable.
Marcin Bugaj:Initial benchmarks of the WASM approach for the state transition function in Go.
Marcin Bugaj:Shows about 3 times instruction count overhead.
Marcin Bugaj:Compared to direct compilation.
Marcin Bugaj:But here's the thing. Instruction count doesn't tell the full story when you're talking about ZKVMs. Normal RISC-V instructions have different proving costs than precompiles.
Marcin Bugaj:So, the next steps are to integrate those precompiled accelerators.
Marcin Bugaj:And measure actual proving time, not just instruction count.
Marcin Bugaj:To find out more about,
Marcin Bugaj:Was an approach for compilation of high-level languages.
Marcin Bugaj:Let me wrap up with a bigger picture. So, the three standards reduce integration complexity for execution client and enable fair comparisons between different ZKVM implementations.
Marcin Bugaj:And the language expansion work, if successful, could open up alternative ways of compiling high-level languages.
Marcin Bugaj:Which is good for diversity and resilience.
Marcin Bugaj:All of this work is open source, in the ZKVN standards repository and WAS Risk Repository on GitHub.
Marcin Bugaj:Please review the standards if you haven't yet, and share your perspective. Thanks.
Kevaundray Wedderburn:I can read out any questions, if there are any in the chat.
Kevaundray Wedderburn:None. I think one point to make here is that, I don't know if Leo is on the call, but they've been working a lot with WASM as well, in particular Warm Air, so we might see some stuff that integrates well with that. It's a bit different since we're compiling Wasm to RISC, but…
Kevaundray Wedderburn:Possibly you can go from WASM just proving the WASM directly, or proving… converting the WASM to Wamir, and then proving that…
Kevaundray Wedderburn:Okay, there's no… okay, Guillaume?
Guillaume:Yeah, it's a side question, based on what you just, like, you just mentioned Powder. Powder wants to have automated precompiles. Do we… how does the C interface project, you know, takes that into account, like.
Guillaume:I know for our WASM project, we would like to use the automated precompiles from Powder, at least see how good it is. Yeah, it seems to be at odd with that other project of having
Guillaume:Yeah.
Guillaume:like, C headers for the precompile, so I'm just wondering, how do we reconcile that?
Kevaundray Wedderburn:Right.
Marcin Bugaj:Oh.
Marcin Bugaj:Yeah, so the idea is that each ZKVM vendor will have to implement that C interface that is standardized.
Marcin Bugaj:And the application logic won't have to change, so basically, the implementation of precompiles will be provided by ZKM vendors, and that will be resolved at the linking stage of the program, so…
Marcin Bugaj:The program will have to be recompiled, with the correct, with the correct,
Marcin Bugaj:archive for pre-compile implementation, as well as for the implementation for I.O. But the logic itself, whether it's in Rust or C or C++, or other language that can bind to C,
Marcin Bugaj:The logic won't have to be refactored or changed.
Marcin Bugaj:So that's the idea. So, so basically, the idea is that, the implementation of,
Marcin Bugaj:the CE interface is provided by ZKVM vendors.
Kevaundray Wedderburn:Maybe some context, we have about 2 minutes remaining for this section, but maybe some context on this precompile notion, what Guillaume was talking about, is that currently ZKVMs essentially provide an API for accelerating certain algorithms.
Kevaundray Wedderburn:So, like, CatTrack or, ACDSA,
Kevaundray Wedderburn:And there's a C interface that we've standardized on that allows the guest program to access these, but these are sort of fixed precompiles, and they're fixed circuits in the ZKVMs, while auto-precompiles can be seen as sort of an automatic way, where they
Kevaundray Wedderburn:check. They look at the guest program, and then they figure out, okay, what…
Kevaundray Wedderburn:What can we do here to speed it up based on this particular guest program, instead of having these generic precompiles?
Kevaundray Wedderburn:I… I think it might require a bit more investigation, but my feeling is that we might not need the C headers for the precompiles if this is the case. Leo, do you want to opine on this?
Leo Alt [powdr]:Yeah, I think just the… Hmm…
Leo Alt [powdr]:In the Auto Brick and Pulse case, what you can do is basically the guest can just choose not to use
Leo Alt [powdr]:Like, this interface or any brick-and-file interface from…
Leo Alt [powdr]:ZKVMs, or choose a specific subset, for example.
Leo Alt [powdr]:that autopre compiles may be performing badly, for instance, and then, so you can choose which ones you want, you can choose none, or you can choose all.
Leo Alt [powdr]:So I think this would be the easiest for a guest.
Leo Alt [powdr]:that wants to use Auto Recompiles to just basically then just not use…
Leo Alt [powdr]:The precompiles that might be working well already with other precompiles.
Kevaundray Wedderburn:Okay, cool. Yeah, just to keep, with time, maybe we can discuss this on Discord as well.
Kevaundray Wedderburn:Tao, do you mind, sharing your screen?
Francesco Risitano:Can you guys hear me?
Kevaundray Wedderburn:Yep.
Francesco Risitano:Cool. So yeah, I've been working on the consensus layer integration, and…
Francesco Risitano:in this talk, I'm gonna essentially give an update on the, on the specs,
Francesco Risitano:And finally, the progress on the Lighthouse, the Lighthouse implementation.
Francesco Risitano:So, to start off, just want to give a quick refresher on the Engine API. So the Engine API is essentially the API that the consensus layer uses to interact with the execution layer.
Francesco Risitano:And the new payload request is essentially the data payload which is used, in the request. So, when the consensus layer receives a new beacon block, it constructs this object, the new payload request, which contains the execution payload.
Francesco Risitano:The versioned hashes, the beacon block, parent beacon block, and execution requests.
Francesco Risitano:And essentially, it asks the execution layer, or the execution engine, to verify that it's correct.
Francesco Risitano:And, some of these methods require the full execution payload, so that includes the transaction data. So the main takeaway from this slide is, currently the, yeah, the execution layer requires full transaction
Francesco Risitano:Data to kind of verify the new payload request and to assert that the new payload is valid.
Francesco Risitano:So ideally in the future, we want to, kind of remove the requirement for ZCAS testers in which they would need the transaction data.
Francesco Risitano:So the idea is, essentially we move this to the, kind of, we move the abstraction,
Francesco Risitano:For the prover, from kind of just the execution of the block to this, to verifying the whole new payload request.
Francesco Risitano:So, essentially, it's the same checks, but it outputs the new payload request root. So that is essentially just the hashtree root of the new payload request.
Francesco Risitano:And inside of the proofs, we do… inside of the prover, we do all of these, kind of consistency checks to assert that the, the versioned hashes, so the KZG commitments for the blobs, and the execution requests are consistent with the transaction data.
Francesco Risitano:And then, in regards to verifying the proof, the public input moves to this new payload request route.
Francesco Risitano:So, so… so… let me move to the next slide. So here we can see the relationship between the, the data types, which we have in the,
Francesco Risitano:in the consensus specs for optional proofs, so there's a direct mapping between the new payload request and the new payload request header. What's nice about this is they ultimately hash to the same root.
Francesco Risitano:So you can replace the execution payload with the execution payload header, still construct the, the same public input.
Francesco Risitano:So, yeah, ultimately that kind of just provides a bit of context on the… on the guest program modifications that Ignacio, touched on.
Francesco Risitano:And then, in regards to the signed execution proof, this is the proof, type that is gossiped over the network. We have the actual execution proof.
Francesco Risitano:We have the validator index, so just to provide context, we're gonna use signed proofs, because, if we had unsigned proofs, then people could just send around a bunch of invalid proofs. They take 100 milliseconds to verify, and, you know, you can just grief the network.
Francesco Risitano:So, yeah, the idea is essentially to use the validator set to sign these proofs,
Francesco Risitano:And the, the execution proof contains the proof data, the proof type, and the public input, which is this new payload request root.
Francesco Risitano:So, we introduced the proof engine, which is essentially kind of analogous to the execution engine, but instead of working with,
Francesco Risitano:kind of the new payload request, or the full execution payload, it works with the new payload request header and the, the execution payload header. So we have, verify execution proof method, we have new payload, notify new payload header method, and, request proofs method.
Francesco Risitano:So, yeah, I'm gonna run through a few flows,
Francesco Risitano:And to kind of show how the proof engine integrates. So, we receive a new beacon block, we extract the new payload request header.
Francesco Risitano:We then, invoke this method on the proof engine. So we send a new payload request header.
Francesco Risitano:The proof engine caches the header.
Francesco Risitano:Such that in the future, when it receives proofs, it can kind of, you know, correspond them with this new payload request header.
Francesco Risitano:And then it returns syncing, and the beacon node will import the, the beacon block optimistically into the fork choice store.
Francesco Risitano:Then when we receive, execution proofs, we receive them over P2P, we look up the validator index, which was included in the signed execution proof, we verify that the signature, is correct, according to, the proof message, which is the execution.
Francesco Risitano:yeah, which is the execution proof itself, essentially just a hash of the execution proof. And then, if that's successful.
Francesco Risitano:We, invoke the verify execution proof method on the proof engine.
Francesco Risitano:We, we check if there's sufficient proofs, so we've got a K of N requirement.
Francesco Risitano:And if so, we communicate valid back to the beacon node, and the beacon node will mark the block as valid in the fork choice store. So previously it was marked as kind of optimistic, but now it can mark it as valid and say that, you know, this block is ready to be, attested by the validator.
Francesco Risitano:And then finally, we rebroadcast the proof.
Francesco Risitano:And then in regards to proof generation, so the idea is that
Francesco Risitano:You know, for optional proofs, we don't have this requirement in which the builder has to generate the proofs, so in the interim, we'll use, validators to fulfill this responsibility, or some, you know, it's opt-in, essentially, this role. It's not required.
Francesco Risitano:But they'll observe a new beacon block, they'll extract a new payload request.
Francesco Risitano:They will then invoke this request proofs method on the proof engine, specifying, the new payload request which needs to be proved, and, proof attributes, which is essentially the different proof types, so, the different, yeah, provers that need to be invoked.
Francesco Risitano:it will receive a proof generation ID, and then,
Francesco Risitano:The proof generation happens asynchronously, and they are sent back from the proof engine to the validator who signs them and subsequently gossips them on the execution proof topic on the beacon node.
Francesco Risitano:So, in regards to the proof gossip protocol, we had, two requirements in which we don't want there to be
Francesco Risitano:a fork.
Francesco Risitano:well, yeah, we don't want there to be a… well, that's the primary, constraint, essentially. We don't want there to be a fork, and, also we can't slash for invalid proofs. So, yeah, this is kind of the construction we,
Francesco Risitano:we decided on. I should note that these specs may change, they're not kind of firm. But yeah, essentially the validator signs the proof and then broadcasts the proof on the execution proof topic.
Francesco Risitano:Nodes will ban peers if they… if the peer has sent them an invalid proof, and they will ban, validators, so essentially, if they ever receive a new proof signed by a validator which previously sent them an invalid proof, they will not even try to verify it.
Francesco Risitano:And one of the problems with that is consensus, because a validator could send a valid proof to validator C, and an invalid proof to validator B.
Francesco Risitano:And, yeah, validator B would, reject the proof, validator C would accept it. So the idea is that, validators will re-sign the proof with their own, with their own validator key, essentially. So then we kind of…
Kevaundray Wedderburn:bad.
Francesco Risitano:Move to a… sorry.
Kevaundray Wedderburn:Sorry, just, putting the timer up that we have one minute, just in case.
Francesco Risitano:Yeah, I'm nearly done.
Francesco Risitano:So, yeah, that's the general idea. It's re-signed and sent to validator B, and then the assumption is just 1 of N, so you have one, validator who… one honest validator that re-signs and propagates the proof.
Francesco Risitano:Yeah, and in terms of the Lighthouse implementation.
Francesco Risitano:We've implemented the proof engine,
Francesco Risitano:the proof gossip is implemented. We've done the, kind of, signature verification stuff.
Francesco Risitano:we've introduced a new service on the validator for, kind of, doing the signing and requesting of proofs.
Francesco Risitano:done the integration between the beacon chain and the proof engine, and unit tests have implemented… been implemented. And then we have a few more
Francesco Risitano:Bits of work to do, but yeah, made some decent progress there.
Francesco Risitano:Yeah, that's all.
Kevaundray Wedderburn:Are there any questions for Tao?
Kevaundray Wedderburn:Manu, if you want to start sharing your screen…
Kevaundray Wedderburn:Manu is a developer from Prism.
Manu:Yes.
Manu:I think you have to… okay, yes, I can share now.
Manu:Oh, sorry.
Manu:Okay, I'm sorry, I have to close, to close,
Manu:Zoom and to reopen it again, so I won't share my screen now. Yes, Flurry, basically, so, we had,
Manu:June Song and developer, which, created an initial pack, proof of concept on Prism. And, then,
Manu:We are currently adapting the codebase to the latest specification.
Manu:Which is supposed to… Zuh… Post is the latest,
Manu:request on the spec. And yeah, so to help testing, I implemented a standalone dummy prover, which was inspired by the one done by, Kev on Lighthouse.
Manu:And so, just basically, this dummy prover listened to Beacon blocks from SSC, and creates just a dummy proof. This dummy proof doesn't do anything, I mean, it's just an empty thing.
Manu:And, yes, and the proverb published is dummy proof to a Beacon nod via the new,
Manu:execution-proof BigConn API.
Manu:And, yes, and also, I modified the core to this package,
Manu:ATM customers package to… to add the prover directly, to connect the approver directly to a, to a BCANN.
Manu:And I will share my… I will share my slides just in the chat.
Manu:And, yes, the big, thing still to implement is, sign execution proof, the sign scam, which was not really doable with the current state of the spec, but I saw that, Francesco modified this,
Manu:And I will talk to him about the new scam, about signing proofs.
Manu:Thank you, sorry, about the slide sharing.
Manu:And that's all for me.
Kevaundray Wedderburn:Thank you, Monu. Yeah, it's pretty good that we'll be able to have a Lighthouse and a PRISM implementation.
Kevaundray Wedderburn:Soon, soon, TM. Han, do you want to share your screen?
Han Jian:Yup.
Han Jian:Can you see my screen?
Han Jian:So, I would give an update to the Perlinium infrastructure project.
Han Jian:I will focus on the array and ZKBoost, and how we use them to provide the execution proof to the consensus layer.
Han Jian:So, in this project, there are 3 major repos that are used.
Han Jian:The first is the array, which integrates various of the KVN SDK to provide a unified interface for use, and it also provides the Dockerized images
Han Jian:a declarized compiler and server images. The server here is just a HTTP wrapper for the proverb.
Han Jian:And the second repo is the array guest, which provides the execution layer guest program, and it published the compiled ELF.
Han Jian:And the third row is the ZKBoost, which has two… which is the actual component that interacts with the consensus layer.
Han Jian:And inside that, it has two components, the execution, Windows Entry, and the ZK boost server.
Han Jian:And the execution, Windows Sentry and the DK boost server are essentially the relay and proof engine that Francisco just introduced, so I will skip the end-to-end flow here.
Han Jian:And in the ZKBoost server, we have the example script to spin up the whole stack for Lighthouse, so we can test the proven infra easily.
Han Jian:And so far, we have integrated the following DKVMs.
Han Jian:And some of them support GPU proving. And here, the multi-GPU means that we can prove in our multi-GPU, but on the same machine.
Han Jian:And in the area guest repo, so far we have this execution layer guest program available, which allows us to provide multiple
Han Jian:execution proof with different ZKVN and execution layer combinations.
Han Jian:The next step will be fully integrate the whole stack into the Ethereum package, so we can test the proven inform more easily. And also, I would need to clean up a bit to follow the EIP825 spec and naming, and add more metrics to track the pipeline efficiency.
Han Jian:Yep, that's my update. Thanks.
Kevaundray Wedderburn:Thanks, Han.
Kevaundray Wedderburn:there are no questions.
Kevaundray Wedderburn:Okay, Stefan is… I think Stefan is sharing now. Justin made a comment, we should consider integrating ZKBoost clients into CL clients. Yeah, I think that's a good direction.
Kevaundray Wedderburn:Cool. Okay, Stefan?
Stefan Starflinger:Yeah, I didn't want to interrupt, I just wanted to test if I can share.
Stefan Starflinger:Can you see the screen, I hope?
Kevaundray Wedderburn:Yep.
Stefan Starflinger:Perfect. So I just, gonna give a quick summary, what we've been looking into, with the CK team and East Bundle Ops. So, we looked at building versus buying versus renting.
Stefan Starflinger:And there's the option either to build the server ourselves, and then put it in a co-location, to buy a pre-built server, or just to rent from a cloud provider.
Stefan Starflinger:And here is kind of an overview. Of course, the do-it-yourself is still the cheapest, even though the ramp prices have exploded. I'll go through it quickly, but we can talk about it in more detail if you want later on.
Stefan Starflinger:And then kind of the idea is to have two clusters, and right now, this would be, how it would look like if we did just the do-yourself build.
Stefan Starflinger:So we would have 4 GPUs per server, and then four servers would be one cluster, and we would have one development cluster, and one production cluster. That would be the idea right now.
Stefan Starflinger:And these are just some requirements for the setup that we're looking into.
Stefan Starflinger:Not gonna go over it in detail. This would be kind of the setup that we're looking into.
Stefan Starflinger:So just, for 5090 GPUs, it would be good if we can get them to be 3.5 slots or smaller.
Stefan Starflinger:we kind of looked into having the Astos version, because they have pretty good cooling, but we have to look in that, the heat gets pushed out of the back, and not just to the side.
Stefan Starflinger:So we're still investigating here what is the best 5090 version.
Stefan Starflinger:1590 is considerably cheaper than the 6000 version, but we saw that the 6000, RTX 6000 Pro
Stefan Starflinger:Max-Q version, which is just 300 watts, which is significantly less than 5090.
Stefan Starflinger:Is less performant, but only by 15%, but it's unfortunately so much more expensive as soon as you get into the enterprise market.
Stefan Starflinger:And then for the CPU, we thought about the Threadripper Pro. The newest version was 32 cores, so we got at least 8 cores per GPU, and it has a lot of PCI lanes for all of the,
Stefan Starflinger:TPUs, and then motherboard is,
Stefan Starflinger:fitting one with enough DIMM slots, so we calculated also for the RAM that we need to use all of the slots so that we can use all of the bandwidth of the PCI 5.016 lanes.
Stefan Starflinger:which is, I think, around 256-something gigabytes per second, and with just 4 slots of RAM, we wouldn't max out the total, but with 8 slots, we would be able to utilize the full bandwidth.
Stefan Starflinger:And storage is not unimportant, but we would want 100GB networking between the individual servers.
Stefan Starflinger:So that, we can copy between them, because four machines would be in parallel, working on the proof.
Stefan Starflinger:That's kind of the setup. Here are some comparisons between pre-built systems that we also looked into.
Stefan Starflinger:But I'll keep over that for now.
Stefan Starflinger:And let's maybe look at the comparison. So doing it ourselves, for a 3-year ownership would be around 570 in the co-location.
Stefan Starflinger:We already got, some…
Stefan Starflinger:information from the co-location, how much the setup would be, and how much the monthly cost would be. And here it compares it against, kind of, the pre-built, cheapest
Stefan Starflinger:The pre-built average and the cloud rental, if you would just rent for those years, even with a 5.5% discount.
Stefan Starflinger:It's considerably more expensive.
Stefan Starflinger:And you also don't have any, amortization of the hardware, and at the end of the time, you don't actually own any of the hardware either. So that's also something that's not reflected here.
Stefan Starflinger:And yeah, here's just kind of the co-location hosting breakdown, from the offer that we got. So it's, around… operating around $8,500 a month.
Stefan Starflinger:There's a $16,500, setup cost.
Stefan Starflinger:And then you can see there are the total cost operating without the hardware as well. And here's just a nice overview, I will share the slides as well.
Stefan Starflinger:How much, the… like, just renting versus doing it ourselves would cost.
Stefan Starflinger:Over time, and where, kind of, the total cost of ownership break-even point is.
Stefan Starflinger:And
Stefan Starflinger:Yeah, so the recommendation right now would be not 100% what this slide shows, but kind of this is the general direction.
Stefan Starflinger:So we could also do, like, a hybrid approach, so either just, go all-in, with this do-yourself build, do, or choose a pre-build. We haven't 100% decided yet, this is just a recommendation.
Stefan Starflinger:Or we can do a hybrid where we just get one do-it-yourself build 16 GPU system in the beginning, and then rent the other one. That's still kind of up for discussion, but I hope this kind of gave you a little bit of an overview.
Stefan Starflinger:And here is the appendix, kind of, like, what CPU to choose.
Stefan Starflinger:And any input or anything would be great, if you saw something that might not
Stefan Starflinger:Match up in the, Presentation.
Stefan Starflinger:But I think that's pretty much it.
Kevaundray Wedderburn:From our side.
Kevaundray Wedderburn:Thanks, Stefan. Yeah, so for people on the call, we may run over by 5 minutes, just because I didn't keep time properly, and didn't expect the questions. If you need to leave, these are being recorded, so it's, like, completely fine.
Kevaundray Wedderburn:The next one will be George from the security team, sorry, the cryptography team.
George Kadianakis:Hello guys, let me share my screen. So, I just want to give an update on the ZKVM Security Sprint, an initiative we launched, late last year, with the goal to bring, ZKVM security to 128 bits
George Kadianakis:this year. So, we plan to do this in 3 milestones over, this entire year through an iterated process with the teams, but today, I mainly want to talk about this update blog post we pushed
George Kadianakis:today on the ZKVM team website, and it does three things, mainly. One thing is that it
George Kadianakis:presents a visualization of the timeline and the milestones and stuff for people who are more of the visual kind. So you can see this thing here, and also, for the first milestone, which is at the end of this month.
George Kadianakis:the SoundCalc integration. After talking to Teams, we would like Teams to also integrate their inner segment lookups into SoundCalc.
George Kadianakis:Because that's a big part of the soundness.
George Kadianakis:of the segments, which is the first thing we want to start, looking at the proof system security. So, this is one update that we want the lookups integrated. Many teams have already done it. And the other update is that we published details on the ZKVM architecture white paper, the documentation effort we want to,
George Kadianakis:start. So if you see here, we have a PDF, with how we expect this document to look like. Again, it's going to be done in an iterated manner, and with different milestones, and now you may
George Kadianakis:start understanding why the visual representation is useful. So yeah, please check out the document on how we expect the white paper to look like. If you have any questions, let us know, and yeah, thanks a lot.
George Kadianakis:I think, who's next, Kev? Maybe it's Cody?
Kevaundray Wedderburn:Cody?
Kevaundray Wedderburn:Could you drop a link to the post as well, George, in the chat?
George Kadianakis:Yeah, absolutely.
cody:All right, you all should be able to see my screen. So, this is a report on Project 7, which is the sort of meta-project of security. A lot of what has already been spoken about is relevant to security. What I did was…
cody:Take the, description on the planning repo and try to map it out into some smaller set of higher-level goals.
cody:this is the planning repo, and either implicit or, slightly missing from the diagram that I'll show on the next page are some of these things. So the, audits and bounties, prover incentives.
cody:Security of the supply chain, which was touched on in terms of, like, reproducibility of, guest program verification keys.
cody:And another issue that was raised in the planning repo was relating to security approvers, if they are co-located, or maybe, you know, the fact that GPUs are shared
cody:with the public could lead to, sort of, starvation of those resources, and that's related to pro-reliveness and incentives. Some of that stuff can be wrapped into the bars on the following page.
cody:Which is supposed to be taken with a grain of salt. It's not exactly,
cody:you know, time consistent, because I took some things that are, mapped out exactly in time, like what George just spoke about, where there are specific deadlines, and tried to lay them out with things that are still a bit fuzzy. But I think still it's useful to have a look.
cody:So, yeah, we aim to have optional proofs in Hegetah,
cody:And sort of that itself is a bit of a fuzzy deadline, but working back from that, this is, I don't know, these bars could be something like a month, a month and a half, purposely, they're not laid out in dates.
cody:But I, I imagine grouping the initiatives into the sort of initial, affirmation
cody:grouping. I actually don't know if you can see my mouse, I hope you can, but at the top left, we have a kind of, like, reaffirming
cody:hardware requirements, writing down a threat model, that's something I've started to do and will reach out to people about and share on the next call. But some of this initial setting of the stage and really getting consensus once and for all behind some of these things.
cody:And then we need to also, on a slightly longer scale, figure out what, is a minimum set of tests that we're happy to launch optional proofs with.
cody:And, also what exactly we want from the specs of these ZKVMs. For instance, the consensus clients should contain, or the consensus spec should contain
cody:specs for the ZKVMs.
cody:But we would like other specs, and there's also this notion of the white paper spec that, George and his team has asked for. And I put some of the cryptography team's goals on here, so we have the SoundCalc integration due pretty soon. And the next phase, we work to improve security.
cody:Of the proving systems, thinking about the, diversity strategy, where we have many proofs to be verified. We need… we want those,
cody:Proofs to be uncorrelated, you know, in terms of, say, dependencies for the guest programs and the provers.
cody:And, we want to also start to think about, which ZKVMs… what… how should we choose what… which ones will be, whitelisted?
cody:what that looks like.
cody:And, yeah, also, I guess, validating by building out these clusters that, Stefan just spoke about. We need to make sure that those hardware requirements are viable. I mean, we have a lot of data from E3S, but it's good to, to be, have an, you know, at least the EF internally, building some of this stuff.
cody:And feeling really, really confident about that. And then at this point, yeah, we can make some decisions. And then in the next phase, we work even more to improve security of testing, building some monitoring, making sure that everything is reproducible.
cody:working on specs, improving security of the proving systems. And then, at some point, we have to choose, which… which ZKVMs, EVMs are… we're really confident about, and what…
cody:is a good, diversity requirement. It might not just be K of N, because if some set of K is highly correlated, that maybe is, no good. And then we have this phase where we think about incident response, we have to monitor for stability and,
cody:We need to sort of test out our incident response and, now look at the specs.
cody:So, yeah, then, for mandatory proofs, well, like, the scope of this call is not really…
cody:on mandatory proofs, but since it was represented in the planning repo, I mention here some additional or expanded requirements, specifically calling out formal verification.
cody:Is, likely a requirement for mandatory, but perhaps not for optional. That doesn't mean we won't have significant formal verification in place.
cody:Though, before, optional proofs.
cody:And yeah, so what's next? Well, I'll keep track of this, stuff, and…
cody:You know, keep track of ownership of these things in a loose sense.
cody:And report on progress in these calls, and we're making monthly updates to the planning repo, and we should discuss, in these calls, and also on the ETH R&D Discord.
cody:That is all from me, thank you.
Kevaundray Wedderburn:Thanks, Cody. There are no questions. Ignacio will give…
Kevaundray Wedderburn:He's talking the next breakouts, just to give more space for this one. And then we have Alex H, and then Farah from Eve Profs. And then we can close out. Yeah, thanks guys for staying on.
Alex Hicks:Yep, I'll quickly share my slides.
Alex Hicks:So my slides are also in the chat, if anyone wants to have them for later, there are links to the website, and there are links to…
Alex Hicks:the Telegram group, where some of that work is discussed.
Alex Hicks:so it says I'm screen sharing, but I can't see that I'm screen sharing.
Kevaundray Wedderburn:I don't know if… Yeah, I think you can confirm.
Alex Hicks:Okay, perfect.
cody:I see your… Oh, we're seeing the Zoom.
Kevaundray Wedderburn:screen. Oh, yeah.
Alex Hicks:Alright, it should be fine now. Okay, so, anyway, there's this big former application project, I'm gonna try to speed this thing, you know, speed through quick updates.
Alex Hicks:There was two tracks. There's the RISC-VKVM track, where we're looking at, you know, the circuit, and particularly the RISC-V circuits and precompiles, and as part of that, the cell RISC-V specification. There's the EVM track, where we're looking at.
Alex Hicks:the guest program, EVM STF running on RISC-V, and trying to assess that that is…
Alex Hicks:you know, running on RISC-V and compiled to RISC-V, ideally bug-free, in a way that can be shown equivalent to a formal EBM specification. And there's a cryptography track, which is about specifications and, you know, formally verifying the proofs of security for the proof systems, and kind of cryptographic primitives, which are used by ZKVMs.
Alex Hicks:To give a quick update on every track, for the ZKVM track, we have some reasonably short-term targets.
Alex Hicks:So we've now finished extracting the official RISC cell specification to lean. This is a general-purpose cell… cell-to-lean extraction. It supports every RISC5 extension, it supports every other ISA that is defined in cell, for that matter. Obviously, we haven't, kind of, tested this as much.
Alex Hicks:There are also extractions, you know, for Rock and Hawthora and Isabel, other proofs of assistance. We're not using them, but in principle, they're usable. I think to rock one in particular, it's fairly polished.
Alex Hicks:We've been able to use this specification to get proofs done for the resource circuits of several ZKVMs. This includes SPE1, although memory consistency hasn't been verified yet. That'll happen. It includes OpenVM, they released this this week. Congratulations and big thanks to both of these for obviously taking the initiative and co-funding this.
Alex Hicks:we'll be, obviously, doing this with the Odyssey KVMs, you know, kind of ideally ahead of grams of them. There is no, kind of, specific preference in ordering. It comes down to, you know, when teams have felt ready to do it in terms of having stable circuits and things like this. And just a quick note, there are some, you know.
Alex Hicks:assumptions that are done regarding lookups, which is that, you know, the semantics of the lookups are correct, and things like this. We'll try to address these, as much as possible, maybe before Glamsterdam, maybe after Glamsterdam, but certainly before Glamsterdam, we want to have
Alex Hicks:you know, kind of ZKVMs that will have their constraints for the develop codes and memory consistency checks and all of this all done, and in a state of maintenance.
Alex Hicks:We're also looking at precompiles, of course.
Alex Hicks:We are able to verify precompiles in the same way that we verify, you know, RISC-V constraints. For example, I mean, one highlight has been verifying the Ponk E3 catch, in, in Rock, actually, not in Lane, and we can do more precompiles. The main issue with precompiles is that, we have several of the KVMs, they all have many precompiles, verifying them all is
Alex Hicks:doable in principle, but a bit of a time sink, and there's a bit of uncertainty regarding how many precompiles the ZKV's gonna have. So we're just looking at, you know, maybe how to scale this, maybe how to use pre-compiles written in Lean, which are easier to verify. We'll see what to do with that, you know, as we get close to Glamsterdam and around that time.
Alex Hicks:We're also verifying order precompiles, you know, with Powder and Satora. This is ongoing. I think order precompiles are great. I hope this helps, you know, drive the adoption of order precompiles.
Alex Hicks:which seemed like it would also solve the issue of having too many manual precompiles to verify. There are a bunch of miscellaneous other things going on. We have lean DSLs for start kits, which are able to define precompiles and actually prototype VMs as well at this point. We have LLZK, which are these MLAR… family of MLAR data for, both constraints and witness generation. These are all ongoing, you know, there were kind of SMT backends, lean backends, verified.
Alex Hicks:being developed for all of this, I won't go into detail here.
Alex Hicks:For the EVM track in 2025, we… we… there was a tooling developed with, runtime verification. We were able to verify
Alex Hicks:that the execution of opcodes on RISC-V, that is, taking RVM or RVM interpreter specifically and compiling that to what at the time was the SP1 RISC-V 32-bit target, and then doing equivalence proofs since KVM was doable. This is… this hasn't been updated yet to, you know, the new 64-bit RISC-V target that is being standardized on, and we'd also want to see how to extend that to, you know, the guest program slash STF as a whole.
Alex Hicks:as well as, obviously, supporting more guest programs. It's, again, there's an issue of this is kind of…
Alex Hicks:doable, it's unclear how robust the toolchain is. Different guest programs, obviously produce different assembly that may be more or less nice to look at and deal with. And there's a question of balancing costs of doing all of this versus the assumptions that we're making about, you know, client diversity as a hedge against bugs.
Alex Hicks:Especially this year, because, budgets, you know, kind of EF-wide are somewhat reduced this year, and so I'm looking at this at the moment, and we'll probably have a
Alex Hicks:more of an update on this, you know, very soon. And same there's a question about, you know, whether it makes sense to have a kind of canonical guest program, which would obviously be something that comes with very high assurance in the form of
Alex Hicks:you know, a guest program that is, generated from a formal specification and compiled via a verified compiler, and, you know, ideally performant enough.
Alex Hicks:Sorry.
Kevaundray Wedderburn:Your screen seems to be, there's something.
Alex Hicks:Choppy. Okay, let me… I'll stop sharing and restart sharing, and that should probably be the fastest way to fix it.
Alex Hicks:Okay, let me know if this is better.
Alex Hicks:So yeah, the EVM track at the moment is a bit in flux, because we also have many new guest programs, and obviously the standardization at the risk-back target.
Alex Hicks:Now the cryptography track, also to go over that very quickly, this is more… this is a bit less shorter term, maybe a bit more medium term, suddenly thinking of mandatory proofs, as Cody had on his slides.
Alex Hicks:We have Rclip. This is a library of formally verified executable specifications for proof systems. This verifies everything down to the underlying coding theory. We are starting to have…
Alex Hicks:specifications in there, we have interactive fry, we have sum check, we're also starting to have, you know, fully executable,
Alex Hicks:specs. The goal here is obviously to be able to verify, in particular, the Rust verifiers. We have a tool called Hacks, which is being developed with a lean backend for this purpose. We're starting to use Hacks, we're starting to verify some Rust code with Hacks.
Alex Hicks:there's a bit of a challenge in the complexity of features that are used in Rust libraries. By features here, I mean features of the Rust language, which, which have varying levels of support by hacks, because we don't have… we don't have formal semantics for Rust, obviously, and so that tooling has to be… support for additional features is done on a, kind of.
Alex Hicks:one-by-one basis, and can take a bit of time. This will be ongoing in the next year or so. It won't be done before optional proofs. We're obviously aiming to get it done, you know, before mandatory proofs.
Alex Hicks:And then on the kind of miscellaneous side, again, you know, we're also looking at actually compiling our lean specifications to optimize the MLIR dialects, and see if, potentially, if we just generate faster code than what is generally understood from Rust, and potentially we can verify, actually, these MLIR dialects, because we don't need too many. Maybe we're able to skip verifying, you know, Rust code in some instances, and making our life easier.
Alex Hicks:again, this is ongoing, and especially this part is slightly exploratory for now. Just to wrap up, we have progress ongoing on each track. There's a mix of short-term targets, like the RISC-V circuit verification, and the pre-compass to an extent that we want to wrap up, you know, around Amsterdam time.
Alex Hicks:There are more, kind of, medium-long-term targets with specs for the proof systems, which, obviously, the proof systems now are more complicated than, you know, just Fry, or just SunCheck, or whatever.
Alex Hicks:And obviously trying to push for great integration of formal verification in the development and testing process to try and make all of this
Alex Hicks:you know, smoother, and we're driving costs down, I think, for a lot of these, formation tasks as well, which is one… one neighbor, see, to make this sustainable. We're aiming to be robust at changing this tax, so that if people rewrite their circuits, change the gas program, whatever, we can handle this. Again, this comes down to kind of making this economically sustainable, and putting upfront effort into tooling to make this happen.
Alex Hicks:So yeah, well, I have high expectations that things like the risk-fired circuits can all be done by Glamsterdam. We're not treating this as a blocker, because we can't do optional processing without this, if we happen to be, you know, delayed by a week or whatever, but I still expect this to happen, regardless.
Alex Hicks:And then we want to obviously use the official proofs period to establish, you know, robust maintenance practices.
Alex Hicks:Before we do mandatory proofs, because, obviously, maintaining the proofs, maintaining the link between the proofs and the software that's verified is something that is going to be a very important,
Alex Hicks:a very important part of, of moving forward and handing upgrades and things of that kind. We have a website, verified-dkvm.org. It was updated a bit recently, so there's a… the grant list and, you know, recent talks and blog posts and all of this, up to date. There is more documentation coming soon regarding, more specific details of what was done on the different grants, as well as
Alex Hicks:some maybe more research-y, challenges and topics that indicate, kind of, some of the future work. There's also a Telegram group, there's a link here, there's a link to the slides in the Google Meets chat you can click on, and, there's, it's not the most active Telegram group. There are a lot of projects, some have split up into, you know, other channels.
Alex Hicks:But it's a good way to follow what's going on, overall.
Alex Hicks:That's it from me. I guess I'm happy to take any questions unless, Kev says no, and we need to leave it here. But, but yeah, happy to also answer questions asynchronously on Telegram, email, Signal, whatever else.
Kevaundray Wedderburn:Yeah, maybe take questions async.
Alex Hicks:Yup.
Kevaundray Wedderburn:Farah, did you wanna…
Fara Woolf:Yep, yep, let me share my screen.
Kevaundray Wedderburn:Thank you again, guys, for staying on.
Fara Woolf:Yeah, so, we're testing all kind of new ZKVMs proving mainnet on ETHBrooks first, so if you're a new team, you can… we'll probably onboard you through this staging app, first, so…
Fara Woolf:I'll drop a link to that in the chat, but if you come to the sign-in button, actually, you'll be able to go through a sign-up process if you click on the sign-up
Fara Woolf:Button here.
Fara Woolf:It should load, and so you can basically sign up as a new team. I'll receive kind of a notification that you're trying to sign up, and I'll approve you, and you'll receive kind of a notification with an API key, in the email.
Fara Woolf:And then once you're a new team, you'll have a dashboard button here, and you'll be able to come into a dashboard and create a new ZKVM.
Fara Woolf:And so you'll… you can see, once you're onboarding, the security metrics and the performance metrics that you'll need to fill out.
Fara Woolf:Once you create a new ZKVM, I'll also receive a notification to review it and approve it, so you'll go into this awaiting review status. You can also edit, make any edits to it, and I'll receive a notification to approve those, too.
Fara Woolf:And so then also you'll be able to create a cluster here to… once the ZKVM is there, and you'll be able to then test the ZKVM that you're, onboarding with.
Fara Woolf:Once you're approved, you'll come into this Coming Soon tab here, and the metrics you won't be able to see yet, but once you actually have a cluster and you're submitting a proof, you'll become active.
Fara Woolf:And so then all of the metrics that you filled out and that we're tracking, you'll be able to… to see here. And then we'll be tracking, you'll… you'll come to… when you're submitting the proofs, this API documentation will help you here. You'll actually self-report a proving time that we track.
Fara Woolf:That helps us also track the average cost, and then we, do the total time to proof, where we're using the block time and the,
Fara Woolf:the time that you submit the proof, and so we're tracking those… those things. So, yeah, reach out to us on Telegram, too, but I'll drop the link to the staging app in the… in the chat.
Kevaundray Wedderburn:Great. Thank you, Farah.
Kevaundray Wedderburn:We have a question…
Kevaundray Wedderburn:If a guest program team is not ready to be on EVE Proofs yet, does it make sense to sign up ahead of time?
Fara Woolf:Yeah, I mean, I don't know why not. I think it's totally fine to sign up, yeah.
Kevaundray Wedderburn:Cool.
Kevaundray Wedderburn:And yeah, you can reach out to Farah async about, about doing this. Okay, so we're about 19 minutes over time. Thank you all for staying on, for the extra 19 minutes. This was the first breakout call.
Kevaundray Wedderburn:I would say please join the Discord, our R&D Discord, to find out, sort of, what's happening async. A lot of things are happening between the monthly calls, and yeah, would be great to just talk with you guys.
Kevaundray Wedderburn:If that's it, I will see you in about 4 weeks.
Alex Hicks:Thanks.
Guillaume:secure?
Ladislaus:Thanks, Kev.
Chat Logs
00:00:28
Marius van der Wijden:Historical breakout room lets goo
00:00:34
Luca Donno | L2BEAT:gmgm
00:00:35
Alex Hicks:going to be shipped once the project is scheduled to be shipped? :D
00:01:04
Ladislaus:planning doc
https://github.com/eth-act/planning/blob/main/projects.md
00:01:21
Ladislaus:+ agenda for this call
https://github.com/ethereum/pm/issues/1900
00:02:04
Alex Hicks:also ethproofs at ethcc!
00:02:41
Will Corcoran:Replying to "also ethproofs at et..."
register here: https://luma.com/beast_mode
00:05:24
Ladislaus:Hat auf "Historical breakout ..." mit 🚀 reagiert
00:09:21
Will Corcoran:Nice overview, @Kevaundray Wedderburn !
00:09:29
Kamil Salakhiev:what is the expected size of zkvm proofs?
00:09:36
Jordi - ZisK:Replying to "also ethproofs at et..."
Is there any incentive mechanism for provers?
00:10:30
Justin Traglia:What do you expect the avg proof verification time to be?
00:11:21
Emiliano | Boundless:sorry baby just came from the daycare :D
00:11:23
david kim:Can you share more on the part where you mentioned the attester verifying the zk proof is similar to replaying it?
00:11:40
Ladislaus:Hat auf "sorry baby just came..." mit 😆 reagiert
00:11:43
Alexandre Belling:Is there a spec for the guest program other than the exec-spec?
00:12:26
Alexandre Belling:Replying to "Is there a spec for ..."
Namely, what the input are and their format and what the output must be exactly
00:13:28
Will Corcoran:Replying to "What do you expect t..."
miliseconds, I believe
00:15:01
Gary Schulte:Replying to "Is there a spec for ..."
I haven’t been able to find output spec
00:16:38
Kevaundray Wedderburn:Replying to "Can you share more o..."
I can give some link on discord, but roughly it is because zkVMs provide a proof of execution
00:17:01
Kevaundray Wedderburn:Replying to "Is there a spec for ..."
We are working with the STEEL team to get this into their specs
00:17:57
Kevaundray Wedderburn:Replying to "Is there a spec for ..."
Currently we have the most “updated” API here if you are interested: https://github.com/eth-act/ere-guests/tree/main/crates/stateless-validator-reth/src
00:18:18
Kevaundray Wedderburn:Replying to "Is there a spec for ..."
Happy to take this to discord to discuss further!
00:18:35
david kim:Replying to "Can you share more o..."
That would be great. Look forward.
00:20:56
Yi Sun:Is there a link to the spec for EIP-8025? The EIP page seems mostly empty at the moment.
00:21:18
Manu:Replying to "Is there a link to t..."
https://github.com/ethereum/consensus-specs/tree/master/specs/_features/eip8025
00:23:03
ignacio:Project, 1, 2 and 6 slides link (https://docs.google.com/presentation/d/1WPMCW63Bq6ybbUa0BW85Qz6uZ0ZCHIDAN23j-nTWxuc/edit?usp=drive_link )
00:31:15
Alexandre Belling:Regarding autoprecompiles enablement (or any static code analysis effort). Would it be realistic to require quest programs to provide basic-block annotations?
00:32:00
Leo Alt [powdr]:In my experience it shouldn't be needed (in the specific case of current autoprecompiles)
00:43:45
Justin Traglia:I didn’t quite understand why validators re-sign proofs, but I will follow up later 🙂
00:44:11
Francesco Risitano:https://frisitano.github.io/slides/presentations/optional-proofs/index.html
00:46:53
Manu:Sorry I never shared my screen on Zoom, I had to restart zoom to enable it.
My slides:
https://docs.google.com/presentation/d/1oteBK4ZWb3M2VKhReZWahPs_sKVwRAxB0KT_I7cZOK0/edit?slide=id.g273f645140f_0_5#slide=id.g273f645140f_0_5
00:47:08
Ladislaus:Hat auf "Sorry I never shared..." mit 🙏 reagiert
00:48:45
Justin Traglia:We should consider integrating zkboost-client into CL clients.
00:49:02
Justin Traglia:Replying to "We should consider i..."
Can chat about this async.
00:49:24
Justin Traglia:So we don’t need another 3rd party piece of software.
00:50:09
Kevaundray Wedderburn:Replying to "We should consider i..."
I think for verification it makes a lot of sense
00:50:10
Francesco Risitano:@Justin Traglia the idea is that a validator A can equivocate. They can send an invalid proof to node B and send a valid proof to node C. Node B will now reject all proofs from Validator A so even if node C forwards the valid proof to node B they will reject it. Therefore there is a discrepancy / lack of consensus on what proofs are valid.
00:51:04
Han Jian:Project 5 slide https://docs.google.com/presentation/d/11-h-h2e1dEAvKO-Ei5yStEi5VtOjKegv8w_bSN7ZNuY/edit?slide=id.p#slide=id.p
00:51:42
Ladislaus:Hat auf "Project 5 slide http..." mit 🙏 reagiert
00:52:09
Emiliano | Boundless:We are happy to provide support here: on the choice of GPUs/tuning clusters as well for scaling providing capacity with Boundless network.
00:54:59
Stefan Starflinger:https://docs.google.com/presentation/d/12SR4cTiDJHAZIkUZTvEim9ejlqRkrQ8R6FKXD-F-ivI/edit?usp=sharing
00:55:16
Yi Sun:How do we envision the HW usage ramping over time as new GPUs are released?
00:55:24
Guillaume:who has access to these clusters ?
00:56:19
Stefan Starflinger:Replying to "How do we envision t..."
What do you refer to with usage, how well zkEVM utilizes the GPU compute resources?
00:56:22
Ladislaus:https://zkevm.ethereum.foundation/blog/cryptography-research-update
00:56:57
Kevaundray Wedderburn:Replying to "who has access to th..."
Currently it will be pandaOPs + EF zkEVM team
00:57:34
Yi Sun:Replying to "How do we envision t..."
E.g. would we move to 6090 when released
00:57:38
Stefan Starflinger:Replying to "How do we envision t..."
I assume new GPUs will always be around 10-10% more efficient and it would make sense over time to replace old hardware with new hardware.
00:57:47
Stefan Starflinger:Replying to "How do we envision t..."
10-20*
00:58:02
George Kadianakis:https://zkevm.ethereum.foundation/blog/cryptography-research-update
00:58:19
Ladislaus:Hat auf "https://zkevm.ethere..." mit ❤️ reagiert
00:58:47
Alex Hicks:Sharing my slides in advance: https://docs.google.com/presentation/d/1sbpbHLyT4F3E76w9JNRbY1rs5cPaCtzfL5EoXEFYbTA/edit?usp=sharing
01:02:36
Justin Traglia:Replying to "@Justin Traglia the ..."
Hmm I see. This is a problem because provers cannot currently be slashed. Alternatively, we could allow/verify proofs from other peers if the proof is different, even if you received a bad proof before. There’s some level of trust that peers have successfully verified before forwarding. I’m a little worried that having everyone re-sign a 300KiB message will be a waste of resources.
01:03:50
Francesco Risitano:Replying to "@Justin Traglia the ..."
Is the message size significant? I would assume you just sign a root?
01:04:15
Manu:Replying to "We should consider i..."
Ideally the BN should call a lib for the verification, like done with the KZG lib.
01:04:19
Justin Traglia:Replying to "@Justin Traglia the ..."
Oh, is that it? Maybe that’s not so bad.
01:05:01
Justin Traglia:Replying to "We should consider i..."
I agree.
01:05:09
Francesco Risitano:Replying to "We should consider i..."
Yeah I think we can integrate proof verification into the proof engine
01:05:56
Kevaundray Wedderburn:Replying to "We should consider i..."
Yeah I agree, right now its easier to have this docker for ease of development and versioning
01:07:32
Francesco Risitano:Replying to "@Justin Traglia the ..."
Yes thats how we’ve implemented it in lighthouse.
01:15:48
Emiliano | Boundless:have to drop. great presentations and keep going.
stefan lmk if you need any support on the hw side of things, feel free to reachout on telegram: emilianonbonassi or email: emiliano@boundless.network
happy hacking!
01:16:46
Gary Schulte:if a guest program team is not ready to be on ethproofs yet, does it make sense to sign up ahead of time?
01:16:54
Fara Woolf:https://staging--ethproofs.netlify.app/sign-up
01:17:19
Will Corcoran:Replying to "if a guest program t..."
Which guest?
01:17:32
Ladislaus:Hat auf "https://staging--eth..." mit 🙏 reagiert
01:17:33
Gary Schulte:Replying to "if a guest program t..."
as-yet-unnamed zig based guest from besu team
01:17:42
Will Corcoran:Replying to "if a guest program t..."
Noice :_
Summary
19 highlights
· 3 action itemsExperimental
Summary
19 highlights · 3 action itemsExperimentalfork status and schedule
project updates
- Execution witness standardization in progress with STEEL team00:11:51
- Guest program includes engine API validation, EIP-8142 login blobs00:20:20
- ZKVM interface standards v0 released; C APIs for precompiles/I.O00:23:41
- Consensus layer: new payload request root abstraction for proofs00:33:14
- Lighthouse implementation: proof engine, gossip, validator service complete00:46:53
- Prysm integration adapting to latest EIP-8025 spec00:48:26
- Array integrates multiple ZKVMs; ZKBoost provides CL proof engine00:50:12
- Hardware: DIY 16-GPU cluster $570k/3yr vs $1.5M+ cloud rental00:54:59
security and testing
- ZKVM security sprint: 128-bit security target by end of year00:56:22
- Milestone 1 (end Feb): SoundCalc integration including lookup segments00:56:59
- RISC-V circuit verification complete for SP1, OpenVM; memory consistency pending01:05:02
- Threat model, hardware requirements documentation in progress00:58:47