Proving systems compared

Compare three widely-used proving systems — Groth16, PLONK, and STARKs — across proof size, verification cost, setup requirements, cryptographic assumptions, and post-quantum posture, honestly, without inventing benchmark numbers, so you can reason about which fits which job.

Track

Engineering

Module

4 · Zero-Knowledge Proofs

Prerequisites

Commitments and setup · Arithmetic circuits and R1CS

By now the pieces are in place: a statement is arithmetized into constraints, commitments pin down the prover's polynomials, and a setup provides public parameters. A proving system is the specific recipe that ties these together into a concrete protocol with concrete trade-offs. The three compared here — Groth16, PLONK, and STARKs — are among the most widely deployed, and they make genuinely different bargains. Choosing one is an engineering and trust decision, not a detail.

All three are succinct non-interactive arguments (SNARKs/STARKs): the verifier does far less work than re-running the computation, and the proof is non-interactive (via Fiat–Shamir or an equivalent). They differ in the arithmetization they expect, the commitment scheme they use, and — most consequentially — the setup they require and the hardness assumptions their soundness rests on.

Groth16

A pairing-based SNARK (Groth, 2016) with a circuit-specific trusted setup. Known for very small, constant-size proofs and very cheap verification.

PLONK

A SNARK (Gabizon, Williamson & Ciobotaru, 2019) using a universal and updatable trusted setup — one ceremony can serve many circuits up to a size bound.

STARK

A transparent proof system (Ben-Sasson et al., 2018) built on hash functions and FRI, requiring no trusted setup and conjectured to resist quantum attacks.

Universal / updatable setup

A setup whose parameters are not tied to one circuit and can be extended by new contributors, reducing (not removing) trusted-setup risk.

Rather than fabricate numbers, this comparison uses qualitative, order-of-magnitude relationships that are well established in the literature. Treat the arrows as "relative to the others", not as measured constants. Actual figures depend heavily on the circuit, field, and implementation, and change over time — always benchmark your own workload.

Honest qualitative comparison (relative, not measured)
                         Groth16          PLONK              STARK
-------------------------------------------------------------------------
Proof size               smallest         small-to-medium     largest
                         (constant)       (constant-ish)      (grows ~polylog
                                                               in circuit size)

Verifier cost            cheapest         cheap               higher
                         (a few pairings) (pairings)          (hashing-heavy)

Prover cost              moderate         moderate            often higher
                                                              (but no pairings)

Setup                    TRUSTED,         TRUSTED,            TRANSPARENT
                         circuit-specific universal+updatable (no setup secret)

Core assumptions         pairing-based    pairing-based       collision-resistant
                         (+ knowledge      (+ knowledge        hash (symmetric)
                         assumptions)      assumptions)

Post-quantum posture     NOT PQ           NOT PQ              plausibly PQ
                         (broken by        (broken by          (relies only on
                         quantum DL)       quantum DL)         hash security)

Change circuit           new setup        reuse universal     no setup at all
                         each time         setup (to a bound)
-------------------------------------------------------------------------
Rule of thumb: smaller proof & cheaper verify  <-->  stronger setup trust
               and weaker post-quantum posture.  Pick your trade.

The structural reasons behind the table: Groth16 and PLONK get tiny proofs and cheap verification from elliptic-curve pairings, but pairings rest on discrete-log-type assumptions that a large quantum computer would break — hence "not post-quantum". STARKs use only hash functions, which are believed to remain secure against quantum adversaries (modulo generic speedups), so they are plausibly post-quantum, but the FRI-based machinery makes proofs substantially larger and verification hashing-heavy. Groth16's setup is tied to one circuit; PLONK's universal/updatable setup is a middle ground; STARKs need no setup secret at all.

1. 1State your hard constraints first: must the proof be tiny (on-chain, bandwidth-limited)? Must verification be dirt-cheap? Is a trusted setup acceptable to all parties? Do you need post-quantum security?
2. 2If a trusted setup is unacceptable or post-quantum resistance is required, STARKs (or another transparent/PQ-oriented system) are the candidates — accept larger proofs.
3. 3If you can run a setup and want the smallest possible proof for a single fixed circuit, Groth16 fits — but you pay a new ceremony whenever the circuit changes.
4. 4If you want small proofs but expect many evolving circuits, PLONK's universal/updatable setup amortizes the ceremony across circuits.
5. 5Benchmark on YOUR circuit and field. The qualitative table orders the systems; only measurement gives real sizes and times for your workload.

