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 in trust, proof size, performance, and quantum resistance.

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.

SNARK trusted setup:

  Participant 1    Participant 2    Participant N
       |                |                |
       v                v                v
  Generate s1 --> Multiply s2 --> ... --> Final params
       |                |                |
    Destroy s1       Destroy s2       Destroy sN

  Security: if ANY participant destroys their secret, system is safe
  Risk: if ALL participants collude or are compromised, proofs can be forged

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
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 O(n log n)

How STARKs Work (Simplified)

PROGRAM (e.g., Cairo)
    |
    v
EXECUTION --> EXECUTION TRACE (table of every computational step)
    |
    v
AIR --> POLYNOMIAL CONSTRAINTS (algebraic encoding of the rules)
    |
    v
FRI --> LOW-DEGREE TEST (logarithmic verification)
    |
    v
STARK PROOF (hash commitments + query responses)

The key insight: if a computation was done correctly, the execution trace can be encoded as a low-degree polynomial. If anyone cheated, the polynomial degree explodes. FRI (Fast Reed-Solomon IOP) efficiently checks the degree without evaluating every point — giving logarithmic verification time.

For deeper details, see Execution Trace & AIR and FRI Protocol.

The Name “S-Two” (Stwo)

S-Two is StarkWare’s next-generation STARK prover, built on circle STARKs over the Mersenne31 field. When SNIP 36 references “S-Two verification,” it means verifying STARK proofs natively within the Starknet protocol. S-Two replaces the older Stone prover with significantly faster proving times.

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 (predecessor to S-Two)

Why No Trusted Setup Matters

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-to-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:

Application logic
    |
    v
STARK proof (fast, large, transparent)
    |
    v
SNARK wrapper (small, cheap L1 verification)
    |
    v
Ethereum L1 verifier contract

Starknet uses this pattern via SHARP: Cairo execution -> STARK proof -> recursive aggregation -> final compressed proof to Ethereum.

2. Lookup-Based Systems

Newer proof systems like Lasso/Jolt (a16z research) and Binius (binary fields) blur the boundary by using lookup arguments and novel algebraic structures that don’t fit neatly into either category.

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 primary differentiator.

4. Folding Schemes

Nova and SuperNova introduce folding — an approach to incremental verifiable computation that represents a third path, particularly useful for long-running computations.

The Landscape (2026)

+------------------------------------------------------+
|              ZERO-KNOWLEDGE PROOF SYSTEMS             |
|                                                      |
|  SNARKs                      STARKs                  |
|  +-- Groth16 (Zcash)        +-- Stwo (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        |
+------------------------------------------------------+

References

Eli Ben-Sasson et al., “Scalable, transparent, and post-quantum secure computational integrity” (2018) — the original STARKs paper
Vitalik Buterin, STARKs explainer series: https://vitalik.eth.limo/general/2017/11/09/starks_part_1.html
Zcash protocol specification: https://zips.z.cash/protocol/protocol.pdf
PLONK paper: https://eprint.iacr.org/2019/953
Halo2 book: https://zcash.github.io/halo2/
Binius (binary field STARKs): https://eprint.iacr.org/2023/1784
Nova folding scheme: https://eprint.iacr.org/2021/370
SHARP and recursive proofs: https://medium.com/starkware/recursive-starks-78f8dd401025
Starknet documentation: https://docs.starknet.io

See also: FRI Protocol, Execution Trace & AIR, Starknet Architecture, Commitment Schemes