.png)
Two elliptic curves stand between a Ziren proof and Ethereum. The first sits inside the proof, carrying memory from one shard to the next. The second wraps the finished proof so that Ethereum can check it cheaply.
In October both got public alternatives: a hash chain for the first, measured at 5.4% more proving time on one GPU and 17.6% on four, and an experimental Solidity verifier for the second, which checked a Ziren proof of an Ethereum mainnet block in a single transaction in a local test. Neither is released yet.
Here we look at what each does, what it costs, and what it does not yet let us claim.
A hash-based proof system rests on the security of its hash, and quantum algorithms weaken a good hash's concrete bounds but are not known to break it. An elliptic curve is different: on a large enough quantum computer, Shor's algorithm computes discrete logarithms, and every assumption built on them falls at once.
In September we argued that hash-based is not the same as post-quantum: read the security theorem, not the primitive list. By that test, Ziren's path to Ethereum has two exceptions: the memory check that piece flagged, and the BN254 wrapper on its release path. This is the work to remove them.
Ziren proves a long execution in shards, and memory has to stay consistent across them: the value one shard reads must be the value an earlier shard wrote. Inside a shard, the lookup argument balances every read against its write, under challenges drawn after the shard's trace is committed. Across shards it cannot, because the two sides of a lookup sit in different shards, proved under different challenges.
Ziren 2.0 bridges them with a multiset hash on an elliptic curve over a degree-seven extension field. Each shard adds up its cross-shard accesses as curve points, and the sums cancel only if the accesses balance. That rests on a discrete-log-type assumption with no known numerical bound, which a quantum adversary breaks.
The replacement, tracked since August 2025 as issue #276 and now in issue #570, is a global challenge built on a hash chain:
The hash chain constrains the order of the work: no shard can be proved until every shard has committed its global round, so the prover executes the block once before it proves it. On RTX 5090s, for a 420-million-cycle Reth block, run back to back against the elliptic-curve digest (time to the compressed proof, warm, before the recursion-key map was regenerated):
The overhead grows with GPUs because the block's single execution, about three to four seconds of the global commit pass (8.2, 5.0 and 4.9 seconds on one, two and four GPUs), does not shrink as cards are added. The proving pass itself is as fast as before or faster: the block needs about nine fewer shards and no global chip. The paper's first measurement of this approach was 29 to 42%; the current implementation measures the figures above.
The hash chain is implemented on the feat/pq-global-challenge branch, with tests that forge cross-shard lookups against it, and the septic-curve code is gone from the Lean, Picus and C++ sources. The map of admissible recursion keys still has to be regenerated: about 393,000 keys, 15.7 MB, in a Merkle tree of height 19.
Ziren, like most zkVMs, ends its release pipeline for Ethereum the same way. A STARK proof is too large to verify cheaply on-chain, so it is wrapped in a Groth16 or PLONK proof over the BN254 curve: 260 bytes for Groth16, checked with a handful of precompile calls. That wrapper rests on pairings. Its setup holds a trapdoor that anyone able to compute discrete logarithms can recover from the public parameters, and with it prove false statements. For a validity bridge, whoever holds that trapdoor can forge the proof that releases the escrow.
PR #568 adds a different last step. The compact shrinker proves the verification of Ziren's compressed proof once more, but commits the result, and runs its transcript, with Keccak-256, a hash the EVM computes natively, in place of Poseidon2. A generated Solidity verifier then checks that proof directly in the EVM: Merkle paths, WHIR openings, sumchecks and field arithmetic over KoalaBear, and it recomputes the Poseidon2 root digest itself. No pairings, no trusted setup.
We took a proof Ziren produced on Ethproofs for Ethereum block 26,240,087, re-shrunk it with the Keccak suite, and submitted it to the verifier on a local Ethereum node that enforces the 16,777,216-gas cap on a single transaction. It verified in one transaction:
13.7 million gas is far more than a Groth16 check, so this suits a rollup that verifies on demand rather than one that verifies every batch. The verifier lives in ProjectZKM/OPSuccinct, next to a proposed bridge design that can wait to finalize until a withdrawal needs it, so that one proof covers every batch since the last.
#568 is a draft. Its release gates include full proving on the current version, a review of its security parameters, and gas and deployment measurements under the transaction cap for every approved build.
Nothing here makes anything post-quantum secure today, and the paper says so in its own terms: the security levels it computes are classical, and it claims post-quantum security for no configuration. Fiat-Shamir proofs like Ziren's stay sound against quantum adversaries in the quantum random-oracle model, but with weaker concrete bounds: a quantum collision search on the 248-bit digest of the measured instantiation costs about 2^83 evaluations rather than 2^124. A post-quantum claim needs that level computed for the configuration that ships.
A hash-based verifier also protects the proof check, not the keys around it. In the bridge design's own words, it "does not make blob KZG, signatures, consensus or governance post-quantum safe". Ethereum's blob commitments and every account's ECDSA key move with Ethereum's own upgrades.
Securing Ziren is ongoing work, and the work described here is public: issue #570, PR #568, the verifier and the paper.
Two elliptic curves stand between a Ziren proof and Ethereum. The first sits inside the proof, carrying memory from one shard to the next. The second wraps the finished proof so that Ethereum can check it cheaply.
In October both got public alternatives: a hash chain for the first, measured at 5.4% more proving time on one GPU and 17.6% on four, and an experimental Solidity verifier for the second, which checked a Ziren proof of an Ethereum mainnet block in a single transaction in a local test. Neither is released yet.
Here we look at what each does, what it costs, and what it does not yet let us claim.
A hash-based proof system rests on the security of its hash, and quantum algorithms weaken a good hash's concrete bounds but are not known to break it. An elliptic curve is different: on a large enough quantum computer, Shor's algorithm computes discrete logarithms, and every assumption built on them falls at once.
In September we argued that hash-based is not the same as post-quantum: read the security theorem, not the primitive list. By that test, Ziren's path to Ethereum has two exceptions: the memory check that piece flagged, and the BN254 wrapper on its release path. This is the work to remove them.
Ziren proves a long execution in shards, and memory has to stay consistent across them: the value one shard reads must be the value an earlier shard wrote. Inside a shard, the lookup argument balances every read against its write, under challenges drawn after the shard's trace is committed. Across shards it cannot, because the two sides of a lookup sit in different shards, proved under different challenges.
Ziren 2.0 bridges them with a multiset hash on an elliptic curve over a degree-seven extension field. Each shard adds up its cross-shard accesses as curve points, and the sums cancel only if the accesses balance. That rests on a discrete-log-type assumption with no known numerical bound, which a quantum adversary breaks.
The replacement, tracked since August 2025 as issue #276 and now in issue #570, is a global challenge built on a hash chain:
The hash chain constrains the order of the work: no shard can be proved until every shard has committed its global round, so the prover executes the block once before it proves it. On RTX 5090s, for a 420-million-cycle Reth block, run back to back against the elliptic-curve digest (time to the compressed proof, warm, before the recursion-key map was regenerated):
The overhead grows with GPUs because the block's single execution, about three to four seconds of the global commit pass (8.2, 5.0 and 4.9 seconds on one, two and four GPUs), does not shrink as cards are added. The proving pass itself is as fast as before or faster: the block needs about nine fewer shards and no global chip. The paper's first measurement of this approach was 29 to 42%; the current implementation measures the figures above.
The hash chain is implemented on the feat/pq-global-challenge branch, with tests that forge cross-shard lookups against it, and the septic-curve code is gone from the Lean, Picus and C++ sources. The map of admissible recursion keys still has to be regenerated: about 393,000 keys, 15.7 MB, in a Merkle tree of height 19.
Ziren, like most zkVMs, ends its release pipeline for Ethereum the same way. A STARK proof is too large to verify cheaply on-chain, so it is wrapped in a Groth16 or PLONK proof over the BN254 curve: 260 bytes for Groth16, checked with a handful of precompile calls. That wrapper rests on pairings. Its setup holds a trapdoor that anyone able to compute discrete logarithms can recover from the public parameters, and with it prove false statements. For a validity bridge, whoever holds that trapdoor can forge the proof that releases the escrow.
PR #568 adds a different last step. The compact shrinker proves the verification of Ziren's compressed proof once more, but commits the result, and runs its transcript, with Keccak-256, a hash the EVM computes natively, in place of Poseidon2. A generated Solidity verifier then checks that proof directly in the EVM: Merkle paths, WHIR openings, sumchecks and field arithmetic over KoalaBear, and it recomputes the Poseidon2 root digest itself. No pairings, no trusted setup.
We took a proof Ziren produced on Ethproofs for Ethereum block 26,240,087, re-shrunk it with the Keccak suite, and submitted it to the verifier on a local Ethereum node that enforces the 16,777,216-gas cap on a single transaction. It verified in one transaction:
13.7 million gas is far more than a Groth16 check, so this suits a rollup that verifies on demand rather than one that verifies every batch. The verifier lives in ProjectZKM/OPSuccinct, next to a proposed bridge design that can wait to finalize until a withdrawal needs it, so that one proof covers every batch since the last.
#568 is a draft. Its release gates include full proving on the current version, a review of its security parameters, and gas and deployment measurements under the transaction cap for every approved build.
Nothing here makes anything post-quantum secure today, and the paper says so in its own terms: the security levels it computes are classical, and it claims post-quantum security for no configuration. Fiat-Shamir proofs like Ziren's stay sound against quantum adversaries in the quantum random-oracle model, but with weaker concrete bounds: a quantum collision search on the 248-bit digest of the measured instantiation costs about 2^83 evaluations rather than 2^124. A post-quantum claim needs that level computed for the configuration that ships.
A hash-based verifier also protects the proof check, not the keys around it. In the bridge design's own words, it "does not make blob KZG, signatures, consensus or governance post-quantum safe". Ethereum's blob commitments and every account's ECDSA key move with Ethereum's own upgrades.
Securing Ziren is ongoing work, and the work described here is public: issue #570, PR #568, the verifier and the paper.
