ZK-SNARKs vs ZK-STARKs: Proof Size, Trusted Setup and Post-Quantum Security

By Nika, NodeTimes newsroom.

Most SNARKs produce the smallest proofs but need a trusted setup and are not post-quantum; STARKs need no setup and are hash-based, but their proofs run to tens of kilobytes. What decides a real deployment is which of the three costs, proof size, prover time and trust, your system actually pays.

The three axes that get conflated

Discussions of SNARK versus STARK usually collapse three independent properties into one ranking, which is why they disagree. Proof size, setup trust and quantum resistance vary separately, and a system can win on one and lose on both others.

Trusted setup: a one-time ceremony that generates proving and verification keys, whose secret randomness ("toxic waste") would let anyone forge proofs if it survived. FRI (Fast Reed-Solomon Interactive Oracle Proof of Proximity): the hash-based low-degree test that makes STARKs transparent and post-quantum secure. Proof system: the pair of algorithms that let a prover convince a verifier of a statement without revealing the witness.

The axes, separately:

• Proof size: SNARKs are constant-size, hundreds of bytes; STARKs grow with the computation.
• Setup trust: Groth16 needs a per-circuit ceremony, PLONK a universal one, Halo2 and FRI-based systems need none.
• Quantum resistance: pairing-based and discrete-log systems fall to Shor's algorithm, hash-based STARKs do not.

Terminology for the wider stack, from commitments to recursion, stays in the blockchain glossary.

Proof size, prover time and verifier time: what benchmarks actually show

Published benchmarks disagree by orders of magnitude, and the disagreement is the most useful thing to know before reading any comparison table. Their numbers come from different circuits and different hardware, and those two variables outweigh the family choice.

Two conclusions follow, and they are more valuable than picking a winner:

• The ordering of prover and verifier times flips between benchmarks, so a table posted without a circuit description is not evidence.
• The stable ordering across both benchmarks is proof size: pairing-based SNARKs stay about two orders of magnitude smaller than STARKs.

Why the trusted setup is a real risk, not a formality

A SNARK ceremony produces a structured reference string, and if any participant kept the toxic waste, they can forge proofs for that circuit forever. The mitigation is ceremony design: Groth16 needs a fresh ceremony per circuit, while PLONK-style universal setups, built on KZG commitments to a single structured reference string, are reusable across circuits up to a size bound.

• Groth16: per-circuit setup, smallest proofs, weakest operational story when the circuit changes often.
• PLONK: one universal setup, proofs around 500 bytes, reusable across circuits.
• Halo2: transparent setup using inner-product arguments, but still built on elliptic curves, so not post-quantum.
• FRI-based STARKs: transparent and hash-based, with no ceremony at any point.

For a protocol that must live for a decade, a one-time ceremony is a governance commitment rather than a technical detail, and that argument is what moved parts of the ecosystem toward hash-based proof systems.

Post-quantum security

STARKs rest on collision-resistant hashes for both commitments and soundness, which is why they are considered post-quantum secure. Groth16 and PLONK rest on pairing assumptions over elliptic curves, which Shor's algorithm breaks.

That has a scheduling consequence rather than an immediate one:

• A SNARK verifying a STARK proof inherits the STARK's soundness but adds a pairing check that a quantum computer could break.
• Proofs already anchored on-chain cannot be re-verified differently later; the verifier that exists when the proof lands is the one that matters.
• If post-quantum verification is a requirement, the inner proof system has to be hash-based, regardless of which wrapper is used.

The wider move to hash-based cryptography is mapped in the site's post-quantum blockchain guide, and the same claim-versus-check question lands in practice in audits, certificates and post-quantum protection.

Where each system is used in production today

The pattern that emerged is composable rather than exclusive: a transparent, hash-based proof generated off-chain is wrapped in a small pairing-based SNARK so on-chain verification stays cheap.

EIP-4844 changed the economics on the L1 side by pricing blob data separately from calldata, which lowers the cost of posting a large proof but does not make it free; blob data is also not stored indefinitely by consensus clients.

How to choose, in order

Decide in this sequence, because each step removes most of the remaining options.

1. If post-quantum verification is required, the inner proof system must be hash-based: STARK, not Groth16 or PLONK.
2. If on-chain verification cost dominates, shave bytes: pairings save calldata, so wrap the big proof.
3. If the circuit changes often, prefer a universal or transparent setup over per-circuit ceremonies.
4. If prover throughput dominates, benchmark your own circuit: published tables disagree, as shown above.
5. If the statement is small and one-off (a range proof, a membership proof), a non-universal SNARK is usually the cheapest thing that works.

The order matters more than the answer: teams that pick a proof system first and then discover their on-chain verification budget usually rebuild the circuit around the budget anyway.

Frequently asked questions

Are ZK-STARKs always better than ZK-SNARKs?

No: STARKs win on trust assumptions and quantum resistance, while SNARKs win on proof size and on-chain verification cost.

The hybrid pattern, a STARK wrapped in a SNARK, exists precisely because neither dominates.

Why are STARK proofs so large?

They are built from Merkle commitments and FRI queries, so their size grows with the computation instead of staying constant.

Pairing-based systems instead compress everything into a few group elements, which is what makes a 384-byte proof possible.

Can a SNARK be made post-quantum?

Not while it relies on pairings or discrete logarithms: lattice-based proof systems are an active research direction, and the production systems in use are either pairing-based or hash-based.

If a roadmap promises post-quantum ZK, ask which of the two families it actually builds on.

Does a trusted setup mean the system is backdoored?

No, but a specific failure mode exists: if the ceremony's secret randomness survived, proofs can be forged, and multi-party ceremonies make that outcome require collusion among many participants.

The honest position is that a setup is a risk to quantify and document, not a property to dismiss.

Which family should a rollup pick?

Most production rollups pick by verification cost on L1 and then wrap accordingly: a hash-based prover for scalability, a small SNARK for the on-chain check.

The choice should be revisited when the circuit changes, because a per-circuit ceremony is a recurring cost rather than a one-time one.