L1-zkEVM Breakout #003
Transcript
- Luca Donno | L2BEAT
gmgm
- Kevaundray Wedderburn
Reacted to "gmgm" with ❤️
- Ladislaus
Hat auf "gmgm" mit 🫡 reagiert
- Alex Hicks
great chat 👍
- Francesco Risitano
Reacted to "gmgm" with 🫡
- Francesco Risitano
Reacted to "gmgm" with ❤️
- Francesco Risitano
Reacted to "great chat 👍" with 😃
- Alexandre Belling
It seems that the overall size of the EVM implementation is very small no? Is that around 1000-ish R5 instruction for the EVM?
- Alex Hicks
the STF will be much bigger though
- Alex Hicks
can we talk about optimizing the produced assembly?
- Alexandre Belling
Reacted to "can we talk about op..." with 👍
- Alex Hicks
ok Mamy is doing it :D
- Mamy
xD
- Yi Sun
One concern about EVM -> AIR directly is that the correctness of the AIRs depends on the global memory / execution model of the zkVM.
- Mamy
this should use unsaturated arithmetic. And there is a formally verified ways of doing this in fiat-crypto
- Alex Hicks
PR this to claude.md please
- Alex Hicks
:)
- Tamir Hemo
It also depend on field sizes etc
- Tamir Hemo
To add to Alex point we can also add skills for the AI to write zk optimal assembly vs hardware optimal
- Alex Hicks
yes that's the idea, the performance profile is obviously very different
- Mamy
One concern about EVM -> AIR directly is that the correctness of the AIRs depends on the global memory / execution model of the zkVM. I wonder if we can have a common AIR serialization format that can handle the variatiosn between the zkVMs?
- Derek Sorensen
Reacted to "PR this to claude.md..." with 👍
- Alexandre Belling
For direct assembly-written EVM, I expect the auto-precompiles approach might work well.
- Derek Sorensen
Reacted to "To add to Alex point..." with 👍
- Derek Sorensen
Reacted to "For direct assembly-..." with 👍
- Alexandre Belling
As there would be typically not that many modules. And that would also avoid to maintain an AIR for EVM opcodes
- Yi Sun
Replying to "One concern about EV..." One concern about EVM -> AIR directly is that the correctness of the AIRs depends on the global memory / execution model of the zkVM. I wonder if we can have a common AIR serialization format that can handle the variatiosn between the zkVMs? I think this might be difficult. We have a separation between these as the “Core” and “Adapter” part of chips in OpenVM, but I wouldn’t expect the separation to generalize across different designs.
- Alex Hicks
Reacted to "As there would be ..." with 💯
- cody
Does evm-asm currently give a way to execute a RV64IM binary?
- Derek Sorensen
Do you have a link for these specs and tests?
- Kevaundray Wedderburn
Replying to "Do you have a link f..." Its in the execution specs: https://github.com/ethereum/execution-specs/tree/projects/zkevm/src/ethereum/forks/amsterdam
- Derek Sorensen
Reacted to "Its in the execution..." with 👍
- ignacio
slides link proj 1, 2 and 6 https://docs.google.com/presentation/d/1YPIU2jPPTetAUw_qzQsefKntXIqOPeFZja7udtFVQUI/edit?usp=sharing
- Ladislaus
Hat auf "slides link proj 1, ..." mit 🙏 reagiert
- Kevaundray Wedderburn
Reacted to "slides link proj 1, ..." with 🙏
- Mamy
@Alex Hicks https://github.com/Verified-zkEVM/evm-asm/issues/175
- cody
Replying to "Does evm-asm curre..." bump
- Derek Sorensen
not yet, no. But hopefully soon 🙂
- cody
Reacted to "not yet, no" with 🙏
- Kevaundray Wedderburn
Replying to "@Alex Hicks https://..." We could also test this with normal guest programs too
- Kevaundray Wedderburn
Replying to "@Alex Hicks https://..." Maybe some sort of conditional compilation such that if the ISA has instructions like add-with-carry, then it uses saturated limbs and without it uses unsaturated
- Ruben
for accelerators, i proposed https://github.com/eth-act/zkvm-standards/issues/23 for io, https://github.com/eth-act/zkvm-standards/issues/21
- Francesco Risitano
Sorry mic issues
- Kevaundray Wedderburn
Replying to "for accelerators, i ..." keccakf makes sense — I think a lot of zkVMs have accelerators for the permutation anyways. It would maybe make our interface incoherent however because the exposed methods correspond to evm precompiles
- Barnabas
couple more days
- Barnabas
just wanna make sure its very user friendly
- Kevaundray Wedderburn
Replying to "for accelerators, i ..." +1 on logging too — maybe @Marcin Bugaj you have some thoughts on these too?
- Kevaundray Wedderburn
Reacted to "just wanna make sure..." with 🔥
- Barnabas
are the lh changes upstreamed already?
- Barnabas
are prysm changes upstreamed already?
- Ruben
Reacted to "+1 on logging too ..." with 👍
- Ruben
Reacted to "keccakf makes sens..." with 👍
- Francesco Risitano
Are all of those dashboard views provided via grafana?
- Han Jian
Slide for project 5 https://docs.google.com/presentation/d/16TJS0fwgxg9IzjLZWq-xsolKP9eOD2t6wolT-eLipfA/edit?usp=sharing
- Kevaundray Wedderburn
Reacted to "Slide for project 5 ..." with 🔥
- Francesco Risitano
Reacted to "Slide for project 5 ..." with 🔥
- Francesco Risitano
Slides for consensus layer updates: https://frisitano.github.io/slides/presentations/optional-proofs-2026-04-08/index.html#1
- Ladislaus
Hat auf "Slides for consensus..." mit 🙏 reagiert
- Alex Hicks
can quickly comment if you want
- Francesco Risitano
Reacted to "just wanna make sure..." with ❤️
Call summary
Targets
- •End of next week - Lighthouse-Prysm interop DevNet launch - 00:45:35
- •Summer 2026 - EVMASM working implementation target - 00:22:02
Highlights
- Zkvm Standards:
- ·5 standards accepted: RISC-V target, I/O interface, crypto accelerators, termination, memory - 00:35:18
- ·Proposed: minimum memory resources standard for stack/heap guarantees - 00:39:02
- ·Proposed: guard regions for null pointer and stack overflow detection - 00:40:22
- Consensus Devnet:
- ·GPU-backed proof DevNet deployed end-to-end with single-command setup - 00:43:41
- ·Target: Lighthouse-Prysm interop DevNet by end of next week - 00:45:35
- ·New P2P messages: execution-proof-status and execution-proofs-by-range - 00:46:33
- Security Testing:
- ·ACT4 RISC-V compliance testing found multiple bugs across ZKVMs - 00:54:12
- ·Compliance testing now includes proving and verification, not just execution - 00:55:03
- ·OpenVM ProverSpec extracted with 50% less effort than ZISC version - 00:56:38
- Evmasm Development:
- ·EVMASM: EVM written in RISC-V assembly using Lean4 formal verification - 00:08:18
- ·24 of 55 RISC-V opcodes formally verified against SAIL spec - 00:14:52
- ·Target: working implementation by summer 2026 - 00:22:02
- Guest Program Progress:
- ·Guest program spec finalized with 25 invalid witness rejection tests - 00:27:38
- ·libSSZ library provides 2x speedup; all guest dependencies now no-std - 00:29:44
- ·ZISC cost reduced 2x via GPU DMA and memcopy optimizations - 00:32:46
- Proving Infrastructure:
- ·ZISC upgraded to 0.16.1 with performance improvements - 00:51:27
- ·OpenTelemetry integrated in AIRey and ZKBoost for trace monitoring - 00:51:41
- Execution Witness Updates:
- ·New Engine API: enginePayloadWithWitness combines payload and witness generation - 00:23:44
- ·139 execution witness tests released; Erigon passing current suite - 00:24:23
- ·Witness generation 20x faster via HTTP+SSZ vs JSON-RPC+JSON - 00:34:52
Action Items
- •ZKVM teams - Review Alex Hicks' SAIL PR for unaligned access extension coverage - 00:19:54
- •All teams - Review repricing methodology adapted from Glamsterdam analysis pipeline - 00:32:33
- •ZKVM vendors - Review and provide feedback on memory resources and guard region proposals - 00:38:34
Key decisions
New Engine API: enginePayloadWithWitness combines payload and witness generation
Introduction of the enginePayloadWithWitness method to the Engine API to combine payload and witness generation.Guest program spec finalized with 25 invalid witness rejection tests
Finalization of the guest program specification and its associated test suite for invalid witness rejection.5 standards accepted: RISC-V target, I/O interface, crypto accelerators, termination, memory
Acceptance of five standards for zkVMs, covering the RISC-V target, I/O interface, crypto accelerators, termination, and memory.New P2P messages: execution-proof-status and execution-proofs-by-range
Implementation of new peer-to-peer messages to support execution proof status tracking and range-based proof requests.
AI Disclaimer: Some content or metadata on EIPsInsight may be AI-inferred or automatically compiled. If you find any discrepancy, please contact us at dev@avarch.org.