Choosing a proof system
A proof system in practice is not one choice but three semi-independent ones: an arithmetisation, an interactive protocol, and a commitment scheme. Most of the properties engineers actually care about — proof size, on-chain gas, prover memory, field constraints, post-quantum posture — are set by the commitment layer and the field, not by the name of the SNARK. Getting this decision right first is what makes the rest of the project tractable; getting it wrong is what makes teams rewrite circuits a year in.
Think of the stack as arithmetisation (R1CS, PLONKish, AIR, CCS, multilinear) → protocol (polynomial IOP, sumcheck/GKR, folding) → commitment (KZG, FRI, IPA, Merkle plus linear code). Teams argue about the middle layer and are then surprised by consequences that came from the bottom one. If you want to predict proof size, verifier cost and post-quantum posture, look at the commitment scheme and the field first.
Pairing-based systems over BN254 still dominate final on-chain verification, because Ethereum has had a cheap pairing precompile for that curve since 2017 and every deployed verifier targets it; BLS12-381 precompiles (EIP-2537) have been live since the 2025 Pectra upgrade, so a 128-bit-security pairing curve is now also affordable on-chain, but the tooling and the deployed base have not moved yet. Hash-based small-field systems dominate bulk proving. Most production systems therefore use both: prove with a transparent hash-based system, then wrap the result in a pairing-based proof for settlement. Recognise this early — it means "we chose a transparent system" and "we need a trusted setup" are routinely both true. See §04.
This document does not reproduce benchmark numbers, because they change monthly and depend on hardware, security parameters and workload. It does say where the live ones are. For zkVMs, ethproofs.org publishes per-prover proving time, cost and cluster size on real Ethereum blocks, continuously and with the parameters stated — it is the closest thing to a neutral scoreboard the field has. For fixed programs across zkVMs, the a16z zkVM benchmark harness and the Delendum benchmarking suite compare implementations on identical workloads. Read every figure with its security level, field, hardware, and whether it includes the recursion and wrapping step. The prover-profile table below says, per family, where credible measurements exist and who maintains the implementations.
First, hash-based systems are configurable across soundness regimes, and vendors routinely ship 96–100 bits rather than 128 — a deliberate, documented performance tradeoff that is easy to miss in a benchmark table. Second, the aggressive "up-to-capacity" proximity-gap conjectures that justified the most optimistic FRI parameters were disproved in late 2025 — with an important qualification: the published counterexamples need fields exponentially large relative to blocklength, and the authors state the results do not apply to the small fields actually used in deployed systems. The practical effect is therefore not that deployed parameters are broken, but that a conjecture people were relying on turned out to be false as stated, and the corrected version costs something. Always demand a written parameter statement rather than a bit count.
Decision criteria · 10
Where the proof is finally verified, and what that costs
This is the hardest constraint in the whole document and it eliminates most of the design space immediately. On a gas-metered chain, verifier cost is dominated by which precompiles the verifier can use; hash-based verifiers get none, so a native FRI verifier on-chain is impractical.
Setup trust model
A circuit-specific setup must be re-run for every circuit change. A universal, updatable SRS is generated once per size bound and reused. A transparent system needs none. This single property determines whether §04 is a workstream or a paragraph.
Proof size and verifier work
Proof size drives calldata and data-availability cost, mobile bandwidth, and whether a proof can be gossiped or embedded in another message. The spread across systems is roughly three orders of magnitude.
Prover time, memory, and the hardware envelope
Client-side proving — browser, phone, wallet — is usually memory-bound before it is time-bound. A prover needing an SRS proportional to circuit size resident in RAM cannot run where a small-field hash-based prover can.
Recursion and aggregation strategy
Nearly every production system is recursive somewhere: to compress a large proof for settlement, to aggregate many proofs, or to make proving incremental. Recursion friendliness reduces to whether the verifier is cheap to express in the prover's own field.
Field and curve constraints imposed by the statement
If the statement verifies existing signatures or commitments, that arithmetic is non-native in almost every proof system and will dominate cost. If the statement is hashing or bit manipulation, small prime or binary fields with strong lookup support win decisively.
Statement shape: uniform, non-uniform, lookups and memory
A zkVM proving arbitrary execution has different needs from a fixed membership circuit. Heavy table lookups — bit operations, range checks, instruction decoding — often dominate prover time more than the choice of headline proof system does.
Post-quantum posture, and how much you actually need it
Pairing- and discrete-log-based systems fall to a cryptographically relevant quantum computer; hash-based systems are plausibly post-quantum. But the urgency differs sharply depending on which property you need to survive.
Soundness regime and the actual security parameter
Benchmarks are routinely published at different security levels, and hash-based systems can be configured in provable or conjectural regimes. The conjectural regime buys meaningful performance, and the conjectures are not all still standing.
Maturity, audit surface and independent implementations
Cryptographic elegance does not survive contact with an underconstrained circuit. The dominant real-world failure mode is not a broken proof system but a broken circuit, transcript or deployment — and mature systems are the ones where those mistakes have already been made and documented.
Selection matrix · 17
Proof system selection matrix
| Family | Setup | Proof size | On-chain verification | PQ | Recursion | Maturity |
|---|---|---|---|---|---|---|
| Groth16 | Circuit-specific | 3 group elements: 128 B compressed, 256 B as EVM calldata | Cheapest deployed option | No | Via curve cycles; awkward | Production since 2016 |
| PLONK family | Universal, updatable | Sub-kilobyte | Practical; above Groth16 | No | Well-exercised | Production; most common deployed family |
| fflonk | Universal | ~768 B as deployed | Fewer verifier group ops than PLONK | No | As PLONK | Was production in one stack, since retired |
| Marlin / Varuna | Universal, updatable | Constant, above Groth16 | Practical | No | Limited | Production in one ecosystem; little greenfield use |
| Halo2 + IPA | None | Logarithmic | Impractical — verifier linear in circuit size | No | Native, via accumulation on a curve cycle | Years in production; gadget-layer bug in 2026 |
| Halo2 + KZG | Universal, updatable | Constant | Practical | No | Supported | Production; central maintenance declining |
| FRI-based STARKs | None | Tens to hundreds of KB | Impractical directly — wrapper is standard | Plausibly | Well-exercised | Heavily production |
| STIR / WHIR | None | Markedly smaller than FRI at equal security | Impractical directly | Plausibly | Inherits FRI approaches | Research maturing into implementation |
| Binius (binary fields) | None | Hash-based scale | Impractical directly | Plausibly | Developing | Early production; fast-moving codebase |
| Ligero / Brakedown | None | Square-root — large | Not viable | Plausibly | Used as an inner layer | Established; mostly used as a component |
| Basefold | None | Between Brakedown and FRI | Impractical directly | Plausibly | As a commitment layer | Research-to-production transition |
| Spartan | None (commitment-dependent) | Depends on commitment | Not a settlement candidate alone | Commitment-dependent | Used inside larger systems | Established construction, widely built upon |
| GKR / sumcheck systems | None (commitment-dependent) | Grows with circuit depth | Wrapper needed | Commitment-dependent | Developing | Production via at least one major zkVM |
| HyperPlonk | Commitment-dependent | Larger than univariate PLONK with KZG | More expensive than PLONK | Commitment-dependent | Supported | Influential; fewer deployments under its own name |
| Nova / folding schemes | None in the folding layer | Accumulator, not a proof — needs final compression | Via the compressing SNARK only | No | This is the whole point | Research to early production |
| Bulletproofs | None | Logarithmic; small for ranges | Linear in circuit size — not succinct | No | Poor | Production for range proofs since 2018 |
| LatticeFold | None | Research-stage | Research-stage | Yes (lattice) | Designed for it | Research only — not a 2026 production choice |
These are structural properties of each design, not benchmark results — implementation performance depends on hardware, circuit shape and optimisation effort and goes stale within months. Proof sizes are order-of-magnitude and assume typical deployed parameters; for hash-based systems size is a dial traded against security, so treat any figure without its parameters as indicative only. "PQ" means the design rests only on hash assumptions, and it is forfeited if you wrap the proof in a pairing-based SNARK.
Prover profile · 17
Prover profile, implementations and benchmarks
| Family | Prover cost profile | Peak prover memory | Off-chain verifier | Implementations and maintainers | Where it is measured |
|---|---|---|---|---|---|
| Groth16 | 256-bit-field MSMs and FFTs; roughly linear in constraints with a high constant. Mature GPU provers exist. | Proving key resident in RAM, growing with circuit size — the usual browser and mobile limit | Milliseconds: three pairings | snarkjs and rapidsnark (iden3), gnark (Consensys), arkworks, bellman (Zcash lineage), ICICLE GPU backends (Ingonyama) | Delendum zk-benchmarking; wrapper cost inside every zkVM benchmark on ethproofs.org |
| PLONK family | 256-bit-field FFTs dominate; custom gates and lookups trade prover work for constraint count | SRS and witness polynomials resident; comparable to Groth16 at equal size | Milliseconds | Barretenberg / UltraHonk (Aztec), gnark (Consensys), plonky2 (Polygon Zero lineage), Kimchi (o1Labs), Halo2 forks | Vendor-published only; no neutral cross-implementation suite |
| fflonk | Heavier than PLONK: polynomials are combined to shrink the verifier | As PLONK | Milliseconds | snarkjs (iden3); formerly Polygon zkEVM | Historical Polygon zkEVM figures only |
| Marlin / Varuna | Universal-SRS R1CS prover; slower than Groth16 at equal size | SRS resident | Milliseconds | arkworks marlin (research), Varuna in snarkVM (Provable / Aleo) | Aleo ecosystem figures only |
| Halo2 + IPA | MSM-dominated over the Pasta curve cycle; no pairing-curve FFT bottleneck | Proportional to circuit size; moderate | Linear in circuit size — tens to hundreds of milliseconds for large circuits | zcash/halo2 (Electric Coin Company) | Zcash Orchard figures; no neutral suite |
| Halo2 + KZG | 256-bit-field FFTs over BN254; the largest gadget ecosystem of any PLONKish frontend | SRS resident; large circuits need tens of gigabytes | Milliseconds | privacy-ethereum/halo2 (Ethereum Foundation PSE, maintenance mode), halo2-lib (Axiom), Scroll's fork | Scroll and Axiom published figures; no neutral suite |
| FRI-based STARKs | Small-field hashing and NTTs; the fastest bulk provers on CPU and GPU, and the basis of most zkVMs | Trace-proportional, but small fields keep it low; continuations bound it | Milliseconds to tens of milliseconds — hashing only | Stone and Stwo (StarkWare), Plonky3 (Polygon Zero lineage; beneath SP1 Turbo, OpenVM, Ziren, Pico), RISC Zero, Miden, ZKsync Airbender (Matter Labs), Winterfell | ethproofs.org real-time Ethereum block proving; a16z zkvm-benchmarks |
| STIR / WHIR | Comparable to FRI; the WHIR prover is somewhat heavier | As FRI | Sub-millisecond for WHIR in the authors' reported settings | Reference implementations by the authors; integrations into production hash-based stacks under way | Authors' comparisons only; measure on your own parameters |
| Binius (binary fields) | Binary-field arithmetic maps to hardware bit operations; strongest on hashing and bitwise workloads | Low — tiny field elements, no embedding overhead | Milliseconds | Binius64 (Irreducible); the original binius repository is archived | Irreducible's published figures; few independent measurements |
| Ligero / Brakedown | Linear-time encoding — the cheapest commitment prover, paid for in proof size | Low | Sublinear, but large proofs to hash | Ligero (Ligero Inc.), Brakedown in the Lasso and Jolt lineage (a16z crypto), arkworks | Component-level measurements only |
| Basefold | Linear-time encoding plus a FRI-like fold; between Brakedown and FRI | Low | Polylogarithmic | Ceno (Scroll) and research implementations | Component-level measurements only |
| Spartan | Sumcheck over sparse R1CS; no FFT; linear in non-zero constraint entries | Low and streaming-friendly | Sublinear after preprocessing; commitment-dependent | Spartan (Microsoft Research), inside Jolt (a16z crypto) and Nexus | Only inside zkVM benchmarks |
| GKR / sumcheck systems | Linear-time; commits only to the input layer | Low relative to trace size | Grows with circuit depth | Expander (Polyhedra), Ceno (Scroll), SP1 Hypercube's sumcheck design (Succinct) | ethproofs.org for the zkVMs built on it; Polyhedra's published figures |
| HyperPlonk | Sumcheck-based, linear-time, no FFT; high-degree gates are cheap | Low | Higher than univariate PLONK | Espresso Systems research implementation; ideas absorbed into other stacks | Paper figures only |
| Nova / folding schemes | Two MSMs per step — the cheapest incremental step known | Bounded by one step plus the accumulator | Only after final compression | Nova (Microsoft Research), Sonobe (Ethereum Foundation lineage), arecibo (Argument Computer) | Repository benchmarks only; no neutral suite |
| Bulletproofs | Linear MSMs; slow for general circuits | Low | Linear in circuit size; batchable | dalek bulletproofs (Rust), Monero, Bulletproofs+ in several wallets | Range-proof figures in Monero and dalek benchmarks |
| LatticeFold | Research-stage | Research-stage | Research-stage | Research prototypes; a lattice-based Jolt variant was announced by a16z crypto in September 2026 | None neutral |
Prover cost and memory are stated as profiles — what dominates and how it scales — rather than as numbers, which belong in the benchmark suites named in the last column. "Off-chain verifier" is the cost of a native verifier on a server or client, the number that matters when no gas-metered contract is involved. "Implementations" names who maintains the code you would actually run; a construction with one implementation and one maintainer is a different risk from one with five.
Commitment schemes · 10
Commitment schemes — the layer that decides most of it
| Scheme | Assumption | Setup | Opening size | Verifier cost | Field constraint |
|---|---|---|---|---|---|
| KZG | Pairings | Structured, universal | Constant | Constant; precompile-backed | Pairing-friendly curve, 256-bit scalar field |
| Multilinear KZG (PST, Zeromorph, HyperKZG) | Pairings | Structured, universal | Logarithmic — hundreds of bytes | Constant pairings plus a logarithmic number of group operations; EVM-practical | Pairing-friendly curve, 256-bit scalar field |
| Hyrax | Discrete log (Pedersen) | None | Square-root | Square-root MSM | Any prime-order group |
| Dory | Pairings, transparent (no trapdoor) | None — public generators | Logarithmic | Logarithmic, with pairings | Pairing-friendly curve |
| FRI | Hash (collision resistance) | None | Polylogarithmic but large in absolute terms | Polylogarithmic; expensive on-chain | High two-adicity; extension for challenges |
| IPA / Bulletproofs-style | Discrete log | None | Logarithmic | Linear unless amortised by accumulation | Any prime-order group; enables curve cycles |
| Brakedown / Ligero | Hash + linear codes | None | Square-root — large | Sublinear, not polylogarithmic | Field-agnostic |
| Basefold | Hash + foldable codes | None | Between Brakedown and FRI | Polylogarithmic | Field-agnostic — no two-adicity requirement |
| WHIR | Hash + constrained RS codes | None | Smaller than FRI at equal security | Reported in hundreds of microseconds | Reed-Solomon-friendly |
| Binius commitments | Hash over binary fields | None | Hash-based scale | Polylogarithmic | Binary field towers |
Two systems built on the same commitment scheme will resemble each other on proof size, verifier cost and post-quantum posture far more than two systems sharing a protocol name but differing here. When comparing proof systems, check this table first. Sumcheck-based systems — Spartan, HyperPlonk, Jolt, GKR stacks — need a multilinear commitment, which is why the multilinear KZG variants, Hyrax and Dory appear here alongside the univariate schemes.
Systems, commitments and lookup arguments · 11 pages
How to run the selection · 8 steps
Write down the verification environment as a number
Where is the proof verified, and what is the budget — gas, milliseconds, bytes? This single constraint eliminates most of the design space, and it is the one teams most often leave qualitative.
Classify the statement by operation mix
Count foreign-field operations, hash invocations, range checks and memory accesses separately. The dominant class determines whether a small-field, binary-field or 256-bit-field system is right, far more than the protocol name does.
Decide the setup posture deliberately
Is a trusted setup acceptable to your users and governance? Will the circuit change after launch? Answer these before comparing performance, because they cut the field decisively and they are the hardest to reverse.
Choose the commitment scheme, then the protocol
Work bottom-up. The commitment scheme and field fix proof size, verifier cost and post-quantum posture; the protocol layered on top is a comparatively free choice among those that fit.
Design the recursion and wrapping strategy now, not later
Decide whether you will wrap for settlement, what the wrapper costs, and what setup the wrapper needs. Teams that defer this discover late that their transparent system depends on a ceremony after all.
Write the security parameter statement
Record field and extension degree, hash output length, rate, query count, grinding bits, decoding regime, and whether the claim is provable or conjectured. Use a shared soundness calculator rather than a bespoke derivation. This document is an audit artefact — see §03.
Prototype the dominant cost, at the shipping parameters
Build the most expensive component in the top two candidates and measure prover time, peak memory and verifier cost at the security level you will actually deploy — not at benchmark parameters.
Record the decision, its assumptions and its expiry conditions
State what would force a revisit: a conjecture falling, a wrapper cost change, a field requirement shifting. This decision has the longest half-life in the project and deserves an explicit record.
Where proof system decisions go wrong · 10
Sources for this section · 40
- Groth16 — On the size of pairing-based non-interactive argumentspaper
- PLONK — permutations over Lagrange bases for oecumenical noninteractive argumentspaper
- fflonk — a fast-Fourier inspired verifier efficient variant of PLONKpaper
- Marlin — preprocessing zkSNARKs with universal and updatable SRSpaper
- Halo — recursive proof composition without a trusted setuppaper
- Nova — recursive zero-knowledge arguments from folding schemespaper
- Spartan — efficient and general-purpose zkSNARKs without trusted setuppaper
- Bulletproofs — short proofs for confidential transactions and morepaper
- Scalable, transparent, and post-quantum secure computational integrity (STARKs)paper
- Proximity gaps for Reed–Solomon codespaper
- Circle STARKs — making Mersenne-31 usable for FRI-based systemspaper
- ethSTARK documentation — concrete soundness parameterspaper
- Binius — succinct arguments over towers of binary fieldspaper
- Basefold — field-agnostic multilinear polynomial commitmentpaper
- Brakedown — linear-time and field-agnostic SNARKs for R1CSpaper
- STIR — Reed–Solomon proximity testing with fewer queriespaper
- WHIR — Reed–Solomon proximity testing with super-fast verificationpaper
- Libra — succinct zero-knowledge proofs with optimal prover computation (GKR)paper
- HyperPlonk — PLONK with linear-time prover and high-degree custom gatespaper
- Signatures of correct computation (PST) — the original multilinear KZG commitmentpaper
- Zeromorph — multilinear evaluation proofs from univariate KZGpaper
- Hyrax — doubly-efficient zkSNARKs without trusted setup (square-root Pedersen commitment)paper
- Dory — transparent logarithmic-size arguments for inner products and polynomial commitmentspaper
- LatticeFold+ — post-quantum folding from latticespaper
- Plookup — a simplified polynomial protocol for lookup tablespaper
- Multivariate lookups based on logarithmic derivatives (LogUp)paper
- cq — cached quotients for fast lookupspaper
- Twist and Shout — memory checking arguments for zkVMspaper
- SoK: Trusted setups for powers-of-tau stringspaper
- EIP-1108 — reduced gas cost for alt_bn128 precompilesspec
- EIP-2537 — BLS12-381 curve operations precompilespec
- EIP-4844 — shard blob transactions and the KZG commitment schemespec
- soundcalc — soundness parameter calculator for hash-based systemstool
- L2BEAT ZK Catalog — catalogue of deployed on-chain verifierscatalogue
- ethproofs.org — continuous real-time proving benchmarks on Ethereum blocks, per prover, with cost and hardwarebenchmark
- a16z zkvm-benchmarks — fixed-program comparison harness across zkVMsbenchmark
- Delendum zk-benchmarking — cross-implementation benchmarks of proof systems and zkVMsbenchmark
- ZKProof Community Reference — terminology and security recommendationsreference
- Plonky3 — polynomial IOP toolkit over small fieldsproject
- Wrapping up the KZG ceremony — the largest deployed universal SRSrecord
Cite this page
MarketComp (2026). Choosing a proof system. The ZK Field Manual (Version 1.3). MarketComp. https://zkpick.com/proof-systems/
@misc{zkfieldmanual-choosing-a-proof-system,
title = {Choosing a proof system — The ZK Field Manual},
author = {MarketComp},
year = {2026},
version = {1.3},
howpublished = {\url{https://zkpick.com/proof-systems/}},
note = {Accessed: YYYY-MM-DD}
}