The Grand Comparison: Every ZKP System, Every Dimension — Article 8 of the ZKP Systems Series
--
You’ve made it to the end of the series. Eight articles, 28 proof systems, four decades of cryptographic history compressed into a reading arc that took you from “what is a zero-knowledge proof” to “which systems survive a quantum computer.”
This final article is a reference document. It answers the question every engineer eventually asks: given my constraints, which system should I use?
We’ll cover the full comparison table first, then a decision framework, then the systems worth watching in 2025 and beyond.
The Complete Comparison Table
Every system in this series, across every dimension that matters for a practical decision.
Columns explained:
- Proof size — the size of the proof sent from prover to verifier
- Prover time — relative to Groth16 baseline (1.0x)
- Verifier time — how fast verification runs
- Trusted setup — None / Universal / Circuit-specific
- Transparent — no trusted setup of any kind
- Universal — one setup for any circuit
- PQ safe — post-quantum secure
- Paradigm — how you write programs for this system
The Decision Framework
Rather than telling you which system to use, here is the decision tree every serious engineer should walk through.
Step 1: Do you need post-quantum security?
Is your application's security horizon > 10 years?
├── YES → eliminate all ECDLP-based systems
│ Remaining: Ligero, Aurora, Virgo, STARK, Zilch,
│ Plonky2, Plonky3, SP1, Hyperbridge
└── NO → all systems are available for current deployment
(but plan a migration path)Step 2: Can you tolerate a trusted setup?
Can you run or participate in a trusted setup ceremony?
├── YES → Groth16 and PLONK become available
│ (smallest proofs, fastest verification)
└── NO → eliminate circuit-specific and universal-setup systems
Remaining: transparent systems onlyStep 3: What is your proof size budget?
Is the proof verified on-chain (L1 Ethereum)?
├── YES → proof size is critical (calldata costs)
│ Best: Groth16 (~200 B) if setup acceptable
│ PLONK (~800 B) if universal setup needed
│ Plonky3 recursion (~50 KB, but aggregated)
└── NO → proof size is less critical
STARK, Plonky2, SP1 all acceptableStep 4: What is your programming model preference?
# Decision map by developer profile
decision_map = {
"I want to write normal Rust": {
"system": "SP1 or Risc0",
"note": "No circuits needed - just write your program"
},
"I need max performance, willing to write circuits": {
"system": "Plonky3 or Halo2",
"note": "Custom gates, full control over constraint system"
},
"I'm building on Ethereum, need on-chain verification": {
"system": "Groth16 or PLONK (via snarkjs/circom)",
"note": "Mature tooling, Solidity verifiers available"
},
"I need recursive proofs + no trusted setup": {
"system": "Halo2 or Plonky2",
"note": "Halo2 if not PQ concerned; Plonky2 if PQ matters"
},
"I'm building a privacy coin or confidential transactions": {
"system": "Bulletproofs (range proofs) or STARK",
"note": "Bulletproofs for compact range proofs; STARK for PQ"
},
"I need the absolute smallest proof": {
"system": "Groth16",
"note": "200 bytes, unbeaten after 8 years - accept the ceremony"
}
}
for use_case, recommendation in decision_map.items():
print(f"Use case: {use_case}")
print(f" → {recommendation['system']}")
print(f" Note: {recommendation['note']}")
print()Step 5: Which ecosystem fits your stack?
Language / tooling preference:
├── Rust → SP1, Risc0, Halo2 (halo2_proofs crate)
├── TypeScript/JS → snarkjs + circom (Groth16, PLONK)
├── Python → py_ecc, arkworks bindings (research/prototyping)
├── Cairo → zk-STARK (StarkNet ecosystem)
└── Leo → Marlin / Aleo ecosystemThe Three Tiers for Production Today
Based on maturity, tooling, and deployment track record, production systems fall into three tiers:
Tier 1 — Battle-tested in production
Groth16 — Zcash Sapling (2018–present), Tornado Cash, Polygon Hermez. Millions of proofs generated. Solidity verifiers audited multiple times. Use for: Ethereum applications where proof size is critical and you can run a ceremony.
zk-STARK — StarkNet, StarkEx (dYdX, Sorare, Immutable X). Billions of dollars of transaction volume proved. Production Cairo tooling mature. Use for: large-scale L2 rollups, applications requiring PQ safety.
Halo2 — Zcash Orchard, Scroll, Taiko. Production zkEVMs running on mainnet. Use for: EVM-equivalent applications, recursive proof systems, no trusted setup required.
PLONK — Aztec Network, multiple zkEVM variants. Universal setup eliminates per-circuit ceremony. Use for: applications with frequently changing circuits.
Tier 2 — Production-ready, growing adoption
Plonky2 — Powers several zkRollup aggregation layers. 100x faster recursion than prior systems. Use for: recursive proof aggregation, post-quantum requirements.
Plonky3 — SP1, Polygon AggLayer, Valida. Fastest prover available (2024). Use for: new projects where raw speed is the priority.
SP1 — Ethereum light client proofs in production (Succinct’s bridge). Use for: proving arbitrary Rust programs, applications where circuit writing is impractical.
Bulletproofs — Monero, Grin. Range proofs only — not general-purpose. Use for: confidential transaction amounts in privacy coins.
Tier 3 — Research / niche
Nova — Nexus zkVM, research projects. Excellent for IVC but not yet production-proven. Use for: incremental computations, research.
Marlin — Aleo. Strong R1CS-native system but limited to that ecosystem.
Ligero, Aurora, Virgo — Important historically and for PQ research, but limited production tooling. Use for: academic research, understanding PQ foundations.
Proof Size vs Prover Speed: The Core Trade-off Visualized
Proof size (log scale, smaller = better)
│
200B┤ ● Groth16 ← smallest
│
800B┤ ● PLONK
│
1KB┤ ● Marlin ● Bulletproofs
│
10KB┤ ● Halo2 ● Halo ● Nova
│
100KB┤ ● Plonky2 ● Plonky3 ● Virgo ● Aurora
│
300KB┤ ● zk-STARK ● Zilch
│
1MB┤ ● SP1
│
└──────────────────────────────────────────────────────────
faster prover ←──────────────────────────────→ slower prover
0.2x 1x 5x 10x 20x
(Plonky3) (Groth16) (Bulletproofs) (Aurora) (Sonic)
PQ-safe systems: Ligero, Aurora, Virgo, STARK, Zilch, Plonky2, Plonky3, SP1, HyperbridgeThe top-left corner — tiny proof, fast prover — is where Groth16 lives alone. The post-quantum systems cluster in the bottom-right. The engineering progress from 2019 to 2024 is visible as PQ-safe systems move toward the top-left: Plonky3 is now in the same prover speed tier as Groth16 while maintaining PQ safety, at the cost of larger proofs.
Benchmarks: The Same Circuit Across Systems
To make the comparison concrete, here are approximate benchmarks for proving a Poseidon hash computation (a common ZK-friendly hash, ~1000 gates) across systems:
# Approximate benchmarks — 1000-gate Poseidon hash circuit
# Hardware: modern server (32-core, 64GB RAM)
# These are order-of-magnitude estimates, not precise measurements
benchmarks = {
"Groth16": {
"proof_size_bytes": 192,
"prover_ms": 50,
"verifier_ms": 2,
"trusted_setup": "circuit-specific",
"pq_safe": False
},
"PLONK (snarkjs)": {
"proof_size_bytes": 800,
"prover_ms": 100,
"verifier_ms": 5,
"trusted_setup": "universal",
"pq_safe": False
},
"Halo2": {
"proof_size_bytes": 5000,
"prover_ms": 150,
"verifier_ms": 10,
"trusted_setup": "none",
"pq_safe": False
},
"zk-STARK": {
"proof_size_bytes": 150_000,
"prover_ms": 250,
"verifier_ms": 30,
"trusted_setup": "none",
"pq_safe": True
},
"Plonky2": {
"proof_size_bytes": 80_000,
"prover_ms": 100,
"verifier_ms": 20,
"trusted_setup": "none",
"pq_safe": True
},
"Plonky3": {
"proof_size_bytes": 50_000,
"prover_ms": 10, # Goldilocks/M31 field speed
"verifier_ms": 15,
"trusted_setup": "none",
"pq_safe": True
},
}
print(f"{'System':<20} {'Proof':>10} {'Prover':>10} {'Verifier':>10} {'Setup':<20} {'PQ'}")
print("-" * 80)
for name, b in benchmarks.items():
pq = "✓" if b["pq_safe"] else "✗"
proof = f"{b['proof_size_bytes']:,} B"
prover = f"{b['prover_ms']} ms"
verifier = f"{b['verifier_ms']} ms"
print(f"{name:<20} {proof:>10} {prover:>10} {verifier:>10} {b['trusted_setup']:<20} {pq}")The key takeaway: Plonky3 has effectively matched Groth16’s prover speed while being post-quantum safe and requiring no trusted setup. The remaining gap is proof size — 50 KB vs 192 bytes. Recursive aggregation closes most of this gap at scale.
What’s Coming Next
The ZKP field moves faster than almost any area of applied cryptography. Here are the directions most likely to produce significant new systems in 2025–2027:
Lattice-based SNARKs — NIST standardized lattice-based signatures and key encapsulation in 2024. Lattice-based proof systems offer post-quantum security with potentially smaller proofs than FRI-based systems. Early constructions exist (Banquet, Ligero++), but none are production-ready.
FRI + PLONK hybrids — Plonky2 showed this works. The next generation will optimize FRI parameters specifically for PLONK custom gates, potentially closing the gap with KZG-based proof sizes.
zkML (ZK Machine Learning) — Proving that a neural network inference was computed correctly, without revealing the model weights. EZKL and similar projects are making this practical with Halo2 and PLONK backends. As models get larger, the demand for efficient ML proof systems will drive new constructions.
On-chain STARK verification cost reduction — Current STARKs are expensive to verify on L1 Ethereum. EIP proposals for STARK-specific precompiles would reduce verification cost 10–100x. If adopted, this would make STARK proofs economical for a much wider class of applications.
Post-quantum Halo2 — Multiple teams are working on replacing Halo2’s IPA with a hash-based commitment scheme. Success would give the largest existing deployment base (Zcash, Scroll, Taiko) a migration path to post-quantum safety without rewriting circuits.
How to Use This Series
If you’re a developer building a ZK application: read Articles 0, 2, 3, and 6. Understand Groth16 (still the most common), PLONK (the most flexible), and SP1 (the easiest). Use the decision framework in this article.
If you’re a researcher entering the ZK space: read the full series in order. The progression from Pinocchio to Nova to Plonky3 is the most efficient path through the field’s history.
If you’re an engineer evaluating ZK for your product: read Article 0 (taxonomy), Article 7 (quantum), and this article. That’s all you need to make an informed system selection decision.
If you’re a cryptographer reviewing someone else’s work: Articles 2–5 give you the vocabulary to reason about any proof system’s security assumptions and trade-offs.
The Series in One Sentence Per Article
Article 0 — ZKP is a family of 28+ systems, not one thing; they differ on setup, universality, and quantum resistance.
Article 1 — Pinocchio (2013) made SNARKs practical by encoding computation as R1CS and verifying via QAP over elliptic curve pairings.
Article 2 — Groth16 (2016) compressed the proof to its theoretical minimum — 3 group elements — by baking the circuit into the setup.
Article 3 — Sonic, PLONK, and Marlin (2019) independently solved circuit-specific setup; PLONK won through extensibility, not performance.
Article 4 — Bulletproofs, Halo, and Halo2 eliminated trusted setup entirely; the cost is larger proofs and, critically, they remain vulnerable to quantum attacks.
Article 5 — Ligero, Aurora, Virgo, and zk-STARK replaced elliptic curves with hash functions, achieving post-quantum security at the cost of much larger proofs.
Article 6 — Nova’s folding schemes reduced recursion overhead from 100x to 15%; Plonky2 made recursive proofs 100x faster; SP1 made ZK proofs accessible to anyone who can write Rust.
Article 7 — Shor’s algorithm breaks all ECDLP-based systems; hash-based systems survive with parameter adjustments; no trusted setup ≠ post-quantum safe.
Article 8 (this one) — When choosing a system: decide on PQ requirements first, then setup tolerance, then proof size budget, then programming model.
Final Thought
Zero-knowledge proofs are one of the most intellectually beautiful areas of computer science. The ability to convince someone of a truth without revealing why it is true sits at the intersection of philosophy, mathematics, and engineering in a way few technologies do.
But they are also increasingly practical. In 2013, Pinocchio proved you could verify a computation in 6 milliseconds. In 2024, SP1 proves arbitrary Rust programs, Plonky3 generates proofs faster than Groth16, and StarkNet processes millions of transactions per day with post-quantum security.
The gap between “theoretically possible” and “runs in production at scale” closed in eleven years. The gap between “current production systems” and “post-quantum safe production systems” is closing now.
If you’ve read this series from the beginning, you are now equipped to read any new proof system paper and understand where it sits in this landscape — what problem it solves, what trade-offs it accepts, and whether it will survive the quantum transition.
That’s the vocabulary the field requires. Use it well.
End of Series
Thank you for reading. If you found this series useful, the best way to support continued writing is to share it with someone who is trying to understand ZKP systems. The field needs more people who can reason clearly about these trade-offs.
Full Series Index
- Article 0: A Field Guide Before You Get Lost
- Article 1: Pinocchio and the Procedural Era (2013–2018)
- Article 2: Groth16 — Why Three Group Elements Is All You Need
- Article 3: The Universal Setup Race — Sonic, PLONK, and Marlin
- Article 4: No Trusted Setup — Bulletproofs, Halo, and Halo2
- Article 5: Hash Functions All the Way Down — The Post-Quantum Systems
- Article 6: Folding Schemes and the zkVM Era
- Article 7: The Quantum Threat — Which Systems Survive
- Article 8: The Grand Comparison (this article)
References
- All papers cited in Articles 0–7
- Thaler, J. — “Proofs, Arguments, and Zero-Knowledge” (textbook, 2022) — the definitive technical reference
- ZKProof Community — https://zkproof.org — standardization efforts
- awesome-zero-knowledge-proofs — github.com/matter-labs/awesome-zero-knowledge-proofs
- ZK Hack — zkhack.dev — hands-on learning resources
