Zero-Knowledge Proofs Explained

Imagine proving you are over eighteen without showing your date of birth, or proving you have enough money to cover a payment without revealing your balance. That is the promise of a zero-knowledge proof: convince someone that something is true while telling them nothing else. It sounds impossible, which is what made it one of the more surprising results in modern cryptography.

The classic intuition is a cave shaped like a ring, with a locked door splitting the far end into two paths. You claim to know the door's password. A skeptic waits at the entrance while you walk in and pick a path at random. They then shout which path they want you to come back along. If you know the password, you can always comply, because you can open the door and switch sides. If you are bluffing, you only have a fifty percent chance each round. Repeat it twenty times and the chance you are faking drops below one in a million. The skeptic ends up certain you know the password, yet they never learn what it is.

The three properties

That cave story is charming, and it also encodes the exact requirements every real zero-knowledge proof must meet. Cryptographers formalise them as three properties.

• Completeness. If the statement is true and both parties follow the protocol, the verifier will be convinced. An honest prover with a real secret always succeeds.
• Soundness. If the statement is false, no cheating prover can convince the verifier except with a vanishingly small probability. This is what the repeated rounds in the cave build up.
• Zero-knowledge. The verifier learns nothing beyond the truth of the statement. They cannot extract the secret, and they cannot even use the proof to convince anyone else.

The third property is the difficult and valuable one. It is formalised by showing that a verifier could have produced a transcript indistinguishable from the real interaction entirely on their own, without ever talking to the prover. If the verifier could have faked the whole conversation, then the real conversation cannot have taught them anything.

This "simulator" argument is worth sitting with, because it is the whole reason zero-knowledge is a rigorous claim rather than a hopeful one. The proof of the zero-knowledge property constructs a hypothetical program, the simulator, that takes only the public statement and produces a transcript that looks exactly like a real prover-verifier exchange, complete with challenges and responses, without any access to the secret. If such a program exists and its output is indistinguishable from the genuine article, then the genuine article can contain no extractable information about the secret, because everything in it could have been manufactured from public data alone. That is a strong guarantee. It does not say the verifier probably learns little. It says there is nothing to learn, formalized as an equivalence between the real transcript and one that never involved the secret at all.

The three properties also pull against each other in a way that makes the design delicate. Completeness wants the honest prover to always succeed, which pushes toward accepting proofs readily. Soundness wants cheating to almost always fail, which pushes toward rejecting proofs unless they are airtight. Zero-knowledge wants the accepting transcript to reveal nothing, which constrains what the verifier is even allowed to ask. A working protocol satisfies all three at once, and the repeated rounds in the cave are the mechanism that lets soundness grow arbitrarily strong without ever weakening the other two.

Interactive versus non-interactive

The cave is interactive: it needs a back-and-forth of challenges and responses. That is awkward for many real systems, where you want to publish a single proof that anyone can check later without a live conversation.

The Fiat-Shamir transform solves this. Instead of waiting for the verifier to supply a random challenge, the prover derives the challenge from a cryptographic hash of the statement and their own commitments. Because a good hash is unpredictable, the prover cannot cheat by choosing the challenge, yet no live interaction is needed. The result is a non-interactive proof: one self-contained object that anyone can verify independently. Almost every blockchain application relies on this. For the hashing that underpins it, see How Digital Signatures Work, which uses a closely related idea.

The security of Fiat-Shamir rests on the challenge being unpredictable to the prover before they commit. If a prover could choose or foresee the challenge, they could prepare a commitment that lets a bluff pass, exactly the cheating that soundness forbids. By deriving the challenge from a hash of the statement and the commitments together, the transform forces the prover to lock in their commitments first, then receive a challenge they could not have steered. This is also why the exact inputs to that hash matter so much in practice. Leaving the statement out of the hashed material is a well-known implementation error that can let a prover reuse a proof for a different statement, which is why careful constructions bind every relevant value into the challenge.

A worked example: proving a graph coloring

The cave is memorable, and a second example makes the commitment-challenge-response rhythm concrete. Suppose you want to prove that a particular map can be colored with three colors so that no two bordering regions share a color, and you want to prove you know such a coloring without revealing it.

The interaction runs like this. You take your secret valid coloring and randomly permute which actual color plays each role, so the specific colors change but the pattern of which regions match and which differ stays intact. You then commit to the color of every region, think of each color sealed in its own locked box, and hand the sealed boxes to the verifier. The verifier picks one border at random and asks you to open just the two boxes on either side of it. You open those two. The verifier checks that the two colors are valid and different. If your coloring was real, the two bordering regions always differ, so you always pass. If you were bluffing with an invalid coloring, at least one border somewhere is wrong, and the verifier had some chance of picking exactly that border and catching you.

