{ "type": "section", "id": "proof-systems", "number": "01", "title": "Choosing a proof system", "url": "https://zkpick.com/proof-systems/", "markdown": "https://zkpick.com/md/proof-systems.md", "summary": "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.", "notes": [ { "kind": "note", "label": "The three layers, and which one actually decides things", "text": "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." }, { "kind": "note", "label": "The landscape is bimodal, and hybrid by default", "text": "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](https://zkpick.com/ceremony/)." }, { "kind": "note", "label": "Where the benchmarks are, and how to read them", "text": "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](https://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](https://github.com/a16z/zkvm-benchmarks) and the [Delendum benchmarking suite](https://github.com/delendum-xyz/zk-benchmarking) 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." }, { "kind": "warn", "label": "Two things to check before quoting anyone's security level", "text": "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." } ], "decisionCriteria": [ { "name": "Where the proof is finally verified, and what that costs", "why": "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.", "how": "Write the verifier down as a concrete gas number at a stated instance size, not as a complexity class. For pairing-based systems on Ethereum, budget the pairing precompile plus a per-public-input cost for the input commitment. If the answer is \"we will wrap it\", price the wrapper — it is the real verifier." }, { "name": "Setup trust model", "why": "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.", "how": "Ask how often the circuit will change and who runs the ceremony each time. If a setup is required, check whether a reusable public artefact already exists on your curve at sufficient degree — running your own phase 1 is almost never the right answer." }, { "name": "Proof size and verifier work", "why": "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.", "how": "Insist on numbers at a stated security level and stated instance size, because for hash-based systems proof size is a tunable dial traded against query count and grinding. A size quoted without its security parameters is not a number." }, { "name": "Prover time, memory, and the hardware envelope", "why": "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.", "how": "Measure peak resident memory, not just wall time, on the actual target device and at the security level you will ship. Ask whether the system supports streaming, chunking or continuation-based proving — folding schemes and continuation-based zkVMs do; a monolithic prover over a huge constraint system does not. Start from the prover-profile table below and the public benchmark suites it points to, then confirm on your own workload." }, { "name": "Recursion and aggregation strategy", "why": "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.", "how": "Ask three concrete questions. Is there an in-circuit verifier already implemented and audited, or would you be writing one? How large is that verifier circuit — this sets your minimum useful step size. Does the design require non-native field arithmetic, which typically dominates the cost?" }, { "name": "Field and curve constraints imposed by the statement", "why": "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.", "how": "Profile the statement by operation class before choosing a backend, then check the field menu the backend actually offers. Some toolkits expose several fields behind one interface, making this a configuration choice rather than a rewrite." }, { "name": "Statement shape: uniform, non-uniform, lookups and memory", "why": "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.", "how": "Count lookups and memory operations, not just gates. If lookups dominate, the lookup argument matters more than the choice between one PLONK variant and another. If the machine is non-uniform, check whether you pay for the union of all instructions at every step." }, { "name": "Post-quantum posture, and how much you actually need it", "why": "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.", "how": "Separate confidentiality from soundness. If the proof hides a long-lived secret, harvest-now-decrypt-later applies and the zero-knowledge property must be statistical or post-quantum. If only soundness matters, a proof verified and settled today cannot be retroactively forged, so the requirement is much weaker. Note also that a pairing-based wrapper removes the inner system's PQ posture." }, { "name": "Soundness regime and the actual security parameter", "why": "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.", "how": "Demand a written parameter statement: field and extension degree, hash output length, rate, number of queries, grinding bits, decoding regime, and explicitly whether the claim is provable or conjectured. Shared calculators now exist for this; use one rather than accepting a bespoke bit count." }, { "name": "Maturity, audit surface and independent implementations", "why": "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.", "how": "Look for an independent second implementation of the verifier, which is a strong maturity signal; published audit reports; and presence in neutral catalogues of deployed verifiers. Check repository health directly rather than trusting a launch post." } ], "comparisons": [ { "title": "Proof system selection matrix", "caption": "Proof system families by structural properties", "url": "https://zkpick.com/proof-systems/#proof-systems-matrix", "note": "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.", "columns": [ { "key": "name", "label": "Family" }, { "key": "setup", "label": "Setup" }, { "key": "size", "label": "Proof size" }, { "key": "verify", "label": "On-chain verification" }, { "key": "pq", "label": "PQ" }, { "key": "recursion", "label": "Recursion" }, { "key": "maturity", "label": "Maturity" } ], "rows": [ { "url": "https://zkpick.com/proof-systems/#proof-systems-matrix-groth16", "constraints": [ "onchain", "small", "recursion" ], "name": "Groth16", "setup": "Circuit-specific", "size": "3 group elements: 128 B compressed, 256 B as EVM calldata", "verify": "Cheapest deployed option", "pq": "No", "recursion": "Via curve cycles; awkward", "maturity": "Production since 2016" }, { "url": "https://zkpick.com/proof-systems/#proof-systems-matrix-plonk-family", "constraints": [ "universal", "onchain", "small", "recursion" ], "name": "PLONK family", "setup": "Universal, updatable", "size": "Sub-kilobyte", "verify": "Practical; above Groth16", "pq": "No", "recursion": "Well-exercised", "maturity": "Production; most common deployed family" }, { "url": "https://zkpick.com/proof-systems/#proof-systems-matrix-fflonk", "constraints": [ "universal", "onchain", "small" ], "name": "fflonk", "setup": "Universal", "size": "~768 B as deployed", "verify": "Fewer verifier group ops than PLONK", "pq": "No", "recursion": "As PLONK", "maturity": "Was production in one stack, since retired" }, { "url": "https://zkpick.com/proof-systems/#proof-systems-matrix-marlin-varuna", "constraints": [ "universal", "onchain", "small" ], "name": "Marlin / Varuna", "setup": "Universal, updatable", "size": "Constant, above Groth16", "verify": "Practical", "pq": "No", "recursion": "Limited", "maturity": "Production in one ecosystem; little greenfield use" }, { "url": "https://zkpick.com/proof-systems/#proof-systems-matrix-halo2-ipa", "constraints": [ "nosetup", "universal", "recursion", "small" ], "name": "Halo2 + IPA", "setup": "None", "size": "Logarithmic", "verify": "Impractical — verifier linear in circuit size", "pq": "No", "recursion": "Native, via accumulation on a curve cycle", "maturity": "Years in production; gadget-layer bug in 2026" }, { "url": "https://zkpick.com/proof-systems/#proof-systems-matrix-halo2-kzg", "constraints": [ "universal", "onchain", "small", "recursion" ], "name": "Halo2 + KZG", "setup": "Universal, updatable", "size": "Constant", "verify": "Practical", "pq": "No", "recursion": "Supported", "maturity": "Production; central maintenance declining" }, { "url": "https://zkpick.com/proof-systems/#proof-systems-matrix-fri-based-starks", "constraints": [ "nosetup", "universal", "pq", "recursion", "lowmem" ], "name": "FRI-based STARKs", "setup": "None", "size": "Tens to hundreds of KB", "verify": "Impractical directly — wrapper is standard", "pq": "Plausibly", "recursion": "Well-exercised", "maturity": "Heavily production" }, { "url": "https://zkpick.com/proof-systems/#proof-systems-matrix-stir-whir", "constraints": [ "nosetup", "universal", "pq", "lowmem" ], "name": "STIR / WHIR", "setup": "None", "size": "Markedly smaller than FRI at equal security", "verify": "Impractical directly", "pq": "Plausibly", "recursion": "Inherits FRI approaches", "maturity": "Research maturing into implementation" }, { "url": "https://zkpick.com/proof-systems/#proof-systems-matrix-binius-binary-fields", "constraints": [ "nosetup", "universal", "pq", "lowmem" ], "name": "Binius (binary fields)", "setup": "None", "size": "Hash-based scale", "verify": "Impractical directly", "pq": "Plausibly", "recursion": "Developing", "maturity": "Early production; fast-moving codebase" }, { "url": "https://zkpick.com/proof-systems/#proof-systems-matrix-ligero-brakedown", "constraints": [ "nosetup", "universal", "pq" ], "name": "Ligero / Brakedown", "setup": "None", "size": "Square-root — large", "verify": "Not viable", "pq": "Plausibly", "recursion": "Used as an inner layer", "maturity": "Established; mostly used as a component" }, { "url": "https://zkpick.com/proof-systems/#proof-systems-matrix-basefold", "constraints": [ "nosetup", "universal", "pq" ], "name": "Basefold", "setup": "None", "size": "Between Brakedown and FRI", "verify": "Impractical directly", "pq": "Plausibly", "recursion": "As a commitment layer", "maturity": "Research-to-production transition" }, { "url": "https://zkpick.com/proof-systems/#proof-systems-matrix-spartan", "constraints": [ "nosetup", "universal", "pq", "lowmem" ], "name": "Spartan", "setup": "None (commitment-dependent)", "size": "Depends on commitment", "verify": "Not a settlement candidate alone", "pq": "Commitment-dependent", "recursion": "Used inside larger systems", "maturity": "Established construction, widely built upon" }, { "url": "https://zkpick.com/proof-systems/#proof-systems-matrix-gkr-sumcheck-systems", "constraints": [ "nosetup", "universal", "pq", "lowmem" ], "name": "GKR / sumcheck systems", "setup": "None (commitment-dependent)", "size": "Grows with circuit depth", "verify": "Wrapper needed", "pq": "Commitment-dependent", "recursion": "Developing", "maturity": "Production via at least one major zkVM" }, { "url": "https://zkpick.com/proof-systems/#proof-systems-matrix-hyperplonk", "constraints": [ "universal", "lowmem", "recursion" ], "name": "HyperPlonk", "setup": "Commitment-dependent", "size": "Larger than univariate PLONK with KZG", "verify": "More expensive than PLONK", "pq": "Commitment-dependent", "recursion": "Supported", "maturity": "Influential; fewer deployments under its own name" }, { "url": "https://zkpick.com/proof-systems/#proof-systems-matrix-nova-folding-schemes", "constraints": [ "nosetup", "universal", "recursion", "lowmem" ], "name": "Nova / folding schemes", "setup": "None in the folding layer", "size": "Accumulator, not a proof — needs final compression", "verify": "Via the compressing SNARK only", "pq": "No", "recursion": "This is the whole point", "maturity": "Research to early production" }, { "url": "https://zkpick.com/proof-systems/#proof-systems-matrix-bulletproofs", "constraints": [ "nosetup", "universal" ], "name": "Bulletproofs", "setup": "None", "size": "Logarithmic; small for ranges", "verify": "Linear in circuit size — not succinct", "pq": "No", "recursion": "Poor", "maturity": "Production for range proofs since 2018" }, { "url": "https://zkpick.com/proof-systems/#proof-systems-matrix-latticefold", "constraints": [ "nosetup", "universal", "pq", "recursion", "lowmem" ], "name": "LatticeFold", "setup": "None", "size": "Research-stage", "verify": "Research-stage", "pq": "Yes (lattice)", "recursion": "Designed for it", "maturity": "Research only — not a 2026 production choice" } ] }, { "title": "Prover profile, implementations and benchmarks", "caption": "Proof system families by prover cost, memory, off-chain verifier, maintainers and where they are measured", "url": "https://zkpick.com/proof-systems/#proof-systems-matrix-2", "note": "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.", "columns": [ { "key": "name", "label": "Family" }, { "key": "prover", "label": "Prover cost profile" }, { "key": "memory", "label": "Peak prover memory" }, { "key": "offchain", "label": "Off-chain verifier" }, { "key": "impls", "label": "Implementations and maintainers" }, { "key": "bench", "label": "Where it is measured" } ], "rows": [ { "url": "https://zkpick.com/proof-systems/#proof-systems-matrix-2-groth16", "constraints": [ "gpu", "client", "neutral", "multi" ], "name": "Groth16", "prover": "256-bit-field MSMs and FFTs; roughly linear in constraints with a high constant. Mature GPU provers exist.", "memory": "Proving key resident in RAM, growing with circuit size — the usual browser and mobile limit", "offchain": "Milliseconds: three pairings", "impls": "snarkjs and rapidsnark (iden3), gnark (Consensys), arkworks, bellman (Zcash lineage), ICICLE GPU backends (Ingonyama)", "bench": "Delendum zk-benchmarking; wrapper cost inside every zkVM benchmark on ethproofs.org" }, { "url": "https://zkpick.com/proof-systems/#proof-systems-matrix-2-plonk-family", "constraints": [ "gpu", "client", "multi" ], "name": "PLONK family", "prover": "256-bit-field FFTs dominate; custom gates and lookups trade prover work for constraint count", "memory": "SRS and witness polynomials resident; comparable to Groth16 at equal size", "offchain": "Milliseconds", "impls": "Barretenberg / UltraHonk (Aztec), gnark (Consensys), plonky2 (Polygon Zero lineage), Kimchi (o1Labs), Halo2 forks", "bench": "Vendor-published only; no neutral cross-implementation suite" }, { "url": "https://zkpick.com/proof-systems/#proof-systems-matrix-2-fflonk", "constraints": [], "name": "fflonk", "prover": "Heavier than PLONK: polynomials are combined to shrink the verifier", "memory": "As PLONK", "offchain": "Milliseconds", "impls": "snarkjs (iden3); formerly Polygon zkEVM", "bench": "Historical Polygon zkEVM figures only" }, { "url": "https://zkpick.com/proof-systems/#proof-systems-matrix-2-marlin-varuna", "constraints": [], "name": "Marlin / Varuna", "prover": "Universal-SRS R1CS prover; slower than Groth16 at equal size", "memory": "SRS resident", "offchain": "Milliseconds", "impls": "arkworks marlin (research), Varuna in snarkVM (Provable / Aleo)", "bench": "Aleo ecosystem figures only" }, { "url": "https://zkpick.com/proof-systems/#proof-systems-matrix-2-halo2-ipa", "constraints": [ "client" ], "name": "Halo2 + IPA", "prover": "MSM-dominated over the Pasta curve cycle; no pairing-curve FFT bottleneck", "memory": "Proportional to circuit size; moderate", "offchain": "Linear in circuit size — tens to hundreds of milliseconds for large circuits", "impls": "zcash/halo2 (Electric Coin Company)", "bench": "Zcash Orchard figures; no neutral suite" }, { "url": "https://zkpick.com/proof-systems/#proof-systems-matrix-2-halo2-kzg", "constraints": [ "gpu", "multi" ], "name": "Halo2 + KZG", "prover": "256-bit-field FFTs over BN254; the largest gadget ecosystem of any PLONKish frontend", "memory": "SRS resident; large circuits need tens of gigabytes", "offchain": "Milliseconds", "impls": "privacy-ethereum/halo2 (Ethereum Foundation PSE, maintenance mode), halo2-lib (Axiom), Scroll's fork", "bench": "Scroll and Axiom published figures; no neutral suite" }, { "url": "https://zkpick.com/proof-systems/#proof-systems-matrix-2-fri-based-starks", "constraints": [ "gpu", "client", "neutral", "multi" ], "name": "FRI-based STARKs", "prover": "Small-field hashing and NTTs; the fastest bulk provers on CPU and GPU, and the basis of most zkVMs", "memory": "Trace-proportional, but small fields keep it low; continuations bound it", "offchain": "Milliseconds to tens of milliseconds — hashing only", "impls": "Stone and Stwo (StarkWare), Plonky3 (Polygon Zero lineage; beneath SP1 Turbo, OpenVM, Ziren, Pico), RISC Zero, Miden, ZKsync Airbender (Matter Labs), Winterfell", "bench": "ethproofs.org real-time Ethereum block proving; a16z zkvm-benchmarks" }, { "url": "https://zkpick.com/proof-systems/#proof-systems-matrix-2-stir-whir", "constraints": [], "name": "STIR / WHIR", "prover": "Comparable to FRI; the WHIR prover is somewhat heavier", "memory": "As FRI", "offchain": "Sub-millisecond for WHIR in the authors' reported settings", "impls": "Reference implementations by the authors; integrations into production hash-based stacks under way", "bench": "Authors' comparisons only; measure on your own parameters" }, { "url": "https://zkpick.com/proof-systems/#proof-systems-matrix-2-binius-binary-fields", "constraints": [ "client" ], "name": "Binius (binary fields)", "prover": "Binary-field arithmetic maps to hardware bit operations; strongest on hashing and bitwise workloads", "memory": "Low — tiny field elements, no embedding overhead", "offchain": "Milliseconds", "impls": "Binius64 (Irreducible); the original binius repository is archived", "bench": "Irreducible's published figures; few independent measurements" }, { "url": "https://zkpick.com/proof-systems/#proof-systems-matrix-2-ligero-brakedown", "constraints": [ "multi" ], "name": "Ligero / Brakedown", "prover": "Linear-time encoding — the cheapest commitment prover, paid for in proof size", "memory": "Low", "offchain": "Sublinear, but large proofs to hash", "impls": "Ligero (Ligero Inc.), Brakedown in the Lasso and Jolt lineage (a16z crypto), arkworks", "bench": "Component-level measurements only" }, { "url": "https://zkpick.com/proof-systems/#proof-systems-matrix-2-basefold", "constraints": [], "name": "Basefold", "prover": "Linear-time encoding plus a FRI-like fold; between Brakedown and FRI", "memory": "Low", "offchain": "Polylogarithmic", "impls": "Ceno (Scroll) and research implementations", "bench": "Component-level measurements only" }, { "url": "https://zkpick.com/proof-systems/#proof-systems-matrix-2-spartan", "constraints": [ "multi" ], "name": "Spartan", "prover": "Sumcheck over sparse R1CS; no FFT; linear in non-zero constraint entries", "memory": "Low and streaming-friendly", "offchain": "Sublinear after preprocessing; commitment-dependent", "impls": "Spartan (Microsoft Research), inside Jolt (a16z crypto) and Nexus", "bench": "Only inside zkVM benchmarks" }, { "url": "https://zkpick.com/proof-systems/#proof-systems-matrix-2-gkr-sumcheck-systems", "constraints": [ "gpu", "neutral", "multi" ], "name": "GKR / sumcheck systems", "prover": "Linear-time; commits only to the input layer", "memory": "Low relative to trace size", "offchain": "Grows with circuit depth", "impls": "Expander (Polyhedra), Ceno (Scroll), SP1 Hypercube's sumcheck design (Succinct)", "bench": "ethproofs.org for the zkVMs built on it; Polyhedra's published figures" }, { "url": "https://zkpick.com/proof-systems/#proof-systems-matrix-2-hyperplonk", "constraints": [], "name": "HyperPlonk", "prover": "Sumcheck-based, linear-time, no FFT; high-degree gates are cheap", "memory": "Low", "offchain": "Higher than univariate PLONK", "impls": "Espresso Systems research implementation; ideas absorbed into other stacks", "bench": "Paper figures only" }, { "url": "https://zkpick.com/proof-systems/#proof-systems-matrix-2-nova-folding-schemes", "constraints": [ "client", "multi" ], "name": "Nova / folding schemes", "prover": "Two MSMs per step — the cheapest incremental step known", "memory": "Bounded by one step plus the accumulator", "offchain": "Only after final compression", "impls": "Nova (Microsoft Research), Sonobe (Ethereum Foundation lineage), arecibo (Argument Computer)", "bench": "Repository benchmarks only; no neutral suite" }, { "url": "https://zkpick.com/proof-systems/#proof-systems-matrix-2-bulletproofs", "constraints": [ "client", "multi" ], "name": "Bulletproofs", "prover": "Linear MSMs; slow for general circuits", "memory": "Low", "offchain": "Linear in circuit size; batchable", "impls": "dalek bulletproofs (Rust), Monero, Bulletproofs+ in several wallets", "bench": "Range-proof figures in Monero and dalek benchmarks" }, { "url": "https://zkpick.com/proof-systems/#proof-systems-matrix-2-latticefold", "constraints": [], "name": "LatticeFold", "prover": "Research-stage", "memory": "Research-stage", "offchain": "Research-stage", "impls": "Research prototypes; a lattice-based Jolt variant was announced by a16z crypto in September 2026", "bench": "None neutral" } ] }, { "title": "Commitment schemes — the layer that decides most of it", "caption": "Polynomial commitment schemes by setup, cost and field requirements", "url": "https://zkpick.com/proof-systems/#proof-systems-matrix-3", "note": "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.", "columns": [ { "key": "name", "label": "Scheme" }, { "key": "basis", "label": "Assumption" }, { "key": "setup", "label": "Setup" }, { "key": "opening", "label": "Opening size" }, { "key": "verifier", "label": "Verifier cost" }, { "key": "field", "label": "Field constraint" } ], "rows": [ { "url": "https://zkpick.com/proof-systems/#proof-systems-matrix-3-kzg", "constraints": [ "constant", "evm" ], "name": "KZG", "basis": "Pairings", "setup": "Structured, universal", "opening": "Constant", "verifier": "Constant; precompile-backed", "field": "Pairing-friendly curve, 256-bit scalar field" }, { "url": "https://zkpick.com/proof-systems/#proof-systems-matrix-3-multilinear-kzg-pst-zeromorph-hyperkzg", "constraints": [ "evm" ], "name": "Multilinear KZG (PST, Zeromorph, HyperKZG)", "basis": "Pairings", "setup": "Structured, universal", "opening": "Logarithmic — hundreds of bytes", "verifier": "Constant pairings plus a logarithmic number of group operations; EVM-practical", "field": "Pairing-friendly curve, 256-bit scalar field" }, { "url": "https://zkpick.com/proof-systems/#proof-systems-matrix-3-hyrax", "constraints": [ "nosetup" ], "name": "Hyrax", "basis": "Discrete log (Pedersen)", "setup": "None", "opening": "Square-root", "verifier": "Square-root MSM", "field": "Any prime-order group" }, { "url": "https://zkpick.com/proof-systems/#proof-systems-matrix-3-dory", "constraints": [ "nosetup" ], "name": "Dory", "basis": "Pairings, transparent (no trapdoor)", "setup": "None — public generators", "opening": "Logarithmic", "verifier": "Logarithmic, with pairings", "field": "Pairing-friendly curve" }, { "url": "https://zkpick.com/proof-systems/#proof-systems-matrix-3-fri", "constraints": [ "nosetup", "pq" ], "name": "FRI", "basis": "Hash (collision resistance)", "setup": "None", "opening": "Polylogarithmic but large in absolute terms", "verifier": "Polylogarithmic; expensive on-chain", "field": "High two-adicity; extension for challenges" }, { "url": "https://zkpick.com/proof-systems/#proof-systems-matrix-3-ipa-bulletproofs-style", "constraints": [ "nosetup" ], "name": "IPA / Bulletproofs-style", "basis": "Discrete log", "setup": "None", "opening": "Logarithmic", "verifier": "Linear unless amortised by accumulation", "field": "Any prime-order group; enables curve cycles" }, { "url": "https://zkpick.com/proof-systems/#proof-systems-matrix-3-brakedown-ligero", "constraints": [ "nosetup", "pq" ], "name": "Brakedown / Ligero", "basis": "Hash + linear codes", "setup": "None", "opening": "Square-root — large", "verifier": "Sublinear, not polylogarithmic", "field": "Field-agnostic" }, { "url": "https://zkpick.com/proof-systems/#proof-systems-matrix-3-basefold", "constraints": [ "nosetup", "pq" ], "name": "Basefold", "basis": "Hash + foldable codes", "setup": "None", "opening": "Between Brakedown and FRI", "verifier": "Polylogarithmic", "field": "Field-agnostic — no two-adicity requirement" }, { "url": "https://zkpick.com/proof-systems/#proof-systems-matrix-3-whir", "constraints": [ "nosetup", "pq" ], "name": "WHIR", "basis": "Hash + constrained RS codes", "setup": "None", "opening": "Smaller than FRI at equal security", "verifier": "Reported in hundreds of microseconds", "field": "Reed-Solomon-friendly" }, { "url": "https://zkpick.com/proof-systems/#proof-systems-matrix-3-binius-commitments", "constraints": [ "nosetup", "pq" ], "name": "Binius commitments", "basis": "Hash over binary fields", "setup": "None", "opening": "Hash-based scale", "verifier": "Polylogarithmic", "field": "Binary field towers" } ] } ], "options": [ { "type": "option", "name": "Groth16", "slug": "groth16", "section": { "id": "proof-systems", "number": "01", "title": "Choosing a proof system", "url": "https://zkpick.com/proof-systems/" }, "url": "https://zkpick.com/proof-systems/groth16/", "markdown": "https://zkpick.com/md/proof-systems/groth16.md", "category": "Pairing-based SNARK", "summary": "Groth16: Pairing-based SNARK. Setup: Circuit-specific. Proof size: 3 group elements: 128 B compressed, 256 B as EVM calldata. On-chain verification: Cheapest deployed option. PQ: No. Recursion: Via curve cycles; awkward. Maturity: Production since 2016. Prover cost profile: 256-bit-field MSMs and FFTs; roughly linear in constraints with a high constant. Mature GPU provers exist. Peak prover memory: Proving key resident in RAM, growing with circuit size — the usual browser and mobile limit. Off-chain verifier: Milliseconds: three pairings. Implementations and maintainers: snarkjs and rapidsnark (iden3), gnark (Consensys), arkworks, bellman (Zcash lineage), ICICLE GPU backends (Ingonyama). Where it is measured: Delendum zk-benchmarking; wrapper cost inside every zkVM benchmark on ethproofs.org. Choose it when: A stable circuit verified on-chain at high frequency where gas is the binding constraint. Also the standard final compression layer for STARK-based systems.", "description": "The 2016 pairing-based preprocessing SNARK over R1CS: the proof is three group elements verified with a single pairing product equation. Requires a per-circuit setup on top of a reusable universal phase one.", "notes": [], "sections": [], "strengths": [ "The smallest proofs and cheapest verifier of any widely deployed system", "The cheapest realistic on-chain verification on Ethereum", "Extremely well understood, with many independent implementations and a decade of scrutiny" ], "tradeoffs": [ "Circuit-specific trusted setup: any circuit change means a new ceremony, and toxic waste breaks soundness for that circuit permanently", "No universality — setup cannot be amortised across circuits", "Not post-quantum", "Proofs are re-randomisable, which breaks any application treating a proof as a unique object" ], "bestFit": "A stable circuit verified on-chain at high frequency where gas is the binding constraint. Also the standard final compression layer for STARK-based systems.", "maintainers": "Construction by Jens Groth (2016). Implementations: snarkjs and rapidsnark (iden3), gnark (Consensys), arkworks, bellman (Zcash lineage), ICICLE GPU backends (Ingonyama)", "maturity": "Production since 2016", "license": "n/a (construction)", "source": "https://eprint.iacr.org/2016/260", "facts": [ { "table": "Proof system selection matrix", "url": "https://zkpick.com/proof-systems/#proof-systems-matrix-groth16", "name": "Groth16", "setup": "Circuit-specific", "size": "3 group elements: 128 B compressed, 256 B as EVM calldata", "verify": "Cheapest deployed option", "pq": "No", "recursion": "Via curve cycles; awkward", "maturity": "Production since 2016" }, { "table": "Prover profile, implementations and benchmarks", "url": "https://zkpick.com/proof-systems/#proof-systems-matrix-2-groth16", "name": "Groth16", "prover": "256-bit-field MSMs and FFTs; roughly linear in constraints with a high constant. Mature GPU provers exist.", "memory": "Proving key resident in RAM, growing with circuit size — the usual browser and mobile limit", "offchain": "Milliseconds: three pairings", "impls": "snarkjs and rapidsnark (iden3), gnark (Consensys), arkworks, bellman (Zcash lineage), ICICLE GPU backends (Ingonyama)", "bench": "Delendum zk-benchmarking; wrapper cost inside every zkVM benchmark on ethproofs.org" } ], "relatedFailureModes": [], "sources": [ { "title": "Groth16 — On the size of pairing-based non-interactive arguments", "url": "https://eprint.iacr.org/2016/260", "kind": "paper" } ], "updated": "2026-09-12", "version": "1.3" }, { "type": "option", "name": "PLONK and the PLONKish family", "slug": "plonk", "section": { "id": "proof-systems", "number": "01", "title": "Choosing a proof system", "url": "https://zkpick.com/proof-systems/" }, "url": "https://zkpick.com/proof-systems/plonk/", "markdown": "https://zkpick.com/md/proof-systems/plonk.md", "category": "Pairing-based SNARK, universal SRS", "summary": "PLONK and the PLONKish family: Pairing-based SNARK, universal SRS. Setup: Universal, updatable. Proof size: Sub-kilobyte. On-chain verification: Practical; above Groth16. PQ: No. Recursion: Well-exercised. Maturity: Production; most common deployed family. Prover cost profile: 256-bit-field FFTs dominate; custom gates and lookups trade prover work for constraint count. Peak prover memory: SRS and witness polynomials resident; comparable to Groth16 at equal size. Off-chain verifier: Milliseconds. Implementations and maintainers: Barretenberg / UltraHonk (Aztec), gnark (Consensys), plonky2 (Polygon Zero lineage), Kimchi (o1Labs), Halo2 forks. Where it is measured: Vendor-published only; no neutral cross-implementation suite. Choose it when: General-purpose circuits where churn is expected and a per-circuit ceremony would be painful, and where on-chain verification is required but need not be absolutely minimal.", "description": "A permutation-argument-based universal SNARK over a custom-gate arithmetisation — selector columns, copy constraints, optional lookup columns. One SRS serves all circuits up to a size bound. The most frequently occurring family among deployed on-chain verifiers.", "notes": [], "sections": [], "strengths": [ "Universal, updatable SRS — one ceremony, many circuits, no per-circuit phase two", "Flexible arithmetisation: custom gates and lookups express non-arithmetic operations efficiently", "Verifier cost close to Groth16 and still practical on-chain", "Very large ecosystem with many independent implementations" ], "tradeoffs": [ "Larger proofs and higher gas than Groth16", "Not post-quantum", "Prover requires large-field FFTs, the main bottleneck at scale", "Arithmetisation flexibility is also a footgun — custom gates and lookup tables are a common source of underconstrained circuits", "'PLONK' names a family, not one artefact: two implementations may share little" ], "bestFit": "General-purpose circuits where churn is expected and a per-circuit ceremony would be painful, and where on-chain verification is required but need not be absolutely minimal.", "maintainers": "Construction by Gabizon, Williamson and Ciobotaru (Aztec, 2019). Implementations: Barretenberg / UltraHonk (Aztec), gnark (Consensys), plonky2 (Polygon Zero lineage), Kimchi (o1Labs), Halo2 forks", "maturity": "Production; most common deployed family", "license": "n/a (construction)", "source": "https://eprint.iacr.org/2019/953", "facts": [ { "table": "Proof system selection matrix", "url": "https://zkpick.com/proof-systems/#proof-systems-matrix-plonk-family", "name": "PLONK family", "setup": "Universal, updatable", "size": "Sub-kilobyte", "verify": "Practical; above Groth16", "pq": "No", "recursion": "Well-exercised", "maturity": "Production; most common deployed family" }, { "table": "Prover profile, implementations and benchmarks", "url": "https://zkpick.com/proof-systems/#proof-systems-matrix-2-plonk-family", "name": "PLONK family", "prover": "256-bit-field FFTs dominate; custom gates and lookups trade prover work for constraint count", "memory": "SRS and witness polynomials resident; comparable to Groth16 at equal size", "offchain": "Milliseconds", "impls": "Barretenberg / UltraHonk (Aztec), gnark (Consensys), plonky2 (Polygon Zero lineage), Kimchi (o1Labs), Halo2 forks", "bench": "Vendor-published only; no neutral cross-implementation suite" } ], "relatedFailureModes": [], "sources": [ { "title": "PLONK — permutations over Lagrange bases for oecumenical noninteractive arguments", "url": "https://eprint.iacr.org/2019/953", "kind": "paper" }, { "title": "fflonk — a fast-Fourier inspired verifier efficient variant of PLONK", "url": "https://eprint.iacr.org/2021/1167", "kind": "paper" }, { "title": "HyperPlonk — PLONK with linear-time prover and high-degree custom gates", "url": "https://eprint.iacr.org/2022/1355", "kind": "paper" }, { "title": "Plonky3 — polynomial IOP toolkit over small fields", "url": "https://github.com/Plonky3/Plonky3", "kind": "project" } ], "updated": "2026-09-12", "version": "1.3" }, { "type": "option", "name": "FRI-based STARKs", "slug": "starks", "section": { "id": "proof-systems", "number": "01", "title": "Choosing a proof system", "url": "https://zkpick.com/proof-systems/" }, "url": "https://zkpick.com/proof-systems/starks/", "markdown": "https://zkpick.com/md/proof-systems/starks.md", "category": "Transparent hash-based proof system", "summary": "FRI-based STARKs: Transparent hash-based proof system. Setup: None. Proof size: Tens to hundreds of KB. On-chain verification: Impractical directly — wrapper is standard. PQ: Plausibly. Recursion: Well-exercised. Maturity: Heavily production. Prover cost profile: Small-field hashing and NTTs; the fastest bulk provers on CPU and GPU, and the basis of most zkVMs. Peak prover memory: Trace-proportional, but small fields keep it low; continuations bound it. Off-chain verifier: Milliseconds to tens of milliseconds — hashing only. Implementations and maintainers: Stone and Stwo (StarkWare), Plonky3 (Polygon Zero lineage; beneath SP1 Turbo, OpenVM, Ziren, Pico), RISC Zero, Miden, ZKsync Airbender (Matter Labs), Winterfell. Where it is measured: ethproofs.org real-time Ethereum block proving; a16z zkvm-benchmarks. Assumption: Hash (collision resistance). Setup: None. Opening size: Polylogarithmic but large in absolute terms. Verifier cost: Polylogarithmic; expensive on-chain. Field constraint: High two-adicity; extension for challenges. Choose it when: High-throughput server-side proving of large computations, especially zkVM execution, where a final wrapper handles settlement.", "description": "AIR or PLONKish arithmetisation committed with Reed–Solomon codewords and Merkle trees, with FRI as the low-degree test. No trusted setup, hash-based, plausibly post-quantum. The workhorse of large-scale transparent proving: StarkWare's Stone and Stwo, the Plonky2 and Plonky3 toolkits, RISC Zero, Miden and ZKsync Airbender are all instances of this family, differing mainly in field, hash and lookup argument.", "notes": [], "sections": [], "strengths": [ "No trusted setup; security reduces to hash collision resistance plus the FRI soundness analysis", "Plausibly post-quantum in the proving layer", "Small-field arithmetic gives excellent CPU and GPU throughput; Circle STARK constructions extend this to fields that FRI could not otherwise use", "Scales well to very large computations" ], "tradeoffs": [ "Proofs are tens to hundreds of kilobytes and verifiers are expensive, so a pairing-based wrapper is standard — which reintroduces a trusted setup and removes post-quantum security", "Security parameters are a dial, and deployed systems routinely ship 96–100 bits rather than 128", "Requires a field with high two-adicity and enough size, or an extension, for challenges", "Parameter tuning across rate, queries, grinding and decoding regime is easy to get wrong" ], "bestFit": "High-throughput server-side proving of large computations, especially zkVM execution, where a final wrapper handles settlement.", "maintainers": "Construction by Ben-Sasson, Bentov, Horesh and Riabzev (StarkWare, 2018). Implementations: Stone and Stwo (StarkWare), Plonky2 and Plonky3 (Polygon Zero lineage), RISC Zero, Miden, ZKsync Airbender (Matter Labs), Winterfell", "maturity": "Heavily production", "license": "n/a (construction)", "source": "https://eprint.iacr.org/2018/046", "facts": [ { "table": "Proof system selection matrix", "url": "https://zkpick.com/proof-systems/#proof-systems-matrix-fri-based-starks", "name": "FRI-based STARKs", "setup": "None", "size": "Tens to hundreds of KB", "verify": "Impractical directly — wrapper is standard", "pq": "Plausibly", "recursion": "Well-exercised", "maturity": "Heavily production" }, { "table": "Prover profile, implementations and benchmarks", "url": "https://zkpick.com/proof-systems/#proof-systems-matrix-2-fri-based-starks", "name": "FRI-based STARKs", "prover": "Small-field hashing and NTTs; the fastest bulk provers on CPU and GPU, and the basis of most zkVMs", "memory": "Trace-proportional, but small fields keep it low; continuations bound it", "offchain": "Milliseconds to tens of milliseconds — hashing only", "impls": "Stone and Stwo (StarkWare), Plonky3 (Polygon Zero lineage; beneath SP1 Turbo, OpenVM, Ziren, Pico), RISC Zero, Miden, ZKsync Airbender (Matter Labs), Winterfell", "bench": "ethproofs.org real-time Ethereum block proving; a16z zkvm-benchmarks" }, { "table": "Commitment schemes — the layer that decides most of it", "url": "https://zkpick.com/proof-systems/#proof-systems-matrix-3-fri", "name": "FRI", "basis": "Hash (collision resistance)", "setup": "None", "opening": "Polylogarithmic but large in absolute terms", "verifier": "Polylogarithmic; expensive on-chain", "field": "High two-adicity; extension for challenges" } ], "relatedFailureModes": [], "sources": [ { "title": "Scalable, transparent, and post-quantum secure computational integrity (STARKs)", "url": "https://eprint.iacr.org/2018/046", "kind": "paper" }, { "title": "Circle STARKs — making Mersenne-31 usable for FRI-based systems", "url": "https://eprint.iacr.org/2024/278", "kind": "paper" } ], "updated": "2026-09-12", "version": "1.3" }, { "type": "option", "name": "Halo2 with IPA, and Halo2 with KZG", "slug": "halo2", "section": { "id": "proof-systems", "number": "01", "title": "Choosing a proof system", "url": "https://zkpick.com/proof-systems/" }, "url": "https://zkpick.com/proof-systems/halo2/", "markdown": "https://zkpick.com/md/proof-systems/halo2.md", "category": "PLONKish SNARK — two distinct trust models", "summary": "Halo2 with IPA, and Halo2 with KZG: PLONKish SNARK — two distinct trust models. As Halo2 + IPA — Setup: None. Proof size: Logarithmic. On-chain verification: Impractical — verifier linear in circuit size. PQ: No. Recursion: Native, via accumulation on a curve cycle. Maturity: Years in production; gadget-layer bug in 2026. As Halo2 + KZG — Setup: Universal, updatable. Proof size: Constant. On-chain verification: Practical. PQ: No. Recursion: Supported. Maturity: Production; central maintenance declining. As Halo2 + IPA — Prover cost profile: MSM-dominated over the Pasta curve cycle; no pairing-curve FFT bottleneck. Peak prover memory: Proportional to circuit size; moderate. Off-chain verifier: Linear in circuit size — tens to hundreds of milliseconds for large circuits. Implementations and maintainers: zcash/halo2 (Electric Coin Company). Where it is measured: Zcash Orchard figures; no neutral suite. As Halo2 + KZG — Prover cost profile: 256-bit-field FFTs over BN254; the largest gadget ecosystem of any PLONKish frontend. Peak prover memory: SRS resident; large circuits need tens of gigabytes. Off-chain verifier: Milliseconds. Implementations and maintainers: privacy-ethereum/halo2 (Ethereum Foundation PSE, maintenance mode), halo2-lib (Axiom), Scroll's fork. Where it is measured: Scroll and Axiom published figures; no neutral suite. Choose it when: IPA: systems verified on a node rather than in a gas-metered contract, where trusted setup is unacceptable. KZG: EVM-verified application circuits and coprocessors needing expressive custom gates.", "description": "The same PLONKish frontend with two very different backends. The original uses an inner-product argument over a curve cycle and needs no trusted setup, with recursion via accumulation. The widely used Ethereum-oriented variant replaces IPA with KZG, giving constant-size proofs and a practical Solidity verifier — and a universal trusted setup. These are routinely conflated.", "notes": [], "sections": [], "strengths": [ "The IPA variant needs no trusted setup and has years of deployment in a value-bearing system", "Recursion without pairing-friendly curves, via accumulation on a two-cycle", "The KZG variant gives constant-size proofs and EVM-practical verification", "Rich, expressive frontend with mature circuit libraries for elliptic-curve and hashing work" ], "tradeoffs": [ "IPA verification is linear in circuit size — that variant is not an EVM settlement candidate", "The KZG variant reintroduces a universal trusted setup, unlike the original — a frequent source of confusion", "Neither is post-quantum", "The ecosystem has fragmented into forks that are not drop-in compatible and have uneven maintenance", "Maturity of the construction does not transfer to its gadget libraries: a counterfeiting bug in the upstream ECC gadget prompted an emergency response in 2026 — check the current status of any deployment cited as evidence" ], "bestFit": "IPA: systems verified on a node rather than in a gas-metered contract, where trusted setup is unacceptable. KZG: EVM-verified application circuits and coprocessors needing expressive custom gates.", "maintainers": "Halo by Bowe, Grigg and Hopwood (Electric Coin Company, 2019); upstream halo2 maintained by Electric Coin Company. KZG fork by Ethereum Foundation PSE (maintenance mode); halo2-lib by Axiom; further forks at Scroll and others", "maturity": "Long production history; forks vary", "license": "n/a (construction)", "source": "https://eprint.iacr.org/2019/1021", "facts": [ { "table": "Proof system selection matrix", "url": "https://zkpick.com/proof-systems/#proof-systems-matrix-halo2-ipa", "name": "Halo2 + IPA", "setup": "None", "size": "Logarithmic", "verify": "Impractical — verifier linear in circuit size", "pq": "No", "recursion": "Native, via accumulation on a curve cycle", "maturity": "Years in production; gadget-layer bug in 2026" }, { "table": "Proof system selection matrix", "url": "https://zkpick.com/proof-systems/#proof-systems-matrix-halo2-kzg", "name": "Halo2 + KZG", "setup": "Universal, updatable", "size": "Constant", "verify": "Practical", "pq": "No", "recursion": "Supported", "maturity": "Production; central maintenance declining" }, { "table": "Prover profile, implementations and benchmarks", "url": "https://zkpick.com/proof-systems/#proof-systems-matrix-2-halo2-ipa", "name": "Halo2 + IPA", "prover": "MSM-dominated over the Pasta curve cycle; no pairing-curve FFT bottleneck", "memory": "Proportional to circuit size; moderate", "offchain": "Linear in circuit size — tens to hundreds of milliseconds for large circuits", "impls": "zcash/halo2 (Electric Coin Company)", "bench": "Zcash Orchard figures; no neutral suite" }, { "table": "Prover profile, implementations and benchmarks", "url": "https://zkpick.com/proof-systems/#proof-systems-matrix-2-halo2-kzg", "name": "Halo2 + KZG", "prover": "256-bit-field FFTs over BN254; the largest gadget ecosystem of any PLONKish frontend", "memory": "SRS resident; large circuits need tens of gigabytes", "offchain": "Milliseconds", "impls": "privacy-ethereum/halo2 (Ethereum Foundation PSE, maintenance mode), halo2-lib (Axiom), Scroll's fork", "bench": "Scroll and Axiom published figures; no neutral suite" } ], "relatedFailureModes": [], "sources": [ { "title": "Halo — recursive proof composition without a trusted setup", "url": "https://eprint.iacr.org/2019/1021", "kind": "paper" } ], "updated": "2026-09-12", "version": "1.3" }, { "type": "option", "name": "Nova, SuperNova and HyperNova", "slug": "nova-folding", "section": { "id": "proof-systems", "number": "01", "title": "Choosing a proof system", "url": "https://zkpick.com/proof-systems/" }, "url": "https://zkpick.com/proof-systems/nova-folding/", "markdown": "https://zkpick.com/md/proof-systems/nova-folding.md", "category": "Folding schemes / IVC", "summary": "Nova, SuperNova and HyperNova: Folding schemes / IVC. Setup: None in the folding layer. Proof size: Accumulator, not a proof — needs final compression. On-chain verification: Via the compressing SNARK only. PQ: No. Recursion: This is the whole point. Maturity: Research to early production. Prover cost profile: Two MSMs per step — the cheapest incremental step known. Peak prover memory: Bounded by one step plus the accumulator. Off-chain verifier: Only after final compression. Implementations and maintainers: Nova (Microsoft Research), Sonobe (Ethereum Foundation lineage), arecibo (Argument Computer). Where it is measured: Repository benchmarks only; no neutral suite. Choose it when: Long, repetitive computations and memory-constrained provers, where the final compression step happens once.", "description": "Folding reduces checking two instances of a relation to checking one, so each step of a long computation costs a couple of multi-scalar multiplications rather than an in-circuit SNARK verification. Variants add non-uniform steps and generalised constraint systems.", "notes": [], "sections": [], "strengths": [ "The lowest known per-step recursion overhead for long, near-uniform computations", "Memory-friendly: proving is incremental, so peak memory tracks one step rather than the whole trace", "No trusted setup in the folding layer itself", "Non-uniform variants avoid paying for the union of all instructions at every step" ], "tradeoffs": [ "Folding produces an accumulator, not a succinct proof — a final compressing SNARK is still required, and its cost is often omitted from benchmarks", "Not post-quantum: security rests on discrete log in the commitment scheme", "Real soundness pitfalls have been published in cycle-of-curves constructions — this is subtle territory", "Implementation maturity trails the pairing-based and FRI families" ], "bestFit": "Long, repetitive computations and memory-constrained provers, where the final compression step happens once.", "maintainers": "Nova by Kothapalli, Setty and Tzialla (Microsoft Research, 2021); SuperNova and HyperNova from the same lineage. Implementations: Nova (Microsoft Research), Sonobe (Ethereum Foundation lineage), arecibo (Argument Computer)", "maturity": "Research to early production", "license": "n/a (construction)", "source": "https://eprint.iacr.org/2021/370", "facts": [ { "table": "Proof system selection matrix", "url": "https://zkpick.com/proof-systems/#proof-systems-matrix-nova-folding-schemes", "name": "Nova / folding schemes", "setup": "None in the folding layer", "size": "Accumulator, not a proof — needs final compression", "verify": "Via the compressing SNARK only", "pq": "No", "recursion": "This is the whole point", "maturity": "Research to early production" }, { "table": "Prover profile, implementations and benchmarks", "url": "https://zkpick.com/proof-systems/#proof-systems-matrix-2-nova-folding-schemes", "name": "Nova / folding schemes", "prover": "Two MSMs per step — the cheapest incremental step known", "memory": "Bounded by one step plus the accumulator", "offchain": "Only after final compression", "impls": "Nova (Microsoft Research), Sonobe (Ethereum Foundation lineage), arecibo (Argument Computer)", "bench": "Repository benchmarks only; no neutral suite" } ], "relatedFailureModes": [], "sources": [ { "title": "Nova — recursive zero-knowledge arguments from folding schemes", "url": "https://eprint.iacr.org/2021/370", "kind": "paper" } ], "updated": "2026-09-12", "version": "1.3" }, { "type": "option", "name": "Binius and binary-field systems", "slug": "binius", "section": { "id": "proof-systems", "number": "01", "title": "Choosing a proof system", "url": "https://zkpick.com/proof-systems/" }, "url": "https://zkpick.com/proof-systems/binius/", "markdown": "https://zkpick.com/md/proof-systems/binius.md", "category": "Transparent hash-based, binary fields", "summary": "Binius and binary-field systems: Transparent hash-based, binary fields. Setup: None. Proof size: Hash-based scale. On-chain verification: Impractical directly. PQ: Plausibly. Recursion: Developing. Maturity: Early production; fast-moving codebase. Prover cost profile: Binary-field arithmetic maps to hardware bit operations; strongest on hashing and bitwise workloads. Peak prover memory: Low — tiny field elements, no embedding overhead. Off-chain verifier: Milliseconds. Implementations and maintainers: Binius64 (Irreducible); the original binius repository is archived. Where it is measured: Irreducible's published figures; few independent measurements. Assumption: Hash over binary fields. Setup: None. Opening size: Hash-based scale. Verifier cost: Polylogarithmic. Field constraint: Binary field towers. Choose it when: Hash- and bitwise-heavy workloads, and client-side proving, for teams able to track a fast-moving codebase.", "description": "SNARKs over towers of binary fields, with a commitment that has no embedding overhead for tiny field elements. The current generation computes natively over 64-bit words with built-in bitwise and multiplication constraints, explicitly targeting client-side proving on commodity CPUs.", "notes": [], "sections": [], "strengths": [ "Binary-field arithmetic maps directly to hardware bit operations — a strong fit for hashing, ciphers and bit manipulation", "No trusted setup; hash-based and plausibly post-quantum", "Explicitly targets commodity CPUs rather than GPU clusters" ], "tradeoffs": [ "The most volatile family here: the original implementation was archived and superseded, with significant features still on the roadmap at the successor's launch — confirm current capability before designing around it", "Small implementation and auditor base", "Not directly on-chain verifiable" ], "bestFit": "Hash- and bitwise-heavy workloads, and client-side proving, for teams able to track a fast-moving codebase.", "maintainers": "Diamond and Posen (Irreducible, formerly Ulvetanna, 2023). Implementation: Binius64 (Irreducible)", "maturity": "Early production; active development", "license": "n/a (construction)", "source": "https://eprint.iacr.org/2023/1784", "facts": [ { "table": "Proof system selection matrix", "url": "https://zkpick.com/proof-systems/#proof-systems-matrix-binius-binary-fields", "name": "Binius (binary fields)", "setup": "None", "size": "Hash-based scale", "verify": "Impractical directly", "pq": "Plausibly", "recursion": "Developing", "maturity": "Early production; fast-moving codebase" }, { "table": "Prover profile, implementations and benchmarks", "url": "https://zkpick.com/proof-systems/#proof-systems-matrix-2-binius-binary-fields", "name": "Binius (binary fields)", "prover": "Binary-field arithmetic maps to hardware bit operations; strongest on hashing and bitwise workloads", "memory": "Low — tiny field elements, no embedding overhead", "offchain": "Milliseconds", "impls": "Binius64 (Irreducible); the original binius repository is archived", "bench": "Irreducible's published figures; few independent measurements" }, { "table": "Commitment schemes — the layer that decides most of it", "url": "https://zkpick.com/proof-systems/#proof-systems-matrix-3-binius-commitments", "name": "Binius commitments", "basis": "Hash over binary fields", "setup": "None", "opening": "Hash-based scale", "verifier": "Polylogarithmic", "field": "Binary field towers" } ], "relatedFailureModes": [], "sources": [ { "title": "Binius — succinct arguments over towers of binary fields", "url": "https://eprint.iacr.org/2023/1784", "kind": "paper" } ], "updated": "2026-09-12", "version": "1.3" }, { "type": "option", "name": "STIR and WHIR", "slug": "stir-whir", "section": { "id": "proof-systems", "number": "01", "title": "Choosing a proof system", "url": "https://zkpick.com/proof-systems/" }, "url": "https://zkpick.com/proof-systems/stir-whir/", "markdown": "https://zkpick.com/md/proof-systems/stir-whir.md", "category": "Hash-based low-degree tests", "summary": "STIR and WHIR: Hash-based low-degree tests. Setup: None. Proof size: Markedly smaller than FRI at equal security. On-chain verification: Impractical directly. PQ: Plausibly. Recursion: Inherits FRI approaches. Maturity: Research maturing into implementation. Prover cost profile: Comparable to FRI; the WHIR prover is somewhat heavier. Peak prover memory: As FRI. Off-chain verifier: Sub-millisecond for WHIR in the authors' reported settings. Implementations and maintainers: Reference implementations by the authors; integrations into production hash-based stacks under way. Where it is measured: Authors' comparisons only; measure on your own parameters. Choose it when: Replacing FRI where hash-based proof size or verifier latency is the binding constraint, for teams who will follow the literature.", "description": "Two successors to FRI from the same research lineage. STIR reduces query complexity by recursively improving the rate of the tested code; WHIR builds on constrained Reed–Solomon codes to give very fast verification, and doubles as a polynomial commitment.", "notes": [], "sections": [], "strengths": [ "Concretely smaller proofs than FRI at equal security — roughly half, in the authors' reported comparisons", "WHIR verification is reported in hundreds of microseconds where prior hash-based verifiers took milliseconds", "Public reference implementations exist and integration into production stacks is under way" ], "tradeoffs": [ "Newer analyses and fewer independent implementations than FRI", "The most aggressive parameterisation relied on an up-to-capacity conjecture disproved for large fields in late 2025; Johnson-bound parameters are unaffected but the optimistic discount is not available as originally stated", "Requires a team able to track fresh cryptanalysis" ], "bestFit": "Replacing FRI where hash-based proof size or verifier latency is the binding constraint, for teams who will follow the literature.", "maintainers": "Arnon, Chiesa, Fenzi and Yogev (2024). Reference implementations by the authors; integrations at several hash-based zkVM teams", "maturity": "Research maturing into implementation", "license": "n/a (construction)", "source": "https://eprint.iacr.org/2024/1586", "facts": [ { "table": "Proof system selection matrix", "url": "https://zkpick.com/proof-systems/#proof-systems-matrix-stir-whir", "name": "STIR / WHIR", "setup": "None", "size": "Markedly smaller than FRI at equal security", "verify": "Impractical directly", "pq": "Plausibly", "recursion": "Inherits FRI approaches", "maturity": "Research maturing into implementation" }, { "table": "Prover profile, implementations and benchmarks", "url": "https://zkpick.com/proof-systems/#proof-systems-matrix-2-stir-whir", "name": "STIR / WHIR", "prover": "Comparable to FRI; the WHIR prover is somewhat heavier", "memory": "As FRI", "offchain": "Sub-millisecond for WHIR in the authors' reported settings", "impls": "Reference implementations by the authors; integrations into production hash-based stacks under way", "bench": "Authors' comparisons only; measure on your own parameters" } ], "relatedFailureModes": [], "sources": [ { "title": "STIR — Reed–Solomon proximity testing with fewer queries", "url": "https://eprint.iacr.org/2024/390", "kind": "paper" }, { "title": "WHIR — Reed–Solomon proximity testing with super-fast verification", "url": "https://eprint.iacr.org/2024/1586", "kind": "paper" } ], "updated": "2026-09-12", "version": "1.3" }, { "type": "option", "name": "GKR-based systems", "slug": "gkr", "section": { "id": "proof-systems", "number": "01", "title": "Choosing a proof system", "url": "https://zkpick.com/proof-systems/" }, "url": "https://zkpick.com/proof-systems/gkr/", "markdown": "https://zkpick.com/md/proof-systems/gkr.md", "category": "Sumcheck / interactive proofs", "summary": "GKR-based systems: Sumcheck / interactive proofs. Setup: None (commitment-dependent). Proof size: Grows with circuit depth. On-chain verification: Wrapper needed. PQ: Commitment-dependent. Recursion: Developing. Maturity: Production via at least one major zkVM. Prover cost profile: Linear-time; commits only to the input layer. Peak prover memory: Low relative to trace size. Off-chain verifier: Grows with circuit depth. Implementations and maintainers: Expander (Polyhedra), Ceno (Scroll), SP1 Hypercube's sumcheck design (Succinct). Where it is measured: ethproofs.org for the zkVMs built on it; Polyhedra's published figures. Choose it when: Wide, shallow, highly parallel workloads — bulk hashing, signature aggregation, inference — and zkVMs using a multilinear arithmetisation.", "description": "The GKR protocol proves layered-circuit evaluation using sumcheck, with prover time linear in circuit size. Modern systems combine it with an error-correcting-code commitment, or use GKR to run the lookup argument itself.", "notes": [], "sections": [], "strengths": [ "Linear-time prover with very low commitment cost — GKR commits only to the input layer, not every intermediate wire", "Extremely high throughput on parallel hardware for wide, uniform workloads", "Now production-proven via at least one major zkVM" ], "tradeoffs": [ "Requires the computation to be expressed as a layered circuit or sumcheck-friendly relation; irregular computation is awkward", "Proof size and verifier cost grow with circuit depth — deep circuits are the failure mode", "Not EVM-cheap; a wrapper is still needed for settlement", "Fewer mature general-purpose frontends" ], "bestFit": "Wide, shallow, highly parallel workloads — bulk hashing, signature aggregation, inference — and zkVMs using a multilinear arithmetisation.", "maintainers": "Goldwasser, Kalai and Rothblum (2008); linear-time prover by Xie et al. (Libra, 2019). Implementations: Expander (Polyhedra), Ceno (Scroll), sumcheck-based zkVM designs at Succinct", "maturity": "Production as of 2026", "license": "n/a (construction)", "source": "https://eprint.iacr.org/2019/317", "facts": [ { "table": "Proof system selection matrix", "url": "https://zkpick.com/proof-systems/#proof-systems-matrix-gkr-sumcheck-systems", "name": "GKR / sumcheck systems", "setup": "None (commitment-dependent)", "size": "Grows with circuit depth", "verify": "Wrapper needed", "pq": "Commitment-dependent", "recursion": "Developing", "maturity": "Production via at least one major zkVM" }, { "table": "Prover profile, implementations and benchmarks", "url": "https://zkpick.com/proof-systems/#proof-systems-matrix-2-gkr-sumcheck-systems", "name": "GKR / sumcheck systems", "prover": "Linear-time; commits only to the input layer", "memory": "Low relative to trace size", "offchain": "Grows with circuit depth", "impls": "Expander (Polyhedra), Ceno (Scroll), SP1 Hypercube's sumcheck design (Succinct)", "bench": "ethproofs.org for the zkVMs built on it; Polyhedra's published figures" } ], "relatedFailureModes": [], "sources": [ { "title": "Libra — succinct zero-knowledge proofs with optimal prover computation (GKR)", "url": "https://eprint.iacr.org/2019/317", "kind": "paper" } ], "updated": "2026-09-12", "version": "1.3" }, { "type": "option", "name": "Spartan", "slug": "spartan", "section": { "id": "proof-systems", "number": "01", "title": "Choosing a proof system", "url": "https://zkpick.com/proof-systems/" }, "url": "https://zkpick.com/proof-systems/spartan/", "markdown": "https://zkpick.com/md/proof-systems/spartan.md", "category": "Transparent SNARK for R1CS", "summary": "Spartan: Transparent SNARK for R1CS. Setup: None (commitment-dependent). Proof size: Depends on commitment. On-chain verification: Not a settlement candidate alone. PQ: Commitment-dependent. Recursion: Used inside larger systems. Maturity: Established construction, widely built upon. Prover cost profile: Sumcheck over sparse R1CS; no FFT; linear in non-zero constraint entries. Peak prover memory: Low and streaming-friendly. Off-chain verifier: Sublinear after preprocessing; commitment-dependent. Implementations and maintainers: Spartan (Microsoft Research), inside Jolt (a16z crypto) and Nexus. Where it is measured: Only inside zkVM benchmarks. Choose it when: An intermediate proof layer, or the theoretical core of a zkVM — particularly when you want to change commitment schemes without changing arithmetisation.", "description": "A transparent SNARK for R1CS built on sumcheck and a multilinear commitment, with sublinear verification after preprocessing and no FFTs. Its distinguishing property is that the commitment scheme is swappable.", "notes": [], "sections": [], "strengths": [ "No trusted setup, and the commitment is swappable — so post-quantum posture becomes a separate, independent choice", "No FFT in the prover; costs are linear in the number of constraint entries", "The sumcheck structure has become the foundation for much newer work" ], "tradeoffs": [ "Proof size and verifier cost are worse than pairing-based SNARKs; not an EVM settlement candidate alone", "Concrete performance depends almost entirely on the chosen commitment, so 'Spartan is fast' is not a meaningful statement unqualified", "The reference implementation is a research artefact rather than a maintained product" ], "bestFit": "An intermediate proof layer, or the theoretical core of a zkVM — particularly when you want to change commitment schemes without changing arithmetisation.", "maintainers": "Srinath Setty (Microsoft Research, 2019). Implementations: Spartan (Microsoft Research), inside Jolt (a16z crypto) and Nexus", "maturity": "Established construction, heavily built upon", "license": "n/a (construction)", "source": "https://eprint.iacr.org/2019/550", "facts": [ { "table": "Proof system selection matrix", "url": "https://zkpick.com/proof-systems/#proof-systems-matrix-spartan", "name": "Spartan", "setup": "None (commitment-dependent)", "size": "Depends on commitment", "verify": "Not a settlement candidate alone", "pq": "Commitment-dependent", "recursion": "Used inside larger systems", "maturity": "Established construction, widely built upon" }, { "table": "Prover profile, implementations and benchmarks", "url": "https://zkpick.com/proof-systems/#proof-systems-matrix-2-spartan", "name": "Spartan", "prover": "Sumcheck over sparse R1CS; no FFT; linear in non-zero constraint entries", "memory": "Low and streaming-friendly", "offchain": "Sublinear after preprocessing; commitment-dependent", "impls": "Spartan (Microsoft Research), inside Jolt (a16z crypto) and Nexus", "bench": "Only inside zkVM benchmarks" } ], "relatedFailureModes": [], "sources": [ { "title": "Spartan — efficient and general-purpose zkSNARKs without trusted setup", "url": "https://eprint.iacr.org/2019/550", "kind": "paper" } ], "updated": "2026-09-12", "version": "1.3" }, { "type": "option", "name": "Bulletproofs", "slug": "bulletproofs", "section": { "id": "proof-systems", "number": "01", "title": "Choosing a proof system", "url": "https://zkpick.com/proof-systems/" }, "url": "https://zkpick.com/proof-systems/bulletproofs/", "markdown": "https://zkpick.com/md/proof-systems/bulletproofs.md", "category": "Transparent discrete-log argument", "summary": "Bulletproofs: Transparent discrete-log argument. Setup: None. Proof size: Logarithmic; small for ranges. On-chain verification: Linear in circuit size — not succinct. PQ: No. Recursion: Poor. Maturity: Production for range proofs since 2018. Prover cost profile: Linear MSMs; slow for general circuits. Peak prover memory: Low. Off-chain verifier: Linear in circuit size; batchable. Implementations and maintainers: dalek bulletproofs (Rust), Monero, Bulletproofs+ in several wallets. Where it is measured: Range-proof figures in Monero and dalek benchmarks. Choose it when: Range proofs and small confidential-transaction statements verified by full nodes.", "description": "Logarithmic-size zero-knowledge arguments from the inner-product argument, with no trusted setup. Best known for range proofs in confidential transactions; general circuits are supported but not the strength.", "notes": [], "sections": [], "strengths": [ "No trusted setup and only the discrete-log assumption", "Very small proofs for range statements, with cheap aggregation of many range proofs", "Batch verification gives real speedups across many proofs", "Long production track record in confidential-transaction systems" ], "tradeoffs": [ "Verification is linear in circuit size — no succinct verifier, so unsuitable for on-chain verification of large statements", "Not post-quantum", "General-circuit performance is poor relative to modern SNARKs; the sweet spot is narrow" ], "bestFit": "Range proofs and small confidential-transaction statements verified by full nodes.", "maintainers": "Bünz, Bootle, Boneh, Poelstra, Wuille and Maxwell (Stanford and Blockstream, 2017). Implementations: dalek bulletproofs (Rust), Monero's Bulletproofs+, several confidential-asset wallets", "maturity": "Production since 2018 in its niche", "license": "n/a (construction)", "source": "https://eprint.iacr.org/2017/1066", "facts": [ { "table": "Proof system selection matrix", "url": "https://zkpick.com/proof-systems/#proof-systems-matrix-bulletproofs", "name": "Bulletproofs", "setup": "None", "size": "Logarithmic; small for ranges", "verify": "Linear in circuit size — not succinct", "pq": "No", "recursion": "Poor", "maturity": "Production for range proofs since 2018" }, { "table": "Prover profile, implementations and benchmarks", "url": "https://zkpick.com/proof-systems/#proof-systems-matrix-2-bulletproofs", "name": "Bulletproofs", "prover": "Linear MSMs; slow for general circuits", "memory": "Low", "offchain": "Linear in circuit size; batchable", "impls": "dalek bulletproofs (Rust), Monero, Bulletproofs+ in several wallets", "bench": "Range-proof figures in Monero and dalek benchmarks" } ], "relatedFailureModes": [], "sources": [ { "title": "Bulletproofs — short proofs for confidential transactions and more", "url": "https://eprint.iacr.org/2017/1066", "kind": "paper" } ], "updated": "2026-09-12", "version": "1.3" }, { "type": "option", "name": "Lookup arguments: Plookup, LogUp, cq, Lasso/Shout/Twist", "slug": "lookup-arguments", "section": { "id": "proof-systems", "number": "01", "title": "Choosing a proof system", "url": "https://zkpick.com/proof-systems/" }, "url": "https://zkpick.com/proof-systems/lookup-arguments/", "markdown": "https://zkpick.com/md/proof-systems/lookup-arguments.md", "category": "Cross-cutting — often the real cost driver", "summary": "Lookup arguments: Plookup, LogUp, cq, Lasso/Shout/Twist: Cross-cutting — often the real cost driver. Lookup arguments prove that values appear in a table, and are how systems express operations that are expensive as raw arithmetic. Maturity: Plookup and LogUp production; structure-exploiting variants research-stage. Maintained by: Plookup: Gabizon and Williamson (Aztec). LogUp: Haböck (Polygon). cq: Eagen, Fiore and Gabizon. Lasso, Twist and Shout: Setty, Thaler and collaborators (a16z crypto). Choose it when: Evaluate the lookup argument explicitly whenever range checks, bitwise operations or instruction decoding dominate your constraint count.", "description": "Lookup arguments prove that values appear in a table, and are how systems express operations that are expensive as raw arithmetic. Plookup is the original and ubiquitous; LogUp uses logarithmic derivatives and is substantially cheaper for wide multi-column lookups; cq makes prover cost independent of table size after preprocessing; Lasso and its successors exploit table structure so huge tables need never be materialised.", "notes": [], "sections": [], "strengths": [ "Frequently determines prover time more than the choice of headline proof system does", "LogUp and its GKR variant dominate modern small-field designs", "Structure-exploiting arguments make instruction-set-sized tables tractable at all" ], "tradeoffs": [ "Plookup scales poorly with large tables and multi-column lookups", "cq requires a KZG SRS and amortised preprocessing — poor fit for changing tables", "Structure-exploiting schemes are tied to sumcheck arithmetisations, need decomposable tables to deliver their headline benefits, and their reference implementation is self-declared alpha", "Multiplicity handling is a known correctness trap: an unconstrained multiplicity column silently breaks soundness" ], "bestFit": "Evaluate the lookup argument explicitly whenever range checks, bitwise operations or instruction decoding dominate your constraint count.", "maintainers": "Plookup: Gabizon and Williamson (Aztec). LogUp: Haböck (Polygon). cq: Eagen, Fiore and Gabizon. Lasso, Twist and Shout: Setty, Thaler and collaborators (a16z crypto)", "maturity": "Plookup and LogUp production; structure-exploiting variants research-stage", "license": "n/a (constructions)", "source": "https://eprint.iacr.org/2022/1530", "facts": [], "relatedFailureModes": [ { "name": "Letting the lookup argument be an afterthought", "url": "https://zkpick.com/proof-systems/failure-modes/letting-the-lookup-argument-be-an-afterthought/" } ], "sources": [ { "title": "Plookup — a simplified polynomial protocol for lookup tables", "url": "https://eprint.iacr.org/2020/315", "kind": "paper" }, { "title": "Multivariate lookups based on logarithmic derivatives (LogUp)", "url": "https://eprint.iacr.org/2022/1530", "kind": "paper" }, { "title": "cq — cached quotients for fast lookups", "url": "https://eprint.iacr.org/2022/1763", "kind": "paper" } ], "updated": "2026-09-12", "version": "1.3" } ], "process": [ { "title": "Write down the verification environment as a number", "detail": "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." }, { "title": "Classify the statement by operation mix", "detail": "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." }, { "title": "Decide the setup posture deliberately", "detail": "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." }, { "title": "Choose the commitment scheme, then the protocol", "detail": "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." }, { "title": "Design the recursion and wrapping strategy now, not later", "detail": "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." }, { "title": "Write the security parameter statement", "detail": "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." }, { "title": "Prototype the dominant cost, at the shipping parameters", "detail": "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." }, { "title": "Record the decision, its assumptions and its expiry conditions", "detail": "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." } ], "failureModes": [ { "type": "failure-mode", "name": "Comparing protocol names instead of commitment schemes", "slug": "comparing-protocol-names-instead-of-commitment-schemes", "section": { "id": "proof-systems", "number": "01", "title": "Choosing a proof system", "url": "https://zkpick.com/proof-systems/" }, "url": "https://zkpick.com/proof-systems/failure-modes/comparing-protocol-names-instead-of-commitment-schemes/", "markdown": "https://zkpick.com/md/proof-systems/failure-modes/comparing-protocol-names-instead-of-commitment-schemes.md", "detail": "Two systems are compared by their headline names when the properties being compared — proof size, verifier cost, post-quantum posture — are set by the commitment layer beneath. The comparison produces a confident conclusion about the wrong variable.", "mitigation": "Identify the commitment scheme and field for each candidate first, and compare those. Two systems sharing a commitment resemble each other far more than two sharing a protocol name.", "relatedOptions": [], "updated": "2026-09-12", "version": "1.3" }, { "type": "failure-mode", "name": "Treating a quoted security level as comparable", "slug": "treating-a-quoted-security-level-as-comparable", "section": { "id": "proof-systems", "number": "01", "title": "Choosing a proof system", "url": "https://zkpick.com/proof-systems/" }, "url": "https://zkpick.com/proof-systems/failure-modes/treating-a-quoted-security-level-as-comparable/", "markdown": "https://zkpick.com/md/proof-systems/failure-modes/treating-a-quoted-security-level-as-comparable.md", "detail": "Benchmarks are compared across systems configured at different security levels. Hash-based systems in particular ship at 96–100 bits in production far more often than teams assume, and a proof size quoted at 96 bits is not comparable to one quoted at 128.", "mitigation": "Require a full written parameter statement with every benchmark, and normalise to a common target before comparing. Treat any bit count without its derivation as unverified.", "relatedOptions": [], "updated": "2026-09-12", "version": "1.3" }, { "type": "failure-mode", "name": "Relying on a conjecture without knowing you are", "slug": "relying-on-a-conjecture-without-knowing-you-are", "section": { "id": "proof-systems", "number": "01", "title": "Choosing a proof system", "url": "https://zkpick.com/proof-systems/" }, "url": "https://zkpick.com/proof-systems/failure-modes/relying-on-a-conjecture-without-knowing-you-are/", "markdown": "https://zkpick.com/md/proof-systems/failure-modes/relying-on-a-conjecture-without-knowing-you-are.md", "detail": "Aggressive hash-based parameters are adopted from a benchmark or a default configuration that quietly assumed a soundness conjecture, and nobody records which conjecture. Conjectures do fall: the up-to-capacity proximity-gap conjectures were disproved in late 2025, and although the counterexamples do not reach the small fields deployed systems use, the corrected conjecture is not free. A team that never wrote down what it was assuming cannot tell whether an event like that touches them.", "mitigation": "State explicitly whether your parameters are provable or conjectural, and set a review trigger tied to the relevant literature. Prefer provable-regime parameters where the performance cost is affordable.", "relatedOptions": [], "updated": "2026-09-12", "version": "1.3" }, { "type": "failure-mode", "name": "Announcing 'no trusted setup' while shipping a wrapper", "slug": "announcing-no-trusted-setup-while-shipping-a-wrapper", "section": { "id": "proof-systems", "number": "01", "title": "Choosing a proof system", "url": "https://zkpick.com/proof-systems/" }, "url": "https://zkpick.com/proof-systems/failure-modes/announcing-no-trusted-setup-while-shipping-a-wrapper/", "markdown": "https://zkpick.com/md/proof-systems/failure-modes/announcing-no-trusted-setup-while-shipping-a-wrapper.md", "detail": "A transparent system is chosen for exactly that property and then wrapped in a pairing-based SNARK to make settlement affordable. The deployed system depends on a trusted setup and forfeits post-quantum soundness, but the public claim is never updated.", "mitigation": "Describe the assumption at the boundary the verifier actually sits on. If a wrapper is used, its setup and its parameters are yours to justify — see §04.", "relatedOptions": [], "updated": "2026-09-12", "version": "1.3" }, { "type": "failure-mode", "name": "Ignoring proof malleability in application logic", "slug": "ignoring-proof-malleability-in-application-logic", "section": { "id": "proof-systems", "number": "01", "title": "Choosing a proof system", "url": "https://zkpick.com/proof-systems/" }, "url": "https://zkpick.com/proof-systems/failure-modes/ignoring-proof-malleability-in-application-logic/", "markdown": "https://zkpick.com/md/proof-systems/failure-modes/ignoring-proof-malleability-in-application-logic.md", "detail": "The application treats a proof or its hash as a unique identifier for deduplication, nonces or replay protection. Several deployed systems produce re-randomisable proofs, so a second valid proof of the same statement is trivially obtainable.", "mitigation": "Never derive uniqueness from proof bytes. Bind it to constrained in-circuit values such as nullifiers, and canonicalise encodings on deserialisation.", "relatedOptions": [], "updated": "2026-09-12", "version": "1.3" }, { "type": "failure-mode", "name": "Choosing on prover time and discovering the memory wall", "slug": "choosing-on-prover-time-and-discovering-the-memory-wall", "section": { "id": "proof-systems", "number": "01", "title": "Choosing a proof system", "url": "https://zkpick.com/proof-systems/" }, "url": "https://zkpick.com/proof-systems/failure-modes/choosing-on-prover-time-and-discovering-the-memory-wall/", "markdown": "https://zkpick.com/md/proof-systems/failure-modes/choosing-on-prover-time-and-discovering-the-memory-wall.md", "detail": "Selection is driven by wall-clock benchmarks, and the system then cannot run in the target environment at all because peak resident memory exceeds what a browser, phone or affordable instance provides.", "mitigation": "Measure peak memory on the actual target device early, and check whether the system supports streaming, chunked or continuation-based proving before committing.", "relatedOptions": [], "updated": "2026-09-12", "version": "1.3" }, { "type": "failure-mode", "name": "Buying post-quantum security you do not have", "slug": "buying-post-quantum-security-you-do-not-have", "section": { "id": "proof-systems", "number": "01", "title": "Choosing a proof system", "url": "https://zkpick.com/proof-systems/" }, "url": "https://zkpick.com/proof-systems/failure-modes/buying-post-quantum-security-you-do-not-have/", "markdown": "https://zkpick.com/md/proof-systems/failure-modes/buying-post-quantum-security-you-do-not-have.md", "detail": "A hash-based system is chosen for post-quantum posture, but the deployed system wraps into a pairing SNARK, or the zero-knowledge property is only computational, or the surrounding signatures and key exchange remain classical. The property does not compose the way the decision assumed.", "mitigation": "Separate soundness from confidentiality and check each end to end. If a long-lived secret is hidden, the hiding property must itself be statistical or post-quantum — a hash-based proof system does not supply that by itself.", "relatedOptions": [], "updated": "2026-09-12", "version": "1.3" }, { "type": "failure-mode", "name": "Adopting a construction ahead of its implementations", "slug": "adopting-a-construction-ahead-of-its-implementations", "section": { "id": "proof-systems", "number": "01", "title": "Choosing a proof system", "url": "https://zkpick.com/proof-systems/" }, "url": "https://zkpick.com/proof-systems/failure-modes/adopting-a-construction-ahead-of-its-implementations/", "markdown": "https://zkpick.com/md/proof-systems/failure-modes/adopting-a-construction-ahead-of-its-implementations.md", "detail": "A recent construction with excellent published numbers is selected, but has one implementation, no independent verifier, thin audit coverage, and a codebase that has already been archived and superseded once.", "mitigation": "Weight an independent second implementation of the verifier heavily — it is the strongest available maturity signal. Match construction novelty to your team's ability to own cryptographic risk.", "relatedOptions": [], "updated": "2026-09-12", "version": "1.3" }, { "type": "failure-mode", "name": "Underestimating the recursion threshold", "slug": "underestimating-the-recursion-threshold", "section": { "id": "proof-systems", "number": "01", "title": "Choosing a proof system", "url": "https://zkpick.com/proof-systems/" }, "url": "https://zkpick.com/proof-systems/failure-modes/underestimating-the-recursion-threshold/", "markdown": "https://zkpick.com/md/proof-systems/failure-modes/underestimating-the-recursion-threshold.md", "detail": "Recursion is assumed to be available, then the in-circuit verifier turns out to be large enough that the minimum useful step size exceeds the actual workload — so recursion costs more than it saves.", "mitigation": "Get the concrete size of the in-circuit verifier circuit before designing around recursion, and check whether it requires non-native field arithmetic, which typically dominates.", "relatedOptions": [], "updated": "2026-09-12", "version": "1.3" }, { "type": "failure-mode", "name": "Letting the lookup argument be an afterthought", "slug": "letting-the-lookup-argument-be-an-afterthought", "section": { "id": "proof-systems", "number": "01", "title": "Choosing a proof system", "url": "https://zkpick.com/proof-systems/" }, "url": "https://zkpick.com/proof-systems/failure-modes/letting-the-lookup-argument-be-an-afterthought/", "markdown": "https://zkpick.com/md/proof-systems/failure-modes/letting-the-lookup-argument-be-an-afterthought.md", "detail": "Enormous effort goes into choosing between proof systems while the lookup argument — which dominates prover time for range checks, bitwise operations and instruction decoding — is inherited from whatever the library defaulted to.", "mitigation": "Count lookups explicitly and evaluate the lookup argument as a first-class decision. Constrain multiplicity columns carefully: an unconstrained multiplicity silently breaks soundness.", "relatedOptions": [ { "name": "Lookup arguments: Plookup, LogUp, cq, Lasso/Shout/Twist", "url": "https://zkpick.com/proof-systems/lookup-arguments/" } ], "updated": "2026-09-12", "version": "1.3" } ], "crossReferences": [ { "section": "frameworks", "note": "Then pick a framework that targets it (§02)", "url": "https://zkpick.com/frameworks/" }, { "section": "ceremony", "note": "This decides whether you need a ceremony (§04)", "url": "https://zkpick.com/ceremony/" }, { "section": "audit", "note": "Novel or modified systems need crypto review (§03)", "url": "https://zkpick.com/audit/" } ], "sources": [ { "title": "Groth16 — On the size of pairing-based non-interactive arguments", "url": "https://eprint.iacr.org/2016/260", "kind": "paper" }, { "title": "PLONK — permutations over Lagrange bases for oecumenical noninteractive arguments", "url": "https://eprint.iacr.org/2019/953", "kind": "paper" }, { "title": "fflonk — a fast-Fourier inspired verifier efficient variant of PLONK", "url": "https://eprint.iacr.org/2021/1167", "kind": "paper" }, { "title": "Marlin — preprocessing zkSNARKs with universal and updatable SRS", "url": "https://eprint.iacr.org/2019/1047", "kind": "paper" }, { "title": "Halo — recursive proof composition without a trusted setup", "url": "https://eprint.iacr.org/2019/1021", "kind": "paper" }, { "title": "Nova — recursive zero-knowledge arguments from folding schemes", "url": "https://eprint.iacr.org/2021/370", "kind": "paper" }, { "title": "Spartan — efficient and general-purpose zkSNARKs without trusted setup", "url": "https://eprint.iacr.org/2019/550", "kind": "paper" }, { "title": "Bulletproofs — short proofs for confidential transactions and more", "url": "https://eprint.iacr.org/2017/1066", "kind": "paper" }, { "title": "Scalable, transparent, and post-quantum secure computational integrity (STARKs)", "url": "https://eprint.iacr.org/2018/046", "kind": "paper" }, { "title": "Proximity gaps for Reed–Solomon codes", "url": "https://eprint.iacr.org/2020/654", "kind": "paper" }, { "title": "Circle STARKs — making Mersenne-31 usable for FRI-based systems", "url": "https://eprint.iacr.org/2024/278", "kind": "paper" }, { "title": "ethSTARK documentation — concrete soundness parameters", "url": "https://eprint.iacr.org/2021/582", "kind": "paper" }, { "title": "Binius — succinct arguments over towers of binary fields", "url": "https://eprint.iacr.org/2023/1784", "kind": "paper" }, { "title": "Basefold — field-agnostic multilinear polynomial commitment", "url": "https://eprint.iacr.org/2023/1705", "kind": "paper" }, { "title": "Brakedown — linear-time and field-agnostic SNARKs for R1CS", "url": "https://eprint.iacr.org/2021/1043", "kind": "paper" }, { "title": "STIR — Reed–Solomon proximity testing with fewer queries", "url": "https://eprint.iacr.org/2024/390", "kind": "paper" }, { "title": "WHIR — Reed–Solomon proximity testing with super-fast verification", "url": "https://eprint.iacr.org/2024/1586", "kind": "paper" }, { "title": "Libra — succinct zero-knowledge proofs with optimal prover computation (GKR)", "url": "https://eprint.iacr.org/2019/317", "kind": "paper" }, { "title": "HyperPlonk — PLONK with linear-time prover and high-degree custom gates", "url": "https://eprint.iacr.org/2022/1355", "kind": "paper" }, { "title": "Signatures of correct computation (PST) — the original multilinear KZG commitment", "url": "https://eprint.iacr.org/2011/587", "kind": "paper" }, { "title": "Zeromorph — multilinear evaluation proofs from univariate KZG", "url": "https://eprint.iacr.org/2023/917", "kind": "paper" }, { "title": "Hyrax — doubly-efficient zkSNARKs without trusted setup (square-root Pedersen commitment)", "url": "https://eprint.iacr.org/2017/1132", "kind": "paper" }, { "title": "Dory — transparent logarithmic-size arguments for inner products and polynomial commitments", "url": "https://eprint.iacr.org/2020/1274", "kind": "paper" }, { "title": "LatticeFold+ — post-quantum folding from lattices", "url": "https://eprint.iacr.org/2025/247", "kind": "paper" }, { "title": "Plookup — a simplified polynomial protocol for lookup tables", "url": "https://eprint.iacr.org/2020/315", "kind": "paper" }, { "title": "Multivariate lookups based on logarithmic derivatives (LogUp)", "url": "https://eprint.iacr.org/2022/1530", "kind": "paper" }, { "title": "cq — cached quotients for fast lookups", "url": "https://eprint.iacr.org/2022/1763", "kind": "paper" }, { "title": "Twist and Shout — memory checking arguments for zkVMs", "url": "https://eprint.iacr.org/2025/105", "kind": "paper" }, { "title": "SoK: Trusted setups for powers-of-tau strings", "url": "https://eprint.iacr.org/2025/064", "kind": "paper" }, { "title": "EIP-1108 — reduced gas cost for alt_bn128 precompiles", "url": "https://eips.ethereum.org/EIPS/eip-1108", "kind": "spec" }, { "title": "EIP-2537 — BLS12-381 curve operations precompile", "url": "https://eips.ethereum.org/EIPS/eip-2537", "kind": "spec" }, { "title": "EIP-4844 — shard blob transactions and the KZG commitment scheme", "url": "https://eips.ethereum.org/EIPS/eip-4844", "kind": "spec" }, { "title": "soundcalc — soundness parameter calculator for hash-based systems", "url": "https://github.com/ethereum/soundcalc", "kind": "tool" }, { "title": "L2BEAT ZK Catalog — catalogue of deployed on-chain verifiers", "url": "https://l2beat.com/zk-catalog", "kind": "catalogue" }, { "title": "ethproofs.org — continuous real-time proving benchmarks on Ethereum blocks, per prover, with cost and hardware", "url": "https://ethproofs.org/", "kind": "benchmark" }, { "title": "a16z zkvm-benchmarks — fixed-program comparison harness across zkVMs", "url": "https://github.com/a16z/zkvm-benchmarks", "kind": "benchmark" }, { "title": "Delendum zk-benchmarking — cross-implementation benchmarks of proof systems and zkVMs", "url": "https://github.com/delendum-xyz/zk-benchmarking", "kind": "benchmark" }, { "title": "ZKProof Community Reference — terminology and security recommendations", "url": "https://docs.zkproof.org/reference", "kind": "reference" }, { "title": "Plonky3 — polynomial IOP toolkit over small fields", "url": "https://github.com/Plonky3/Plonky3", "kind": "project" }, { "title": "Wrapping up the KZG ceremony — the largest deployed universal SRS", "url": "https://blog.ethereum.org/2024/01/23/kzg-wrap", "kind": "record" } ], "updated": "2026-09-12", "version": "1.3", "canonical": "https://zkpick.com/proof-systems/", "license": "https://creativecommons.org/licenses/by/4.0/", "authors": [ "MarketComp" ] }