Ethproofs Report (August 26, 2025)

The recent @eth_proofs Call #4 focused on the proposal to enshrine RISC-V at @ethereum L1, diving into the technical, architectural, and philosophical implications of using a standard ISA for zkVMs and Ethereum clients. 

The two-hour session featured updates from teams building zkVMs, hardware providers, formal verification researchers, and Ethereum leadership, including @VitalikButerin.

Full recording:

Summaries of the talks

Justin Drake opened the call with updates to the Ethproofs tracker and broader strategic alignment efforts. He framed the discussion in the context of Lean Ethereum and the motivation for enshrining RISC-V at the protocol level.

Highlights from @drakefjustin's talk:

• Tracker improvements: GPU readiness, ISA classification, and client compatibility now tracked
• Plans to auto-generate zkVM pages with health metrics and roadmap alignment on http://ethproofs.org
• @ethereumfndn's Lean Ethereum initiative (Consensus, Execution, Data) as the long-term framing
• Reiterated that RISC-V is already the de facto standard - 9 out of 10 zkVMs proving Ethereum mainnet blocks use it
• Emphasized benefits of a standardized ISA: developer tooling, compiler reuse, hardware support, and formal verifiability
• Positioned enshrining RISC-V as key to building a ZK-native Ethereum L1 and reducing fragmentation across zkVMs

Yi Sun of @axiom_xyz & @openvm_org presented progress on OpenVM’s GPU prover.

Highlights from @theyisun's talk:

• Fully end-to-end trace generation and proving on GPU
• Dual-licensed under MIT & Apache 2.0
• Interpreter running at 250 MHz
• $0.02 per Ethereum mainnet transaction
• Example block proving in ~80 seconds on single 4090 GPU
• Real-time proving now achievable via multi-GPU parallelization (25 GPUs = ~8.5 sec/block)

Sphere Liu of @Scroll_ZKP provided updates on the Ceno zkVM:

• Added recursion support in proving
• GTR and Base Volt verifier circuits implemented using OpenVM DSL (~30% of runtime)
• Supporting both BabyBear and Goldilocks fields
• GPU prover at 1.5 MHz on 3090 GPU
• Plans to onboard to Ethproofs in October 2025
• Sphere also presented research on optimizing register handling in register-based zkVMs:
• Proposed avoiding generic memory-style register tracing
• Suggested dividing programs into basic blocks (no branches) and using GKR-style proofs
• This reduces register proof costs from 2 traces per op → 1 per block boundary
• Reduces overhead for loop-heavy programs, making registers “behave like real registers”

Jeremy Bruestle gave a 30-minute deep-dive into why @RiscZero chose RISC-V and why it may be ideal for Ethereum L1.

Highlights from @BruestleJeremy's talk:

• Tradeoffs: custom ISA vs. standard ISA - chose RISC-V for long-term compiler and dev ecosystem benefits
• Compared RISC-V vs. WebAssembly (WASM) and MIPS - found RISC-V minimal, elegant, and hardware-friendly
• Suggested standardizing around RV64GC (64-bit + compressed + full extensions)
• Advocated for using standard Linux ABI for broader language/library support
• ZK benefits: deterministic, no floating-point required, formal verification-friendly
•   Proposed path to broader RISC-V adoption in Ethereum via ZK clients and L1 enshrinement

Next, @VitalikButerin shared his perspective on enshrining RISC-V at L1:

• Proving cost is bottlenecking gas limit scaling - block execution + hashing = 90% of ZK prover time
• Replacing EVM with a simpler ISA (like RISC-V) could give 10–100× proving speedup
• Precompiles are complex, consensus-fragile, and better replaced with RISC-V code

Envisioned a multi-step transition:

1. Add RISC-V precompile(s)
2. Let contracts opt into RISC-V VM
3. Migrate EVM into RISC-V code eventually

Highlighted benefits for privacy-preserving clients, account abstraction, and simplicity

Diego Nehab of @cartesiproject explored the use of RISC-V’s supervisor mode and privileged extensions:

• Highlighted that EVM embeds OS-level behavior into the VM
• Proposed shifting part of the L1 system logic into RISC-V “firmware” inside the VM, allowing updates without changing the L1 client
• Supported full Linux support inside Cartesi’s VM (privileged RISC-V ISA)
• Questioned how many EIPs could be turned into upgradable RISC-V firmware

Next, @ethereumfndn's @alexanderlhicks discussed the formal verification pathway for RISC-V-based zkVMs:

• Lean-based tooling now exists to verify zkVMs against official RISC-V ISA spec
• Advocated using MLIR (LLVM dialects) to bridge custom ISAs and formally verifiable workflows
• Highlighted compiler efforts (e.g. by @powdr_labs team) toward write-once memory and infinite registers
• Argued that MLIR-based ZK circuits could offer zkVM modularity + formal verification

Milos Stanisavljevic of @PonosTechnology introduced the Ponos crypto CPU:

• A specialized RISC-V processor for ZK workloads
• 4x vector cores + 8x scalar cores + modular arithmetic co-processors
• Designed for proving + execution: trace gen, NTT, ECDSA, modular exponentiation
• Target: 16-core cards priced ~$1,200 proving Ethereum blocks in real-time
• 100× better energy efficiency vs. current GPU/CPU setups
• ASIC planned for 2026

Finally, @vwuestholz of @ConsensysAudits showcased Argus, a new fuzzer for zkVMs:

• Found 11 critical bugs across @a16zcrypto's Jolt, @RiscZero, and @NexusLabs 
• Catches both soundness (wrong proof accepted) and completeness (crash) bugs
• Uses adversarial program execution to break constraints
• Planning to support Plonky3, BL3, and more proof systems
• Fuzzer and tooling currently private but actively used

The next call will focus on Native Rollups and feature a deep-dive presentation by @l2beat's @donnoh_eth. 

Future calls will expand the discussion toward the $1 Million Bounty for Proving the Up-to-Capacity Proximity Gaps Conjecture (see https://hozk.io/journal/ethereum-foundations-1-million-bounty-for-proving-the-up-to-capacity-proximity-gaps-conjecture) and broader explorations of RISC-V alternatives and formal verification.