One round gives the verifier only a small chance of catching a cheat, so you repeat the whole procedure many times, freshly permuting the colors and re-committing each round. Because you re-randomize the color assignment every round, the two regions the verifier sees in one round tell them nothing they can join up with the two from another round. Each opening shows only that one border is validly colored, never the coloring itself. After enough rounds the probability that a bluffer survives every single challenge shrinks to nothing, and the verifier becomes convinced you hold a valid coloring while having seen nothing but a series of unrelated, valid-looking pairs. That is completeness, soundness, and zero-knowledge working together on a real statement.

SNARKs, STARKs and the trade-offs

Modern zero-knowledge systems come in families with different trade-offs. The two names you will hear most are SNARKs and STARKs.

Property	zk-SNARK	zk-STARK
Proof size	Very small	Larger
Verification speed	Very fast	Fast
Trusted setup	Often required	Not required
Quantum resistance	Depends on the construction	Generally better

A zk-SNARK (succinct non-interactive argument of knowledge) produces tiny proofs that verify in milliseconds, which is why they became popular on blockchains where every byte and every computation costs money. The catch is that many SNARK constructions need a trusted setup: a one-time ceremony that generates public parameters. If the secret randomness from that ceremony is not destroyed, someone could forge proofs. Ceremonies are run with many independent participants so that a single honest one is enough to keep it safe.

A zk-STARK (scalable transparent argument of knowledge) removes the trusted setup entirely and relies only on hash functions, which also gives it better resistance to quantum attack. The price is larger proofs. Neither is strictly better; the choice depends on whether you care more about proof size or about avoiding a setup ceremony.

Where zero-knowledge proofs are used

The technique moved out of the theory papers when people found problems it solved cleanly.

Private cryptocurrency transactions. Some blockchains let you prove a transaction is valid, that the inputs exist and the amounts balance, without revealing the sender, receiver or amount. The proof convinces the network the rules were followed while keeping the details private. This is the most mature production use.

Blockchain scaling with rollups. A zk-rollup processes thousands of transactions off-chain, then posts a single succinct proof to the main chain showing that all of them were executed correctly. The chain verifies one small proof instead of re-running every transaction, which increases throughput dramatically. The zero-knowledge property is secondary here; the value is succinctness and verifiable computation. For the wider context see Blockchain Privacy Guide.

Selective disclosure identity. You can prove you are old enough, resident in a country, or accredited to trade, and the verifier receives only a yes or no. The underlying document stays with you. This is where zero-knowledge meets everyday privacy, and it overlaps with the goals of End-to-End Encryption Explained.

Verifiable computation generally. A cloud provider can prove it ran your computation correctly without you re-running it, a goal it shares with Homomorphic Encryption Explained, which keeps the data itself hidden during processing.

Authentication without shared secrets. A login system can let you prove you know a password without the server ever receiving it, so a breach of the server reveals nothing to reuse. The same principle secures hardware keys and passwordless schemes, where the device proves possession of a private credential while the secret never leaves it.

Proofs of knowledge versus proofs of a statement

There is a subtle distinction worth keeping straight. Some protocols prove that a statement is true, for example that a number has a square root, without proving the prover knows that root. Others, called proofs of knowledge, prove that the prover actually possesses a specific secret, called a witness. The cave story is a proof of knowledge: it demonstrates you hold the password, not merely that a password exists.

Most practical applications want proof of knowledge, because the value comes from tying the proof to a secret the prover controls. Spending a private coin means proving you know the key that owns it. Passing an identity check means proving you hold a valid credential. The formal machinery guarantees that if the proof succeeds, a hypothetical extractor could recover the witness from the prover, which is the precise sense in which the prover must genuinely know it. This is what stops someone from replaying or forging a proof for a secret they do not have.

Getting the reasoning right

Zero-knowledge proofs are powerful, and they are also easy to misunderstand in ways that matter.

1. A proof is only as meaningful as its statement. "I know a valid password" is useful; a poorly specified statement can be technically true and practically worthless. Get the statement right first.
2. Trusted setup is a real assumption. If you use a SNARK that needs one, understand who ran the ceremony and whether the toxic waste was destroyed.
3. Zero-knowledge hides the witness, not the metadata. The proof reveals nothing about the secret, but the surrounding system (timing, network, on-chain patterns) can still leak information. Treat privacy as a whole-system property.
4. Performance is the real constraint. Generating proofs is computationally heavy. The verification is cheap, but the proving side needs planning for anything at scale.

Zero-knowledge next to related ideas

Zero-knowledge is one tool in a family of privacy-preserving cryptographic techniques, and placing it alongside its neighbors clarifies what it uniquely offers.

Technique	What stays hidden	What it produces	Typical use
Zero-knowledge proof	The secret witness	Conviction that a statement is true	Prove a fact without the data behind it
Homomorphic encryption	The data being computed on	An encrypted result	Compute on data you cannot see
Secure multiparty computation	Each party's private input	A jointly computed output	Compute a function across parties
Digital signature	The private key	Proof a message came from a keyholder	Authenticity and integrity
Commitment scheme	A value until it is opened	A binding, hiding placeholder	Lock in a choice before revealing it

