L1-zkEVM breakout #03, April 8, 2026

Protocol Calls & happenings
1

Agenda

Meeting Time: Wednesday, April 08, 2026 at 15:00 UTC (60 minutes)

GitHub Issue

1 Like
2

YouTube recording available: https://youtu.be/uldmKxLXqF8

3

Meeting Summary:

The L1ZKVM breakout call number 3 focused on updates across multiple projects. Derek presented EVM ASM, a project to implement the EVM in RISC-V assembly for formal verification using Lean 4, with 24 out of 55 RISC-V opcodes currently proven correct. Ignacio shared progress on execution witness generation, including a new Engine API RPC proposal and 139 new tests covering execution witness fields. Marcin provided updates on zkVM guest API standardization, highlighting five accepted standards including RISC-V target triple and cryptographic accelerators, along with two new proposals for minimal memory resources and memory safety guard regions. Francesco reported on DevNet progress, including the deployment of a GPU-backed test network and plans for initial interop testing with Prism at the end of the following week. Han shared improvements to zkVM integration and observability features, including open telemetry integration and real-time proof monitoring dashboards. Cody discussed RISC-V compliance testing using the ACT 4 framework, which revealed new compliance issues and bugs, and shared progress on Python specifications for Snark Stark and OpenVM provers.

Click to expand detailed summary

The meeting began with Ladislaus and Kevaundray discussing font size issues with a prompt calf, though they couldn’t reach a definitive conclusion about the appearance on different screen sizes. Kevaundray then welcomed attendees to the L1ZKVM breakout call number 3 and outlined three agenda items: EVM ASM updates, DevNet updates for ZKCL, and general project updates. The meeting was in its early stages, with Derek expected to provide updates on EVM ASM, though the transcript ended before he could begin.

Derek provided an update on the EVM ASM project, explaining that it aims to implement the EVM directly in RISC-V assembly for L1 ZK EVMs. The project, initiated by Yoichi at Zki Security, focuses on formally verifying the RISC-V and EVM components using Lean 4 and AI to ensure correctness and maintainability. Derek reported that 24 out of 55 RISC-V opcodes have been verified, and the primary EVM opcodes are implemented, though formal verification against the NetherMind EVM spec remains a to-do item.

The team discussed the size of the EVM implementation, with Alexandre noting that the current implementation uses around 1,000 RISC-V instructions, which is much smaller than a complete EVM program would be. Mamy explained that a complete EVM program would include additional functions for gas accounting and other overhead, while the current assembly code removes this complexity. Derek expressed optimism about making progress on the SDF and EVM parts within the next few months, aiming to have a working implementation by the summer to test and evaluate its performance.

The team discussed updates on two main projects. For the execution witness project, Ignacio reported that Developer Uche has been working on a new Engine API RPC proposal called “Engine with Witness” which combines two previous RPC calls into one. The project now has 139 new tests covering various execution scenarios, with good progress reported by multiple team members including Israex and Rev. For the guest programs project, Ignacio announced that a final spec has been completed with 25 tests to validate execution witness rejection. The team can run these tests on their EL working branches targeting the latest DevNets.

Inacio presented updates on benchmarking and metrics improvements, including a 2X speed up in public input calculation using a new Rust SSC library and a 5% overall speed up in block proving time. He also refreshed an emulator profiling tool and is working on transforming benchmarking results into concrete repricing proposals using a similar methodology to Glamson repricings. Marcin briefly mentioned a 20X reduction in witness generation by switching protocols and a 2X ZKSNARK cost reduction achieved through DMA and GPU optimizations.

Marcin provided an update on Project 3, CK VM guest API standardization, highlighting five accepted standards including RISC-V target triple, I/O interface, cryptographic accelerators C interface, execution termination semantics, and memory layout restrictions. He also presented two new proposals: minimal memory resources to address gaps in memory usage across different zkVMs, and memory safety guard regions to catch common low-level bugs like null pointer traps and stack overflows. Marcin noted that the Ethereum Foundation can provide engineering support to help zkVM vendors implement these standards, and requested feedback on the two new proposals under review.

The team discussed several key updates and progress in their projects. Francesco reported on the deployment of a GPU-based test network using the Kurtosis framework, with plans for an initial interop with Prism at the end of next week. Han shared updates on zkVM integration and observability features, including new dashboards for monitoring proof traces. Cody provided updates on RISC-V compliance testing, finding new compliance issues and bugs, and discussed the progress on formal verification and specification efforts. The team also briefly discussed a recent paper by Nadeem Kobesi highlighting issues with formal verification tools, with Alex Hicks providing context on their approach to verification and the use of alternative methods like assembly code and formally verified compilers.

Next Steps:

  • Derek: Continue formally verifying RISC-V opcodes against the SAIL spec (24 of 55 done), targeting completion of remaining 31 opcodes.
  • Derek/Yoichi (EVM ASM team): Begin implementation and formal verification of the EVM state transition function (STF), which has not yet been started.
  • Derek/EVM ASM team: Work toward a working, pluggable EVM ASM implementation by summer.
  • Mamy: Review EVM ASM repository when time permits to assess potential for formally verified AIR constraint generation for branch-free opcodes.
  • Kevaundray: Take Mamy’s suggestion about formalizing AIR representation offline/async for a future call.
  • Uche (Developer): Continue formalizing the spec for the new Engine API RPC (engine_getPayloadWithWitness) and progress the EIP implementation branch.
  • Ignacio: Add remaining execution witness test coverage for edge cases involving out-of-gas scenarios and partial execution witnesses.
  • Ignacio: Complete integration of proving-time benchmarks into automated repricing proposal reports using Maria’s analysis pipeline methodology.
  • EL teams (Reth, Silkworm, others): Run the latest execution witness test release against their working branches targeting the latest Bot DevNet.
  • Francesco (Tom): Touch base with Manu from Prism to confirm status of progress toward the provisional end-of-next-week interop DevNet between Lighthouse and Prism.
  • Francesco (Tom): Clean up open PRs and branches for the DevNet deployment framework, then share single-command deployment instructions with the team.
  • Francesco (Tom): Continue discussions with Lighthouse team regarding upstreaming the Lighthouse changes.
  • Han: Integrate the cluster client directly into zkBoost to bypass the Ariel hop for proof creation requests.
  • Han: Explore proof cancellation functionality in zkBoost to prevent proof request queue buildup for long-running block proofs.
  • Marcin: Profile the most demanding guest programs under realistic conditions to determine concrete minimum stack and heap size values for the minimal memory resources proposal.
  • Marcin/zkVM vendors: Ensure I/O interface and cryptographic accelerator standards are implemented in all zkVM SDKs; reach out to Ethereum Foundation for engineering support if needed.
  • Kevaundray: Async review of Ruben’s proposed accelerator additions (CatalogF and Charity56) for the zkVM standards.
  • Cody: Continue RISC-V compliance testing using the ACT4 framework and report findings to zkVM teams; coordinate eventual disclosure of fuzzing-found bugs.
  • Alex Hicks: Continue engagement with the SAIL spec PR to ensure coverage of unaligned memory access extension (Zicclsm) for formal verification purposes.
  • Alex Hicks/Cody: Prepare final report documenting formal verification boundaries, assumptions, and audits for production code as planned.

Recording Access:

4

YouTube recording available: https://youtu.be/lohcW-sGzjU

5