Skip to content

SNARK Arena

zk-SNARKs · Groth16 & PLONK

Drive R1CS circuits and witnesses through both proving systems, run a real in-browser trusted-setup ceremony, and watch a leaked toxic-waste τ forge a proof.

ZK Proof Lab introduces Schnorr and Fiat-Shamir. SNARK Arena goes deeper into the two systems that power production zero-knowledge systems.

Groth16 (Groth 2016) and PLONK (Gabizon, Williamson, Ciobotaru 2019) are shown side by side with setup assumptions, proof sizes, and verification behavior. The interactive panels run real finite-field arithmetic in your browser — every number is computed live and small enough to check by hand.

EXHIBIT 01Definition and Properties

What is a zk-SNARK?

You'll learn: what the letters S-N-A-R-K mean, and what an arithmetic circuit and a witness actually are — by driving one yourself below.

SNARK means Succinct Non-interactive ARgument of Knowledge.

Succinct: proof is small (often hundreds of bytes) regardless of computation size.

Non-interactive: prover sends one message; no back-and-forth transcript.

Argument of Knowledge: verifier is convinced prover knows a witness satisfying the circuit.

Completeness: honest prover with valid witness is accepted.

Soundness: cheating prover without witness is rejected except negligible probability.

Zero-knowledge: proof reveals nothing about the witness beyond validity.

A circuit is an arithmetic constraint system over a finite field. The classic teaching example proves knowledge of x such that x³ + x + 5 = 35. It compiles to three rank-1 constraints over the field, with witness wires v1 = x·x and v2 = v1·x.

Interactive: R1CS Circuit Playground

Public statement: “I know a secret x with x³ + x + 5 = 35.” The verifier sees only that the output wire equals 35. Your secret x is the witness.

3

Drag to choose x. The wires recompute over the field Fp, p = 8191, and every constraint is checked live.

Why this matters: zk-SNARKs underpin Zcash private transfers, zkEVM rollups, zkLogin, Semaphore identity proofs, and anonymous credential systems. For foundational Schnorr, Fiat-Shamir, and commitment mechanics, see ZK Proof Lab.
Key takeaway A proof is "I have a witness that satisfies every constraint." The multiplication gates pin the intermediate wires; the public wire pins the answer. Only x = 3 satisfies all three.
LIVEReal Groth16 · runs in your browser

Now Prove It For Real

You'll learn: that none of this is hand-waving. Here is a genuine Groth16 proof of the exact same circuit, generated and verified entirely in your browser with snarkjs — no server, no simulation.

The playground above used a toy field so you could read every number. This panel runs the production stack on the same statement x³ + x + 5 = out: a circom circuit compiled to a witness generator, proven over the BN254 curve using a real powers-of-tau + phase-2 trusted setup.

The artifacts — the witness-generator WASM (34 KB), the proving key (3.6 KB), and the verification key — are static files shipped with the page. That is precisely why a real SNARK works on GitHub Pages with no backend: proving and verifying are pure client-side computation.

Live: Groth16 prove + verify (snarkjs / BN254)

3

Pick your secret x. The prover computes out = x³ + x + 5 and proves it knows an x producing that output — without revealing x. First proof loads the ~0.7 MB snarkjs library; later proofs are instant.

Not simulated: snarkjs.groth16.fullProve runs the real proving algorithm on the WASM witness generator and a proving key from an actual ceremony. It runs single-threaded — GitHub Pages can't send the COOP/COEP headers that multi-threaded WASM needs — which is still plenty fast for a circuit this size.
Why this matters: the gap between "toy demo" and "production zk" is mostly artifact size and ceremony rigor, not architecture. The same three calls — compile, prove, verify — scale from this 3-constraint circuit to Zcash's millions.
Key takeaway Real client-side SNARKs need no server — only static artifacts. The proof is ~256 bytes and verifies in milliseconds, no matter how large the circuit.
EXHIBIT 02Groth16 Per-Circuit Setup

Groth16: Per-Circuit Trusted Setup

You'll learn: why Groth16's proofs are the smallest in production — and the price it pays: a fresh ceremony for every circuit.

Groth16 is a pairing-based SNARK over curves like BN254 and BLS12-381 using QAP-style encodings (Groth, EUROCRYPT 2016).

Setup has Powers of Tau plus a circuit-specific phase 2 that emits proving key and verification key.

Proof has three group elements (A, B, C). On BN254 this is 128 bytes; on BLS12-381 this is 192 bytes.

Workflow

Circuit definition
Powers of Tau (universal)
Phase 2 (circuit-specific)
proving key + verification key
prove → verify

Sample Parameters: x² = 9

Constraint count: 2

Proving key size: 42 KB (simulated educational profile)

