The choice between SNARKs and STARKs is one of the most consequential technical decisions in ZK rollup design. Both systems allow a prover to convince a verifier that a computation was performed correctly without revealing inputs — the “zero knowledge” property. But they achieve this with fundamentally different cryptographic constructions, each with distinct tradeoffs: SNARK proofs are tiny (288 bytes for Groth16) and cheap to verify on-chain but require a “trusted setup” ceremony where if participants collude or are compromised, the entire security of the system breaks. STARK proofs are orders of magnitude larger but require no trusted setup — their security relies only on collision-resistant hash functions (the most battle-tested cryptographic primitive), making them quantum-resistant. This isn’t merely academic: Ethereum’s zkSync uses SNARKs; StarkWare uses STARKs; Polygon’s Plonky2 attempts to blend both; understanding the proof system is necessary for evaluating the security claims of every ZK rollup.
Background: Zero-Knowledge Proofs
The basic ZK proof idea:
Alice knows the secret number N. She wants to convince Bob she knows N without revealing N.
A ZK proof system allows Alice to run a mathematical protocol that:
- Convinces Bob with overwhelming probability that Alice knows N (soundness)
- Reveals nothing about N to Bob (zero-knowledge)
Why this matters for blockchains:
A ZK rollup prover wants to convince Ethereum validators that “this batch of 1,000 transactions was correctly executed” without validators re-running all 1,000 transactions. A ZK proof of correct execution lets validators verify in milliseconds what would take seconds to re-execute.
Key properties any ZK proof system needs:
- Completeness: Honest prover can always generate a valid proof
- Soundness: Cheating prover cannot generate a valid proof for a false statement (except with negligible probability)
- Zero-knowledge: Verifier learns nothing except that the statement is true
ZK-SNARKs
Succinct Non-Interactive Arguments of Knowledge
Properties
- Non-interactive: Single message from prover to verifier (no back-and-forth)
- Argument: Computationally sound (not perfectly sound)
- Verification: Very fast (<10ms on Ethereum, ~$0.50-$2.00 gas cost)
Trust Assumption: Trusted Setup
SNARKs require generating “common reference string” (CRS) parameters. This setup:
- Generates secret random values (the “toxic waste”)
- Derives public parameters from them
- MUST destroy the toxic waste — if kept, any prover could fake proofs
Trusted setup ceremonies:
- Participants generate their portion of the parameters, then destroy their secrets
- Security: at least 1 honest participant → toxic waste never reconstructed
- Zcash’s original “Powers of Tau” ceremony had 6 participants; recent ceremonies have 1,000+
- “Perpetual Powers of Tau” (Ethereum): ongoing SNARK parameter generation with thousands of contributors
Major SNARK Constructions
Groth16 (2016):
- Smallest proofs (192 bytes), fastest verification
- Downside: circuit-specific trusted setup (different setup for each smart contract)
- Used by: Zcash, earlier ZK rollups
PLONK (2019):
- “Universal” trusted setup: one Powers of Tau ceremony works for any circuit up to a size limit
- Updatable: new participants can join existing setup
- Larger proofs than Groth16 but much more flexible
- Used by: zkSync Era, many Ethereum ZK toolkits
Plonky2 (Polygon):
- SNARK-like but uses STARKs internally for some components
- Very fast proving (10x faster than PLONK for many circuits)
- Used by Polygon’s ZK systems
ZK-STARKs
Scalable Transparent Arguments of Knowledge
Properties
- Transparent: No trusted setup — uses only public randomness (from hash functions)
- Argument: Computationally sound
- Proof sizes: Larger than SNARKs (10s of KB to 100s of KB)
No Trusted Setup
STARKs derive their security from:
- Hash functions (SHA-256, Keccak, Poseidon)
- The Fiat-Shamir transform (converting interactive protocol to non-interactive)
- The FRI (Fast Reed-Solomon Interactive) polynomial commitment scheme
Security assumption: The security of STARKs relies only on collision-resistant hash functions — the most conservatively trusted cryptographic primitive. Even if elliptic curve discrete log breaks (which would break SNARKs), STARKs remain secure.
Quantum resistance: SNARKs rely on elliptic curve pairings — broken by quantum computers (Shor’s algorithm). STARKs rely on hash functions — secure against known quantum attacks. This matters for long-term security planning.
STARK Proof Sizes
Compared to SNARK’s ~200-500 bytes:
- STARK proof sizes: typically 40–200KB
- Much larger to verify on-chain → higher gas cost
- Practical implication: STARK verification on Ethereum costs ~$10-100 vs. SNARK’s ~$1-2
However: For recursive proofs (STARKs that verify other STARKs), proof sizes can be managed. StarkWare’s SHARP prover aggregates many proofs recursively before posting to Ethereum.
Real-World Deployments
The following sections cover this in detail.
SNARK Users
- Polygon zkEVM: SNARK-based proofs
- Mina Protocol: SNARKs for constant-size blockchain (every block is one SNARK)
- Tornado Cash: Groth16 SNARKs for private transfers
STARK Users
- dYdX V3/V4: StarkEx STARK proofs for order book
- Immutable X: StarkEx STARKs for NFT scalability
Hybrid / Recursive
- Nova / Sangria: Folding schemes (different paradigm for recursive proofs)
- Halo2: SNARK without trusted setup using “inner product argument” (more secure than standard SNARK setups)
SNARK vs. STARK: Direct Comparison
| Aspect | ZK-SNARK | ZK-STARK |
|---|---|---|
| Proof size | ~200-500 bytes | 40-200 KB |
| Verification cost | Very cheap (~$1-2 gas) | More expensive (~$10-100 gas) |
| Trusted setup | Required (Groth16/PLONK) | Not required (transparent) |
| Quantum resistance | No (elliptic curves) | Yes (hash functions only) |
| Proving speed | Moderate (PLONK) | Can be faster for large computations |
| Math complexity | Pairings, ECC | Hashes, FRI polynomial commitments |
| Adoption | Wider (older system) | Growing (StarkWare ecosystem) |
| Prover hardware | CPU feasible | GPU/FPGA preferred for large circuits |
The Proving Cost Problem
Generating ZK proofs is computationally intensive — the primary bottleneck for ZK rollup scaling:
Current state (2024):
- Proving an Ethereum block (type-1 EVM): minutes on GPU cluster
- Cost: ~$0.10-1.00 per block in compute costs
- This adds to user gas fees as a “proof cost”
Declining trend:
- Every year: proving costs drop ~3-5x due to algorithm improvements and hardware
- Custom ASICs for ZK proving (Ingonyama, Irreducible) could reduce costs 10-100x
- The race to efficient provers is among DeFi’s most important engineering challenges
Social Media Sentiment
The SNARK vs. STARK debate is primarily a researcher and developer conversation — most users don’t care which proof system underlies their L2, only that it works. Among developers, STARKs are gaining reputation as the more “pure” approach (no trusted setup, quantum-resistant), while SNARKs are battle-tested and have smaller proof sizes that make them more gas-efficient today. StarkWare’s position that STARKs are the correct long-term answer is credible; zkSync’s pragmatic use of SNARKs is defensible. The clearest signal: both systems work in production, costs are falling rapidly, and the bottleneck has shifted from “can we prove this?” to “how quickly and cheaply?” The proving hardware race (ASICs for ZK) is increasingly viewed as the next major factor in ZK rollup economics.
Last updated: 2026-04
Related Terms
Sources
Groth, J. (2016). On the Size of Pairing-Based Non-interactive Arguments. EUROCRYPT 2016.
Gabizon, A., Williamson, Z. J., & Ciobanu, O. (2019). PLONK: Permutations over Lagrange-Bases for Oecumenical Noninteractive Arguments of Knowledge. Cryptology ePrint Archive, 2019/953.
Ben-Sasson, E., Bentov, I., Horesh, Y., & Riabzev, M. (2018). Scalable, Transparent, and Post-Quantum Secure Computational Integrity. Cryptology ePrint Archive, 2018/046.
Bunz, B., Bootle, J., Boneh, D., Poelstra, A., Wuille, P., & Maxwell, G. (2018). Bulletproofs: Short Proofs for Confidential Transactions and More. IEEE S&P.
Wahby, R. S., Tzialla, I., Shelat, A., Thaler, J., & Walfish, M. (2018). Doubly-Efficient zkSNARKs Without Trusted Setup. IEEE S&P.