A zero-knowledge proof lets one party — the prover — convince another — the verifier — that a specific statement is true, without revealing anything about why it's true beyond the fact itself. The canonical toy example is proving you know the combination to a lock without ever stating the combination: you can demonstrate you can open it, repeatedly, under conditions that rule out faking it, without the combination itself ever crossing the table.

Three properties define a real zero-knowledge proof, and all three have to hold together. Completeness means a true statement can always be proven. Soundness means a false statement can't be proven except with vanishingly small probability. Zero-knowledge means the verifier learns nothing from the interaction beyond the statement's truth — no partial information leaks out along the way.

What makes this useful for blockchains specifically is a further property called succinctness. A zk-SNARK can prove a statement about an arbitrarily large computation — “these ten thousand transactions were all valid, and this is the resulting state” — in a proof that's a few hundred bytes and verifies in milliseconds, regardless of how much computation it's actually attesting to. That asymmetry, expensive to generate and cheap to verify, is the entire reason a zk-rollup can compress thousands of transactions into a proof layer 1 barely has to work to check.

The two dominant families make different trade-offs. zk-SNARKs are smaller and cheaper to verify, but most variants require a trusted setup — a one-time ceremony generating public parameters, secure only if at least one participant destroyed their portion of the secret data. zk-STARKs avoid a trusted setup entirely and are believed resistant to quantum computers, at the cost of larger proof sizes and higher verification cost.

Generating the proof is the expensive part in both families, often requiring specialised hardware and materially more computation than simply running the original transactions would take. Proof generation, not verification, is usually the bottleneck rollups are racing to optimise — the succinct proof stays cheap to check precisely because someone did a large amount of work upstream to produce it.

None of this requires understanding the underlying mathematics to use correctly. What's worth carrying forward is the shape of the trade-off: a system using zk-proofs exchanges upfront computational cost, and in some variants a one-time trust assumption at setup, for a verification step that stays cheap no matter how large the underlying computation grows.