Explainer · 7 June 2026

Zero-knowledge proofs explained

A zero-knowledge proof (ZKP) is a cryptographic protocol where one party — the prover — convinces another — the verifier — that a statement is true without revealing any information beyond the truth of that statement. You can prove you know a wallet's private key without broadcasting the key. You can prove a batch of transactions was processed correctly without posting every line item on-chain. The idea dates to the 1980s (Goldwasser, Micali, Rackoff) but only became practical at scale in the last decade — powering privacy coins, layer-2 rollups, and identity systems that need selective disclosure.

The intuition: prove without showing

The classic classroom story uses two colored balls that look identical. The prover knows which is red and which is green; the verifier does not. The prover puts the balls behind their back, swaps them or not, and shows them again. The verifier asks "did you swap?" After enough rounds, the verifier becomes convinced the prover can distinguish the colors — but still cannot name which ball is which. The proof transfers knowledge of a distinction without transferring the labels.

Real applications follow the same shape:

Age verification — Prove you are over 18 without sending your birth date to every website.
Balance sufficiency — Prove an account balance covers a payment without revealing the full balance or transaction history.
Computation integrity — Prove a program ran correctly on private inputs without re-executing it on a public machine.

This is fundamentally different from hashing or signing. A signature says "the holder of this key approved this message." A ZK proof says "this mathematical statement holds" — and the verifier learns nothing about the witness (secret inputs) that made it true.

Three properties every ZK protocol must satisfy

Cryptographers formalize "zero knowledge" with three requirements. Weakness in any one breaks the guarantee.

Completeness — If the statement is true and both parties follow the protocol honestly, the verifier accepts. Honest provers never fail.
Soundness — A cheating prover cannot convince the verifier of a false statement, except with negligible probability. You cannot forge proof of a lie.
Zero-knowledge — The verifier learns nothing beyond "the statement is true." The transcript could have been simulated without access to the prover's secret — meaning the proof leaks no extractable information about the witness.

Soundness is where engineering gets hard. Interactive proofs repeat random challenges to drive forgery probability down. Non-interactive proofs bake randomness into a single message — convenient for blockchains that cannot run a chat protocol between thousands of validators.

Interactive vs non-interactive proofs

Early ZK protocols were interactive: prover and verifier exchanged multiple rounds of messages. That works for two-party authentication but not for a public ledger where anyone must verify later without talking to the original prover.

Non-interactive zero-knowledge (NIZK) proofs compress the dialogue into one broadcastable artifact. The Fiat-Shamir heuristic replaces the verifier's random challenges with hashes of prior messages, making the proof deterministic given public randomness. Modern systems build on this pattern:

zk-SNARKs (Succinct Non-interactive Arguments of Knowledge) — tiny proofs (hundreds of bytes) verified in milliseconds. Setup often requires a trusted ceremony that generates public parameters; if those parameters leak, forged proofs become possible.
zk-STARKs (Scalable Transparent Arguments of Knowledge) — larger proofs but no trusted setup; security reduces to hash functions. Verification cost grows slowly with computation size — attractive for heavy workloads.
Bulletproofs — No trusted setup, good for range proofs (e.g. "this committed value is between 0 and 2^64"), but proof size grows logarithmically and verification is slower than SNARKs for big circuits.

"Succinct" matters on-chain: Ethereum calldata and Solana account space are expensive. Posting a 200-byte proof plus public inputs beats dumping an entire execution trace.

What gets proved? Circuits and witnesses

Practical ZK systems do not prove arbitrary English sentences. They prove that a constraint system — usually an arithmetic circuit — evaluates to zero for some secret assignment called the witness.

Example: a range proof shows a committed balance b satisfies 0 ≤ b < 2^64 without revealing b. The circuit encodes the bit decomposition and carry constraints; the witness holds the actual bits of b. The proof says "there exists a witness satisfying all constraints."

