Every zk-rollup team building on Ethereum in 2026 eventually hits the same fork in the road: Groth16 or PLONK. Both are zk-SNARK proving systems, both let a prover convince a verifier that a computation ran correctly without revealing the inputs, and both show up across the current crop of Layer 2 networks, privacy coins, and storage-proof systems. Ethereum’s own developer documentation groups zk-rollups together precisely because they all lean on some flavor of zk-SNARK or zk-STARK to compress thousands of transactions into a single proof, but the choice of which proving system sits underneath that proof is anything but interchangeable.
Groth16 and PLONK solve the trusted-setup problem, the proof-size problem, and the gas-cost problem in almost opposite ways. Picking the wrong one locks a team into either a fragile one-time ceremony or a heavier, more expensive verifier. This comparison breaks down proof size, on-chain verification cost, prover speed, and who is actually running each system in production right now, using published benchmarks and protocol documentation rather than marketing claims from either camp.
The stakes are higher than a purely academic exercise. A rollup that picks the wrong proving system either pays a permanent gas-cost tax on every batch it settles or locks itself into re-running a multi-party ceremony every time it wants to ship a circuit upgrade. Both mistakes are expensive to reverse once a protocol has real users and real value moving through it, which is why the engineering teams at Zcash, Polygon, Scroll, zkSync, and Aztec have all made explicit, public choices about which system, or which combination of systems, their production circuits run on.
What Is Groth16?
Groth16 comes from Jens Groth’s 2016 paper “On the Size of Pairing-Based Non-Interactive Arguments”, and it remains the smallest general-purpose zk-SNARK proving system in production use a decade later. A Groth16 proof is always exactly three elliptic-curve group elements, which means the proof size stays fixed no matter how large or complex the underlying circuit gets. On the BLS12-381 curve, that works out to roughly 192 bytes. On BN254, compressed encodings bring it down to around 128 bytes. Nothing else in this comparison gets close to that footprint.
The tradeoff is baked into the setup. Groth16 requires a circuit-specific trusted setup: a multi-party computation ceremony run once for each individual circuit, producing proving and verification keys tied to that exact circuit. If the circuit changes, even by adding one constraint, the ceremony has to run again. The randomness generated during that ceremony (often called “toxic waste”) must be destroyed by every participant, because anyone who retains it could forge fake proofs for that circuit. Zcash’s original Sapling ceremony and the Filecoin genesis ceremony are the two most cited examples of this process being run at scale.
What Is PLONK?
PLONK, short for “Permutations over Lagrange-bases for Oecumenical Noninteractive arguments of Knowledge,” was introduced by Ariel Gabizon, Zachary Williamson, and Oana Ciobotaru in a 2019 paper. Ethereum researcher Vitalik Buterin’s widely read explainer at the time framed PLONK’s core contribution as a universal, updatable structured reference string (SRS): a single trusted-setup ceremony that can serve any circuit up to a fixed size, not just one specific circuit. That single change reshaped how teams think about zk-SNARK deployment, because it decouples the expensive, security-critical ceremony from the day-to-day work of shipping and iterating on circuits.
PLONK’s proofs run larger than Groth16’s. Common benchmark tables put a PLONK proof around 576 bytes, while production-oriented implementations that batch commitments or add extra rounds often land between 0.8 and 1.2 kilobytes. PLONK is also less a single fixed algorithm than a family: Halo2, TurboPLONK, and UltraPLONK are all PLONK-derived systems that swap in different commitment schemes, custom gates, or lookup arguments, which is part of why “PLONK performance” varies so much between projects.
Trusted Setup: Toxic Waste vs a Reusable Ceremony
Every pairing-based or polynomial-commitment zk-SNARK needs some form of trusted setup: a set of structured public parameters generated from secret randomness that must never fully surface again. The two systems differ in how narrowly that setup applies, and that single design choice cascades into almost every other tradeoff in this comparison, from proof size to how easily a protocol can ship new circuit versions.
Groth16’s Per-Circuit Ceremony
Because Groth16’s proving and verification keys are derived from the exact arithmetic circuit being proved, any change to that circuit, a bug fix, a new feature, an optimization, invalidates the old setup and forces a new ceremony. Each ceremony needs enough independent, honest participants that at least one of them destroys their secret randomness. If every single participant colludes or is compromised, the whole setup is broken. This is manageable for a protocol with one stable circuit, which is exactly why Zcash and Filecoin, both of which settled on largely fixed circuit designs, still run on Groth16 in 2026.
PLONK’s Universal, Updatable SRS
PLONK-family systems built on KZG polynomial commitments can reuse a single structured reference string across any circuit that fits within the SRS’s size bound. The Ethereum Foundation’s own KZG Ceremony, originally run to support proto-danksharding, is now treated by the broader industry as a reusable, publicly trustworthy SRS for any KZG-based system, including PLONK and Halo2-KZG variants, that fits its size budget. Thousands of independent contributors added entropy to that ceremony, and as long as a single one of them discarded their secret, the resulting SRS is safe for every project that draws on it, which is a fundamentally different trust model from Groth16’s one-ceremony-per-circuit approach. The older Perpetual Powers of Tau ceremony still gets cited as the canonical universal setup path for teams that need a larger reference string. The updatability matters too: new participants can add fresh entropy to an existing SRS at any time, extending its security without invalidating what came before, so a PLONK-based protocol never has to treat its trusted setup as a one-time, unrepeatable event the way a Groth16 deployment does.
Proof Size Compared: Bytes on the Chain
Proof size determines how much calldata a rollup has to post to Ethereum, and calldata is one of the most expensive resources on the network. Groth16’s fixed three-group-element structure keeps it small regardless of circuit complexity, which is the main reason it survives as a “final compression” layer even inside systems that use other proving systems earlier in the pipeline. PLONK’s larger proof reflects its polynomial-commitment structure, which needs to encode more openings and evaluation proofs to support the flexibility of a universal setup.
| Proof System | Typical Proof Size (BLS12-381) | Typical Proof Size (BN254) | Notes |
| Groth16 | ~192 bytes | ~128 bytes | Fixed 3 group elements regardless of circuit size |
| PLONK (benchmark configs) | ~576 bytes | Varies by curve | From common 2026 benchmark tables |
| PLONK (production configs) | 0.8–1.2 KB | Varies by implementation | Larger due to batching and extra commitment rounds |
That gap, roughly three to six times, sounds small until it is multiplied across thousands of daily rollup batches, which is why several PLONK-family rollups still wrap their final proof in a Groth16 layer before posting it to Ethereum, taking PLONK’s flexible mid-pipeline proving and Groth16’s compact final verification in the same stack.
On-Chain Verification Gas Cost
Smaller proofs generally mean cheaper verification, and that holds here. A 2024 engineering breakdown that is still cited in 2026 discussions models Groth16 verification gas as roughly 181,150 plus 6,150 gas per public input plus 4,096 base calldata gas, which separates the cost into pairing checks, multi-scalar multiplication, and calldata. In practice, most current sources put Groth16 verification in the 200,000 to 230,000 gas range for typical circuits. Succinct’s documentation for its Groth16 proof wrapper cites proofs around 260 bytes verifiable on-chain for roughly 270,000 gas, a slightly higher figure that reflects the overhead of wrapping a different proof system’s output.
PLONK verification runs heavier because the verifier has to check polynomial commitment openings rather than a fixed small number of pairings. Current engineering comparisons place PLONK verifiers at roughly 300,000 gas or more, which lines up with the larger proof size discussed above. The gap between the two systems, on the order of 70,000 to 100,000 gas per verification, is the single biggest reason protocols with high transaction volume default to Groth16 wherever they can.
This gap sits on top of, not instead of, the other costs a rollup pays to settle on Ethereum. Posting the transaction data itself, whether as calldata or as a blob under Ethereum’s proto-danksharding upgrade, is a separate line item from proof verification, and it does not change based on which SNARK a rollup uses. The verification-gas difference between Groth16 and PLONK is specifically the marginal cost of checking that the proof is valid, isolated from everything else a rollup batch has to pay for, which is why teams model it separately when deciding which proving system to standardize on.
| Metric | Groth16 | PLONK |
| Typical on-chain verification gas | ~200,000–230,000 gas | ~300,000+ gas |
| Verification gas (wrapped proof, Succinct docs) | ~270,000 gas | Not published as a comparable wrapped figure |
| Off-chain verification time (2026 benchmark) | ~3.1 ms | ~5.2 ms |
What It Actually Costs to Verify a Proof
Turning gas units into dollars requires an ETH price and a gas price, both of which move constantly, so the figures below are a snapshot rather than a fixed price list. On September 17, 2026, ETH traded in the $2,415 to $2,440 range across major exchanges and trackers, with a working figure of roughly $2,435. Ethereum mainnet gas prices for ordinary, non-congested activity have generally run in the 10 to 30 gwei band through late 2025 and into 2026, with spikes well above that during high-demand events. Applying those ranges to the verification gas figures above gives a rough sense of what a single on-chain proof verification costs at different levels of network congestion.
| Network Condition | Gas Price | Groth16 Verify Cost (~200K gas) | PLONK Verify Cost (~300K gas) |
| Quiet network | 10 gwei | ~$4.87 | ~$7.31 |
| Typical network | 15 gwei | ~$7.31 | ~$10.96 |
| Busy network | 30 gwei | ~$14.61 | ~$21.92 |
These are estimates built from published gas figures and a same-day ETH price snapshot, not an official price sheet, since neither Groth16 nor PLONK is a commercial product with a rate card. That distinction matters on the proving side too: commercial zero-knowledge proving-as-a-service vendors including Succinct, RiscZero, and the =nil; Foundation do not publish fixed per-proof pricing as of 2026. Their documentation points toward negotiated enterprise agreements, marketplace-style job pricing, or capacity-based billing rather than a flat dollar figure per Groth16 or PLONK proof, so teams evaluating a managed proving service should expect a sales conversation rather than a published rate.
Prover Time and Benchmark Results
Proving time is where the two systems diverge the most by implementation and circuit type, which makes it the hardest axis to summarize with a single number. A 2026 systematics paper reported Groth16 proof generation in the roughly 0.8 to 1.15 second range across its test circuits, with verification consistently staying under a second, reinforcing Groth16’s reputation as fast to verify but variable to prove. On the PLONK side, a 2025 benchmark of TurboPLONK and UltraPLONK on a circuit with 2^22 gates recorded proving times of about 104 seconds and 191 seconds respectively in that specific library setup, a reminder that “PLONK” performance depends heavily on which implementation and commitment scheme is doing the proving.
Circuit type shifts the outcome further. Aztec’s own 2026 benchmark post found PLONK running roughly five times faster than Groth16 on Pedersen hash-heavy circuits, a workload PLONK’s custom gates handle efficiently. A separate 2026 benchmarking study reported the opposite result for different ZK-friendly hash circuits, with Groth16 winning on both prover time and memory usage. Neither system is categorically faster. The answer depends on what the circuit is actually computing, which is why serious teams benchmark their own circuit rather than trusting a general “X is faster than Y” claim from an unrelated workload.
Hardware acceleration adds another variable that shifts year to year. GPU-focused zero-knowledge infrastructure vendors such as Ingonyama build accelerated multi-scalar multiplication and number-theoretic-transform libraries that both Groth16 and PLONK-family provers can call into, since both proof systems bottleneck on the same underlying elliptic-curve and polynomial arithmetic. That means raw proving-time comparisons between the two systems can shift significantly depending on whether a team is running a CPU-only implementation or a GPU-accelerated one, which is one more reason the specific benchmark numbers above should be read as directional rather than as a permanent ranking.
Recursion and Proof Aggregation
Modern rollup architecture leans heavily on recursive proofs: proofs that verify other proofs, letting a chain compress thousands of transactions into one final proof posted to Ethereum. PLONK-family systems, especially Halo2, were built with this in mind and are widely described in current survey material as more recursion-friendly than vanilla Groth16, because their polynomial-commitment structure composes more naturally across proof layers. That is a major reason PLONK derivatives dominate the middle layers of modern zkEVM proving pipelines.
Groth16 still shows up at the very end of many of these pipelines rather than throughout them. Its small, fixed proof size makes it a good final wrapper, taking a larger intermediate proof from a recursion-friendly system and compressing it into something cheap to verify on Ethereum, even though Groth16 itself is not the system doing the recursive aggregation. Polygon’s zkEVM is the most frequently cited example of this hybrid approach: a FRI-based SNARK layer handles the heavy computation, and a final Groth16 wrap keeps on-chain verification cheap.
Where Groth16 and PLONK Fit in the Broader zk-Proof Family
Groth16 and PLONK are both zk-SNARKs, which puts them in one branch of a larger zero-knowledge proof family that also includes zk-STARKs and Bulletproofs. Our zk-SNARKs vs zk-STARKs comparison covers the bigger structural split: STARKs trade a much larger proof for the complete removal of any trusted setup, using hash-based commitments instead of elliptic-curve pairings or polynomial commitments tied to an SRS. That tradeoff is also why Polygon’s zkEVM pairs a FRI-based STARK-style layer with a Groth16 wrapper rather than using Groth16 end to end: STARKs handle the trusted-setup-free heavy lifting, and Groth16 handles the cheap final compression.
Bulletproofs sit at a third point on the same map, trading proof size for a setup-free design in a different way than STARKs do. Our coverage of Bulletproofs vs zk-STARKs and Bulletproofs vs zk-SNARKs walks through why Bulletproofs became the default for confidential transaction amounts in systems like Monero and Grin, even though their proof size and verification cost make them a poor fit for the high-frequency rollup verification that Groth16 and PLONK are built for. None of these systems has “won” outright, which is the same conclusion this Groth16-versus-PLONK comparison keeps landing on: the right proving system depends on whether a protocol values proof size, setup-free security, or circuit flexibility most.
Merkle structures show up underneath most of these systems too, as the data structure that lets a prover commit to large state without hashing the entire dataset for every proof. Our explainer on Merkle Trees vs Verkle Trees covers how Ethereum’s own state-proof design is evolving in parallel with the SNARK proving-system debate described here, and why smaller state proofs matter for the same reason smaller zk-SNARK proofs do: less data posted on-chain means lower gas costs for everyone verifying it.
Common Mistakes When Choosing a Proving System
The most frequent mistake teams make is picking a proving system based on a single headline benchmark rather than their own circuit. Aztec’s finding that PLONK ran roughly five times faster than Groth16 applied specifically to Pedersen hash-heavy circuits. A different 2026 benchmarking study found Groth16 winning on prover time and memory for other ZK-friendly hash workloads. Treating either result as a universal ranking, rather than a workload-specific data point, leads teams to choose a system that performs worse on their actual circuit than the alternative would have.
A second common mistake is underestimating how disruptive a circuit change is under Groth16. Teams that expect to iterate quickly, adding features, fixing edge cases, tuning constraints, often commit to Groth16 for its small proof size without accounting for the operational cost of running a new MPC ceremony every time the circuit changes. That cost is not just engineering time. It is also a fresh round of trust assumptions about ceremony participants each time. A third mistake runs the other direction: adopting PLONK’s universal setup for a circuit that will never change, and paying a permanently larger proof and higher gas bill for flexibility the protocol will never use. Zcash and Filecoin are the clearest counterexamples, both of which stuck with Groth16 specifically because their core circuits are stable enough that the per-circuit ceremony cost was a one-time expense rather than a recurring one.
A fourth mistake is assuming a proving system decision is permanent and binary. Polygon’s zkEVM, Scroll, and zkSync all demonstrate that hybrid architectures, layering a recursion-friendly system underneath and a compact final wrapper on top, are a legitimate third option that avoids forcing an all-or-nothing choice between Groth16’s cheap verification and PLONK’s flexible setup. Teams that treat the decision as strictly binary often over-optimize for one property at the expense of the other, when the production systems covered in this article increasingly do not make that tradeoff at all.
Full Specs Comparison Table
| Property | Groth16 | PLONK |
| Published | 2016 | 2019 |
| Proof size (BLS12-381) | ~192 bytes | ~576 bytes (benchmark) / 0.8–1.2 KB (production) |
| Proof size (BN254) | ~128 bytes | Varies by implementation |
| Trusted setup type | Per-circuit MPC ceremony | Universal, updatable SRS |
| Reusable across circuits | No — new ceremony per circuit | Yes, within the SRS size bound |
| On-chain verification gas | ~200,000–230,000 | ~300,000+ |
| Off-chain verification speed (benchmark) | ~3.1 ms | ~5.2 ms |
| Recursion / aggregation friendliness | Limited — typically final layer only | Strong — common in rollup pipelines |
| Commitment scheme | Pairing-based | Polynomial commitment (commonly KZG) |
| Circuit flexibility post-setup | Fixed to one circuit | Flexible across many circuits |
| NIST or IETF standardization | None identified | None identified |
| Notable 2026 adopters | Zcash, Filecoin, Tornado Cash, Polygon zkEVM (final layer) | zkSync (Boojum), Scroll (Halo2), Aztec |
Who Uses Each System in 2026
Groth16 in Production
Zcash’s technology documentation confirms that shielded transactions since the Sapling upgrade still run on Groth16, making it one of the longest-running production deployments of any zk-SNARK system. Filecoin’s storage network is widely described as still built on Groth16 for its proof-of-replication and proof-of-spacetime circuits, the mechanisms that let the network verify storage providers are actually holding the data they claim to hold. Tornado Cash’s circuit documentation, still mirrored across multiple archives, describes its privacy pool generating Groth16 proofs verified through on-chain Solidity verifier contracts. Polygon’s zkEVM design, per a 2026 technical survey, composes a FRI-based SNARK with a final Groth16 wrapping layer specifically to keep smart-contract verification succinct and cheap.
PLONK and Its Derivatives in Production
zkSync’s Boojum prover, per current comparative material, is built on PLONKish arithmetization, placing it firmly in the PLONK-derivative camp rather than the Groth16 camp. Scroll’s public documentation and 2026 project comparisons both identify its proving stack as Halo2 with KZG commitments, a direct PLONK descendant chosen for its recursion-friendly structure across Scroll’s zkEVM circuits. Aztec is likewise grouped with the PLONK and Halo2 family in current landscape write-ups, reflecting its emphasis on flexible, privacy-preserving smart contract circuits that benefit from a universal setup rather than a per-circuit ceremony.
Seven production deployments make the split easy to see at a glance. Four lean on Groth16 specifically because their circuits are stable and verification cost matters more than flexibility. Three lean on PLONK or a Halo2-family derivative because they are actively iterating on circuit design or depend on recursive proof composition.
| Project | Proving System | What It Proves |
| Zcash | Groth16 | Shielded transaction validity (Sapling era onward) |
| Filecoin | Groth16 | Proof-of-replication and proof-of-spacetime storage proofs |
| Tornado Cash | Groth16 | Membership proofs for the privacy pool’s on-chain verifier |
| Polygon zkEVM | FRI-based SNARK + Groth16 wrap | EVM execution, with Groth16 compressing the final proof |
| zkSync (Boojum) | PLONKish | zkEVM execution proofs for zkSync’s rollup |
| Scroll | Halo2 with KZG commitments | zkEVM execution proofs for Scroll’s rollup |
| Aztec | PLONK / Halo2 family | Private smart contract execution |
Migration Guide: Moving a Circuit from Groth16 to PLONK
Teams that outgrow Groth16’s per-circuit ceremony, usually because they are iterating on circuit design faster than they want to run new MPC ceremonies, tend to follow a similar migration path toward a PLONK-family system. This is not a drop-in swap, since it touches the arithmetization, the setup, and the on-chain verifier. Budget several weeks for the rewrite on any circuit of meaningful size, since the constraint system itself has to be re-expressed rather than mechanically translated, and plan the gas-cost increase into the protocol’s economics before committing to the migration.
- Audit the existing R1CS circuit and identify which constraints can be expressed more efficiently with PLONK’s custom gates or lookup arguments.
- Choose a specific PLONK variant (vanilla PLONK, TurboPLONK, UltraPLONK, or Halo2) based on whether the circuit needs custom gates, lookups, or full recursion support.
- Select or generate a universal SRS large enough for the new circuit, using a public ceremony such as the Ethereum KZG Ceremony or Perpetual Powers of Tau rather than running a new bespoke ceremony.
- Re-express the circuit’s constraints in the target proving library’s arithmetization format, since PLONK’s gate structure differs from Groth16’s R1CS.
- Regenerate proving and verification keys from the universal SRS instead of a per-circuit ceremony output.
- Deploy a new on-chain verifier contract sized for PLONK’s larger proof and higher gas cost, and budget for the roughly 70,000 to 100,000 additional gas per verification.
- Benchmark prover time and memory on production-representative circuit inputs, since PLONK-family performance varies sharply by implementation and circuit type.
- Run both verifiers in parallel during a transition window if the protocol cannot tolerate downtime, verifying new proofs under the PLONK path while legacy Groth16 proofs still settle under the old one.
- Decide whether to keep a final Groth16 wrapping layer for cost control, following the pattern used by Polygon’s zkEVM, or verify PLONK proofs directly on-chain.
A minimal circom-to-snarkjs style toggle looks like this at the tooling level, switching only the proving system flag while keeping the same circuit definition where the library supports both backends. This works only for the simplest circuits. Anything using PLONK-specific custom gates or lookup tables needs the constraint system rewritten from scratch rather than re-flagged.
snarkjs groth16 setup circuit.r1cs pot_final.ptau circuit_0000.zkey
snarkjs plonk setup circuit.r1cs pot_final.ptau circuit_plonk.zkeyIn practice, most real migrations involve more than a flag change since custom gates and lookup tables need circuit-level rewrites, but the setup step above illustrates the core difference: Groth16’s setup consumes a circuit-specific artifact, while PLONK’s setup pulls from the same universal ptau file regardless of circuit.
Pros and Cons
Groth16
- Smallest proof size of any production zk-SNARK, around 192 bytes on BLS12-381
- Cheapest on-chain verification, typically 200,000 to 230,000 gas
- A decade of production hardening through Zcash, Filecoin, and Tornado Cash
- Fast, close to constant-time verification regardless of circuit size
- Requires a new trusted-setup ceremony for every circuit change
- Poor fit for protocols that iterate on circuits frequently
- Weaker native support for recursive proof composition
PLONK
- Universal, updatable trusted setup that serves many circuits from one ceremony
- Strong recursion and aggregation support, favored in modern rollup pipelines
- Flexible custom gates and lookup arguments for specialized computation
- Backed by a large, active derivative ecosystem including Halo2, TurboPLONK, and UltraPLONK
- Larger proofs, roughly 576 bytes to 1.2 KB depending on configuration
- Higher on-chain verification gas, typically 300,000 or more
- Performance varies widely between implementations, complicating benchmarking
Use Cases: Which Proving System Fits Your Project
None of the recommendations below are exclusive, since several of the production systems already covered in this comparison mix approaches across a single pipeline. Use these as a starting point for narrowing the decision, then validate against your own circuit’s actual gate count, hash function choice, and expected upgrade frequency before committing.
- Privacy-preserving payments with a stable circuit: Groth16 fits shielded-transaction systems like Zcash’s, where the circuit rarely changes and minimal on-chain footprint matters most.
- Decentralized storage proofs at massive volume: Filecoin-style proof-of-replication systems benefit from Groth16’s cheap, near-constant verification cost across huge numbers of daily proofs.
- General-purpose zkEVMs under active development: PLONK or Halo2 fits teams like Scroll and zkSync that are still iterating on circuit design and cannot afford a new ceremony every release.
- Rollup provers doing heavy recursive aggregation: PLONK-family systems handle proof-of-proofs composition more naturally, making them the default for multi-layer proving pipelines.
- Cost-sensitive final settlement layers: A hybrid approach, proving with a flexible system and wrapping the final proof in Groth16, follows Polygon zkEVM’s pattern for cutting the last-mile gas bill.
- Early-stage protocols still finalizing circuit design: PLONK’s universal SRS avoids the sunk cost of running repeated per-circuit ceremonies during active development.
The Verdict: Groth16 vs PLONK in 2026
Neither system has replaced the other, and the data explains why. Groth16 wins decisively on proof size (roughly 192 bytes versus 576 bytes to 1.2 KB) and on-chain verification cost (roughly 200,000 to 230,000 gas versus 300,000 or more), which is why Zcash, Filecoin, and Tornado Cash have kept it in production for years and why even PLONK-heavy zkEVMs like Polygon’s still wrap their final proof in Groth16. PLONK wins decisively on flexibility and recursion: a single universal SRS serving many circuits, and a structure that composes far more cleanly across the multi-layer proving pipelines that modern rollups like Scroll and zkSync depend on.
The practical rule that falls out of the 2026 landscape is straightforward. If a circuit is stable and verification cost is the binding constraint, Groth16 is still the better default. If a circuit is still evolving, or the architecture depends on recursive proof composition, PLONK or a Halo2-family derivative removes the ceremony bottleneck at the cost of a heavier, more expensive proof. Many of the largest 2026 deployments do not choose one exclusively. They use PLONK-family systems for the flexible, recursive middle of the pipeline and Groth16 for the fixed, cheap final wrap that actually touches Ethereum.
One caveat applies to both systems equally: neither Groth16’s pairing-based assumptions nor PLONK’s polynomial-commitment assumptions are post-quantum secure. That is a long-term concern rather than a 2026 one, since a cryptographically relevant quantum computer does not exist yet, but it is worth tracking alongside our broader cryptography coverage and our look at how NIST’s post-quantum standards leave older elliptic-curve and pairing-based systems exposed. For now, that exposure applies equally to a Groth16 verifier and a PLONK verifier, so it does not change the calculus in this comparison.
Frequently Asked Questions
These are the questions that come up most often once a team has read through the proof-size, gas-cost, and trusted-setup tradeoffs above and needs to translate them into an actual engineering decision.
Is Groth16 or PLONK more secure?
Both rely on well-studied pairing and polynomial-commitment assumptions and neither has a known practical break as of 2026. The bigger security variable is operational: Groth16’s per-circuit ceremony creates a one-time toxic-waste risk if every participant colludes, while PLONK’s universal SRS concentrates that same risk into a single reusable ceremony that many protocols can share.
Why do some rollups use both Groth16 and PLONK together?
Hybrid pipelines, like Polygon zkEVM’s FRI-plus-Groth16 design, use a flexible system for the heavy intermediate computation and Groth16 only at the final step, where its small proof size keeps the last on-chain verification cheap.
Does PLONK really need a new trusted setup for every project?
No, and that is the whole point of PLONK’s design. A single universal SRS, such as the output of the Ethereum KZG Ceremony, can serve any circuit that fits within its size bound, which is the opposite of Groth16’s per-circuit requirement.
Which proving system is cheaper to verify on Ethereum?
Groth16, by a meaningful margin. Typical verification runs 200,000 to 230,000 gas for Groth16 versus 300,000 or more for PLONK, a gap of roughly $5 to $15 per proof depending on gas price at current ETH prices near $2,435.
Is Halo2 the same thing as PLONK?
Halo2 is a PLONK derivative that adds its own commitment scheme and recursion tooling. It shares PLONK’s universal-setup philosophy and custom-gate arithmetization, and current adopters like Scroll list Halo2 with KZG commitments specifically, but it is not identical to the original 2019 PLONK paper.
Can I switch an existing Groth16 protocol to PLONK without downtime?
It is possible but not trivial. Teams typically run both verifiers in parallel during a transition window, settling legacy proofs under the old Groth16 verifier while new proofs move through the PLONK path, until the migration is complete.
Do zk proving-as-a-service companies charge a fixed price per proof?
Not publicly as of 2026. Providers including Succinct, RiscZero, and the =nil; Foundation handle pricing through negotiated enterprise deals, marketplace-style job pricing, or capacity-based billing rather than a published per-proof rate card.
Which system is faster to prove with?
It depends entirely on the circuit. Aztec’s 2026 benchmark found PLONK roughly five times faster than Groth16 on Pedersen hash-heavy circuits, while a separate 2026 benchmarking study found Groth16 faster on prover time and memory for different ZK-friendly hash workloads. Neither system wins across all circuit types, so benchmarking your own workload is the only reliable test.
Why does Polygon’s zkEVM use Groth16 if it already has a STARK-style prover?
Polygon’s design uses a FRI-based SNARK to do the heavy computation without a trusted setup, then wraps the result in a Groth16 proof purely to shrink the final artifact that gets posted to Ethereum. That hybrid pattern captures Groth16’s small proof size and cheap gas cost without forcing the whole pipeline through a per-circuit ceremony.
Are Groth16 and PLONK standardized by NIST or IETF?
No. Current sources reviewed for this comparison found no NIST or IETF standardization track for either proving system. Adoption is driven by protocol engineering teams and academic research rather than a formal standards body, which is part of why implementations and performance vary so widely across projects.
