SNARK vs. STARK

Both let a prover convince a verifier that a computation was performed correctly, without forcing the verifier to repeat it. The interesting part is how each one gets there.

Start with the problem

Suppose I run a large computation and get some result. Rather than asking you to run the whole program again to check it, I want to hand you a cryptographic proof that it was done correctly.

SNARKs and STARKs are the two major approaches to building proof systems like this. They share the same broad goal, but the cryptographic machinery underneath — and the engineering trade-offs that come with it — differ substantially.

What is a SNARK?

SNARK stands for Succinct Non-interactive Argument of Knowledge. "Succinct" means the proof is small and verification is far cheaper than repeating the original computation. "Non-interactive" means that once the proof is produced, the verifier can check it without any further back-and-forth with the prover.

Many well-known SNARK constructions transform a computation into algebraic constraints, and those constraints into statements about polynomials. Depending on the proving system, polynomial commitments and elliptic-curve cryptography then compress that statement into a compact proof.

Why are SNARK proofs so small?

The verifier never receives every intermediate value from the computation — the proving system compresses the claim into a small cryptographic proof instead. In pairing-based systems such as Groth16, the verifier checks a handful of elliptic-curve elements against a pairing equation, rather than replaying the computation itself.

The trade-off is that some SNARK constructions require a trusted setup. If the secret randomness from that setup is retained and later compromised, the security of that particular setup can fail. That's not true of every SNARK, though — "SNARK means trusted setup" isn't a rule that holds universally.

What is a STARK?

STARK stands for Scalable Transparent Argument of Knowledge. The word transparent marks one of the most important differences: STARK constructions avoid a secret trusted setup entirely.

A STARK typically represents a computation as an execution trace, with algebraic constraints describing how valid rows of that trace must relate to one another. Those constraints become polynomial identities, committed to with hashes and checked using low-degree testing.

Instead of sending the whole polynomial to the verifier, the prover commits to its evaluations. The verifier then checks a small number of positions and uses a protocol called FRI to gain confidence that those committed evaluations really do correspond to a polynomial of sufficiently low degree.

The practical comparison

The biggest conceptual difference

A useful way to build intuition is to ask what actually gives the verifier confidence in each case.

In many pairing-based SNARKs, succinct verification comes from algebraic commitments and elliptic-curve pairing relations. In a STARK, the verifier instead leans on polynomial identities, cryptographic hashes, Merkle commitments, random sampling, and low-degree testing.

Why STARK proofs are larger

STARK verification generally needs authentication paths for queried values, polynomial evaluations, and data from each FRI round. Merkle authentication paths are made up of multiple hashes each, so the proof naturally carries more data than a pairing-based SNARK's.

That extra size is simply the cost of transparency and a hash-oriented design — not a flaw so much as a different point on the same trade-off curve.

Which one should you use?

There's no universal winner. If extremely small proofs and cheap on-chain verification matter most, a SNARK construction is probably the better fit. If transparency, hash-based assumptions, and scalable proving are the priority, a STARK usually wins out.

In real systems, the decision also comes down to prover time, verifier cost, recursion, hardware, proof aggregation, implementation maturity, and where verification actually happens.