STARKs vs SNARKs

Two families of zero-knowledge proofs. Both prove that a computation was performed correctly without revealing the input data — but they make fundamentally different tradeoffs.

Why This Matters

Zero-knowledge proofs (ZKPs) are one of the most impactful cryptographic primitives of the last decade. They power privacy-preserving transactions (Zcash), scalable Layer 2 blockchains (Starknet, zkSync, Polygon), verifiable computation, and increasingly, identity and compliance systems.

But not all ZKPs are created equal. The two dominant families — SNARKs and STARKs — make different choices about trust, proof size, performance, and quantum resistance. Understanding these tradeoffs is essential for anyone building on or evaluating ZK systems.

SNARKs (Succinct Non-interactive ARgument of Knowledge)

SNARKs produce small proofs that are fast to verify, making them attractive for on-chain verification where every byte costs gas.

Key properties

Proof size: Very small (~200 bytes for Groth16, ~400 bytes for PLONK)
Verification time: Constant-time, typically a few milliseconds
Trusted setup: Most variants require a ceremony where secret parameters are generated and then destroyed. If anyone retains the secret (“toxic waste”), they can forge valid proofs
Cryptographic basis: Elliptic curve pairings (bilinear maps)
Quantum resistance: No — quantum computers can solve the discrete logarithm problem that underpins elliptic curves

Major variants

System	Trusted Setup	Proof Size	Key Feature
Groth16	Per-circuit	~200 bytes	Most compact, widely deployed (Zcash, Tornado Cash)
PLONK	Universal (one-time)	~400 bytes	Reusable setup across circuits, growing ecosystem
Halo2	None (uses IPA)	~10 KB	No trusted setup, but slower proving and larger proofs
Marlin	Universal	~1 KB	Algebraic holographic proofs

Who uses SNARKs

Zcash — private transactions with Groth16 (launched 2016, the first major ZKP deployment)
zkSync Era — Ethereum L2 with PLONK-based proof system
Polygon zkEVM — EVM-compatible L2 using PLONK/FFLONK
Scroll — zkEVM using a custom SNARK system
Aztec (Noir) — privacy-first L2 with a PLONK variant

The trusted setup problem

The trusted setup is the most debated aspect of SNARKs. In practice:

Per-circuit setups (Groth16) require a new ceremony for each circuit change — operationally burdensome
Universal setups (PLONK) only need one ceremony, reusable across circuits — much better
Powers of Tau ceremonies involve hundreds of participants; security holds as long as at least one participant was honest and destroyed their secret
IPA-based systems (Halo2) eliminate the setup entirely, but at the cost of larger proofs

The practical risk is low for well-executed ceremonies (Zcash’s ceremony had 100+ participants), but the theoretical vulnerability remains. For systems where trust assumptions matter (government identity, healthcare), this can be a dealbreaker.

STARKs (Scalable Transparent ARgument of Knowledge)

STARKs take a fundamentally different approach: no trusted setup, relying only on hash functions and public randomness.

Key properties

Proof size: Larger than SNARKs (~50-200 KB), though actively being reduced
Verification time: Fast, but with a larger constant factor than SNARKs
Trusted setup: None — the “T” in STARK stands for Transparent. Anyone can verify the setup is secure
Cryptographic basis: Hash functions (Pedersen, Poseidon) and Reed-Solomon codes
Quantum resistance: Yes — hash functions are not efficiently broken by known quantum algorithms
Scalability: Prover time scales quasi-linearly with computation size, O(n log n)

The name “S-Two”

S-Two is StarkWare’s specific STARK implementation used in the Starknet protocol. When SNIP 36 references “S-Two verification,” it means verifying STARK proofs natively within Starknet.

Who uses STARKs

Starknet — Ethereum L2 with Cairo VM, all execution proved via STARKs
SHARP (Shared Prover) — StarkWare’s batch prover that aggregates proofs for Ethereum verification
StarkEx — Application-specific rollup engine (dYdX v3, Immutable X, Sorare)
Stone Prover — Open-source STARK prover from StarkWare

Why no trusted setup matters

The absence of a trusted setup is not just a theoretical nicety:

