What is zk-STARK?

A zero-knowledge proof system that needs no trusted setup and relies only on hash functions, at the cost of larger proofs than a zk-SNARK.

The letters stand for scalable transparent argument of knowledge, and transparent is the distinguishing word. It means the public parameters are generated from public randomness with no secret involved, so there is no ceremony to run and no secret anyone could have kept.

That removes an entire category of risk. A zk snark with a compromised setup can produce proofs of false statements, and no amount of auditing the deployed system would reveal it. A STARK has nothing equivalent to compromise.

How it works

Where pairing-based SNARKs rest on elliptic curve assumptions, STARKs are built from hash functions and error-correcting codes, using a low-degree testing protocol. The prover commits to a polynomial encoding of the computation, and the verifier checks a small number of randomly chosen points, gaining high confidence without examining the whole thing.

Three consequences follow from the construction. Security rests only on the collision resistance of the underlying hash function, which is why STARKs are treated as post-quantum candidates while pairing-based schemes are not. Proofs are larger, in the tens to hundreds of kilobytes against a few hundred bytes for a scheme such as Groth16, which matters because posting a proof on chain costs gas in proportion to its size. And proving time scales close to linearly with the computation, which is favorable for very large batches.

Recursive proving is what makes the size penalty manageable. One proof can attest to the validity of many others, so a system can prove batches separately and then prove the proofs, keeping the on-chain verification cost roughly flat as the work being proved grows.

Example

Illustrative, comparing the two families on the same job. A rollup proves a batch of 10,000 transactions.

With a pairing-based SNARK, the proof might be a few hundred bytes and cost little to post, and the system depends on a ceremony run once and trusted forever. With a STARK, the proof might be a hundred kilobytes, costing meaningfully more to post on the base chain, and depends on no ceremony at all.

Apply recursion and the picture changes again: prove ten batches of 10,000 separately, then produce one proof attesting to all ten, and a single verification covers 100,000 transactions. The on-chain cost is paid once rather than ten times, which is how the larger proof size stops being the deciding factor.

Why it matters when you buy

This is infrastructure you use without seeing. Networks built on these proofs settle withdrawals to a base chain in minutes rather than the multi-day window optimistic rollups require, which affects how quickly funds move back toward an exchange. The chain pages cover settlement behavior by network, and the guide on layer 1 versus layer 2 covers the categories.

Related terms

• zk snark: the smaller-proof alternative with a setup
• zero knowledge proof: the general category
• validity proof: the rollup application of both
• zk rollup: the layer 2 design using them
• rollup: the broader scaling category
• data availability: the separate question of publishing data

Questions

Why would a project accept larger proofs?

To avoid a trusted setup and to gain post-quantum security assumptions. Where recursion is used, the on-chain cost of the larger proof is amortized across a great deal of work, which weakens the objection.

Are STARKs actually quantum safe?

They rely on hash function security rather than on number-theoretic assumptions a quantum computer is expected to break, which is why they are described as post-quantum candidates. That is a well-founded expectation rather than a proof.

Is the "zk" in zk-STARK about privacy?

Usually not in rollup deployments. The property being used is succinct verification, and the transaction data is typically published openly so anyone can reconstruct the state.