Proof Systems Landscape — SNARKs, STARKs & Plonk

A map you need before choosing tools

Every ZK application requires you to pick a proving system. That choice determines your proof size, proving speed, verification cost, trusted setup requirements, and which programming languages you can use.

The proof systems in production today are not interchangeable. They make fundamentally different tradeoffs. This lesson gives you a precise map of the landscape so you can reason about which system fits which use case.

The two architectural families

All proof systems fall into one of two broad families based on their arithmetization and commitment scheme.

SNARKs (Succinct Non-Interactive Arguments of Knowledge) are pairing-based systems built on elliptic curve cryptography. They produce constant-size proofs regardless of circuit complexity. Verification requires a fixed number of pairing operations and is extremely fast. The cost of this succinctness is a trusted setup and non-post-quantum security.

STARKs (Scalable Transparent Arguments of Knowledge) are hash-based systems built on FRI and Reed-Solomon codes. They require no trusted setup and are believed to be post-quantum secure. The cost is larger proof sizes, typically tens to hundreds of kilobytes, and slower verification compared to SNARKs.

This distinction is the first decision you make when choosing a proving system.

Groth16

Groth16 is the most widely deployed SNARK in production. It was introduced by Jens Groth in 2016 and remains the standard for applications where proof size and verification cost must be minimized.

Arithmetization: R1CS. Every computation is expressed as rank-1 constraints of the form A·w * B·w = C·w. This maps naturally from Circom circuits.

Commitment scheme: Pairing-based, closely related to KZG. The proof consists of three group elements. On the BN254 curve used by Ethereum, a Groth16 proof is 128 bytes.

Trusted setup: Circuit-specific. A separate ceremony must be performed for each new circuit. The structured reference string encodes the circuit topology and cannot be reused across different circuits.

Verification: Three pairing operations. On Ethereum, this costs roughly 200,000 to 300,000 gas.

Where it is used: Zcash shielded transactions, Tornado Cash, Polygon zkEVM's outer proof layer, zkBridge recursive compression, Semaphore identity protocol.

Primary limitation: The circuit-specific trusted setup is operationally costly. Every circuit change requires a new ceremony. This makes iteration slow for teams actively developing their circuit.

<hr/>

PLONK and its variants

PLONK was introduced in 2019 and addressed Groth16's main limitation: it uses a universal trusted setup. One ceremony produces an SRS that works for any circuit up to a supported size bound. You do not repeat the ceremony for each circuit.

Arithmetization: Custom gate-based. PLONK introduces a more flexible constraint system called Plonkish arithmetization. Computations are expressed as a table of values where each row satisfies a polynomial constraint. This allows custom gates that encode complex operations more efficiently than R1CS.

Commitment scheme: KZG by default. The prover commits to the computation trace as a set of polynomials and proves constraint satisfaction at a random evaluation point.

Trusted setup: Universal. The Powers of Tau ceremony produces an SRS usable by any PLONK-based circuit. Ethereum's KZG ceremony for EIP-4844 is compatible with PLONK verification.

UltraPlonk extends PLONK with custom gates and lookup arguments, allowing more efficient encoding of bitwise operations and range checks that would be expensive in vanilla PLONK. UltraPlonk is the proof system used by the Barretenberg library behind Noir, though as of Barretenberg v0.87.0, UltraPlonk has been deprecated in favor of UltraHonk.

UltraHonk uses the same circuit format as UltraPlonk but replaces the polynomial commitment scheme with a variant that avoids the need for an SRS of degree equal to circuit size. It is the current Noir proof system.

Halo2 is a PLONK variant developed by the Zcash team that achieves recursive proof composition without a trusted setup, using the Inner Product Argument instead of KZG. It powers Zcash's Orchard protocol and Scroll's zkEVM.

<hr/>

## STARKs STARKs use a completely different mathematical foundation. Instead of elliptic curves and pairings, they use hash functions and Reed-Solomon error correcting codes. The core component is FRI (Fast Reed-Solomon Interactive Oracle Proof), which provides the polynomial commitment.

Arithmetization: AIR (Algebraic Intermediate Representation). Computations are expressed as polynomial constraints over execution traces, where each step of a computation maps to a row in the trace. Fibonacci sequences, hash function rounds, and CPU execution steps all map naturally to AIR.

Commitment scheme: FRI. Polynomials are evaluated at many points, Reed-Solomon encoded, and committed using Merkle trees of hashes. No elliptic curves. No pairings. No trusted setup.

Proof size: Large. A STARK proof for a computation requiring thousands of steps is typically tens to hundreds of kilobytes. This is the primary cost compared to SNARKs.