Auditability: Anyone can verify the proof system’s security by inspecting the public parameters
Upgrade safety: Changing the circuit or proof system doesn’t require a new ceremony
Regulatory clarity: No “ceremony participants” who need to be trusted — simpler compliance story
Long-term security: Post-quantum resistance means proofs generated today remain valid even if quantum computers arrive

Head-to-Head Comparison

Property	SNARKs	STARKs
Trusted setup	Required (most variants)	None
Proof size	~200 bytes – 10 KB	~50 – 200 KB
Verification time	~1-5 ms	~5-50 ms
Prover time	Varies; often slower for complex circuits	O(n log n), parallelizable
Post-quantum	No	Yes
Transparency	Depends on ceremony	Fully transparent
On-chain cost	Lower (smaller proof = less calldata)	Higher (but improving rapidly)
Maturity	More established (Zcash 2016)	More recent (StarkWare 2018)
Recursive composition	Well-studied (Halo, Nova)	Native via SHARP and Cairo

When to use each

Choose SNARKs when:

On-chain verification cost is critical (L1 Ethereum, where every byte of calldata is expensive)
The trusted setup is acceptable for your threat model
Proof size must be minimal (embedded systems, bandwidth-constrained)
You’re building on an existing SNARK ecosystem (circom, Halo2, Noir)

Choose STARKs when:

Transparency and zero trust assumptions are priorities
Quantum resistance is a requirement (long-lived proofs, government, healthcare)
You’re building on Starknet or using Cairo
The computation is large (STARKs scale better for big traces)
Proof size is acceptable (L2 or off-chain verification)

The Convergence Trend (2025-2026)

The SNARK vs STARK divide is blurring. Several trends are driving convergence:

1. STARK → SNARK wrapping

Use STARKs for the heavy computation (large trace, fast proving), then “wrap” the STARK proof in a small SNARK for cheap on-chain verification. This gives you:

STARK benefits: no trusted setup, quantum resistance, fast proving
SNARK benefits: tiny proof for L1 verification

Starknet uses this pattern via SHARP: Cairo execution → STARK proof → recursive aggregation → final SNARK to Ethereum.

2. Lookup-based systems

Newer proof systems like Lasso/Jolt (from a]16z research) and Binius (binary fields) blur the boundary between SNARKs and STARKs by using lookup arguments and novel algebraic structures.

3. Hardware acceleration

Both families are seeing hardware acceleration (FPGAs, ASICs, GPUs). As proving becomes faster and cheaper, the size/speed tradeoffs matter less — the trust and security properties become the differentiator.

4. Folding schemes

Nova and SuperNova introduce folding — an approach to incremental verifiable computation that doesn’t fit neatly into either SNARK or STARK categories. This represents a third path that may eventually supersede both for certain applications.

The Landscape (2026)

┌────────────────────────────────────────────────────┐
│              ZERO-KNOWLEDGE PROOF SYSTEMS           │
│                                                     │
│  SNARKs                    STARKs                   │
│  ├── Groth16 (Zcash)       ├── S-Two (Starknet)   │
│  ├── PLONK (zkSync, Aztec) ├── Stone (open-source) │
│  ├── Halo2 (Scroll)        └── SHARP (aggregation)  │
│  ├── FFLONK (Polygon)                               │
│  └── Nova/SuperNova (folding)                       │
│                                                     │
│  Convergence: STARK proving → SNARK verification    │
│  Emerging: Binius, Lasso/Jolt, lookup arguments     │
└────────────────────────────────────────────────────┘

STARKs vs SNARKs

STARKs vs SNARKs

Why This Matters

SNARKs (Succinct Non-interactive ARgument of Knowledge)

Key properties

Major variants

Who uses SNARKs

The trusted setup problem

STARKs (Scalable Transparent ARgument of Knowledge)

Key properties

The name “S-Two”

Who uses STARKs

Why no trusted setup matters

Head-to-Head Comparison

When to use each

The Convergence Trend (2025-2026)

1. STARK → SNARK wrapping

2. Lookup-based systems

3. Hardware acceleration

4. Folding schemes

The Landscape (2026)

Further Reading