EIPsInsight

Loading Experience

Preparing your insights...

Loading0%
zkEVM2026-03-11_002

L1-zkEVM Breakout #002

2026-03-11 2 decisions 429 transcript lines

Transcript

Ask about this call

Answered from this call's summary and transcript only.

AI-generated — verify against the recording.

Call summary

Decisions
  • RV64IM baseline required; 32-bit ZKVMs must migrate to 64-bit — 00:39:23
  • ZKVM SDKs must be no_std compatible for bare-metal target — 00:41:03
Highlights
  • Tamago Update:
    • ·TamaGo: bare-metal Go runtime; proposal for upstream acceptance in Go 1.27 — 00:06:10
    • ·Experimental branch removes A and D RISC-V extensions; runs in 5-6MB RAM — 00:10:56
  • Zkvm Standards:
    • ·Three standards accepted: RV64IM target, I/O interface, crypto acceleration C API — 00:39:23
    • ·Execution termination semantics ready to accept; memory layout needs review — 00:42:04
  • Guest Program Specs:
    • ·First draft guest program specs published; using SSZ for serialization — 00:31:47
    • ·Stateless input/output fields added to fixtures for early experimentation — 00:32:32
  • Benchmarking Updates:
    • ·Fusaka support added to benchmark tests; dashboard updated with latest results — 00:58:25
    • ·Proof verification dashboard released; measures on EIP-7870 compliant hardware — 01:01:17
  • Proving Infrastructure:
    • ·4x4 GPU cluster (16 GPUs) in preparation for benchmarking — 00:53:57
    • ·Proof Node API drafted: request proof, SSE subscription, deterministic retrieval — 00:47:35
  • Execution Witness Specs:
    • ·First execution witness spec released with 12,000+ test fixtures — 00:24:03
    • ·Spec validated against RETH; bugs found in both RETH and specs — 00:25:15
  • Serialization Discussion:
    • ·Engine API SSZ initiative: 20x performance improvement over JSON in worst cases — 00:22:23
    • ·SSZ vs RLP debate ongoing; guest input encoding not finalized — 00:38:31
Action Items
  • All EL teams — Run execution witness fixtures; compare against canonical witness field — 00:23:50
  • All ZKVM vendors — Review and provide feedback on memory layout restrictions standard — 00:42:52

