SNARKs and STARKs are families of cryptographic proof systems. They let a prover convince a verifier that a computation satisfies a statement without asking the verifier to repeat the whole computation. A scheme with the zero-knowledge property can also hide specified private inputs. These systems are used in privacy applications and in blockchain validity proofs, but “SNARK” or “STARK” alone does not describe every security assumption or performance detail.
What does a proof establish?
A prover supplies a proof for a public statement, such as “this state update follows the program’s rules,” together with private witness data used to construct it. The verifier checks the proof against the statement and the chosen verification key. The exact guarantees depend on the proof system, the program or circuit, the public inputs, and how the system is implemented.
Zero-knowledge, succinctness, and validity are related but separate ideas. A zero-knowledge proof is designed not to reveal the protected witness beyond what follows from the public statement. A blockchain validity proof can establish that a batch of state transitions was computed correctly without hiding the transactions themselves. For example, a rollup may publish transaction data to its settlement layer so others can reconstruct its state; the proof does not make that published data private.
SNARKs
SNARK stands for “succinct non-interactive argument of knowledge”; the “zk” prefix indicates a scheme that also provides zero knowledge. “Succinct” means the proof and verification can be much smaller or cheaper than re-running a large computation, although actual size and cost depend on the construction and parameters.
Some widely used SNARK constructions use elliptic-curve or pairing-based cryptography and produce compact proofs. Their setup requirements are not all the same:
- Groth16 is a pairing-based SNARK with very compact proofs, but it requires parameters generated for a particular circuit. The ceremony and handling of any secret setup material are part of its trust model.
- PLONK uses a universal, updatable structured reference string for circuits within a size bound. “Universal” does not mean setup-free; it changes how the setup can be reused and updated.
- Other SNARK designs, including Halo-family approaches, can avoid a trusted setup by using different assumptions and techniques. Therefore, it is inaccurate to say that every SNARK needs the same ceremony or even any trusted setup.
STARKs
STARK stands for “scalable transparent argument of knowledge.” STARK constructions are transparent: they do not require a secret, trusted setup ceremony. Common designs use hash-based commitments and protocols such as FRI to check that a computation’s encoded constraints are consistent.
STARKs are often associated with larger proofs than compact pairing-based SNARKs, while their proving and verification trade-offs can be attractive for large computations. Neither description is a fixed rule for every implementation. Proof size, generation time, verification cost, memory use, and on-chain fees depend on the circuit, parameters, recursion or aggregation, hardware, and target blockchain.
Because common STARK constructions rely on hash-based assumptions rather than the elliptic-curve pairing assumptions used by many SNARKs, they are often discussed as post-quantum candidates. That is not a blanket guarantee: security depends on the exact construction, hash functions, parameter choices, and cryptanalysis.
SNARK vs. STARK
| Question | SNARK family | STARK family |
|---|---|---|
| Setup | Varies: some constructions need circuit-specific or reusable setup; some avoid trusted setup. | Transparent constructions use public randomness and avoid a secret trusted setup. |
| Typical proof trade-off | Some pairing-based designs have very compact proofs and efficient verification. | Proofs are often larger, with different scaling and hash-based trade-offs. |
| Security assumptions | Depend on the construction; many popular schemes use elliptic-curve assumptions. | Common constructions rely on hash-based assumptions and protocol-specific parameters. |
| Best choice | Depends on the application’s setup, proof, verifier, and hardware needs. | Also depends on the application; the name alone does not establish lower cost or higher security. |
Many systems use recursion, aggregation, or multiple proof layers, so a deployed protocol may not fit a simple one-word label. Compare the actual proof construction, assumptions, verifier code, data-availability design, upgrade controls, and independent audits rather than relying on a generic SNARK-versus-STARK table.
How they relate to ZK rollups
A rollup can use a validity proof to show that proposed state changes follow its rules. The proof can help Ethereum verify those changes without re-executing every operation. The proof system is only one part of a rollup’s security: users should also consider where transaction data is published, who operates the sequencer and prover, what users can do during censorship or downtime, and how the contracts can be upgraded.
The term “ZK rollup” is commonly used for rollups that use validity proofs, even when their published transaction data is not private. A proof’s zero-knowledge property does not hide information that the protocol separately publishes. Privacy requires a design that deliberately keeps relevant inputs or transaction details confidential.
Social Media Sentiment
In one r/ethereum discussion, a user asks why rollups use proofs with a zero-knowledge property if validity is the main purpose. Replies debate the distinction between proving correct execution and hiding transaction information. The thread is useful as an example of recurring terminology confusion, but it is one discussion and does not represent all Ethereum users or cryptography researchers: “Why do zkRollups use proofs with zero knowledge property?” on r/ethereum.
Last updated: 2026-10
Related Terms
See Also
- What Are Zero-Knowledge Proofs — And Why Every Major Blockchain Is Building Around Them
- Are Layer 2 Networks Actually Decentralized?
- Does Ethereum TPS Include Layer 2 Transactions?
- Swap crypto with ChangeNOW
Sources
- Zero-Knowledge Proofs — ethereum.org — Explains proof properties and why zero knowledge is distinct from proving validity.
- Zero-Knowledge Rollups — ethereum.org — Describes validity proofs, data publication, and rollup trust considerations.
- On the Size of Pairing-based Non-interactive Arguments — IACR ePrint — Jens Groth’s paper presents the compact pairing-based construction known as Groth16.
- PLONK — IACR ePrint — The paper describes a universal and updatable setup for circuits within a size bound.
- Scalable, Transparent, and Post-Quantum Secure Computational Integrity — IACR ePrint — The STARK paper sets out its transparent, hash-based proof design and assumptions.
- Halo: Recursive Proof Composition without a Trusted Setup — IACR ePrint — Gives a concrete example of recursive proof composition that avoids a trusted setup.