Zero-knowledge proofs, from a cave to Ethereum: proving you are right without showing why

Blockchains are built on a blunt idea: if everyone re-runs every transaction, nobody has to trust anybody. It works, but it has two costs. Everything is public, and everything is slow, because the whole network repeats the same work. Zero-knowledge proofs attack both costs at once. They let one party do the work and hand everyone else a short receipt that says "this was done correctly", and they can do it without revealing the private inputs behind the work.

This post is the first in a short series on protocols. It starts with the intuition, adds just enough precision to read papers, and ends with where ZK is used on-chain today and what is still open.

The idea with no maths

The classic story is the cave of Ali Baba, from a 1989 paper written to explain zero knowledge to children. A cave has one entrance that splits into a left and a right tunnel, and the two tunnels meet at a locked door deep inside. Peggy (the prover) says she knows the password that opens the door. Victor (the verifier) wants to be convinced, but Peggy will not tell him the password.

So they play a game. Victor waits outside while Peggy walks into one tunnel of her choosing. Then Victor walks to the fork and shouts "come out on the left" or "come out on the right", at random. If Peggy knows the password she can always comply, passing through the door if she has to. If she does not, she can only comply when Victor happens to call the side she already chose, which is a coin flip.

One round proves little: a cheater survives with probability 1/2. Twenty rounds leave a cheater a chance of about one in a million, and forty rounds about one in a trillion. Victor ends up convinced, and yet he has learned nothing he could use to open the door himself, or even to convince a third person: a video of the game could have been staged by agreeing on the shouts in advance.

That last point is the heart of zero knowledge. The proof convinces the person who took part, but it carries no information beyond "the statement is true".

Three properties, stated a bit more carefully

Every zero-knowledge proof system promises three things. These are the words you will see in every paper, so they are worth learning:

• Completeness. If the statement is true and the prover follows the protocol, an honest verifier accepts.
• Soundness. If the statement is false, no cheating prover can make the verifier accept, except with a tiny probability (like the one in a trillion above). In practice this is stated as "bits of security": 128-bit security means the cheating chance is about 2^-128.
• Zero knowledge. The verifier learns nothing beyond the truth of the statement. Formally, everything the verifier sees could have been produced by a "simulator" that never knew the secret, which is exactly the staged-video argument from the cave.

The secret the prover holds is called the witness. The public claim, such as "I know a password whose hash is this value", is the statement. A proof system is a way to turn a statement and a witness into a proof that anyone can check against the statement alone.

From conversations to one-shot proofs

The cave game is interactive: Victor has to be there, shouting. Blockchains need proofs that a contract can check later with nobody around. Two ideas get us there.

The Fiat–Shamir heuristic replaces Victor's random shouts with the output of a hash function applied to everything the prover has said so far. The prover cannot predict the hash before committing, so it plays the role of an honest random verifier, and the whole conversation becomes one message that anyone can re-check.

Arithmetization turns the statement into maths a proof system can handle. Any computation, whether it is "this signature is valid" or "this block of 300 transactions was executed correctly", is rewritten as a set of polynomial equations over a finite field. Proving the computation then means proving that those polynomials satisfy certain identities, and polynomials have a useful property: two different low-degree polynomials agree at very few points, so checking an identity at one random point catches almost every lie.

Put together, you get a non-interactive proof that is often tiny and fast to verify, even when the computation behind it was enormous. This property, called succinctness, is what makes ZK interesting for blockchains even when privacy is not needed at all.

SNARKs and STARKs in one table

The two families you will meet most often are SNARKs (Succinct Non-interactive ARguments of Knowledge) and STARKs (Scalable Transparent ARguments of Knowledge). The names overlap; in practice the difference is in the cryptography underneath.

A trusted setup is a one-off ceremony that generates public parameters from secret randomness. If every participant colluded and kept their randomness, they could forge proofs. Ceremonies with thousands of participants (Zcash's, Ethereum's KZG ceremony for blobs with over 140,000 contributions) reduce this to "at least one participant was honest". STARKs avoid the question entirely, at the price of bigger proofs. Many production systems now prove with a STARK and then wrap the result in a small SNARK, getting fast proving and a cheap on-chain check.

Where ZK is already used on-chain

1. Privacy: hiding who paid whom

Zcash launched in 2016 as the first large deployment of zk-SNARKs. A shielded transaction proves "these coins exist, I am allowed to spend them, and inputs equal outputs" without revealing the sender, receiver or amount. Mixers on Ethereum used the same trick with a simpler statement: "I know the secret behind one of the deposits in this list, and I have not withdrawn it before." Privacy is also where ZK meets law and policy most directly, which makes it a rich area for research rather than only engineering.

2. Scaling: zk-rollups

This is where most ZK on Ethereum lives today. A zk-rollup executes thousands of transactions off-chain, posts the compressed data to Ethereum, and submits a validity proof that the new state is the correct result of applying those transactions to the old state. Ethereum checks one proof instead of re-running every transaction.

Compared with optimistic rollups, which assume batches are valid and give everyone a challenge window (usually about seven days) to dispute them, a zk-rollup is final as soon as its proof is verified. The cost moved from "wait a week" to "pay for a prover", and proving costs have fallen quickly. zkSync, Starknet, Scroll, Linea and Polygon's zkEVM line are the best-known examples, and they differ mostly in how closely they copy the Ethereum Virtual Machine.

3. Identity and credentials

A proof can say "this passport was signed by a real government and its holder is over 18" without revealing the name, number or birthday. Projects that read the chip in an ordinary e-passport and prove facts about it inside a phone app make this concrete. The same pattern works for "I am a member of this lab" or "I hold at least 32 ETH", which is why ZK is a natural fit for private voting, airdrops without doxxing and access control.

4. Ethereum checking itself

The most ambitious use is now on Ethereum's own roadmap. Instead of every validator re-executing every block, a validator could verify a ZK proof that the block was executed correctly. That would let much weaker machines, even phones, follow the chain with full security, and it would let the gas limit rise without pushing small validators out.

Two years ago this was science fiction because proving one block took many minutes. In December 2025 the Ethereum Foundation reported that the zkVMs tracked on Ethproofs prove 99% of mainnet blocks in under 10 seconds on target hardware (about $100k of GPUs within a 10 kW power budget). The Foundation then set a security-first plan for 2026: provers must reach 100-bit provable security by the Glamsterdam upgrade and full 128-bit security by the end of the year, with strict limits on proof size. Speed was the headline of 2025; soundness is the headline of 2026.

What is still hard

ZK is not magic, and the open problems are where a research group can contribute:

• Bugs in circuits. A circuit that forgets one constraint will happily prove false statements. "Under-constrained" circuits are the ZK equivalent of a missing access check, and several audits and academic tools now focus on finding them.
• Prover cost and centralisation. Fast proving needs expensive GPUs. If only a few companies can afford to prove, a "decentralised" rollup still depends on them.
• Soundness you can measure. Many deployed systems rely on conjectures about their parameters. Turning "we think it is secure" into a number you can audit is exactly what the 128-bit push is about.
• Usability for developers. Writing circuits by hand is error-prone. zkVMs let you write normal Rust and prove it, but they are larger and slower than hand-written circuits.

Takeaway

A zero-knowledge proof gives you two things that sound too good to be true: confidence without re-doing the work, and confidence without seeing the secret. Blockchains first used it for privacy, then for scaling, and are now moving it into the core of how the chain validates itself. If you want one thing to try this week, write a tiny circuit in Circom or Noir that proves you know the preimage of a hash, generate a proof, and verify it in a Solidity contract. It takes an afternoon, and after that every ZK paper becomes much easier to read.