The lines blur because these techniques compose. A zero-knowledge proof often uses a commitment scheme as a building block, exactly the sealed boxes in the coloring example. Signature schemes derived through Fiat-Shamir are non-interactive proofs of knowledge of a private key. A system might run a computation under homomorphic encryption and attach a zero-knowledge proof that the computation was done correctly. What sets zero-knowledge apart in the group is its output: it produces belief in a statement while surrendering none of the evidence, which is a different deliverable from an encrypted result or a signed message.

Common misconceptions

"Zero-knowledge means the proof is anonymous." The property hides the witness, and it says nothing about network metadata, timing, or on-chain linkage. A perfectly zero-knowledge proof submitted from an identifiable address at a revealing time can still deanonymize you. Privacy is a whole-system property that the proof contributes to without guaranteeing.

"A trusted setup means the system is centralized or backdoored." A setup ceremony is an assumption, and well-run ceremonies distribute the trust across many independent participants so that a single honest one keeps the parameters safe. The concern is real and manageable, and transparent constructions like STARKs remove it entirely at the cost of larger proofs.

"Proving is as cheap as verifying." The economics are lopsided. Verification is usually fast and small, which is what makes these systems attractive on blockchains, and proof generation can be heavy in time and memory. Any system that generates many proofs has to plan for the proving cost.

"Zero-knowledge proves a statement is true in the world." It proves a statement about the prover's knowledge or about a mathematical relation, relative to the inputs given. If the statement is poorly specified, a technically valid proof can be practically meaningless. The rigor of the proof does not fix a badly chosen claim.

"It is quantum-proof." It depends entirely on the construction. Some SNARKs rest on assumptions a quantum computer would break, while hash-based systems like STARKs fare better. Zero-knowledge is a property of a protocol, not a blanket promise about the underlying hardness assumptions.

How the idea reached production

Zero-knowledge proofs began as a theoretical result in the 1980s, when researchers formalized the notion that a statement could be proven while leaking nothing about why it was true, and gave the simulator definition that made the claim precise. For years the work stayed in that theoretical world, elegant and impractical, because the constructions were too expensive to run on anything real.

Two threads carried it into practice. The first was steady progress on succinctness, producing proof systems whose output was small and quick to verify even for large statements, which turned "possible in principle" into "cheap enough to check on a busy network." The second was the arrival of public blockchains, which created a problem shaped exactly like what zero-knowledge solves: a shared ledger where everyone needs to verify that rules were followed, and where privacy and scalability both matter and both cost money. Private-transaction systems demonstrated confidentiality on a public chain, and succinct proofs of correct off-chain execution became the basis for scaling. The same machinery is now moving into identity and credential systems, where the goal is to reveal a single fact and withhold the document behind it. The core idea did not change across that journey. The engineering caught up with it.

Frequently asked questions

Does zero-knowledge mean the verifier learns absolutely nothing? The verifier learns exactly one thing: that the statement is true. Beyond that single bit, the zero-knowledge property guarantees they gain nothing they could not have produced themselves from public information, which is what the simulator argument establishes.

What is the difference between a proof and an argument? A proof's soundness holds even against an all-powerful prover, while an argument's soundness holds only against a prover who cannot break the underlying cryptography. Most practical systems are arguments, which is fine because that is the same computational security model the rest of the internet already relies on.

Why do some systems need a trusted setup? Certain succinct constructions require public parameters generated from secret randomness, and if that randomness is not destroyed it could be used to forge proofs. The setup ceremony creates those parameters, and distributing it across many participants ensures one honest party is enough to keep it secure. Transparent systems avoid the ceremony altogether.

Are zero-knowledge proofs only useful for blockchains? Blockchains are the most visible deployment, and the technique is general. It applies to identity checks that reveal only a yes or no, authentication where the server never receives the secret, and verifiable computation where one party proves it ran a job correctly. Any place where a fact needs sharing but the data behind it does not is a candidate.

Is a zero-knowledge proof the same as encryption? No. Encryption hides data while allowing it to be recovered by a keyholder. A zero-knowledge proof does not carry the data at all. It carries only evidence that a statement about the data is true, and there is nothing in the proof to decrypt back into the secret.

What is a witness in this context? A witness is the secret that makes the statement true, such as the password in the cave, the valid coloring in the graph example, or the private key that owns a coin. A proof of knowledge demonstrates the prover actually possesses the witness, formalized by showing an extractor could in principle recover it from a successful prover.

Zero-knowledge proofs took decades to travel from a theoretical curiosity to running code that moves real value. The core idea stayed constant the whole way: separate the fact you need to share from the secret that makes it true, and share only the fact. Once you see systems that way, a surprising number of privacy problems turn out to be zero-knowledge problems wearing a different hat.

Related guides

• Homomorphic Encryption Explained
• Blockchain Privacy Guide
• How Digital Signatures Work
• End-to-End Encryption Explained