Meeting chat100

  • Will Corcoran

    zkGM

  • Kevaundray Wedderburn

    Reacted to "zkGM" with 🔥

  • Luca Donno | L2BEAT

    Reacted to "zkGM" with 🔥

  • Will Corcoran

    love that font @Kevaundray Wedderburn

  • Luca Donno | L2BEAT

    Reacted to "love that font @Keva..." with ➕

  • Tamaghna

    Reacted to "love that font @Keva…" with ➕

  • Fara Woolf

    Reacted to "zkGM" with 🔥

  • Somnath Banerjee

    Are there OS level tweaks built in?

  • Lumi | Offchain Labs

    Have you talked with Go Ethereum team for ZK proving GETH?

  • Somnath Banerjee

    Replying to "Are there OS level..." *HW/target level

  • Guillaume

    nope

  • Lumi | Offchain Labs

    Reacted to "nope" with 👍

  • Ruben

    any major tradeoffs comapred to regular go?

  • Łukasz Rozmej

    Can you share slides?

  • Lumi | Offchain Labs

    Reacted to "Can you share slides..." with ➕

  • Kevaundray Wedderburn

    Replying to "Have you talked with..." https://github.com/eth-act/skunkworks-tama/tree/kw/develop

  • Andrea Barisani

    https://github.com/abarisani/abarisani.github.io/tree/master/research/tamago

  • Luca Donno | L2BEAT

    Reacted to "nope" with 😮

  • Andrea Barisani

    Slides

  • Andrea Barisani

    rv64cfimsu

  • Lumi | Offchain Labs

    Any plans to target WASM?

  • Andrea Barisani

    wasm is already supported by Go

  • Andrea Barisani

    https://go.dev/wiki/WebAssembly

  • Kevaundray Wedderburn

    Replying to "Any plans to target ..." Do you mean wasm32-unknown or with wasi?

  • Łukasz Rozmej

    There is an initiative to move to REST and SSZ on engine API

  • Kevaundray Wedderburn

    Replying to "Any plans to target ..." We didn’t have time to go into it, but we also tried Go -> WASM -> C -> RISCV64 and Tamago seems to be the most performant

  • Lumi | Offchain Labs

    Replying to "Any plans to target ..." wasm32-unknown

  • Lumi | Offchain Labs

    Reacted to "We didn’t have time ..." with 👍

  • Kevaundray Wedderburn

    Reacted to "wasm32-unknown" with 👍

  • Kevaundray Wedderburn

    Reacted to "There is an initiati..." with 👍

  • Luca Donno | L2BEAT

    Reacted to "There is an initiati..." with 🙏

  • Trent

    See here: https://github.com/ethereum/execution-apis/pull/764

  • Andrea Barisani

    Can you share slides? I just updated the deck at the link I shared earlier. For any further questions please email me, happy to help.

  • Guillaume

    and bugs

  • Kevaundray Wedderburn

    Reacted to "Can you share slides..." with 🙏

  • Łukasz Rozmej

    Can you review Nethermind implementation?

  • Kevaundray Wedderburn

    Replying to "Can you review Nethe..." I started looking into it a few days ago

  • Łukasz Rozmej

    Reacted to "I started looking in..." with 🙏

  • Iván | Lambda

    Are you planning on supporting EIPs 7708, 7778, and 7843 in the new spec tests? I’ve been integrating them with ethrex and made ~13 of them pass by “disabling” those EIPs

  • Łukasz Rozmej

    can you post the link to the spec?

  • Iván | Lambda

    https://github.com/ethereum/execution-spec-tests/releases/tag/zkevm%40v0.2.0 if I’m not mistaken

  • Kevaundray Wedderburn

    Replying to "can you post the lin..." Yep this is correct

  • Kevaundray Wedderburn

    Replying to "can you post the lin..." We use the projects/zkevm branch on the execution-specs repo: https://github.com/ethereum/execution-specs/tree/projects/zkevm

  • Gary Schulte

    link to guest spec?

  • Somnath Banerjee

    Is there any guest program tests at all, other than EESTs at the moment?

  • Kevaundray Wedderburn

    Replying to "link to guest spec?" Its in the execution specs repo here: https://github.com/ethereum/execution-specs/blob/1d98b55a4a5d0615bca62ec69b308096059f6c06/src/ethereum/forks/amsterdam/stateless_guest.py#L33

  • Ruben

    @kev i believe all the links to the slides, specs, etc. will be provided after the call like the last time, right?

  • Gary Schulte

    ssz neutral == 😂

  • Kevaundray Wedderburn

    Replying to "Is there any guest p..." Can you clarify what would need to be added?

  • Kevaundray Wedderburn

    Reacted to "ssz neutral == 😂" with 😁

  • Somnath Banerjee

    Zilkworm uses RLP

  • Kevaundray Wedderburn

    Replying to "@kev i believe all t..." Yep, it will be on the issue

  • Gary Schulte

    Replying to "Zilkworm uses RLP" zevm-stateless, besu zig guest is using rlp also

  • Kevaundray Wedderburn

    Replying to "Zilkworm uses RLP" What is being RLP’d?

  • Gary Schulte

    Replying to "Zilkworm uses RLP" stateless_input

  • Łukasz Rozmej

    Replying to "Zilkworm uses RLP" Nethermind is currently using RLP

  • Somnath Banerjee

    Replying to "Zilkworm uses RLP" The witness + block data

  • Luca Donno | L2BEAT

    chain id as input helps with native rollups

  • Ruben

    Reacted to "Yep, it will be on..." with 👍

  • Iván | Lambda

    Reacted to "chain id as input he..." with ❤️

  • Kevaundray Wedderburn

    Replying to "Zilkworm uses RLP" We can benchmark concretely with zkVMs,ssz was more performant outside of circuit. I don’t think we have a strong bias towards ssz or rlp

  • Trent

    Reacted to "chain id as input he..." with ❤️

  • Gary Schulte

    historically ELs do not have a complete-enough SSZ implementation

  • Łukasz Rozmej

    we have to go with something platform/library independent

  • Ruben

    Reacted to "historically ELs d..." with ➕

  • Łukasz Rozmej

    Reacted to "historically ELs do ..." with ➕

  • Somnath Banerjee

    Replying to "Zilkworm uses RLP" RLP should be slower, but it's the EL standard now. We plan on switching to something faster (not ssz)

  • ignacio

    Replying to "historically ELs do ..." Yes, this is true. Although this other chats of potentially supporting SSZ in EngineAPI might give more reason on maybe trying to support it

  • Kevaundray Wedderburn

    Replying to "Zilkworm uses RLP" I don’t think we can standardize on something that is not rlp or ssz because every EL will need to support it

  • Gary Schulte

    Replying to "historically ELs do ..." if ssz engine api makes it into a fork, definitely that should resolve it. I wasn’t expecting that to actually make it into a fork though

  • Kevaundray Wedderburn

    Replying to "Zilkworm uses RLP" Maybe message pack? But I think we should benchmark because it could be a micro optimization that is not needed

  • Kevaundray Wedderburn

    Reacted to "we have to go with s..." with 👍

  • Iván | Lambda

    Reacted to "we have to go with s..." with 👍

  • Gary Schulte

    Replying to "Zilkworm uses RLP" https://xkcd.com/927/

  • Kevaundray Wedderburn

    Reacted to "https://xkcd.com/927..." with 😁

  • Łukasz Rozmej

    Reacted to "I don’t think we can..." with 👍

  • Francesco Risitano

    Replying to "Zilkworm uses RLP" Transport protocol doesn’t necessarily have to follow the same encoding as zkvm input, however it may make sense to do so.

  • ignacio

    Reacted to "I don’t think we can..." with 👍

  • Somnath Banerjee

    Reacted to "Transport protocol..." with 👍

  • wawd dad

    Reacted to "Transport protocol d..." with 👍

  • Łukasz Rozmej

    Reacted to "Transport protocol d..." with 👍

  • Luis Pinto | Besu

    How much effort would be for ZKVms to support F and D RISC-V instructions? A big effort? Just curiosity

  • Somnath Banerjee

    Replying to "Zilkworm uses RLP" We put in RLP, speculating on the standards. But as of today the pre-processing is a reality and we can just do something way faster with the pre-processing. The JSON-RPC can and should be replaced with RLP or ssz and we can tweak it further

  • Manu

    That’s why there is also the info in metadata

  • Kevaundray Wedderburn

    Would we need a MetadataV4 for that?

  • Manu

    Replying to "That’s why there is ..." It’s already done if I’m not wrong

  • Manu

    Replying to "That’s why there is ..." here

  • Manu

    Replying to "That’s why there is ..." https://github.com/ethereum/consensus-specs/pull/4877

  • Kevaundray Wedderburn

    Replying to "That’s why there is ..." You mean for 8025?

  • Manu

    Replying to "That’s why there is ..." yes

  • Kevaundray Wedderburn

    Replying to "That’s why there is ..." Ah yeah, I think the idea is that with ExecutionProofStatus, we would not upgrade the version

  • Francesco Risitano

    Introducing a new version touches pre-existing codepaths and adds complexity because peers would have to use different versions of the existing status type for different peers. I think its cleaner to have things decoupled into a separate rpc @Manu

  • Andrea Barisani

    I need to go, thanks for the opportunity of presenting TamaGo. Again email me for any questions, happy to help, I think it would be a very interesting use case for it. Cheers.

  • Kevaundray Wedderburn

    We also have been analysing what precompiles we can turn into evm bytecode. Currently doing some analysis to see how often the precompiles are being used. The main issue right now is modexp imo

  • Kevaundray Wedderburn

    Reacted to "I need to go, thanks..." with 🙏

  • cody

    Reacted to "I need to go, than..." with 🙏

  • Ruben

    Reacted to "We also have been ..." with 👍

  • cody

    https://codygunton.github.io/talks-and-writing/2026-03-11-zkevm-breakout/

  • ignacio

    Slides for Proj 1, 2 and 6: https://docs.google.com/presentation/d/1fmSZYyp8SNl3FHw4JQGAz1Ik0gQlfq6XEYcV1xLPChc/edit?usp=sharing

  • Han Jian

    Slide for project 5 https://docs.google.com/presentation/d/1Iw5RqCIrhvhmAWUl9UjAS9I1zSq1Lr50YVukGMqmqp0/edit?usp=sharing

Key decisions

  • RV64IM baseline required; 32-bit ZKVMs must migrate to 64-bit

  • ZKVM SDKs must be no_std compatible for bare-metal target