Meeting Summary:
The meeting focused on updates from the L1ZKVM breakout call number 2, beginning with Andrea presenting developments on the Tamago project, a modified Go compiler for bare-metal execution. The team then discussed progress across multiple ZKVM-related projects, including execution witnesses, guest program specifications, and API standardization efforts. Various updates were shared on ongoing projects including benchmarking, proof verification, and security-related work, with the team agreeing to continue discussions asynchronously in the Discord channel.
Click to expand detailed summary
The meeting began with informal greetings between participants, including Lumi and Kevaundray. Kevaundray confirmed they were recording and introduced the purpose of the L1ZKVM breakout call number 2, which would focus on updates from Andrea regarding Tamager and project updates from seven ongoing projects, followed by a Q&A session. The meeting was set to start with Andrea sharing their screen to present updates on Tamager exploration breakthroughs.
Andrea presented an update on the Tamago project, a modified Go compiler that enables bare-metal execution without an operating system. The project supports four architectures and various devices, including physical hardware and virtual machines. Tamago maintains compatibility with the regular Go ecosystem while reducing code and attack surface. Andrea also mentioned a recent experimental branch that allows running on smaller targets with limited RAM and supports RISC-V architectures without specific extensions.
Andrea explained that the proposed Go compiler modifications are being considered for inclusion in Go 1.27 and do not directly affect hardware drivers or initialization. He clarified that while there are some restrictions on libraries using system calls, the modifications do not introduce major trade-offs compared to regular Go, as they use the same compiler and runtime. The discussion also covered the removal of atomics and double-precision floating-point extensions, with Andrea noting that while this is possible, it requires careful handling of intrinsics and assembly code. Guillaume inquired about other Go extensions and their potential removal, to which Andrea responded that while it’s theoretically possible to support different instruction sets, the complexity varies depending on the specific extension.
Ignacio provided updates on project one, which focuses on execution witnesses for zkVM. Developer Uche has been exploring benchmarking EnginePayload with Windness RPC to improve proving performance, finding that the main bottleneck is the transport layer used in the current JSON RPC implementation. The team released the first Execution Witness generation specs, which include around 1,000 field tests, and compared them with Reth’s implementation to identify inefficiencies and bugs. The next step is for all execution layer (EL) teams to run the fixtures in stateful mode to ensure their ELs generate execution witnesses correctly.
The team discussed the implementation of Execution Witness testing, with Ignacio explaining that the fixtures are compatible with existing EELS tests but include an additional ExecutionWitness field for comparison. The discussion covered the difference between debug Execution Witness and engine payload with witness, with Kevaundray requesting clarification on terminology. Ignacio presented updates on Project 2, which involves developing specs for guest programs, including a draft implementation and new fixtures for stateless input and output bytes. The team also discussed serialization options, with Gary noting that Zilkworm currently uses RLP and suggesting benchmarking different encoding methods.
The team discussed the implementation and testing of stateless inputs and chain configurations for the guest program. Ignacio explained that providing the full chain configuration allows for flexibility in testing various setups beyond mainnet configurations. Somnath raised concerns about testing the witness and MPT handling for stateless cases, which Ignacio confirmed would be addressed with new test cases in the coming weeks. The group also discussed encoding options between RLP and SSZ, with Ignacio noting that RLP was previously found to be slower than SSZ but further exploration is needed. Marcin presented updates on Project 3, CKVM guest API standardization, highlighting three accepted standards: the RISC-V target triple, I/O interface, and cryptographic acceleration C interface.
The team discussed progress across multiple ZKVM-related projects. Marcin reported on standards progress, noting that execution termination semantics is ready for acceptance while memory layout restrictions needs more attention from vendors. Francesco presented updates on Lighthouse implementation, including proof validity features and a proposed new RPC method for proof-capable peer discovery. Han shared updates on Project 5, including the preparation of a 4x4 cluster for benchmarking and the drafting of ProofNote API for zkester. Ignacio provided an overview of Project 6’s benchmarking efforts, including new releases and a proof verification dashboard. Cody gave updates on security-related work, including RISC-V compliance testing improvements and progress on creating specs for ZKVMs using AI translation. The team agreed to continue discussions asynchronously in the Discord channel.
Next Steps:
- Andrea: Follow up on Go 1.27 proposal and respond to any concerns or feedback from Go core team
- All EL teams: Run execution witness fixtures from the new release in stateful mode, generate execution witness for test blocks, and compare against the ExecutionWitness field in fixtures
- All EL teams: Contact team via Discord if any bugs are found in the execution witness specs or if there are questions
- Ignacio: Create more tests for Execution Witness border cases to harden the implementation
- Ignacio: Create more tests for guest program covering invalid inputs and missing information cases
- EL teams working on guest programs: Start looking at the draft guest program specs in the ExecutionPs repo and provide feedback
- EL teams: Experiment with stateless input and stateless output fields, including testing SSC deserialization with libraries they plan to use
- All stakeholders: Review and signal support for the Execution termination semantics standard to move it to accepted status
- All zkVM vendors: Review the memory layout restrictions specification and leave feedback
- Francesco: Speak with Manu and other individuals about the ExecutionProof status RPC proposal and finalize whether to add it to specs
- Han: Focus on cluster integration to test on 4x4 cluster, finish implementation of ProofNote API on ZK boost, and integrate with ConsensusLayer
- Han: Experiment with 4x4 cluster to get optimal performance for proofs and create documentation for reproducing the setup
- Ignacio: Integrate Maria’s analysis pipeline for repricing analysis to create end-to-end pipeline from measurements to repricing results
- Cody: Integrate Act 4 (new RISC-V compliance testing framework) into test monitor
Recording Access: