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

ETHPrague 2026: ZK comes to L1 Ethereum

From ZK Rollups to ZK Ethereum (Sergey Shemyakov / L2BEAT)

The 2024–2025 rollup ZK story is now operational; the 2026–2027 story is ZK execution at L1. Shemyakov’s mapping:

Today — Validators re-execute every block on commodity hardware (the current gas-limit bottleneck). ~50% of blocks built by Titan Builder; centralized block construction is the empirical baseline.
EIP-8025 / Hegota (~2027) — Optional proofs: validators may verify a ZK proof instead of re-executing.
Post-Hegota — Optimizations to make L1 more ZK-friendly (deferred decisions).
Long-term endgame — Mandatory proofs; validators only verify proofs; the EF prover cluster (€250K hardware + €100K/yr ops, GPU-packed) is the reference deployment.

Why this is different from L2 ZK

L2s have it easy — single guest program, single proving system, no obligation to client diversity. L1 must:

Maintain client diversity into the ZK stack — three guest programs, three proving systems, all required to agree.
Achieve real-time proving within an ~10s window (currently 91% of blocks already provable in <10s on parallel GPU; the remaining 9% are the bottleneck).
Find permissionless proving economics — today only one project allows permissionless proving in production; the bootstrap version of EIP-8025 assumes altruistic provers (placeholder, not endgame).
Solve the multi-party guest-program-upgrade problem — an on-chain registry of trusted programs and provers is the open coordination proposal.

ZisK Pushing the Limits of Real-Time Proving (Jordi Baylina)

Updates to the ZisK status from the ETHDenver coverage above:

Real-time proving now production-grade enough that EZ synchronous cross-rollup composability (L2 Synchronous Composability) is the headline application — a single proof aggregating cross-chain state transitions in one Ethereum slot.
Decentralized proving is feasible — Baylina’s argument (subject to economic-coordination work).
Vulnerabilities continue to be found weekly; ZK tech is not yet mature to the standard required for unattended mandatory deployment.

zk-Based Consensus Proofs: Making Stateless Ethereum Practical (Steffen Kux)

The consensus-layer extension: ZK proofs of the consensus state transition, not just execution. Combined with stateless clients, this means a light client need only verify a single ZK proof to know the canonical chain. Critical for:

Embedded devices (hardware wallets, IoT) participating in light verification.
Cross-chain bridges using ZK-verified consensus snapshots (rather than committee signatures).
The post-quantum migration path — consensus is the harder half to migrate cryptographically.

Kux’s argument: zk-consensus-proofs need to ship before mandatory execution-layer ZK proofs, because otherwise validator infrastructure has no way to scale verification cost.

POD: Recursive Logical Client-Side Proofs (Rob Knight)

Knight’s primitive: take a ZK proof, restructure it as a recursive logical claim the user can selectively reveal. The use case set:

Identity claims with selective disclosure.
Voting eligibility (without revealing identity).
Credential aggregation across multiple issuers (academic, government, professional) into one proof.

POD complements ZK-passport / X511-style personhood with a richer logical layer — not just “I am unique” but “I am unique AND I have credential X AND I have not used this nullifier.”

Keccacheck: Toward SNARK-Friendly Keccak (Greg Swirski / Reilabs)

Keccak is the most-used hash function on Ethereum, but is one of the worst for ZK proving — Keccak-friendliness is what’s driving the Poseidon-everywhere push in Lean Ethereum. Keccacheck is the bridge: a SNARK-friendly construction of Keccak that lets existing Solidity contracts (which use keccak256 everywhere) be ZK-verified without rewriting. The economic argument: until Lean Ethereum ships, the existing $200B+ of deployed Solidity code needs an efficient ZK path; Keccacheck is that path.

Reimagining money with zero-knowledge proofs (Jason Morton)

The applications layer of L1 ZK: programmable, private money that performs all the cryptographic checks needed for compliance inside the ZK proof. Combined with Encrypted Computing — FHE & Obfuscation for private contract state, this is the long-arc privacy stack — “ZK + FHE/obfuscation = private smart contracts at the limits.”

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?