Proof without the reveal

Say you want to show a friend that two balls are different colours, but your friend is colour-blind. They hide the balls behind their back, maybe swap them, and show you one. You say whether they swapped. If the balls were really the same colour, you could only guess, and you would be wrong half the time. After twenty rounds without a mistake, your friend is convinced. Yet they still don't know which ball is red.

That little game has all three properties a zero-knowledge proof needs:

• Completeness. If the statement is true and you follow the protocol, the verifier accepts.
• Soundness. If the statement is false, no prover gets accepted except with tiny probability. Every extra round halves a cheater's chances.
• Zero-knowledge. The verifier learns nothing beyond “it's true”. The formal version: anything the verifier saw, they could have produced on their own without the secret.

Goldwasser, Micali and Rackoff defined this in 1985. The surprising part, proven soon after, is that every statement you can check efficiently has a zero-knowledge proof, as long as basic cryptography (one-way functions) exists.

A blockchain can't play twenty rounds with you. It needs one message it can check alone. The Fiat–Shamir transform makes that possible: wherever the verifier would send a random challenge, the prover instead hashes the transcript so far and uses the hash as the challenge. Nobody can steer the hash, so the challenges are as good as random.

The catch is that everything has to go into that hash. In June 2025, researchers found that Solana's ZK ElGamal Proof program left one component out of a transcript. That opened a way to forge proofs, so confidential transfers were switched off within days. No funds were lost, and the program came back in 2026 after audits. The lesson stands: the hash is the security.

Every proof in the lab is non-interactive this way. The STARK prover there derives each challenge from a SHA-256 transcript of the commitments that come before it.

A proof is always about a computation. Three words do most of the work:

• Statement: the public part. “The fingerprint is 0x1b…9f.”
• Witness: the private input that makes it true. Here, the secret.
• Circuit (or constraint system): the computation written as equations, here “MiMC7(secret) = fingerprint”.

Change the circuit and you change what is proven. “This secret is in that Merkle tree” gives you an allowlist. “These encrypted amounts add up and none is negative” gives you a confidential transfer. The math underneath stays the same.

Two families matter on chain. A SNARK (succinct non-interactive argument of knowledge) has tiny proofs and fast checks: Groth16, the one most Solana programs verify today, is 256 bytes whatever the circuit. Most SNARKs need a trusted setup and rest on elliptic-curve pairings.

A STARK (scalable transparent argument of knowledge) needs no setup and uses only hash functions, which is why it survives quantum computers. The price is size: the STARK in this site's lab is 99,629 bytes. Chapter 4 covers why that trade-off is about to matter.

• ZK Compression (Light Protocol): accounts live as hashes in Merkle trees, and a single 128-byte proof shows the ones you touch are really there.
• Confidential transfers (Token-2022): balances are encrypted, and each transfer carries proofs that the hidden amounts add up.
• Private claims: allowlists, airdrops and votes where you prove membership without revealing which member you are. The lab builds one.