The core idea
A prover wants to convince a verifier that a statement is true, for example "I know a number whose hash is X" or "these 5,000 transactions move the state from root A to root B". A zero-knowledge proof does this without revealing the number or the transaction details.[1]
ethereum.org traces the concept to a 1985 paper, The knowledge complexity of interactive proof systems, whose definition of zero-knowledge proofs is still widely used.[1]
The textbook illustration, which ethereum.org cites, is the Ali Baba cave story: a prover shows she knows the secret phrase that opens a magic door without revealing it. If a guesser has a 1 in 2 chance each round, our own calculation gives (1/2)^20, about one in a million, after 20 rounds, yet the verifier never hears the phrase.[1]
In blockchains, the statement is usually about computation: a batch of transactions, run off chain, produced this new state. ethereum.org describes validity proofs that let Ethereum confirm offchain computation without re-executing it.[2]
Three required properties
Completeness: if the statement is true and both sides follow the protocol, the verifier accepts.[1]
Soundness: if the statement is false, a lying prover cannot trick an honest verifier into accepting it.[1]
Zero-knowledge: the verifier learns nothing beyond the truth of the statement.[1]
Early protocols were interactive: the prover and verifier exchanged many rounds of messages. Blum, Feldman, and Micali proposed the first non-interactive zero-knowledge proofs, where one message can be checked later, which is the form SNARKs and STARKs take.[1]
Zero-knowledge is what separates these proofs from ordinary digital signatures. A signature proves that someone with a key approved a message; a ZK proof can show that a hidden value satisfies a rule without disclosing the value.
SNARKs and STARKs
A zk-SNARK is a succinct non-interactive argument of knowledge. Groth16, from a 2016 paper by Jens Groth, produces proofs of just three group elements, and verification checks a single pairing product equation using three pairings.[3]
The trade-off is a trusted setup. Groth16 is a preprocessing SNARK, and SNARKs of this kind need a Common Reference String generated in advance for the circuit. ethereum.org explains that ceremonies involve many participants, and the system stays secure as long as one honest participant destroys their secret input.[2]
zk-STARKs are transparent: they need no trusted setup and instead rely on publicly verifiable randomness. ethereum.org describes them as an improvement on SNARKs in scalability and transparency, but their proofs are larger and more expensive to verify on Ethereum.[2]
Succinct is the key word for blockchains. ethereum.org notes that SNARKs are popular for small proofs and constant-time verification, which lets one Ethereum contract call stand in for re-executing a whole batch.[2]
Developers write the statement as an arithmetic circuit. ethereum.org notes that SNARK proving time scales linearly with the size of the computation, while STARK proving scales quasilinearly, so proving a large batch costs far more than proving a single small statement.[2]
| Property | zk-SNARK (e.g. Groth16) | zk-STARK |
|---|---|---|
| Trusted setup | Required per circuit | Not required |
| Proof size | Very small (three group elements) | Larger |
Worked example: a ZK rollup batch
A ZK rollup collects, say, 5,000 transfers. Off chain, a prover runs them, computes the new state root, and generates a validity proof that the root follows from the old root and the batch.[2]
The rollup posts the batch data and the proof to Ethereum. The verifier contract checks the proof in one call; Ethereum never re-executes the 5,000 transfers. If the proof checks out, the new state root is final and withdrawals can proceed.[2]
Compare an optimistic rollup: it posts the same kind of batch with no proof and waits about seven days for anyone to challenge it.[5]
Since EIP-4844, rollup batch data can go into blobs of 128 KiB, which are priced separately from execution gas. Each blob is committed to with a KZG commitment, a polynomial commitment scheme.[4]
The cost structure is the reverse of optimistic designs. ethereum.org explains that ZK rollups spread fixed costs across many users by batching, while proof verification on L1 is the larger cost of operating one, which is why they prefer proofs that are cheap to verify.[2]
See also: Layer 2 in the glossary
Uses beyond scaling
Privacy: ethereum.org describes decentralized identity, where a person proves citizenship without revealing a tax ID or passport details.[1]
Proof of personhood systems such as World ID let a verified user generate a ZK proof of membership in a list of unique humans, so only one statement is revealed: this person is unique.[1]
ethereum.org describes Bhutan's National Digital ID system on Ethereum as a real-world example: citizens can prove facts such as being a citizen or being over 18 without revealing more.[1]
Onchain voting is another listed use: ethereum.org discusses zero-knowledge proofs as a way to reduce bribery and collusion in onchain voting.[1]
See also: World ID · Human Passport
Limits and risks
The math of a well-studied proof system is rarely the only weak point. The proof covers the circuit as written, so if a circuit leaves out a constraint, a proof can be valid for a statement the developers did not intend.
Trusted setups move the risk to a ceremony. Because the Common Reference String is generated for a specific circuit, changing the circuit means generating new parameters, and the security rests on at least one participant destroying their input.[2]
Proving is expensive. ethereum.org notes that producing validity proofs requires specialized hardware, which may encourage centralized control of a ZK rollup by a few parties.[2]
Verifier contracts can also be upgraded. A ZK rollup whose verifier can be replaced instantly by a small multisig is only as trustworthy as that multisig, whatever the proof system.
None of this makes ZK proofs weaker than the alternatives. It means that reading an audit of the circuit and the verifier is as important as knowing which proof system a project uses.
The bottom line
For users, the practical effect of zero-knowledge proofs today is faster exits from ZK rollups and privacy features in identity apps. For developers, the choice is concrete: Groth16 gives three-element proofs that are cheap to verify but need a trusted setup, while STARKs skip the setup and pay for it in proof size.[3]
Educational content, not financial advice. Crypto assets are volatile; do your own research.