Zero knowledge proofs for practitioners

What a proof system promises

A proof system works over a relation R(x, w): a public statement x and a private witness w. "This batch of 5,000 transactions takes the rollup from state root A to state root B" is a statement; the transactions and intermediate states are the witness. Four properties define the tool:

Two terms follow. A SNARK is a succinct non-interactive argument of knowledge; "argument" means soundness holds against computationally bounded provers. Non-interactive proofs come from the Fiat-Shamir transform, which replaces the verifier’s random challenges with hashes of the transcript so far. Most blockchain "ZK" is really about succinctness: rollups rarely hide anything, they just prove. Privacy applications need the zero knowledge property as well. The idea dates to Goldwasser, Micali and Rackoff in 1985; practical systems arrived three decades later.

Arithmetization: turning programs into polynomials

Proof systems do not verify code. They verify that a set of polynomial equations over a finite field is satisfied. Arithmetization is the translation, and its cost model is the whole game: every constraint or trace row costs prover time.

R1CS

Rank one constraint systems express a computation as constraints of the form (A·w) × (B·w) = C·w, one multiplication each, with additions free inside the linear combinations. Proving knowledge of x with x³ + x + 5 = 35 flattens to three constraints:

PLONKish

PLONK style systems use a table of wires a, b, c and one generic gate equation per row, with selector columns switching terms on and off, plus copy constraints enforced by a permutation argument:

Custom gates and lookup arguments extend this: a range check or a byte operation becomes one table lookup instead of dozens of constraints.

AIR

STARKs use an algebraic intermediate representation: the computation is an execution trace, a table with one row per step, and transition constraints relate each row to the next one or few. A Fibonacci trace needs a single constraint, t_i+2 = t_i+1 + t_i, applied to every row. This fits virtual machines naturally, since a CPU step is exactly a transition.

Across all three, native field arithmetic is cheap and everything else is expensive. Bitwise hashes such as keccak and SHA-256, or secp256k1 arithmetic inside a BN254 circuit, are expensive: a SHA-256 compression costs roughly 25,000 to 30,000 R1CS constraints, a keccak permutation around 150,000, and a secp256k1 ECDSA verification over a million, which is why circuits favor algebraic hashes such as Poseidon and why proving the EVM as is was long considered impractical.

Polynomial commitments: where the trust lives

Once a computation is a set of polynomials, the prover commits to them and the verifier checks them at random points. The commitment scheme determines proof size, verifier cost and whether a trusted setup is needed.

KZG

KZG (Kate, Zaverucha and Goldberg, 2010) uses a structured reference string of powers [τⁱ]G for a secret τ that nobody may know:

Whoever knows τ can open a commitment to any value, so the setup is run as a multiparty ceremony where one honest participant who destroys their share is enough. Ethereum’s KZG ceremony for EIP-4844 ran for 208 days in 2023 and collected 141,416 contributions. Every blob is committed to with KZG, and the point evaluation precompile at 0x0a verifies an opening for 50,000 gas (see data availability).

FRI

FRI (Fast Reed-Solomon Interactive Oracle Proofs of Proximity) needs no setup. The prover evaluates the polynomial over a domain several times larger than its degree, commits with a Merkle tree, then repeatedly folds the polynomial in half using random challenges. The verifier spot checks a number of queries against Merkle paths. Security rests only on collision resistant hashing, which is why FRI based systems are called transparent and plausibly post quantum. The price is size: proofs run to tens or hundreds of kilobytes.

SNARKs: Groth16 and PLONK

Groth16 is still the smallest and cheapest proof to verify. A proof is three group elements, two in G₁ and one in G₂, which is 128 bytes compressed on BN254, and verification is a single pairing product check:

The catch is a circuit specific trusted setup: a universal "powers of tau" phase followed by a second phase for each circuit, repeated whenever the circuit changes. Onchain, the BN254 pairing precompile costs 34,000 gas per pair plus 45,000 (EIP-1108), and the check above is passed as four pairs:

PLONK (Gabizon, Williamson and Ciobotaru, 2019) trades a little size for flexibility. Its KZG setup is universal and updatable: one ceremony serves every circuit up to a size bound, and anyone can add fresh randomness later. Proofs are larger but still under a kilobyte, verification uses two pairings (113,000 gas for the pairing check) plus more scalar multiplications, and the PLONKish format supports custom gates and lookups. Most modern SNARK stacks descend from it.

