zk-SNARK vs zk-STARK vs PLONK
How the three major proof-system families compare on trusted setup, proof size, prover cost, and quantum resistance — and which production rollups picked which.
What All Three Are Trying to Do
A zero-knowledge proof lets you prove you know something (a witness) without revealing it. Modern proof systems do something even more useful: they let you prove that a long computation (millions of steps) was performed correctly, by producing a tiny proof that anyone can verify quickly. This is what powers ZK rollups — a prover compresses thousands of L2 transactions into a single proof, posted to L1, that lets Ethereum verify the whole batch in milliseconds. The three major families are SNARK, STARK, and PLONK (and PLONK's many descendants).
The Three In One Sentence Each
**SNARK** (Succinct Non-interactive ARgument of Knowledge): tiny proofs, fast verification, but requires a one-time 'trusted setup' ceremony (Zcash, original Filecoin). **STARK** (Scalable Transparent ARgument of Knowledge): no trusted setup, post-quantum secure, but proofs are larger (StarkNet, Polygon Miden). **PLONK**: universal trusted setup that can be reused across circuits, hybrid properties (Aztec, zkSync, Scroll).
- SNARK pioneers (Zcash, Aleo): small proofs, requires per-circuit trusted setup
- STARK (StarkNet): transparent, post-quantum-secure, larger proofs
- PLONK family (Aztec, zkSync, Scroll, Polygon zkEVM): reusable setup, flexible
- All three solve 'prove the long computation was correct, with tiny proof' — they trade off how
Key Takeaways
- Three families: SNARK (small + trusted setup), STARK (transparent + bigger), PLONK (universal setup)
- All three let you compress a long verifiable computation into a small proof
- Production ZK rollups use all three — there's no single winner
- Choice depends on your priorities: proof size vs. setup vs. quantum resistance
Related Content
Related Coins
Key Terms
2026 Trends
More Topics
Browse all 179 topicsData Availability Sampling
How light nodes can be cryptographically confident that a block's full data was published — without downloading it — and why this is the key unlock for Ethereum's full danksharding and the modular blockchain stack.
Finality and Fork Handling
What it means for a transaction to be 'final,' why different chains finalise differently, how reorgs happen, and the MEV incentives that complicate the picture.
State Pruning and Expiry
Why Ethereum's state has grown to hundreds of gigabytes, what 'archive,' 'full,' and 'light' nodes actually store, and how proposals like EIP-4444 and Verkle trees aim to keep node hardware accessible for years to come.
ECDSA vs EdDSA vs BLS
The three signature schemes you'll meet across the crypto stack — what each does well, what tradeoffs they impose, and why Ethereum uses three of them simultaneously.
Threshold Signatures and MPC
How t-of-n threshold signatures and multi-party computation let multiple parties sign together without any one holding the full key — the cryptography behind Fireblocks, Lit Protocol, and modern institutional custody.
Verifiable Random Functions
How VRFs produce randomness that's both unpredictable before commitment and cryptographically verifiable after — enabling fair lotteries, leader election, and on-chain randomness without trusted parties.
Hash Functions Compared
SHA-256, Keccak-256, Blake3, and Poseidon — which one each chain uses, why ZK systems needed a new family of 'arithmetic-friendly' hashes, and what tradeoffs each makes.
Stealth Addresses and Confidential Transactions
Privacy primitives that hide who's receiving what — from Monero's foundational stealth addresses to Ethereum's ERC-5564 and the legal context post-Tornado-Cash.
References & further reading
- primary
- secondary