SNARKs and STARKs: The Two Families of Succinct Proofs

A succinct proof is one that is small and fast to verify even when the thing being proved is enormous. Two families dominate production systems today - SNARKs and STARKs - and choosing between them is less about speed benchmarks than about trust assumptions.

SNARKs and the setup problem

SNARK stands for succinct non-interactive argument of knowledge. The best-known construction, published by Jens Groth in 2016 and universally called Groth16, produces proofs of just three group elements - on the order of 128 bytes - that verify in constant time regardless of how large the underlying computation was. That is a remarkable property: a proof about a million-step computation is the same tiny size as a proof about ten steps.

Why bytes decide winners

Proof size sounds like an implementation detail until you meet the verifier that charges by the byte. On a public blockchain, every byte of a posted proof is paid for at the network’s going rate, forever, by whoever posts it - and verification cost is paid in on-chain computation, the most expensive computation on earth. This is why pairing-based SNARKs conquered the first generation of production systems: a few hundred bytes and a constant-time check is a rounding error per batch. A proof measured in tens or hundreds of kilobytes is a real line item, and engineering teams have spent years compressing STARKs - or wrapping them inside a final small SNARK - to pay the base-chain toll in the cheaper currency.

Off-chain, the calculus inverts. If the verifier is a server, a phone, or an auditor’s laptop, kilobytes are free and the trusted-setup question dominates. The same two constructions, ranked opposite ways by two venues - which is why “which is better” is a malformed question, and “better for whom, verifying where” is the one professionals ask.

	Pairing-based SNARKs (e.g. Groth16, PLONK)	STARKs
Trusted setup	Required - per-circuit (Groth16) or universal (PLONK)	None - transparent
Proof size	Hundreds of bytes	Tens of kilobytes and up
Verification	Milliseconds, near-constant	Fast, grows slowly with computation size
Assumptions	Elliptic-curve pairings	Hash functions only
Post-quantum	No - pairing assumptions break	Plausibly yes

The catch is the trusted setup. Groth16 requires a one-time ceremony that generates public parameters for each specific circuit, and that ceremony produces secret “toxic waste” which, if retained by an attacker, would let them forge proofs. Real deployments run elaborate multi-party ceremonies so that security holds as long as a single participant was honest and destroyed their share. It works, but it is a trust assumption you carry forever.

Later SNARKs eased this. PLONK, introduced in 2019 by Gabizon, Williamson and Ciobotaru, replaced the per-circuit ceremony with a single universal, updatable setup: one ceremony serves any circuit up to a size bound, and anyone can extend it, with honesty of one contributor sufficient. It trades slightly larger proofs (around half a kilobyte) for far less operational pain.

STARKs and transparency

STARKs - scalable transparent arguments of knowledge, introduced by Ben-Sasson, Bentov, Horesh and Riabzev in 2018 - take a different route. They use hash functions and error-correcting codes rather than elliptic-curve pairings, and crucially they require no trusted setup at all. There is no toxic waste because there is no secret to generate. As a bonus, their security rests on assumptions believed to survive quantum computers, which pairing-based SNARKs do not.

Choosing a proof system is choosing a trust assumption you will live with for the life of the deployment.

The price is proof size. STARK proofs are measured in tens or hundreds of kilobytes rather than hundreds of bytes. On a blockchain, where every byte of a proof is stored and paid for, that difference has real economic weight - which is exactly why much of the engineering effort in this space goes into compressing STARKs or wrapping them inside a small SNARK for final verification.

How to choose

There is no universally best answer, and anyone who tells you otherwise is selling something. If on-chain proof size dominates your costs and you can tolerate a setup ceremony, a pairing-based SNARK is attractive. If you want no trusted setup and post-quantum security, and can absorb larger proofs, a STARK fits. Increasingly, systems combine them - proving with a transparent system, then compressing with a succinct one - because the trade-offs are complementary rather than absolute.

The vocabulary is dense, but the decision underneath is simple to state: how small must the proof be, and whom are you willing to trust to get it there.

Choosing in practice

Real systems increasingly refuse to choose. A common production pattern proves the heavy work in a fast, transparent system, then wraps the result in one final pairing-based proof so the chain sees only a few hundred bytes - hash-based security where the computation happens, byte-efficiency where the tolls are charged. Another pattern picks per workload: transparent proofs for anything that must outlive current cryptographic assumptions, tiny proofs for anything posted a thousand times a day. The families are converging into a toolbox, and the interesting engineering is in the joins.

For a reader, the practical test survives all of it: when a team announces its choice of proof system, the announcement should tell you the verifier’s venue, the setup story, and the sizes. If it only tells you a speed multiple, the choice was marketing.