STARKs: transparent and hash based

STARKs (Ben-Sasson, Bentov, Horesh and Riabzev, 2018) combine AIR with FRI. No setup, only hashes, and provers that run fast over small fields such as Goldilocks (2⁶⁴ − 2³² + 1), BabyBear (2³¹ − 2²⁷ + 1) and Mersenne31 (2³¹ − 1), where arithmetic fits in machine words. The costs are proof size and a soundness analysis that is harder than it looks.

Many deployed parameters relied on conjectures about Reed-Solomon proximity to reach their advertised security. In a December 2025 post the Ethereum Foundation noted that some of those conjectures had been disproven, so a system advertised at 100 bits might deliver closer to 80, and set milestones for zkEVMs of 100 bits of provable security by the end of May 2026 and 128 bits, with proofs of at most 300 KiB, by the end of 2026. A common production pattern is to prove with a STARK and then wrap the final proof in a Groth16 or PLONK proof for cheap L1 verification. The wrapper inherits a trusted setup and pre-quantum assumptions, which is why the Foundation’s real time proving target excludes wrappers that use trusted setups.

Choosing a proof system

zkVMs, recursion and proving costs

Hand writing circuits does not scale to large programs. A zkVM arithmetizes an instruction set, often RISC-V, once; developers then write ordinary Rust, compile it, and prove its execution trace. Long executions are split into segments proven in parallel, and recursion joins them: a proof that verifies other proofs, repeated until one small proof remains. The same technique aggregates many independent proofs into one, so a single L1 verification covers a whole batch. Folding schemes, which defer verification by combining instances algebraically, are an active research line for making recursion cheaper.

Proving still costs orders of magnitude more compute than running the program, but the curve has moved fast. In July 2025 the Ethereum Foundation defined real time proving for the L1 as proving at least 99% of mainnet blocks in 10 seconds or less, on hardware costing at most $100,000 and drawing at most 10 kW, with 128 bit security and proofs of at most 300 KiB. By December 2025 it reported that zkVMs could prove 99% of blocks in under 10 seconds on target hardware, after a year in which typical proving latency fell from around 16 minutes to around 16 seconds and costs fell about 45 times. The plan it described starts with optional clients that verify proofs instead of re-executing blocks, with the security bar as the remaining gate.

Where ZK is used

What ZK does not do

A proof shows that a witness satisfies the constraints. If the constraints do not say what you meant, the proof faithfully certifies the wrong thing. The most common bug class is the under-constrained circuit, where the witness generator computes a value that no constraint pins down:

// Under-constrained: the witness generator computes out, but nothing
// in the constraint system forces it. A malicious prover can set out
// to anything and still produce a valid proof.
template IsZeroBroken() {
    signal input in;
    signal output out;
    out <-- (in == 0) ? 1 : 0;      // assignment only, no constraint
}

// The standard gadget: two constraints pin out to the right value.
template IsZero() {
    signal input in;
    signal output out;
    signal inv;
    inv <-- (in != 0) ? 1 / in : 0;  // hint, checked by the constraints below
    out <== 1 - in * inv;            // if in == 0 then out == 1
    in * out === 0;                  // if in != 0 this forces out == 0, so inv == 1/in
}

The failures reach below application code. In 2018 a Zcash Company cryptographer found that the setup algorithm in the BCTV14 paper, used by Zcash’s original Sprout circuits, produced extra elements that let a cheating prover forge proofs and so counterfeit coins. It was fixed quietly by the Sapling upgrade in October 2018 and disclosed on February 5, 2019, with no evidence of exploitation. In April 2022 Trail of Bits disclosed "Frozen Heart", a class of bugs where implementations of PLONK, Bulletproofs and other systems omitted public values from the Fiat-Shamir hash, allowing forged proofs.

Open questions

• Provable versus conjectured security. Reaching 128 bits of provable security without proofs growing past what a peer to peer network can propagate is the current frontier for STARK based zkVMs.
• Post quantum end to end. A hash based proof wrapped in a pairing based one is only as quantum safe as the wrapper. Removing wrappers raises onchain verification cost.
• Formally verified circuits. Constraint systems for a whole VM are huge; proving they match an instruction set specification is ongoing work across teams.
• Who proves. If proving is expensive, a few provers could become a liveness or censorship choke point. The Foundation’s 10 kW, $100,000 target exists to keep home proving possible.

Common questions

Where to go next