Groth16 vs PLONK vs STARKs: Security Trade-offs for Protocol Designers
Zero-knowledge proof systems have moved from academic curiosity to production infrastructure. Rollups settle billions of dollars of value using zkSNARKs. Identity protocols issue credentials that anchor real-world legal claims. Voting systems derive their integrity guarantees from proof verification. In every one of these deployments, the choice of underlying proof system is not merely an engineering preference — it is a security decision with concrete, lasting consequences.
This article examines three dominant proof systems — Groth16, PLONK, and STARKs — strictly through the lens of security. It does not rank them. Each system encodes a different set of tradeoffs, and the correct choice depends on the threat model, the deployment context, the expected longevity of the protocol, and the institutional capacity to manage ceremony infrastructure. Understanding those tradeoffs precisely is the designer’s job.
The Landscape at a Glance
Before diving into each system individually, it helps to establish the axes along which they differ:
- Trusted setup: Does the system require a multi-party ceremony to generate public parameters, and what happens if that ceremony is compromised?
- Proof size: How large is a proof, and how does size scale with circuit complexity?
- Verification cost: How expensive is it to verify a proof, both computationally and in terms of on-chain gas?
- Cryptographic assumptions: What mathematical hardness problems must hold for soundness and zero-knowledge to be maintained?
- Quantum resistance: Does the security of the system survive the advent of large-scale quantum computers?
- Security model impact: How does the proof system choice propagate upward into the overall security posture of a protocol?
Each of these dimensions interacts with the others. A system that avoids trusted setup may carry larger proofs. A system with small proofs may rely on assumptions that are less conservatively understood. There is no free lunch, and the table stakes for every system are high.
Groth16
Construction Overview
Groth16 is a pairing-based zkSNARK. It constructs proofs over a bilinear group — an algebraic structure where an efficiently computable map, the pairing, sends pairs of group elements to a target group in a way that preserves multiplicative structure. The system encodes an arithmetic circuit as a Quadratic Arithmetic Program (QAP), and the prover demonstrates knowledge of a satisfying witness by producing group elements whose pairing relationships encode the constraint satisfaction.
The result is a proof consisting of exactly three group elements. This is its defining virtue: proof size is constant, circuit-independent, and extremely compact.
Trusted Setup: The Circuit-Specific Ceremony
Groth16 requires a circuit-specific trusted setup. This means that for every distinct arithmetic circuit — every distinct computation you want to prove — a fresh multi-party computation (MPC) ceremony must be performed to generate a Structured Reference String (SRS) that encodes the circuit’s QAP into group elements.
The ceremony produces two outputs: a proving key and a verification key. The proving key is used by the prover to construct proofs. The verification key is used by everyone else to verify them. During the ceremony, each participant contributes secret randomness (called “toxic waste”) and then — critically — destroys it. If even one participant among the many destroys their secret honestly, the full SRS is secure.
The risk is existential and precise. If all participants collude, or if a single participant’s toxic waste is recovered by an adversary, that adversary can generate false proofs that pass verification for that circuit. There is no way to detect this from the outside. A compromised Groth16 ceremony is cryptographically indistinguishable from an honest one. The verification key looks identical. Proofs generated with the trapdoor look identical to honest proofs. This is the defining property that makes the trusted setup a first-class security concern rather than a mere operational footnote.
Several large deployments have run elaborate ceremonies with hundreds of participants to minimize collusion risk. But the ceremony must be re-run for every circuit modification. Even a minor constraint change — adding a range check, altering a hash function — invalidates the existing SRS and demands a new ceremony. This imposes significant operational overhead on teams that need to iterate.
Cryptographic Assumptions
Groth16’s security rests on three interlocking assumptions:
The Knowledge of Exponent (KEA) assumption (in various forms): The prover cannot produce valid group element combinations unless it “knows” a witness. This is a non-falsifiable assumption in the standard sense — it cannot be reduced to a concrete computational problem in the traditional way. It asserts something about the structure of the prover’s computation, not merely about computational difficulty.
The q-Strong Diffie-Hellman (q-SDH) assumption: Roughly, given g, g^x, g^(x²), …, g^(x^q) for a secret x, it is hard to compute g^(1/(x+c)) for a chosen c. This underpins the binding property of the polynomial commitment embedded in the SRS.
Pairing-friendly elliptic curve security: The security of all group operations depends on the hardness of the Discrete Logarithm Problem (DLP) in the relevant curve groups. The BN254 and BLS12-381 curves are the dominant choices in production systems.
Compromising Groth16’s Assumptions in Practice
If the DLP in the pairing-friendly curve group is broken — either through classical advances in index calculus algorithms or through quantum computation — an adversary can extract secret keys from group elements and forge proofs at will. The consequences are total: every proof ever verified under that curve is now suspect, and the system provides no guarantees.
If the KEA assumption fails — that is, if a prover can produce valid transcripts without knowing a witness through some algebraic shortcut — soundness breaks. This would mean an adversary could prove false statements, undermining the entire integrity property of any protocol that relies on Groth16 proofs.
The trusted setup compromise, as described above, is practically the most likely threat vector. It does not require breaking any mathematical hardness assumption. It requires only colluding with ceremony participants or compromising the infrastructure on which they ran their contributions.
PLONK
Construction Overview
PLONK is a universal and updatable zkSNARK. It uses a polynomial commitment scheme — most commonly the KZG (Kate-Zaverucha-Goldberg) commitment scheme — to allow the prover to commit to polynomials representing the computation, and then open those commitments at evaluation points chosen by the verifier. The constraint system is expressed as a set of polynomial equations that must hold over a structured domain.
PLONK’s key architectural innovation relative to Groth16 is universality: a single SRS can support any circuit up to a maximum size. The SRS is tied to a maximum degree bound, not a specific circuit. This means the ceremony needs to be performed once (for a given maximum circuit size), and any circuit fitting within that bound can use the same parameters.
PLONK also introduced the notion of updatability: new participants can contribute to the SRS after the initial ceremony, extending the set of honest parties without invalidating existing parameters. This improves the security posture of the ceremony over time.
Trusted Setup: Universal but Still Required
PLONK still requires a trusted setup. The difference from Groth16 is meaningful but not absolute. The ceremony is performed once, and its output — typically called a “universal SRS” or “powers of tau” — is usable across all circuits within the size bound. This dramatically reduces ceremony overhead for protocols that deploy multiple circuits or iterate on circuit design.
The risk structure is the same in kind: if all ceremony participants collude or if toxic waste is recovered, the adversary can forge proofs for any circuit using that SRS. The universal nature of the SRS makes a compromise potentially more damaging in scope — a single successful attack on the ceremony invalidates the security of every circuit that uses it, rather than just one.
The updatability property provides a meaningful mitigation: protocols can run periodic “contribution rounds” where new participants add entropy, continuously reducing the probability that all contributors with live toxic waste are compromised. But the fundamental trusted setup requirement remains.
KZG-based systems also bind the SRS to a specific elliptic curve. The maximum circuit size is fixed at ceremony time by the degree of the SRS. Exceeding it requires a new ceremony.
Cryptographic Assumptions
The KZG polynomial commitment scheme rests on the q-Strong Diffie-Hellman (q-SDH) assumption and on the security of the pairing. The binding property of KZG — the guarantee that a committed polynomial cannot be opened to two different values at the same point — follows from q-SDH. The hiding property follows from the discrete logarithm problem.
Pairing security: Like Groth16, PLONK with KZG depends on the hardness of DLP in pairing-friendly curve groups. The choice of curve (BN254, BLS12-381, or others) determines the concrete security level.
The Fiat-Shamir heuristic: In practice, PLONK is deployed non-interactively by replacing the verifier’s random challenges with a cryptographic hash function applied to the transcript. This transformation is secure in the Random Oracle Model (ROM) — a theoretical model where the hash function is treated as a truly random function. In the standard model (without this idealization), the security of the Fiat-Shamir transformation is more nuanced and depends on the specific hash function’s properties.
Some PLONK variants replace KZG with alternative polynomial commitment schemes — most notably inner product argument-based schemes (such as those derived from Bulletproofs) or FRI-based commitments. Each substitution carries its own assumption set and changes the trusted setup requirements. Inner product argument schemes are trustless but produce larger proofs. FRI-based schemes avoid pairings entirely.
Compromising PLONK’s Assumptions in Practice
Breaking q-SDH in the underlying group allows an adversary to open a KZG commitment to an incorrect value — to claim a polynomial evaluates to something it does not. This means proofs of false statements can be constructed, and the soundness of the entire proof system collapses.
Breaking the pairing — finding a non-trivial relationship in the target group that should not exist — would similarly undermine the binding property of the commitment scheme and allow forgery.
If the Fiat-Shamir hash function is not collision-resistant or exhibits exploitable structure, an adversary could potentially manipulate transcript challenges to produce convincing proofs for false statements. In practice, the ROM is widely accepted as a reasonable security model for deployed systems, but it is an idealization, and this idealization should be part of any rigorous threat model analysis.
STARKs
Construction Overview
STARKs (Scalable Transparent ARguments of Knowledge) take a fundamentally different approach. They replace algebraic groups and pairings with hash functions and error-correcting codes. The prover encodes the computation as a polynomial over a finite field, commits to it using a Merkle tree (with a collision-resistant hash function at the leaves), and then uses the FRI (Fast Reed-Solomon IOP of Proximity) protocol to prove that the committed polynomial is close to a low-degree polynomial — which, by soundness of the FRI protocol, implies the computation was performed correctly.
The interactive protocol is made non-interactive via the Fiat-Shamir transformation, again invoking the ROM.
Trusted Setup: None
STARKs require no trusted setup. There is no ceremony, no toxic waste, no SRS, no group of participants whose honesty must be assumed. The public parameters are entirely transparent — they consist of the description of a hash function that anyone can verify is a standard construction. This is the system’s defining security advantage.
The absence of a trusted setup removes an entire threat category. There is no ceremony to compromise, no collusion risk to model, no operational security burden around key destruction. For protocols where the trusted setup represents an unacceptable institutional or political risk — decentralized systems with no natural ceremony coordinator, protocols designed to operate for decades without governance, systems where the provenance of parameters will be publicly scrutinized — STARKs eliminate this concern entirely.
Proof Size and the Transparency Cost
STARKs pay for their transparency with proof size. A STARK proof is substantially larger than a Groth16 or PLONK/KZG proof. Where Groth16 produces a constant-size proof of roughly 200 bytes regardless of circuit size, and PLONK/KZG proofs are compact (a few hundred bytes plus logarithmic-size openings), STARK proofs are measured in tens to hundreds of kilobytes for practical circuits.
The proof size is dominated by the Merkle authentication paths required for FRI decommitments. The number of query rounds in FRI determines the soundness error — more queries means stronger soundness but larger proofs. This is a tunable parameter, and protocol designers can trade proof size for security level within the constraints of the hash function’s security.
Verification cost follows proof size. On-chain verification of a STARK is more expensive than on-chain verification of a Groth16 proof. This has meaningful implications for rollup protocols where verification costs are paid in gas on every settled batch. The cost differential is significant enough that many production rollup teams use recursive proving — proving the verification of a STARK inside a smaller SNARK — to compress the final on-chain verification cost while retaining the STARK’s transparency properties during proof generation.
Cryptographic Assumptions
STARKs require only:
Collision resistance of the hash function: The Merkle tree commitments are binding only if the hash function is collision-resistant. Breaking collision resistance allows an adversary to equivocate on committed values, opening the door to soundness attacks.
The Random Oracle Model: The Fiat-Shamir transformation, used to make the interactive FRI protocol non-interactive, requires treating the hash function as a random oracle. Soundness proofs for deployed STARK systems are in the ROM.
That is essentially the full assumption set. There are no algebraic groups, no pairings, no structured reference strings, no elliptic curves. The security depends on properties of hash functions — the most conservative and well-studied cryptographic primitives available.
FRI soundness: FRI itself has a concrete soundness analysis as a proximity testing protocol. The soundness error decreases geometrically with the number of query rounds. The analysis is in the information-theoretic model conditioned on the hash function behaving as a random oracle. The security reduction is tight and quantifiable.
Compromising STARKs’ Assumptions in Practice
If the hash function is not collision-resistant — if an adversary can find two inputs hashing to the same output — they can equivocate on Merkle commitments, opening committed polynomials to incorrect values. This breaks the binding property of the commitment scheme and allows proof forgery.
In practice, the hash functions used in production STARKs (Keccak-256, BLAKE3, Poseidon, and others) are not believed to be close to broken. Even a significant weakening of collision resistance — reducing the effective security level from 128 bits to, say, 90 bits — would not immediately enable practical attacks given current computational bounds. The conservative assumption structure of STARKs means that partial cryptanalytic advances are less immediately threatening than in pairing-based systems.
Quantum Resistance: A Comparative Analysis
Quantum computing poses a specific and well-characterized threat to current cryptographic systems. The relevant quantum algorithm is Shor’s algorithm, which runs in polynomial time on a quantum computer and solves the discrete logarithm problem and the integer factorization problem.
Groth16 Under Quantum Attack
Groth16 is not quantum-resistant. Its security relies on the hardness of DLP in pairing-friendly elliptic curve groups. Shor’s algorithm breaks DLP. A sufficiently powerful quantum computer could extract the trapdoor from the SRS directly from the published group elements, forge arbitrary proofs, and retroactively compromise every proof ever generated under that system.
This is not a hypothetical distant concern for long-lived protocols. If a protocol is designed to provide integrity guarantees over a period of decades, and if quantum computers capable of breaking 256-bit elliptic curve DLP become available within that window, all historical Groth16 proofs lose their validity guarantees simultaneously.
PLONK Under Quantum Attack
PLONK with KZG commitments shares Groth16’s quantum vulnerability. The KZG scheme depends on DLP in the same class of pairing-friendly curves. Shor’s algorithm would break KZG’s binding property and allow proof forgery.
PLONK variants using inner product argument-based commitment schemes (such as Halo2-style accumulation) also depend on DLP, though in curves without pairing structure. They are equally vulnerable.
PLONK variants using FRI-based polynomial commitments (effectively making them STARK-like in their commitment layer) inherit the quantum resistance properties of STARKs. The universality and low-degree test structure can be preserved while substituting hash-based commitments for pairing-based ones, though the proof size increases accordingly.
STARKs Under Quantum Attack
STARKs are plausibly quantum-resistant. Their security relies on collision resistance of hash functions, which is affected by quantum computing through Grover’s algorithm rather than Shor’s. Grover’s algorithm provides a quadratic speedup for searching, which effectively halves the security level of a hash function in terms of bit security. A hash function providing 256-bit classical collision resistance provides approximately 128-bit quantum collision resistance — still at a level considered secure against foreseeable quantum adversaries.
This makes STARKs the only major deployed proof system class with a credible claim to post-quantum security, assuming adequate hash function security parameters are chosen. For protocols intended to operate beyond the horizon of classical cryptography dominance, this is a material advantage.
It is worth noting that the security of STARKs against quantum adversaries has not been as rigorously analyzed as post-quantum lattice-based systems. The ROM under quantum access (the Quantum Random Oracle Model, or QROM) has subtleties that affect the security proof for Fiat-Shamir-based protocols. Ongoing research continues to tighten these proofs, and current analysis suggests that STARKs with 128-bit quantum security parameters remain sound, but the theoretical foundations are more recent and less battle-tested than the classical security analysis.
Verification Cost and Proof Size: Security-Adjacent Tradeoffs
Proof size and verification cost are not pure performance metrics. They interact with security in several ways.
On-chain verification and economic security: For rollup protocols, the cost of verifying a proof on a base layer determines the economic viability of fraud prevention. If verification is prohibitively expensive, the protocol may adopt weaker verification mechanisms — batching proofs, using optimistic assumptions, or reducing verification frequency — any of which weakens the overall security model. Groth16’s constant-size, cheaply verifiable proofs provide strong economic alignment between cryptographic security and on-chain cost.
Proof aggregation and recursion: The practical response to STARK proof size is recursive proving. A STARK proof’s verification is encoded as an arithmetic circuit, and that circuit is proven using a second proof system — often a SNARK — whose proof is small and cheap to verify on-chain. This approach is sound: the final on-chain verifier only checks the outer SNARK, which proves (in zero-knowledge) that a valid STARK proof exists. But it introduces layered trust: the outer SNARK carries its own trusted setup (if it is Groth16 or PLONK/KZG), its own cryptographic assumptions, and its own ceremony requirements. The security of the combined system is the intersection of both systems’ security properties.
Soundness error and parameterization: All proof systems have a soundness error — the probability that an invalid proof passes verification. For STARKs, this is tunable by adjusting the number of FRI query rounds. For SNARKs, the soundness error is typically negligible and fixed by the curve’s security level. Protocol designers must ensure that the chosen parameterization achieves a soundness error below the threshold that would make grinding attacks practical given the value at stake in the protocol.
How Proof System Choice Shapes the Overall Security Model
The proof system is not an isolated component. Its security properties propagate throughout every layer of the protocol that depends on it.
Trust Minimization and Ceremony Governance
A protocol built on Groth16 or PLONK/KZG inherits a social trust assumption: the ceremony was run honestly by a sufficiently diverse set of participants. This assumption must be communicated to users, audited, and maintained. For decentralized protocols with no central governance body, this creates an inherent tension. Who is responsible for re-running the ceremony when the circuit changes? Who audits the participant list? Who verifies that toxic waste was destroyed? These are governance questions, and governance failure is a security failure.
STARKs eliminate this layer entirely. The proof system’s security can be fully verified from public code and public parameters, without trusting any party’s past behavior. This is a meaningful property for protocols designed to be maximally trust-minimized.
Upgradeability and Circuit Evolution
Groth16’s circuit-specific ceremony creates friction for protocol upgrades. Every iteration requires a new ceremony, which requires coordination, communication, and operational security. Protocols that expect frequent iteration — privacy-preserving applications that need to update their constraint systems as regulations or features change — face compounding ceremony overhead.
PLONK’s universal SRS partially mitigates this. The ceremony runs once per size class, and circuit changes within that size bound do not require new ceremonies. But size bound increases do, and the governance of the universal SRS (who can update it, under what conditions, with what verification) must be addressed.
STARKs have no ceremony-related upgradeability constraint. Circuit changes require only new code. This dramatically simplifies the operational security of iterative protocol development.
Composability and Proof Aggregation
When multiple proof systems are composed — as in recursive proving stacks — the security model becomes the logical conjunction of all component systems’ assumptions. A STARK-proven computation wrapped in a Groth16 outer proof is secure only if both the hash function assumptions (for the inner STARK) and the pairing assumptions and ceremony integrity (for the outer Groth16) hold simultaneously. This is often a reasonable tradeoff, but it must be made explicitly, not accidentally. Security designers must map the full dependency graph of cryptographic assumptions and ensure that each assumption’s failure mode is understood.
Long-Horizon Security Planning
For protocols with long expected operational lifetimes, the quantum resistance question is not academic. A protocol launched today using Groth16 or PLONK/KZG is making an implicit bet that elliptic curve DLP will remain computationally hard for the entire protocol lifetime. If that bet is wrong, historical proofs lose their guarantees. For applications like credential issuance, land registry, or long-term identity systems, this is a materially different risk posture than for applications with short operational windows.
STARKs allow protocol designers to avoid making this bet. By relying only on hash function collision resistance — which quantum computers attack less effectively — STARKs provide a more conservative security basis for long-lived deployments.
Summary of Security Tradeoffs
| Property | Groth16 | PLONK (KZG) | STARKs |
|---|---|---|---|
| Trusted setup | Circuit-specific ceremony | Universal, updatable ceremony | None (transparent) |
| Ceremony compromise impact | Forgery for that circuit | Forgery for all circuits in SRS | Not applicable |
| Proof size | ~200 bytes (constant) | ~400–600 bytes | Tens to hundreds of KB |
| Verification cost | Very low | Low | High (without recursion) |
| Primary assumption | Pairing-group DLP + KEA | Pairing-group DLP + q-SDH | Hash collision resistance |
| Assumption model | AGM / ROM | AGM / ROM | ROM / QROM |
| Quantum resistance | No | No | Plausible (Grover only) |
| Circuit upgradeability | New ceremony per circuit | One ceremony per size class | No ceremony needed |
Conclusion
Groth16 offers the smallest proofs and lowest verification cost of any widely deployed proof system, but demands a circuit-specific ceremony and rests on assumptions that do not survive quantum attack. It is optimal for production systems where proof size and on-chain verification cost are primary constraints, the circuit is stable, the ceremony can be executed with high-quality participant diversity, and quantum longevity is not a concern.
PLONK improves on Groth16’s ceremony ergonomics through universality and updatability, making it more suitable for protocols that require circuit flexibility without per-circuit ceremonies. It carries the same quantum vulnerability and introduces a wider blast radius if the universal SRS is compromised.
STARKs provide the strongest baseline security assumptions — requiring only hash function collision resistance — with no trusted setup, plausible quantum resistance, and freely updatable circuits. They pay for these properties with large proofs and high raw verification cost, costs that are practically managed through recursive aggregation at the expense of introducing layered trust assumptions.
No proof system is universally superior. The correct choice is determined by the intersection of the protocol’s threat model, its operational context, its expected lifetime, and its governance capacity. Security designers who treat proof system selection as a performance optimization rather than a trust-model decision are leaving their users exposed to risks that are entirely avoidable with careful analysis.
The cryptographic assumptions underlying these systems are not implementation details. They are the bedrock of every security guarantee that a ZK protocol can offer. Understanding them precisely — and communicating them honestly to users — is the foundational responsibility of anyone building in this space.