Verification key size: 1.6 KB (simulated educational profile)

Proof size: 128 bytes (BN254)

Proof bytes (hex, truncated):

Verification time: 1.4 ms

Simulated: Proof bytes are random for visualization; sizes/timings follow snarkjs benchmark conventions.
Awaiting verification...

Trusted Setup Ceremony Visualizer

Security holds if at least one participant destroys toxic waste.

One honest participant: the ceremony is secure if even one participant honestly deletes their randomness. No one can retroactively extract another participant's contribution from the final SRS. See the real math in Exhibit 05 ↓

Examples: Zcash Sapling (88 participants, 2018), Hermez (214 participants, 2021), Semaphore (open participation, thousands of contributors).

Why this matters: Groth16's tiny proofs and fast verification are ideal when every byte and millisecond matters, but each circuit needs its own phase-2 ceremony.
Key takeaway Smallest proof + fastest verify in production, paid for by a per-circuit trusted setup. Change the circuit, run a new ceremony.
EXHIBIT 03PLONK Universal Setup

PLONK: Universal Trusted Setup

You'll learn: how one universal setup serves many circuits, trading a few hundred extra proof bytes for deployment freedom.

PLONK uses polynomial commitments and a permutation argument in Lagrange form (ePrint 2019/953).

One universal setup (Powers of Tau) can support many circuits up to a maximum size.

Proofs are larger than Groth16 (typically around 400-500 bytes) with still-fast verification.

Workflow

Powers of Tau (once)
Any circuit under SRS bound
prove → verify
Simulated: Parameters from snarkjs benchmark data.

Sample Parameters: x² = 9

Proof size: 448 bytes

Proof bytes (hex, truncated):

Verification time: 3.8 ms

Awaiting verification...

Universal Setup Visualizer

Circuit A → same universal SRS
Circuit B → same universal SRS
Circuit C → same universal SRS

SRS examples: 2¹⁴ constraints ≈ 256 MB, 2²¹ constraints ≈ 2 GB.

Contrast with Groth16: Groth16 requires a new phase-2 ceremony for every circuit. PLONK reuses the same universal SRS — write your circuit today, no ceremony needed.

PLONK Variants

PLONK (original): KZG commitments.

TurboPlonk: custom gates (Aztec).

UltraPlonk: lookups and richer gate systems.

Halo2: no trusted setup via IPA commitments, used in Zcash Orchard and Scroll proving systems.

Why this matters: universal setup lowers deployment friction by removing per-circuit ceremonies for new applications.
Key takeaway Set up once, prove any circuit under the size bound. Slightly bigger proofs buy you freedom from per-circuit ceremonies.
EXHIBIT 04Head-to-Head

Groth16 vs PLONK on the Same Circuit

You'll learn: how to choose between the two — and where each one wins.

Groth16: x² = y

Proof bytes:

Proof size: 128 bytes (BN254)

Verification time: 1.5 ms

Setup type: per-circuit

PLONK: x² = y

Proof bytes:

Proof size: 448 bytes

Verification time: 3.9 ms

Setup type: universal

Simulated: byte strings are generated for visualization, with size and timing ranges aligned to snarkjs benchmark conventions.

Comparison Table

Comparison of Groth16 and PLONK proving systems
PropertyGroth16PLONK
Setup typePer-circuitUniversal (once)
Proof size128 bytes (BN254)~400-500 bytes
Verification time~1-2ms~3-5ms
Proving timeFastSlightly slower
Circuit languageR1CS / circomPLONKish / Halo2
Trusted setup riskCircuit-specificUniversal SRS
Recursive SNARKsComplexNative in Halo2 variants
Post-quantum safeNo (pairing-based)No (pairing-based)
Used inZcash, SemaphoreAztec, Polygon zkEVM

Decision Tree

I need smallest proof for fixed circuit → Groth16.

I need circuit flexibility without new ceremonies → PLONK.

I need recursive composition → Halo2.

I cannot run trusted setup → Halo2 or STARKs.

I need post-quantum security → STARKs.

Cross-link: Neither Groth16 nor PLONK is post-quantum secure — both rely on pairing-based assumptions. For the post-quantum alternative, see STARK Tower.
STARK Tower (post-quantum alternative)
Key takeaway Fixed circuit, every byte counts → Groth16. Evolving circuits, no new ceremonies → PLONK. No setup or post-quantum → Halo2 / STARKs.
EXHIBIT 05Trusted Setup Security

Trusted Setup Problem in Depth

You'll learn: what "toxic waste" really is, why one honest participant saves the whole ceremony, and — with live numbers — exactly how a leaked secret forges a proof for a false statement.

Toxic waste is the secret setup exponent τ. If retained, forged proofs for false statements become possible and soundness collapses.

