Other proof systems

The leaderboard ranks Groth16 verifiers. Alongside it we built and measured CashVM verifiers for two other proof systems, each for what it could bring to Bitcoin Cash. Both are research, not leaderboard entries. For the wider landscape, see beyond Groth16.

Sizes are the total on-chain bytes to verify one proof, under three sets of limits: today’s rules (at most 10 KB per input and 100 KB per standard transaction), a single input of up to 100 KB if the 10 KB consensus and relay limits were raised (which limits to raise), and the proposed bch-spec VM, which pairs 100 KB inputs with a larger compute budget.

STARK: post-quantum, no trusted setup

Plonky3 is an open-source STARK prover used by several zkVMs. Set up with SHA-256, which CashVM hashes natively, its proofs verify on today’s VM with no new opcode. They need no trusted setup and rest only on the hash, so they stay secure against quantum computers. Most of the verifier is generic, so one design serves any statement of the shape it supports. Zero-knowledge mode makes the proof larger and is meant to keep private inputs private (see the limits below).

Research, not a leaderboard entry. Measured on two small test statements (Fibonacci and MiMC, 65,536 rows each), with every proof accepted and every tampered one rejected. Limits, in plain words: the 128-bit level rests on a published theorem plus a proof step of ours that is reviewed internally, not yet externally; zero-knowledge comes from Plonky3’s construction and was not tested for hiding (our test proofs use a fixed seed); and this first verifier handled one trace table and no lookups; the one below lifts both. Full report.

A post-quantum private spend

We then verified the statement a privacy pool is built on: a note is in a Merkle tree of about a billion entries, and here is its nullifier, in zero-knowledge and tied to the spending transaction’s outputs so it cannot be reused for another payment. Proved with Plonky3’s multi-table prover at 128 bits, it verifies in one standard transaction today (12 inputs, 99 KB), checked on a Bitcoin Cash Node, or in a single 100 KB input. With larger inputs, the same design also verifies proofs with several tables, fixed columns and lookups. Research, not a leaderboard entry: the 128-bit level rests on the same argument, the binding to the outputs relies on a standard property of the proof system that we assume rather than prove, and the hiding is Plonky3’s by construction. On top of it we built a pool covenant that records spent nullifiers in a hashed tree and refuses a second spend of the same note: on a Bitcoin Cash Node a withdrawal took two transactions (about 133 KB) and a double spend was rejected (pool report). Deposits join the tree in batches of 16 that anyone can flush; on the node, 272 deposits in 17 flushes matched an offline copy of the tree. Full report.

PLONK / KZG: any circuit, one public ceremony

gnark is a widely used prover whose PLONK challenges already use SHA-256. Our verifier checks its proofs against Aztec Ignition, a public setup ceremony with 176 participants. For Bitcoin Cash that means a developer can take a new circuit from standard tooling and verify its proofs on chain without running a ceremony of their own. Every circuit below fits in one standard transaction today, at about three times the bytes of a sound Groth16 verifier on the leaderboard (about 28 KB). It is pairing-based, so not post-quantum.

Research, not a leaderboard entry. Ranges cover five valid proofs per circuit. Limits: one commitment per circuit is supported (what gnark’s range checks use), and the ceremony was checked as far as the verifier relies on it, not in full. Full report.

What a proof costs

At the default relay fee of one satoshi per byte, verifying a proof costs about its size in satoshis: roughly 28,000 for a sound Groth16 verifier on the leaderboard, 83,000 to 90,000 for PLONK and 99,000 for the post-quantum private spend. A Bitcoin Cash Node checks them in about 3.5, 11 and 17 milliseconds (measured).