Ziren 2.0 is here, replacing the proving core of our zkVM with a new proof system, jagged-over-WHIR, rebuilt across 1,690 commits and documented in the design paper on the IACR Cryptology ePrint Archive.
The short version: on Ethproofs, the Ethereum Foundation’s open proving dashboard, Ziren proves the average Ethereum mainnet block in 8.6 seconds on a four-GPU cluster, at an average cost of $0.0061 per proof; the compressed proof is 284 KiB whatever the length of the execution; native verification takes about 25 milliseconds; and the determinism of every extracted chip is machine-checked in Lean.
Here we set out what changed, what it measures, and what it rests on.
Previous versions of Ziren proved MIPS32 execution the way most production zkVMs of its generation did: a central CPU table coordinating satellite chips, per-shard STARKs, and FRI as the proximity test. Ziren 2.0 keeps the instruction set, the toolchain and the recursion discipline, and replaces the argument underneath.
In 2.0, one zerocheck covers every chip's constraints and one LogUp-GKR instance covers every bus balance, rather than one argument per table. A shard of an Ethereum block commits up to about 36,000 columns whose heights run from 32 rows to millions; the jagged sumcheck of Hemo, Jue, Rabinovich, Roh and Rothblum stacks those columns at their real heights, with no padding to a common size, and reduces the claims on all of them to a single evaluation. One batched WHIR opening, the proximity test of Arnon, Chiesa, Fenzi and Yogev with its super-fast verifier, then authenticates that evaluation against every commitment. The field is the same 31-bit KoalaBear; the commitments are hash-based throughout.
The machine on top changed with it. There is no CPU table in Ziren 2.0. Each executed instruction is one row in an opcode-specific chip, carrying an instruction frame: the shared columns and bus interactions that bind it to the committed program, fix its register accesses, and constrain the machine-state transition. The state carries the current and next program counters as a pair, which is what preserves the MIPS branch-delay slot instead of normalizing it away and proving a different machine. Registers and memory share one offline memory-checking argument carried across shards by an elliptic-curve digest, and recursion composes shard proofs under a verifying-key allowlist, so a proof only verifies against the programs the keys commit to.
The benchmarks below are of the frozen 2.0 release, on named hardware, NVIDIA RTX 5090s on an AMD EPYC 9355 host: throughput measured on 1 November 2026, proof size and verification on 28 October. The full tables are in the performance documentation. Four results carry the release.
Proving in public. Ethproofs tracks Ziren proving live mainnet blocks alongside every other evaluated team, on a listed four-GPU RTX 5090 cluster. As of 3 November 2026 the listing shows an average of 8.6 seconds per block, at an average cost of $0.0061 per proof.
Proving whole blocks in seconds. Fifteen consecutive Ethereum mainnet blocks, 26,303,831 to 26,303,845, proved end to end with two different execution clients compiled to MIPS32: Reth, written in Rust, and the block keeper of Geth, written in Go. With the Reth guest on eight GPUs, every block took between 3.7 and 14.5 seconds from prove request to compressed proof. The Geth guest, whose blocks run billions of cycles, sustained 65.3 MHz of proving throughput across the set, with the first block's cold start excluded from the total, and peaked at 75.1 MHz. Proving both clients over the same blocks also yields a number only a system that proves Geth can produce: Geth executes about ten times the guest cycles of Reth for the same work, 31.35 billion against 3.21 billion across the set, a reference point for the Ethereum Foundation and for any team weighing what proving Geth actually costs.
Scaling that follows block size. A shard takes about 0.36 seconds on one GPU with the Reth guest and about 0.30 with Geth, and the serial recursion tail after the last shard is a fixed cost per block. So the heavier the block, the better the hardware is used: the 358-million-cycle block in the set proves in 51.3 seconds on one GPU, 28.2 on two and 16.7 on four, while the smallest block in the set gains nothing after two GPUs because the tail dominates. At the sizes mainnet actually produces, adding GPUs keeps paying.
A proof that stays small. The compressed proof at the root of the recursion tree is 290,530 bytes, about 284 KiB, and its size is independent of how long the proven execution ran. Native verification takes a median of 25.5 milliseconds. The paper's proof-size section sets out the schedule that buys this, query counts, code rate, folding factors and grinding, and what each parameter trades against at a fixed soundness level.
These are the numbers that supersede the throughput figures the paper stated at publication, and they are reproducible from the public record: the per-run timings and build metadata of the runs are archived, every proof in the tables was checked by a native verifier.
A release that changes the proof system owes a precise account of what the new one guarantees, and this is where Ziren 2.0 differs most from a changelog. The paper quantifies the argument: every proving stage has more than 100 bits of interactive soundness, and the composite security of a block, a measure this paper introduces, is 93.5 bits for a tree of 149 core-schedule proofs and one compress root. Composite security counts the error of every node in the block’s recursion tree together; other teams’ soundness reports state per-proof levels, and a per-proof level is not the security of a block. The accounting after Fiat-Shamir compilation, and the five hypotheses the end-to-end claim rests on, are stated in the paper rather than left implicit. Security is not a property anyone finishes; stating what remains open is part of the work, and the open items are listed in one place.
Two kinds of evidence sit under those numbers. First, determinism is machine-checked: the constraint system of each of the 57 chips the extraction models is taken from the same Rust description the prover evaluates, lowered into Lean, and proved to admit at most one behavior per input, 104 theorems, all closed, with no axioms beyond Lean's standard three. A chip with two valid outputs for one input would let a cheating prover choose between them, and honest traces would never expose it; the theorems close that door chip by chip. Second, conformance ties the proven machine to the real ISA: 224 generated programs and 48 of 49 of Optimism's Cannon test programs were proved and verified end to end, the one exception being a program that halts with a non-zero exit code, which the emulator accepts and the arithmetization does not admit.
The division of labor is worth stating, because it is what makes the engineering safe to iterate on: soundness rests only on the verifier and what it reads, the constraint descriptions, the verifying keys and the allowlist root. The executor, the JIT compiler, trace generation and the GPU kernels bear only on completeness. A bug in them yields a proof that fails to verify, not one that verifies falsely.
The release is the fifth step in a path that has been public at every stage: the production 1.0 release in May 2025; the independent evaluation of v1.1.4 by ProofLab in September 2025; v1.2.5 in April 2026, when Ziren became the first zkVM to prove Geth without modifying the Go compiler; the design paper's publication on the ePrint archive in October 2026, with the security reviews around it; and now the 2.0 proving core that the paper documents.
Programs that build for previous versions build for 2.0 unchanged, in Rust, C and Go; what changes underneath are the proofs and the verifying keys, which are regenerated for the new machine.
Ziren's benchmark workload is the Ethereum block because it is the hardest public test in regular use, but the system is built for more than the benchmark.
The compressed proof is what a native verifier checks, and two verification routes carry it onward: a pairing-based SNARK wrapper produces an onchain verifier for EVM environments, and a garbled-verification route develops a hash-based verifier intended for BitVM-style protocols, where a Boolean circuit checks the proof on Bitcoin only when a dispute arises.
In production today, GOAT Network's Bitcoin-secured zkEVM runs on Ziren proofs of its state transitions.
Ziren 2.0 is live on GitHub under open-source licenses, with the paper, the Lean extraction and the Veridise audit report in the repository, and the documentation at docs.zkm.io. Guests are ordinary programs: write Rust, C or Go, compile, prove, and hand anyone a 284 KiB object that settles what your program did in about 25 milliseconds.
ZKM builds zero-knowledge proving infrastructure for verifiable computing. Ziren, an open-source general-purpose zkVM, proves MIPS32 execution for Geth and programs in Rust, C and Go.
Ziren 2.0 is here, replacing the proving core of our zkVM with a new proof system, jagged-over-WHIR, rebuilt across 1,690 commits and documented in the design paper on the IACR Cryptology ePrint Archive.
The short version: on Ethproofs, the Ethereum Foundation’s open proving dashboard, Ziren proves the average Ethereum mainnet block in 8.6 seconds on a four-GPU cluster, at an average cost of $0.0061 per proof; the compressed proof is 284 KiB whatever the length of the execution; native verification takes about 25 milliseconds; and the determinism of every extracted chip is machine-checked in Lean.
Here we set out what changed, what it measures, and what it rests on.
Previous versions of Ziren proved MIPS32 execution the way most production zkVMs of its generation did: a central CPU table coordinating satellite chips, per-shard STARKs, and FRI as the proximity test. Ziren 2.0 keeps the instruction set, the toolchain and the recursion discipline, and replaces the argument underneath.
In 2.0, one zerocheck covers every chip's constraints and one LogUp-GKR instance covers every bus balance, rather than one argument per table. A shard of an Ethereum block commits up to about 36,000 columns whose heights run from 32 rows to millions; the jagged sumcheck of Hemo, Jue, Rabinovich, Roh and Rothblum stacks those columns at their real heights, with no padding to a common size, and reduces the claims on all of them to a single evaluation. One batched WHIR opening, the proximity test of Arnon, Chiesa, Fenzi and Yogev with its super-fast verifier, then authenticates that evaluation against every commitment. The field is the same 31-bit KoalaBear; the commitments are hash-based throughout.
The machine on top changed with it. There is no CPU table in Ziren 2.0. Each executed instruction is one row in an opcode-specific chip, carrying an instruction frame: the shared columns and bus interactions that bind it to the committed program, fix its register accesses, and constrain the machine-state transition. The state carries the current and next program counters as a pair, which is what preserves the MIPS branch-delay slot instead of normalizing it away and proving a different machine. Registers and memory share one offline memory-checking argument carried across shards by an elliptic-curve digest, and recursion composes shard proofs under a verifying-key allowlist, so a proof only verifies against the programs the keys commit to.
The benchmarks below are of the frozen 2.0 release, on named hardware, NVIDIA RTX 5090s on an AMD EPYC 9355 host: throughput measured on 1 November 2026, proof size and verification on 28 October. The full tables are in the performance documentation. Four results carry the release.
Proving in public. Ethproofs tracks Ziren proving live mainnet blocks alongside every other evaluated team, on a listed four-GPU RTX 5090 cluster. As of 3 November 2026 the listing shows an average of 8.6 seconds per block, at an average cost of $0.0061 per proof.
Proving whole blocks in seconds. Fifteen consecutive Ethereum mainnet blocks, 26,303,831 to 26,303,845, proved end to end with two different execution clients compiled to MIPS32: Reth, written in Rust, and the block keeper of Geth, written in Go. With the Reth guest on eight GPUs, every block took between 3.7 and 14.5 seconds from prove request to compressed proof. The Geth guest, whose blocks run billions of cycles, sustained 65.3 MHz of proving throughput across the set, with the first block's cold start excluded from the total, and peaked at 75.1 MHz. Proving both clients over the same blocks also yields a number only a system that proves Geth can produce: Geth executes about ten times the guest cycles of Reth for the same work, 31.35 billion against 3.21 billion across the set, a reference point for the Ethereum Foundation and for any team weighing what proving Geth actually costs.
Scaling that follows block size. A shard takes about 0.36 seconds on one GPU with the Reth guest and about 0.30 with Geth, and the serial recursion tail after the last shard is a fixed cost per block. So the heavier the block, the better the hardware is used: the 358-million-cycle block in the set proves in 51.3 seconds on one GPU, 28.2 on two and 16.7 on four, while the smallest block in the set gains nothing after two GPUs because the tail dominates. At the sizes mainnet actually produces, adding GPUs keeps paying.
A proof that stays small. The compressed proof at the root of the recursion tree is 290,530 bytes, about 284 KiB, and its size is independent of how long the proven execution ran. Native verification takes a median of 25.5 milliseconds. The paper's proof-size section sets out the schedule that buys this, query counts, code rate, folding factors and grinding, and what each parameter trades against at a fixed soundness level.
These are the numbers that supersede the throughput figures the paper stated at publication, and they are reproducible from the public record: the per-run timings and build metadata of the runs are archived, every proof in the tables was checked by a native verifier.
A release that changes the proof system owes a precise account of what the new one guarantees, and this is where Ziren 2.0 differs most from a changelog. The paper quantifies the argument: every proving stage has more than 100 bits of interactive soundness, and the composite security of a block, a measure this paper introduces, is 93.5 bits for a tree of 149 core-schedule proofs and one compress root. Composite security counts the error of every node in the block’s recursion tree together; other teams’ soundness reports state per-proof levels, and a per-proof level is not the security of a block. The accounting after Fiat-Shamir compilation, and the five hypotheses the end-to-end claim rests on, are stated in the paper rather than left implicit. Security is not a property anyone finishes; stating what remains open is part of the work, and the open items are listed in one place.
Two kinds of evidence sit under those numbers. First, determinism is machine-checked: the constraint system of each of the 57 chips the extraction models is taken from the same Rust description the prover evaluates, lowered into Lean, and proved to admit at most one behavior per input, 104 theorems, all closed, with no axioms beyond Lean's standard three. A chip with two valid outputs for one input would let a cheating prover choose between them, and honest traces would never expose it; the theorems close that door chip by chip. Second, conformance ties the proven machine to the real ISA: 224 generated programs and 48 of 49 of Optimism's Cannon test programs were proved and verified end to end, the one exception being a program that halts with a non-zero exit code, which the emulator accepts and the arithmetization does not admit.
The division of labor is worth stating, because it is what makes the engineering safe to iterate on: soundness rests only on the verifier and what it reads, the constraint descriptions, the verifying keys and the allowlist root. The executor, the JIT compiler, trace generation and the GPU kernels bear only on completeness. A bug in them yields a proof that fails to verify, not one that verifies falsely.
The release is the fifth step in a path that has been public at every stage: the production 1.0 release in May 2025; the independent evaluation of v1.1.4 by ProofLab in September 2025; v1.2.5 in April 2026, when Ziren became the first zkVM to prove Geth without modifying the Go compiler; the design paper's publication on the ePrint archive in October 2026, with the security reviews around it; and now the 2.0 proving core that the paper documents.
Programs that build for previous versions build for 2.0 unchanged, in Rust, C and Go; what changes underneath are the proofs and the verifying keys, which are regenerated for the new machine.
Ziren's benchmark workload is the Ethereum block because it is the hardest public test in regular use, but the system is built for more than the benchmark.
The compressed proof is what a native verifier checks, and two verification routes carry it onward: a pairing-based SNARK wrapper produces an onchain verifier for EVM environments, and a garbled-verification route develops a hash-based verifier intended for BitVM-style protocols, where a Boolean circuit checks the proof on Bitcoin only when a dispute arises.
In production today, GOAT Network's Bitcoin-secured zkEVM runs on Ziren proofs of its state transitions.
Ziren 2.0 is live on GitHub under open-source licenses, with the paper, the Lean extraction and the Veridise audit report in the repository, and the documentation at docs.zkm.io. Guests are ordinary programs: write Rust, C or Go, compile, prove, and hand anyone a 284 KiB object that settles what your program did in about 25 milliseconds.
ZKM builds zero-knowledge proving infrastructure for verifiable computing. Ziren, an open-source general-purpose zkVM, proves MIPS32 execution for Geth and programs in Rust, C and Go.
