zk-SNARKs vs zk-STARKs: Differences and When to Use Each

zk-SNARKs vs zk-STARKs is a choice between two families of Zero-Knowledge Proofs. SNARK proofs are very small and cheap to verify on-chain, and most of them need a trusted setup. STARK proofs need no trusted setup and rely only on hash functions, but they are much larger and cost more to verify. The choice depends on where the proof is checked and how often.

A Zero-Knowledge Proof lets one party prove that a statement is true without revealing anything beyond that fact. If the idea is new to you, start with our plain explanation of Zero-Knowledge Proofs. The rest of this post compares the two families row by row and then explains which one fits which job.

SNARK stands for Succinct Non-interactive Argument of Knowledge. STARK stands for Scalable Transparent Argument of Knowledge. Both are non-interactive: the prover sends one proof and the verifier checks it without a back-and-forth. Both prove a circuit, which is the computation written as a fixed set of math steps.

A zk-SNARK is a proof whose size and verification time stay small no matter how big the computation is. That is the "succinct" in the name. Most SNARKs get this from pairings, a special operation on elliptic curve points, and most need a set of public parameters made in advance.

Groth16 is the best-known example. In Jens Groth's 2016 paper, a proof is only 3 group elements (points on an elliptic curve), and verification checks one equation with 3 pairings in total. Ethereum has a built-in contract for pairings, whose price EIP-1108 cut in 2019. This is why Groth16 is cheap to check inside a smart contract.

PLONK is the other common example. Its authors describe a universal SNARK whose public parameters from the setup can be updated, so one setup serves many circuits. Our docs explain the construction in detail on the PLONK page.

Zcash was the first widespread application of zk-SNARKs, according to its own site. It generated its parameters through multi-party ceremonies for two of its upgrades. In May 2022 it added the Orchard protocol, built on Halo 2, a SNARK with no trusted setup. This shows the setup is not a rule for every SNARK.

A zk-STARK is a proof system with no trusted setup at all. Ben-Sasson and his co-authors call this "transparent": the system is set up with no reliance on any trusted party. ethereum.org explains that STARKs take their public parameters from publicly verifiable randomness.

STARKs rely only on collision-resistant hash functions, where it is practically impossible to find two inputs with the same output. Because of this, ethereum.org says they are considered immune to the threat of quantum computing. They also scale well: the 2018 paper says verification scales exponentially faster than the size of the data being checked.

The cost is proof size. ethereum.org notes that STARKs produce larger proofs than SNARKs, so verification costs more. Starknet uses STARK-based proofs to bundle thousands of transactions off-chain, per its docs. Our docs cover a newer variant on the Circle STARKs page.

A trusted setup is a one-time event that creates the public parameters a SNARK needs to make and check proofs. The process produces secret values that must be destroyed. If someone kept them, they could create false proofs that still pass verification. ethereum.org puts it plainly: trusted setups require users to trust the participants in parameter generation.

In practice, projects run the setup as a multi-party ceremony. Many people each add their own random input, and the result is safe as long as one of them destroyed their share. That lowers the risk, but it does not remove it, and the circuit-specific part of the ceremony has to be repeated when a system like Groth16 changes its circuit.

The setup matters most when circuits change often or when users will not accept any trust in a ceremony. It matters least when the circuit is small, fixed and rarely changed. Universal setups like PLONK's sit in the middle: one ceremony covers many circuits.

Use a SNARK when the proof is checked on-chain often and someone pays gas for each check. A small proof and a few pairings keep the cost per proof low, and that cost adds up fast when proofs arrive with every update.

Use a STARK when the computation is very large, when you want no trusted setup, or when post-quantum security is a hard requirement. The larger proof matters less when it is checked off-chain or checked rarely.

Many systems now use both. They prove a large computation with a STARK, then wrap that STARK inside a small SNARK for the final on-chain check. RISC Zero's docs describe this step: the last recursion stage outputs a Groth16 receipt that its verifier contract checks on-chain. The STARK gives a prover with no trusted setup; the SNARK gives a small proof for the chain.

zkDatabase is a verifiable database powered by Zero-Knowledge Proofs. Its core job is to prove that a query result matches a Merkle root, the single hash that sums up all the data in a collection at a point in time, and to let a smart contract on an EVM chain check that proof. The proof shows the data was stored and processed as claimed, without showing the data.

That job fits Groth16 well. In zkDatabase, data lives as documents in collections, and each collection has a Merkle tree with a fixed height. The circuit for a collection is set when the collection is created and does not change, so a per-circuit setup is a one-time cost rather than an ongoing burden.

The numbers follow from that choice. zkDatabase runs Groth16 in production with 192-byte proofs, and an on-chain check costs about 100,000 to 150,000 gas on any EVM chain. In our own test, proving takes about 0.4 seconds at Merkle height 128, a tree deep enough for very large collections. Proof size is a large part of that cost story, as our post on Groth16 proof size explains.

Groth16 is the system in production today. Plonky3, Halo2, Nova and Pickles are planned, so the database can add other proof systems as its workloads change.

They are considered resistant to quantum attacks because they rely only on hash functions, per ethereum.org. zk-SNARKs built on elliptic curves are not: a large enough quantum computer could break that security model.

For the systems in wide use today, yes. A Groth16 proof is a few hundred bytes, while STARK proofs run to many kilobytes. Exact sizes depend on the system and the circuit, so compare the specific systems you plan to use.

No. That is the "transparent" in the name. Their public parameters come from public randomness, so there is no ceremony and no secret to destroy.

Sources for the table: Jens Groth, "On the Size of Pairing-based Non-interactive Arguments" (2016); Gabizon, Williamson and Ciobotaru, "PLONK" (2019); Ben-Sasson et al., "Scalable, transparent, and post-quantum secure computational integrity" (2018); ethereum.org, "Zero-knowledge proofs"; RISC Zero docs, "Recursion"; Starknet docs, protocol introduction.

View Docs: see how zkDatabase builds and checks Groth16 proofs for documents in collections.