Choosing a Proving System: Security Trade-offs

Most proving-system comparisons rank proof size and prover time. Those matter, but for a team shipping value-bearing infrastructure, the security dimensions matter more: what has to stay secret, what math has to stay unbroken, how mature the tooling is, and whether anyone qualified can audit what you build. This guide compares the major families through that lens.

The Contenders

Groth16

The 2016 workhorse. Pairing-based SNARK with the smallest proofs in practice (three group elements, ~200 bytes on BN254) and the cheapest on-chain verification — one reason it still dominates Ethereum applications via snarkjs and circom.

Security profile:

• Trusted setup, per circuit. Every circuit needs its own phase-2 ceremony on top of a universal powers-of-tau. If the setup's "toxic waste" is retained by colluding participants, proofs can be forged undetectably. Every circuit change — even a one-constraint fix — requires a new ceremony.
• Assumptions. Pairing-friendly curves and knowledge-of-exponent-style assumptions in the generic group model; not post-quantum.
• Proof malleability. Groth16 proofs can be re-randomized: a third party can produce a different valid proof of the same statement. Protocols must never key uniqueness or replay protection off proof bytes.
• Maturity. Nearly a decade of production use, well-understood verifier contracts, and the largest pool of auditors familiar with its failure modes. Maturity is itself a security property.

PLONK and the KZG family

PLONK-style systems (PLONK, TurboPlonk-descendants, halo2-with-KZG, and many rollup provers) use polynomial commitments — most commonly KZG — with a universal, updatable setup.

• One ceremony, many circuits. A single powers-of-tau-style setup serves every circuit up to a size bound, and it is updatable: anyone can add a contribution later, and only one contributor ever needs to have been honest. This removes the per-circuit ceremony treadmill, which in practice removes a whole class of operational risk (rushed ceremonies for hotfixes).
• Assumptions. Still pairing-based and not post-quantum. Fiat–Shamir transforms feature heavily, and getting the transcript hashing right is a real implementation risk — Trail of Bits' "Frozen Heart" disclosures showed several independent codebases derandomizing Fiat–Shamir incorrectly, enabling proof forgery.
• Flexibility vs. reviewability. Custom gates and lookup arguments make circuits faster and also harder to audit: every custom gate is a small bespoke cryptographic argument.

halo2 deserves special mention: the original Halo 2 (as used by Zcash) uses an inner-product argument instead of KZG, eliminating trusted setup entirely at the cost of larger proofs and slower verification, while the widely-forked halo2 API is often instantiated with KZG for cheap on-chain verification.

STARKs

Hash-based systems (as pioneered by StarkWare, and underlying most zkVMs today) using FRI for low-degree testing.

• Transparent. No trusted setup at all. Nothing toxic exists to leak; nothing to ceremonially destroy. For a security team, this deletes an entire risk category and its audit surface.
• Assumptions. Collision-resistant hashes and the security of FRI — no pairings, no discrete log, and plausibly post-quantum. This is the most conservative assumption set of the major families.
• Cost. Proofs are tens to hundreds of kilobytes. On-chain verification on Ethereum is expensive enough that STARK proofs are commonly wrapped in a final SNARK (often Groth16 or a PLONK variant) for settlement — which quietly reintroduces the SNARK's assumptions and any setup it required. Know what your actual end-to-end trust chain is after wrapping.
• Implementation risk. FRI soundness parameters (blowup factor, number of queries, conjectured vs. proven soundness) are configuration, not constants. Systems have shipped with soundness margins thinner than users assumed; auditors should ask for the concrete parameter file, not the paper.

zkVMs and folding schemes

SP1, RISC Zero, and similar zkVMs prove execution of ordinary programs (typically RISC-V) compiled from Rust. Folding/recursion schemes (Nova-lineage and successors) make incremental computation cheap and underpin many of these designs.

• The circuit bug class largely moves. Application developers write Rust, not constraints, so hand-rolled under-constraint bugs mostly disappear from the application layer — and concentrate in the zkVM itself. You are trading "audit my circuit" for "trust the zkVM's constraint system, its precompiles, and its recursion stack," which is a far larger but shared and heavily-scrutinized artifact. ChainLight's disclosure of a soundness bug in zkSync Era's prover shows that even mature, audited proving stacks harbor critical issues; it was patched before exploitation.
• Precompiles/accelerators (SHA-256, Keccak, pairing ops) are hand-written circuits inside the VM and historically where zkVM soundness bugs cluster.
• Auditability. Application logic in Rust is reviewable by any systems-security auditor, dramatically widening your talent pool. The VM layer, by contrast, is auditable by very few people — but you share that review cost with the whole ecosystem.

The Decision Dimensions

• Trusted setup risk. None (STARK, IPA-halo2) < universal/updatable (PLONK/KZG) < per-circuit (Groth16). Per-circuit ceremonies are a recurring operational burden, not a one-time cost.
• Cryptographic assumptions. Hashes-only (STARK) is strictly more conservative than pairings. If your horizon is decades or your threat model includes quantum adversaries, that asymmetry matters.
• Circuit language maturity. circom is battle-tested with real tooling (circomspect, Picus); Noir prioritizes developer safety and is younger; halo2's Rust API is powerful and easy to misuse (missing selector/copy constraints are its version of <-- bugs); zkVM-Rust is the most forgiving surface for application teams.
• Auditor availability. Groth16/circom has the deepest bench. Exotic custom-gate PLONK configurations and novel folding schemes may have a reviewer pool measured in dozens of people globally. An unauditable design is a security decision, not just a hiring problem.
• Ecosystem maturity. Verifier contract templates, ceremony tooling, fuzzing harnesses, and prior public audits all reduce the chance you are the first to hit a failure mode.
• Performance vs. security. Aggressive optimizations — custom gates, lookups, small fields, low FRI query counts, hand-tuned precompiles — are precisely where soundness bugs concentrate. Buy performance last, after correctness is established.

Practical Recommendation Matrix

• Small, stable, well-specified statement; cheapest on-chain verification; you can run a real ceremony: Groth16 + circom. Budget for the ceremony and for re-running it on every circuit change.
• Multiple circuits that will evolve; you want one setup and cheap verification: PLONK-family with KZG (or halo2/KZG). Invest audit time in custom gates and Fiat–Shamir handling.
• Long-lived infrastructure, conservative assumptions, no ceremony appetite, proof size manageable off-chain: STARK. If you wrap in a SNARK for settlement, audit the wrapper as part of the system.
• Complex or fast-changing application logic; team is stronger in Rust than in constraints: a zkVM (SP1, RISC Zero). Treat the VM as a critical dependency: track its audits and advisories, pin versions, and scrutinize any custom precompiles you enable.
• Maximum-assurance niche components (e.g., a signature or hash gadget reused everywhere): consider formal verification regardless of proving system — the proving system choice doesn't save you from circuit-level specification bugs.

Closing

There is no security-optimal proving system, only security trade-offs priced in different currencies: ceremony risk, assumption risk, implementation risk, and auditability. The consistent pattern across real incidents — from BCTV14's parameter flaw to Frozen Heart to zkVM soundness bugs — is that failures come from the implementation and integration layers, not from the underlying math being broken. Choose the system whose failure modes your team can actually detect, audit, and operate around — then spend the money you saved on adversarial testing.