synthetic — matching a system to an agent requirement
Requirement set 1: proof verified by a cheap, bandwidth-limited
  on-chain verifier; circuit is fixed; a one-time ceremony is OK.
  -> Groth16  (smallest proof, cheapest verify; accept fixed-circuit setup)

Requirement set 2: many evolving policy circuits; small proofs still
  wanted; one shared ceremony across all of them is tolerable.
  -> PLONK    (universal/updatable setup amortizes the ceremony)

Requirement set 3: cross-org agents that trust NO common ceremony,
  and authority proofs must survive a future quantum adversary.
  -> STARK    (no trusted setup, plausibly post-quantum; larger proofs)

No set is "wrong" for the others' answer -- each optimizes a
different axis. Interchanging them silently changes your trust model.

Notice that the same abstract task — "prove authorization in zero-knowledge" — lands on three different systems depending on constraints that have nothing to do with the statement itself. That is the central lesson: the proving system encodes trust and performance assumptions that the statement does not.

For an agent fleet, verification cost and proof size dictate whether proving authority at runtime is feasible: if every tool call carries a proof, a verifier doing a few pairings (Groth16/PLONK) scales very differently from one hashing a large STARK proof. Conversely, if agents cross trust boundaries where no common setup ceremony is acceptable, or if proofs must remain valid for years against an evolving threat model, the transparent, plausibly-post-quantum posture of STARKs may outweigh their size cost.

The honest architectural stance: pick the proving system from the deployment's trust and performance constraints, document the assumption you are buying (ceremony honesty, or hash security, or quantum timeline), and revisit it as the field and the threat model evolve. This directly feeds the Module 5 delegation case study.

• ▸Do not treat the systems as drop-in replacements: swapping one for another silently changes proof size, verifier cost, setup trust, and post-quantum posture.
• ▸Pairing-based systems (Groth16, PLONK) are not post-quantum; a sufficiently large quantum computer breaks their underlying discrete-log assumptions. STARKs are only "plausibly" PQ — security rests on the hash function and standard conjectures, not a theorem.
• ▸Groth16's per-circuit trusted setup means every circuit change is a new ceremony and a new trust event; PLONK reduces this to a universal setup but still requires a trusted ceremony.
• ▸The qualitative table orders systems but gives no absolute numbers; real sizes and times depend on circuit, field and implementation and must be measured — beware any quoted benchmark without its exact conditions.
• ▸The ZK ecosystem evolves quickly; new systems and variants appear and existing ones improve. Treat this comparison as a stable mental model, not a current leaderboard.

Expected direction: Wrong/dangerous assumptions: (1) "same proofs" — STARK proofs are much larger and verification is hashing-heavy rather than a few pairings, so proof-size and verifier-cost budgets change substantially; (2) the circuit/arithmetization is not portable — Groth16 uses R1CS + pairings while STARKs use an AIR-style arithmetization and FRI, so the circuit likely must be rewritten and re-audited; (3) trust model changes — Groth16 needs a circuit-specific trusted setup (toxic waste), STARKs need none, so governance and setup assumptions change entirely. The post-quantum gain is real but comes bundled with these changes; it is not a drop-in "swap".

Which of the three systems requires no trusted setup, and what does it trade for that?

STARKs require no trusted setup (transparent). They trade it for substantially larger proof sizes and heavier, hashing-based verification.

Why are Groth16 and PLONK not post-quantum, while STARKs are plausibly post-quantum?

Groth16 and PLONK rely on pairing/discrete-log assumptions that a large quantum computer would break; STARKs rely only on the security of hash functions, which are believed to resist quantum attacks (up to generic speedups).

What does PLONK's "universal and updatable" setup give you over Groth16's setup?

One trusted-setup ceremony can serve many circuits (up to a size bound) and can be extended by new contributors, instead of requiring a fresh circuit-specific ceremony for every circuit as Groth16 does.