Compilers (Circom, Noir, Cairo, Risc Zero's zkVM) let developers write high-level logic that lowers to these circuits. The hard part is not the syntax — it is keeping constraint count low. Every multiplication gate costs prover time and, on some systems, verification budget. Teams profile circuits the way game studios profile GPU shaders.

Where ZK shows up in production

Privacy-preserving transfers

Privacy-focused chains use ZK to hide sender, receiver, and amount while still proving no coins were created from nothing (conservation of value). The verifier sees a proof that balances add up — not the ledger rows themselves. Regulatory pressure pushes newer designs toward selective disclosure: encrypted metadata with viewing keys for auditors rather than fully opaque pools.

Layer-2 rollups and validity proofs

Rollups execute transactions off-chain, then post a succinct proof that the new state root is correct given the old root and the batch. Validators on the base layer verify the proof — not thousands of individual transfers. This is how ZK rollups on Ethereum aim to scale throughput without abandoning L1 security assumptions. Solana's native execution model is different (single high-throughput chain), but ZK still appears in bridges, verifiable compute, and cross-chain light clients that need to trust remote state without replaying every slot.

Identity and credentials

Decentralized identity projects use ZK so users prove membership ("I am in this allow-list") or attributes ("my KYC provider scored me as low-risk") without doxxing their passport scan on-chain. The proof binds to a nullifier so the same credential cannot vote twice — similar in spirit to how WebAuthn binds authentication to an origin, though the cryptography is unrelated.

Verifiable computation

A prover runs a heavy ML inference or ETL job and supplies a proof the output matches the claimed program. The verifier checks the proof in milliseconds instead of re-running the job. This pattern is early but matters for "compute on someone's GPU, trust the result on-chain" workflows.

Connection to Merkle trees and blockchains

ZK proofs and Merkle trees often appear together. A Merkle root commits to a large dataset in 32 bytes; a ZK proof can show "this leaf is in the tree" and "this leaf satisfies policy P" without revealing sibling leaves. Light clients use Merkle inclusion paths; ZK can compress those paths further or combine multiple statements in one proof.

On payment rails, merchants still verify transfers the straightforward way — checking signatures and balances on-chain — because transparency is a feature for settlement. ZK enters when privacy or batch compression is worth the prover cost. Wallet users should not confuse "ZK privacy" with wallet security: hiding a transaction does not protect a leaked seed phrase.

Limitations and trust assumptions

ZK is not magic privacy dust. Understand the caveats before designing around it:

Trusted setup — Many SNARK systems require a ceremony. Participants destroy toxic waste (private setup randomness); if it leaks, forged proofs break the system. STARKs and some newer SNARKs avoid this, with trade-offs in proof size.
Prover cost — Generating proofs can take seconds to minutes for large circuits. Real-time games and sub-second payments rarely prove every click in ZK; they batch or prove only the settlement layer.
Trusted computing boundaries — A ZK proof verifies math about a stated program. If the program hash is wrong, or the prover runs malware that lies about inputs before proving, cryptography cannot help. Supply-chain integrity still matters.
Metadata leakage — Hiding amounts inside a proof does not hide that you sent a transaction at 14:03 UTC from this IP. Network-layer privacy needs separate tools.
Quantum uncertainty — SNARKs built on elliptic-curve pairings face long-term quantum threats; hash-based STARKs are more future-proof. Migration planning is a decade-scale concern, not tomorrow's outage.

How to evaluate a ZK product claim

Marketing decks love the words "zero knowledge." Ask these questions:

What exact statement does the proof verify? Vague "privacy" is not a circuit.
Who generates the proof, and how long does it take? Prover latency dominates UX.
What setup assumptions exist? Transparent vs trusted ceremony changes your threat model.
What remains public? Timing, transaction count, proof size, and fee patterns leak information.
Is the verifier open source and audited? Soundness bugs have shipped in production systems.

Zero-knowledge proofs are one of the few cryptographic tools that let you separate truth from exposure. Used well, they shrink what blockchains must publish while keeping verifiers honest. Used as buzzword wallpaper, they add prover bills without hiding anything an analyst could already infer from the mempool.