Imagine a Vietnamese village at night. Two watchmen patrol the streets, each with a different philosophy of security.
Watchman A (SNARK) carries a master key — a single secret that unlocks every door in the village. He proves he checked every house by showing you a magical seal that only his key could create. The seal is tiny, elegant, and verifies instantly. But there's a catch: the key was forged in a secret ceremony years ago. If anyone who attended that ceremony kept a copy, they can forge seals for houses they never visited.
Watchman B (STARK) carries no keys. Instead, he posts the patrol rules on the village gate for everyone to see: "I check each door at midnight. I shout the result. Anyone can verify by checking the echoes." His proof is a long scroll of shouted results, each bound to the next by mathematical chains anyone can follow. No secret ceremony. No master key. Just transparent rules and public verification.
This is snark vs stark in a nutshell — two fundamentally different approaches to zero-knowledge proofs (ZKP), the cryptographic magic powering privacy coins, zk-rollups, and the next generation of blockchain scaling.
What Are Zero-Knowledge Proofs? (The Village Context)
Before comparing our two watchmen, let's understand what they're actually proving.
A zero-knowledge proof lets a prover convince a verifier that a statement is true — without revealing why it's true. In our village:
- Statement: "I know the secret password to the treasury."
- Prover: The watchman claiming to have checked the treasury.
- Verifier: The village elder who needs assurance but must not learn the password.
- Zero-knowledge: The elder learns that the watchman knows the password, but not what the password is.
Both SNARK and STARK achieve this. They differ in how they construct the proof, what assumptions they require, and what tradeoffs they make.
SNARK: The Watchman with a Master Key
SNARK = Succinct Non-interactive ARgument of Knowledge.
How SNARK Works (The Sealed Envelope)
Think of SNARK as a sealed envelope containing a polynomial — a mathematical object encoding the entire computation.
- Trusted Setup (The Key Ceremony): Before any proofs exist, a group of participants runs a multi-party computation (MPC) ceremony — the famous Powers of Tau. Each adds their secret randomness, then destroys it. The output: a proving key and verification key. If all participants collude (or one keeps their secret), they can forge proofs for false statements.
- Proving: The prover takes the proving key + their private inputs (witness) + the public circuit → generates a proof. In Groth16 (the classic SNARK), this proof is just 3 group elements (~200 bytes).
- Verification: The verifier uses the verification key + public inputs + proof → checks a few pairing equations. Done in milliseconds.
SNARK Variants You'll Meet
| Variant | Setup | Proof Size | Verification | Used By |
|---|---|---|---|---|
| Groth16 | Per-circuit trusted setup | ~200 bytes | Fastest (3 pairings) | Zcash, Tornado Cash, early zk-rollups |
| PLONK | Universal trusted setup | ~1-2 KB | Fast | zkSync v1, Aztec, Polygon Hermez |
| Halo2 | No trusted setup (IPA) | ~5-10 KB | Slower | Midnight, Penumbra, Electric Coin Co. |
| Plonky2 | Universal trusted setup | ~100-200 KB | Very fast (recursive) | Polygon zkEVM, RISC Zero |
Key insight: "Universal setup" means one ceremony serves many circuits — but it's still a trusted setup.
STARK: The Watchman with Public Rules
STARK = Scalable Transparent ARgument of Knowledge.
How STARK Works (The Public Shout)
STARK replaces the sealed envelope with a Merkle tree of polynomial evaluations — the FRI (Fast Reed-Solomon Interactive Oracle Proof) protocol.
- Transparent Setup: No ceremony. No secrets. Public parameters = hash function (Keccak-256 or Poseidon) + field parameters. Anyone can verify the parameters are correct.
- Arithmetization: The computation becomes a set of polynomial constraints over a finite field (usually a 64-bit or 256-bit prime field). Each execution step = one row in an execution trace table.
- Low-Degree Extension: The trace polynomials are extended to a larger domain. If the computation is valid, these polynomials have low degree.
- FRI Protocol: The prover commits to the polynomial via Merkle tree. The verifier queries random points. If the polynomial is not low-degree, the queries catch it with high probability. Repeat for soundness.
- Proof: A Merkle root + authentication paths for queried points. Proof size: 10-100 KB (larger than SNARK, but no trusted setup).
STARK Properties
| Property | SNARK (Groth16/PLONK) | STARK |
|---|---|---|
| Trusted Setup | Yes (per-circuit or universal) | No |
| Proof Size | ~200 bytes - 2 KB | 10-100 KB |
| Verification Time | ~1-5 ms (pairings) | ~10-50 ms (hash-based) |
| Prover Time | Fast (MSM-heavy) | Slower (FFT + FRI) |
| Quantum Resistance | Broken by quantum (pairings) | Resistant (hash-based) |
| Recursion | Needs cycle of curves | Native (FRI composes naturally) |
| Tooling Maturity | High (Circom, snarkjs, Arkworks) | Growing (Cairo, Stone, Winterfell) |
The Trusted Setup Ceremony: What Actually Happened
The most misunderstood part of SNARK. Let's demystify.
The Powers of Tau Ceremony (2022, Round 2)
- 100+ participants from Ethereum Foundation, Zcash, Filecoin, academia, individuals
- Each generated random secret → computed contribution → destroyed secret
- Security model: Only one honest participant needed. If any participant deletes their secret, the toxic waste is gone forever.
- Verification: Each contribution published; anyone can verify the transcript.
Analogy: Imagine 100 villagers each adding a secret ingredient to a communal pot, then burning their written recipe. The final broth (proving key) is public. To poison it, all 100 must have secretly kept their recipes and colluded.
Reality check: This is stronger than a single master key, but weaker than STARK's zero-trust model. The ceremony is a social trust assumption, not a mathematical one.
STARK Transparent Setup: No Ceremony Needed
STARK's setup is just public parameters:
`rust // STARK public parameters (simplified) struct StarkParams { field: PrimeField, // e.g., 2^64 - 2^32 + 1 (Goldilocks) or 256-bit hash: HashFunction, // Keccak-256 or Poseidon fri_folding_factor: u32, // 2, 4, 8... security_bits: u32, // 96, 128, 192... } `
Anyone can:
- Read the parameters
- Verify the field is prime
- Verify the hash function is standard
- Generate their own proving key — no ceremony, no trust
This is why "stark transparent setup" is a core differentiator.
Polynomial Commitments: The Heart of the Difference
Both systems need to commit to a polynomial then prove evaluations. This is where KZG (SNARK) and FRI (STARK) diverge.
KZG Commitment (SNARK) — The Sealed Envelope
Kate-Zaverucha-Goldberg (KZG) uses elliptic curve pairings.
` Commitment: C = [p(τ)]₁ (τ = secret from trusted setup) Opening proof: π = [(p(τ) - p(z)) / (τ - z)]₁ Verification: e(C - [p(z)]₁, [1]₂) = e(π, [τ - z]₂) `
- Commitment: Single group element (32 bytes on BLS12-381)
- Trust assumption: τ must be secret. If τ is known, anyone can forge openings for any polynomial.
- Used by: Ethereum EIP-4844 (blob commitments), PLONK, Groth16 (implicitly)
FRI Commitment (STARK) — The Merkle Tree of Evaluations
Fast Reed-Solomon IOP (FRI) uses hash-based commitments.
`
- Evaluate polynomial p(x) on large domain D → vector v
- Commit: Merkle root of v
- FRI rounds: Fold v → v' → v'' ... until degree < threshold
- Proof: Merkle paths for queried indices in each round
`
- Commitment: Merkle root (32 bytes)
- Trust assumption: None. Hash function is public.
- Proof size: Grows with domain size and security level
- Used by: StarkNet, zkSync Era (validity proofs), Winterfell, Stone
Figure 1: Two night watchmen — SNARK (master key) vs STARK (public rules)
Figure 2: Trusted setup ceremony vs transparent setup
When to Choose Which? (The Decision Framework)
Choose SNARK When:
- Proof size matters most — On-chain verification (Ethereum calldata costs)
- Verification speed critical — High-throughput settlement layers
- Mature tooling needed — Circom, snarkjs, established audit frameworks
- Recursion via cycles acceptable — Halo2, Nova, or cycle-of-curves approach
- Team knows elliptic curve crypto — Pairings, MSM optimization
Real-world: Zcash (shielded txs), Tornado Cash (privacy), zkSync v1, Aztec, Filecoin (WinningPoSt)
Choose STARK When:
- Trust minimization is paramount — No ceremony, no toxic waste, ever
- Quantum resistance required — Long-term secrets, state archives
- Large computations — STARK prover scales better for huge traces (VM execution)
- Native recursion needed — Recursive STARKs compose without curve cycles
- Willing to invest in tooling — Cairo, Stone, Winterfell learning curve
Real-world: StarkNet (validity rollup), zkSync Era (validity proofs), RISC Zero (ZK-VM), Polygon Miden, Herodotus (storage proofs)
The Hybrid Reality: Most Production Systems Use Both
Here's what vendors don't always advertise: most "STARK" rollups settle with SNARKs.
` StarkNet: STARK validity proof → SHARP prover → SNARK (Groth16) verifier on Ethereum zkSync Era: STARK validity proof → SNARK (PLONK) recursive compression → Ethereum RISC Zero: STARK (RISC-V execution) → SNARK (Groth16) for on-chain verification `
Why? Ethereum's precompiles support BLS12-381 pairings (SNARK verification) but not FRI verification. Verifying a STARK on-chain costs ~5M gas; verifying a Groth16 proof costs ~200k gas.
The architecture:
- STARK for proving (transparent, quantum-resistant, scalable prover)
- SNARK for settlement (tiny proof, fast on-chain verification, existing precompiles)
This is the best of both worlds — and where the industry is converging.
Figure 4: SNARK vs STARK properties comparison
Figure 3: Polynomial commitment — KZG envelope vs FRI Merkle tree
FAQ: Your Questions Answered
Q: Is SNARK "broken" because of trusted setup?
A: No. The Powers of Tau ceremony (100+ participants, multi-party computation) makes collusion extremely unlikely. But it is a social trust assumption. STARK removes it mathematically.Q: Why are STARK proofs so much larger?
A: FRI commits to many evaluations of the polynomial (Merkle tree), while KZG commits to one group element. STARK trades proof size for transparency. Recursion and compression (e.g., STARK → SNARK) mitigate this for on-chain use.Q: Can STARK run on Ethereum today?
A: Verifying a raw STARK on Ethereum costs ~5M gas (too expensive). Production STARK rollups use a STARK-to-SNARK wrapper: prove with STARK, compress to SNARK, verify SNARK on-chain.Q: Which is more quantum-resistant?
A: STARK. Its security reduces to hash function collision resistance (Keccak-256/Poseidon). SNARK security reduces to discrete log / pairing assumptions — broken by Shor's algorithm on a large quantum computer.Q: Do I need to learn Cairo for STARK?
A: For StarkNet — yes. For general STARK development: Winterfell (Rust), Stone (Rust), or SP1 (RISC-V) let you write in Rust/C++. Cairo is domain-specific.Q: What about Halo2 / Nova — no trusted setup SNARKs?
A: Halo2 uses IPA (Inner Product Argument) instead of KZG — no trusted setup, but larger proofs (~5-10 KB) and slower verification. Nova/IVC enable incrementally verifiable computation — recursive SNARKs without curve cycles. These blur the line but remain niche compared to Groth16/PLONK/FRI.Summary: Two Watchmen, One Village
| Watchman | Philosophy | Best For |
|---|---|---|
| SNARK (Secret Key) | "Trust the ceremony, gain efficiency" | On-chain verification, privacy apps, mature tooling |
| STARK (Public Rules) | "Trust no one, verify everything" | Trust-minimized rollups, quantum resistance, large computations |
The village needs both. SNARK guards the treasury gate (on-chain verification). STARK patrols the streets (execution proofs, privacy, scaling). Together, they secure the blockchain village — one with a master key forged in ceremony, one with rules posted on the gate for all to see.
Understanding snark vs stark isn't about picking a winner. It's about knowing which watchman to station where — and recognizing that the strongest defenses often combine both.
Word count: ~2,800 | Primary keyword: "snark vs stark" | Secondary: "zk snark stark khác nhau", "stark transparent setup"