Verification keys cannot detect forgeries made by a party holding toxic waste. This is a catastrophic failure mode.

MPC ceremonies chain contributions from many participants; the combined secret is their product τ = τ₁·τ₂·…·τₙ, so security holds if at least one honest participant deletes their factor.

Groth16 compromise is circuit-scoped to the affected phase-2 setup, while universal setup compromise can affect all circuits using that SRS.

Live: Powers-of-Tau Ceremony (real arithmetic)

Five participants each contribute a secret factor τᵢ. The combined secret is the running product, and the public SRS element is gτ. Toggle who deletes their waste, then run.

Toy scale: group order r = 17, generator g = 64 mod 103. Real ceremonies use 254-bit curves where recovering τ from gτ is infeasible (discrete log).

Live: Forge a Proof if τ Leaks (KZG opening)

A KZG commitment to a polynomial f(x) is C = gf(τ). An honest opening proves f(z) = y. Watch what an honest prover can do, then what an attacker who kept τ can do.

What's real vs. shown: the SRS, commitment, quotient polynomial, and proof element are computed with real modular arithmetic. The accept/reject decision is the exponent equality f(τ)−y = q(τ)·(τ−z) that a real bilinear pairing enforces using only C, π, and the SRS — never τ.

Ceremony Timeline

Zcash Sprout (2016): 6 collocated participants.

Zcash Sapling (2018): 88 participants over 6 weeks.

Hermez 1.0 (2021): 214 participants.

Semaphore: open participation, thousands of contributors.

Ethereum KZG Ceremony for EIP-4844 (2023): approximately 141,000 contributors.

Why this matters: trusted setup is an operational security cornerstone. If it fails, proof security fails completely.
Key takeaway τ is the keys to the kingdom. The ceremony survives if one participant deletes their factor; it dies the instant anyone can reconstruct τ — then any lie verifies.
EXHIBIT 06Production Deployments

SNARK Applications in Production

You'll learn: where these proving systems run today, and what statement each one proves.

A. Zcash Shielded Transactions (Groth16)

Every shielded transaction proves: "I know a spending key and note commitment that authorizes spending this amount" without revealing either.

Circuit: Sapling circuit, ~4 million constraints. Proof: 192 bytes (BLS12-381), generated in ~2–3 seconds on mobile. Verification: ~10 ms on a full node. Same circuit since 2018 Sapling upgrade.

B. Polygon zkEVM (PLONK/FFLONK)

Proves correct execution of Ethereum EVM bytecode. The proof allows Ethereum mainnet to verify L2 transactions without re-executing them — this is how zkRollups achieve scalability.

Circuit: millions of constraints for EVM opcode coverage. FFLONK (Fast PLONK variant): ~800 byte proofs, ~200 ms verification on-chain.

C. WorldID / Semaphore (Groth16)

Proves: "I am a unique human who has not already voted in this poll" without revealing which human. Uses Groth16 with the Semaphore ceremony.

Enables anonymous, sybil-resistant voting and credential systems.

D. zkLogin (Sui Network, Groth16)

Proves: "I own this OAuth account (Google/Apple)" without revealing which account or its credentials. Enables blockchain accounts controlled by OAuth credentials.

Generates proofs client-side in ~2 seconds.

Why this matters: SNARKs are deployed infrastructure for privacy, identity, and scaling, not only research artifacts.
Key takeaway Every deployment is one sentence — "I know X without revealing X" — compiled to a circuit and proven succinctly.
REFERENCEGlossary

Glossary of Terms

Witness
The secret input the prover knows (here, x). A valid witness makes every constraint hold.
Circuit
A computation expressed as arithmetic constraints over a finite field. The statement to prove.
R1CS
Rank-1 Constraint System: each constraint has the shape (A·s)(B·s) = (C·s) — one multiplication per constraint.
Finite field Fp
Arithmetic mod a prime p. All SNARK values live here. Division means multiplying by a modular inverse.
Trusted setup / SRS
A Structured Reference String of group elements gτⁱ generated once, needed by pairing-based SNARKs.
Toxic waste (τ)
The secret exponent behind the SRS. Must be destroyed; whoever keeps it can forge proofs.
KZG commitment
A constant-size commitment gf(τ) to a polynomial, with succinct opening proofs. The core of PLONK.
Pairing
A bilinear map e(ga, gb) = e(g,g)ab that lets a verifier check products "in the exponent" without learning a or b.
Succinct
Proof size and verification time stay small (often constant) no matter how large the computation is.
Soundness
A prover without a valid witness is rejected except with negligible probability.
CHECKPOINTSelf-Check

Self-Check: Did It Land?

Five questions. Answer from memory; each reveals an explanation. No score is stored — this is for you.