ZK Proving Infrastructure
Zero-knowledge proving of Ethereum has crossed the threshold for real-time use: EthCC[9] featured two independent teams demonstrating sub-12-second block proving on commodity hardware. This unlocks synchronous cross-chain composability and decentralized validation at scale. (→ EthCC[9] — Conference Overview)
Real-Time Ethereum Proving
OpenVM 2.0 (Yi Sun / Axiom)
- Proves Ethereum blocks in 5 seconds average, P99 = 8.5 seconds on 16 GPUs (down from 64 GPUs prior).
- Proof system: SWIRL — multilinear commitments with 100-bit post-quantum security, <300KB proof size.
- Formal verification of RISC-V frontend in Lean 4 — first formally verified zkVM compiler.
- Ahead-of-time native executor runs at 3.8 GHz to match computation speed.
- Open-source; community extensibility via precompile coprocessors.
- Alan Li’s prediction: “By 2035, 99% of blockchain computation happens off-chain and verified by ZK proof.”
Pico Prism 2.0 (Alan Li / Brevis)
- Architecture rewrite: global scheduler + data locality optimization + CUDA batch operations.
- Reduced GPU requirement from 64 to 16 (75% compute reduction) at same proving speed.
- P99 = 8.5 seconds — equivalent to one Ethereum slot (12 seconds), enabling real-time L1 verification.
- Function-level precompiles + application-level coprocessors = modular extensibility.
Threshold crossed: 16 GPUs are accessible to individuals and small operators. This is the decentralization inflection point for ZK validation.
ZK Assembly & Direct Arithmetization (David Pearce / ConsenSys Linea)
Linea takes a different approach — writing constraints directly against EVM semantics rather than compiling via a RISC-V VM:
- ZK Assembly language: field-agnostic, destructuring assignment, unstructured control flow.
- Vectorization: flattens programs into vector instructions to minimize trace rows.
- Branch table optimization + field-agnosticity via limb splitting.
- Trade-off: more complex toolchain, tighter constraint efficiency vs. VM-based approaches.
Two philosophies:
- zkVM (OpenVM, Pico): compile arbitrary Rust programs → RISC-V → ZK circuit. Flexibility at the cost of overhead.
- Direct arithmetization (Linea): write EVM semantics explicitly into circuits. Tighter but less general.
Post-Quantum Proof-of-Seed (Fabrizio Romano Genovese & Stefano Gogoso)
ZK enables a PQ key recovery primitive:
- Vitalik’s proposal: prove ownership of seed phrase (not private key) — hashing is quantum-resistant.
- ZK-Boo runs on Ledger’s 32KB stack, generating a proof that seed → key without revealing seed.
- Challenge: proof is huge (~438 fragments). Second stage compresses via Binius or similar.
- Enables key rotation without breaking ECDSA — a migration bridge to the PQ era. See also: Post-Quantum Cryptography.
Ethereum Economic Zone (EEZ) Dependency
Real-time ZK proving is the prerequisite for synchronous cross-L2 composability. Jordi Baylina (Zisk) demonstrated cross-chain calls returning within a single block using real-time proofs. If proof latency stays <12 seconds, the Ethereum Economic Zone (EEZ) becomes practical — restoring the composability that rollups fractured.
Requirement: all participating L2s must accept EEZ security model + prove blocks fast enough for synchronous calls.
Hardware & Privacy Proving
World Orb (0xPenryn / Worldcoin): Custom silicon for biometric ZK:
- Iris biometrics + MPC + ZK for uniqueness verification at human scale.
- Multi-party computation (with Deseo) splits iris codes into secret shares — no single party sees raw biometrics.
- Iris chosen because: sufficient entropy at human scale, doesn’t reveal age/gender/race unlike face.
- Tamper resistance via secure elements with provisioned keys; SD card firmware enables verification.
FHE as Complementary Privacy Primitive
Eugene Joo (Wasder):
- CKKS-based FHE enables computation on encrypted data without decryption — different from ZK.
- EF Institutional Privacy Task Force: mapped 52 privacy patterns, 20 use cases, 21 vendors.
- Most practical near-term use: shielded pools (ZeroCash-style) + compliance via separate spending/viewing keys.
- FHE multisigs (OpenZeppelin): possible but computationally heavy; requires asynchronous decryption steps that break ERC-4337 flow.
Formal Verification of Provers
A new concern: verifying the prover itself, not just the contracts. OpenVM’s Lean 4 formal verification of the RISC-V frontend is the first instance of a fully proved zkVM compiler. This matters because a bug in the prover invalidates all proofs generated by it.
Keeper: Turning Geth into a zkVM Guest (Guillaume Ballet / EF, ETHDenver 2026)
The challenge: Geth (Go) and Nethermind (C#) are the two dominant clients, but neither was designed for embedded/ZKVM targets. Running them as ZKVM guest programs requires bridging a fundamental mismatch. (→ [[ethdenver]])
What is a ZKVM guest program? A program that runs inside a ZKVM — which today resembles an embedded target (no MMU, no OS, bare RISC-V or MIPS architecture). The guest runs, the ZKVM produces traces, ZK magic turns those traces into a proof.
The mismatch problem:
- Geth is written in Go and relies on an OS and runtime
- Go makes OS syscalls; in a ZKVM there’s no OS to answer those calls → nothing can be proved
Two Approaches
| Approach | Description | Trade-off |
|---|---|---|
| Embedded-friendly rewrite | Only accept programs in no-std Rust/C | Ships faster, but very constrained even in “safe” languages |
| ZKVM provides OS interface | ZKVM emulates enough Linux kernel for a binary to run as-if on Linux | More ZKVM complexity, but lets you run existing binaries unchanged |
Guillaume argues the ZKVM-as-OS approach is correct: Linux is already designed for embedded targets without MMU; implementing a minimal Linux kernel interface is feasible. The optimization budget for ZKVMs should be partially spent here.
A third option (“fit square peg into round hole”): hack a Linux binary directly into a ZKVM. Works experimentally, not acceptable for mandatory proofs.
Geth’s Target Platforms (as of ETHDenver 2026)
| ZKVM | Architecture | Status |
|---|---|---|
| Ziren | Custom | Works well — first class support |
| SP1 | WASM → RISC-V | Works via Arbitrum WASM transpiler |
| OpenVM | WASM via Powder | Works |
| Zisk | RISC-V | WIP via Tamago compiler; issues remain |
Geth’s approach: conservative — target only ZKVMs with Linux-compatible OS interfaces. Geth’s mission is correctness and being the reference implementation, not speed.
Proving Speed Status
- Average block: 13 seconds to prove (too slow for 12-second slots)
- Median block: 7.8 seconds (not viable for 6-second target)
- Significant optimization budget remains; room for major improvement
Key recommendation: enshrining RISC-V as Ethereum’s canonical ZKVM architecture would be premature — almost no current ZKVMs in the support matrix are RISC-V native. WASM is more practical near-term.
Timeline: optional proofs planned for 2026; mandatory proofs targeted for 2028. Guillaume characterized this as aggressive (“open heart surgery”) but the ecosystem is in accelerationist mode.
Jolt: Client-Side ZK (Andrew Tretyakov / a16z crypto, ETHDenver 2026)
Previous ZKVMs failed for client-side use because they optimized for algebraic operations (multiplications) rather than bitwise operations needed for standard cryptography (SHA-256, ECDSA, RSA).
Jolt’s approach:
- Standardizes on RISC-V ecosystem — inherits security audits, avoids fragmentation
- 300 bytes per RISC-V cycle in the browser
- Generates SHA-256 proofs in 2 seconds on an iPhone without recursion
- Proving Ethereum requires only 50 MHz — achievable on consumer devices
- Enables privacy by default at client level without centralized server wrapping
This is the decentralization end-point for ZK: proofs generated by the user’s device, not a server farm.
Jolt Deep Dive: GPU Parallelization Architecture (Markos Georghiades / a16z, Devconnect Argentina)
The Devconnect Just Prove It talk provided a more detailed architectural breakdown of Jolt’s design choices. (→ [[devconnect-argentina]])
The GPU scaling problem with existing ZKVMs: Existing ZKVMs don’t parallelize well because their data structures create dependencies across GPU threads. Throwing 2,000 GPUs at a Stark prover won’t prove Ethereum in 1 second — the parallelism ceiling is hit first. Current benchmark: P99 ETH block takes ~14 seconds with a Stark prover, producing 165MB proofs.
Jolt’s partition-friendly data: Jolt restructures the zkVM so that data can be cleanly partitioned across GPU cores without inter-thread dependencies — 800× speedup using 16 GPUs (not 2,000).
Target with Lattice Jolt (post-quantum variant): <1 second proofs on 16 GPUs (4× faster than curve-based Jolt).
No circuits, no recursion — two core design choices:
Circuits as bugs: Traditional zkVMs define constraints per instruction using circuits. Circuits are “the largest source of bugs” due to their complex auditing surface. Jolt replaces circuits with batch evaluation: each RISC-V instruction is ~10 lines of Rust code.
Recursion as bottleneck: Recursion in ZK (proving the proof itself) requires loading 8–10GB of data into memory — a hard constraint for any non-server deployment. Jolt uses streaming evaluation instead: make multiple passes through the execution trace, parallelizable within each pass.
128-bit field advantage: Stark provers use 31-bit fields. A 16×16 multiply overflows a 64-bit integer — requiring byte decomposition into smaller chunks before operating. This overhead compounds throughout computation. Jolt uses a 128-bit field where a single field multiplication handles the full result without decomposition.
Mobile milestone: Only RISC-V ZKVM capable of client-side proving on a phone. Benchmark: 30 RISC-V cycles proved in 4.7 seconds using 246.6 MB RAM — the first RISC-V ZKVM with demonstrated mobile client-side proving.
Current state (Devconnect 2026):
- GPU prover not yet shipped; awaiting speed parity with Stark before Ethereum protocol integration
- 70KB proofs, 330 bytes per RISC-V cycle
- Lattice Jolt (PQ variant) is the next milestone
ZisK: Synchronous Cross-Rollup Composability (Jordi Baylina / ZisK, ETHDenver 2026)
ZisK separates data availability from execution via ZK proofs, enabling something previously impossible:
Synchronous composability across rollups: transactions can atomically call across multiple L2s with instant finality, without a fork.
- Real-time proving (within 12-second Ethereum slots) allows updating multiple rollups simultaneously
- Base rollups simplify protocol complexity (rollups don’t need EVM compatibility — just ZK provable state transitions)
- This is the Ethereum Economic Zone (EEZ) made practical — not a future vision, but a live architecture
FRI Formal Verification (Petar Maksimovic / Nethermind, ETHDenver 2026)
FRI (Fast Reed-Solomon IOP) underpins billions of dollars in ZK systems (StarkWare, Succinct, RiscZero). For the first time, it’s been formally verified in Lean — and the verification found an issue in previously-believed-correct soundness proofs.
- Verification in Lean theorem prover; AI-assisted auto-formalization filling remaining gaps
- Result: ZK verifier code can be mechanically checked against official RISC-V specs
- Eliminates an entire class of bugs from ZK infrastructure
- Sets precedent for formally verifying the prover stack, not just contracts
Connections
- Post-Quantum Cryptography — SWIRL provides 100-bit PQ security; ZK-Boo enables PQ seed recovery
- Ethereum Scaling Roadmap — EEZ requires real-time proving; L1 statelessness proofs require efficient ZK
- Smart Contract Security (2026 State) — Formal verification of provers is the next frontier in security
- Privacy as UX Design — FHE and ZK enable new privacy primitives; ZK whistleblowing as killer app
Open Questions
- Can proving cost drop below single-GPU threshold within 5 years, enabling true decentralized validation?
- Will zkVM or direct arithmetization dominate? Or do both coexist for different use cases?
- How does the EEZ handle L2s that can’t meet the <12-second proving requirement?
- Is Lean 4 formal verification of provers scalable as proof systems grow in complexity?