Verification: Logarithmic in computation size, not constant. Verifying a STARK requires checking a sequence of FRI rounds and Merkle path openings. On Ethereum, native STARK verification is prohibitively expensive, which is why teams wrap STARK proofs in Groth16 for EVM settlement.

Where it is used: StarkNet, Polygon Miden, RISC Zero, SP1. All major zkVMs use STARK-based backends because STARKs parallelize well and have no trusted setup ceremony to manage.

<hr/>

Plonky2

Plonky2 was developed by Polygon and combines PLONK-style custom gates with FRI commitments over a 64-bit Goldilocks field rather than a large prime field. This makes field arithmetic significantly faster in practice.

Key property: Designed for recursive proof composition. Plonky2 can verify its own proofs inside a Plonky2 circuit efficiently. This enables aggregation of many proofs into one without the Groth16 wrapping overhead.

Commitment: FRI over the Goldilocks field. No trusted setup.

Proof size: Larger than SNARKs but smaller than standard STARKs due to the smaller field. Around 100-200KB for typical circuits.

Where it is used: Polygon's zkEVM internally, systems that need fast recursion without a trusted setup.

<hr/>

zkVMs: a separate category

zkVMs are not a proof system in themselves. They are virtual machines where execution traces can be proved using an underlying proof system. The crucial distinction is the level of abstraction.

In a circuit-based system like Circom or PLONK, you write the circuit manually and control every constraint. In a zkVM, you write a program in a general-purpose language and the VM generates the circuit automatically from the execution trace.

RISC Zero uses a STARK backend based on the FRI protocol with Poseidon2 as the hash function. You write guest programs in Rust. The zkVM executes the program and produces a proof of correct execution. The trace is an AIR over a RISC-V instruction set.

SP1 is built by Succinct Labs and also targets RISC-V execution. It uses a STARK backend and is designed for compatibility with the Succinct prover network. SP1 proofs are submitted in compressed form.

Both systems allow writing proofs for arbitrary Rust computation without thinking about circuits, at the cost of larger proofs and slower proving time compared to hand-optimized circuits.

<hr/>

Folding schemes: the new category

Folding schemes are a fundamentally different approach to recursive proof composition introduced with Nova by Microsoft Research in 2021.

Instead of verifying one proof inside another proof, folding takes two instances of the same computation and folds them into one. The result has the same structure as either input but accumulates the correctness guarantee of both. Repeated folding produces an incrementally verifiable computation with near-constant overhead per step.

Nova was the first folding scheme. It operates over R1CS and achieves recursive composition with much lower overhead than traditional SNARK recursion.

HyperNova extends Nova to a more general constraint system called CCS (Customizable Constraint Systems) that subsumes R1CS and Plonkish arithmetization.

Sonobe is an open-source library implementing Nova, HyperNova, and related folding schemes in Rust. It is the primary practical entry point for building systems based on folding.

Folding schemes are not yet as widely deployed as Groth16 or PLONK but are the direction the research community considers most promising for efficiently proving long sequential computations and recursive aggregation.

<hr/>

How to read this landscape as a developer

The choice of proof system is primarily determined by three questions:

Do you need a trusted setup? If your application requires provably transparent verification with no ceremony assumptions, use a STARK-based system or Halo2. If you can accept a trusted setup and need small proofs and fast verification, Groth16 or PLONK are appropriate.

What is your circuit language? Circom targets Groth16 and PLONK via snarkjs. Noir targets UltraHonk. If you want to write Rust, RISC Zero and SP1 are your options. The language choice constrains the proof system.

What does your verifier cost? If your proof is verified on Ethereum, SNARK proof sizes matter enormously because you pay gas for every byte. If you are verifying on zkVerify, native STARK proofs are accepted directly and you avoid the wrapping cost.

| System | Arithmetization | Commitment | Setup | Proof Size | |--------|----------------|------------|-------|------------| | Groth16 | R1CS | Pairing | Circuit-specific | ~128 bytes | | PLONK | Plonkish | KZG | Universal | ~500 bytes | | UltraHonk | Plonkish | IPA variant | None | ~1-5 KB | | Halo2 | Plonkish | IPA | None | ~5-20 KB | | STARKs | AIR | FRI | None | 50-500 KB | | Plonky2 | Plonkish + FRI | FRI | None | 100-200 KB | | RISC Zero | AIR (RISC-V) | FRI | None | 100-300 KB | | SP1 | AIR (RISC-V) | FRI | None | 100-300 KB |