What is zk-SNARK?
A proof that a computation was performed correctly, small enough to check quickly and revealing nothing about the inputs.
Not yet verifiedHow we verify
3 min read
In this entry
A proof that a computation was performed correctly, small enough to check quickly and revealing nothing about the inputs.
The letters stand for zero-knowledge succinct non-interactive argument of knowledge, and each word is doing work. Succinct means the proof is tiny relative to the computation. Non-interactive means the verifier needs no back and forth with the prover, so a proof can be posted once and checked by anyone later, which is exactly what a blockchain requires.
The property that made these practical for chains is not the privacy in the name. It is that verifying costs far less than repeating the work.
How it works
The computation to be proved is first expressed as an arithmetic circuit, a set of constraints that hold only if the computation was performed correctly. The prover produces a proof that it knows inputs satisfying those constraints. The verifier checks the proof against public parameters and the public inputs.
Most widely deployed constructions rely on elliptic curve pairings, and most require a trusted setup: a one-time ceremony generating public proving and verifying parameters. The ceremony produces a secret as a byproduct, and anyone retaining it could forge proofs for false statements. That is why setups are run as multi-party ceremonies with many independent participants, where the secret is unrecoverable if even one participant behaves honestly and destroys their contribution.
Proof sizes are the payoff. Groth16, one of the common schemes, produces proofs of a few hundred bytes verifiable in milliseconds regardless of how large the underlying computation was. Newer universal-setup schemes such as PLONK trade slightly larger proofs for a setup that can be reused across circuits rather than redone for each one.
Applications split into two groups: privacy systems such as shielded transactions, where hiding the inputs is the point, and scaling systems such as validity rollups, where succinctness is.
Example
Illustrative. A rollup batches 5,000 transactions. Verifying them the ordinary way means every Ethereum node re-executing all 5,000, which is precisely the cost the rollup exists to avoid.
Instead the operator generates a proof, perhaps a few hundred bytes, and the base chain verifies it in a fixed, small amount of gas. Proving might take minutes on specialized hardware, and verifying takes milliseconds. Batch 50,000 transactions instead and the proof stays roughly the same size and the verification cost barely moves. That asymmetry is the entire reason the design works.
Why it matters when you buy
You never touch a proof directly, and you use the networks built on them. Layer 2 chains using these proofs finalize withdrawals in minutes rather than the multi-day window optimistic designs require, which affects how quickly funds return to a base chain or an exchange. The chain pages cover settlement behavior by network.
Related terms
- zk stark: the setup-free alternative
- zero knowledge proof: the general category
- validity proof: the rollup application
- zk rollup: the layer 2 design using them
- shielded transaction: the privacy application
- rollup: the broader scaling category
Questions
What happens if a trusted setup is compromised?
Whoever holds the secret could construct proofs for false statements, which for a rollup would mean forging state and for a privacy system would mean minting hidden value. Multi-party ceremonies exist so that a single honest participant makes this impossible.
Are zk-SNARKs quantum resistant?
Pairing-based constructions are not, since their security rests on assumptions a sufficiently capable quantum computer would break. Hash-based systems such as STARKs are treated as post-quantum candidates.
Why do some rollups use SNARKs and others STARKs?
Smaller proofs mean cheaper on-chain verification, which favors SNARKs. No trusted setup and post-quantum assumptions favor STARKs. Projects weigh proof size against setup assumptions differently.