Zero Knowledge
Usually, proving something means showing the evidence. You show the password, the identification, the receipt, or the computation. The verifier learns why the claim is true because you hand over the thing that makes it true.
A zero-knowledge proof separates those two acts. It lets one party prove that a statement is true without giving the other party the private information behind it.
The usual names are prover and verifier. The prover has a private witness: a password, a key, a credential, or the inputs to a computation. The verifier knows the public statement and the rules the witness must satisfy. The proof convinces the verifier that a valid witness exists without revealing the witness itself.
That requires three things. An honest prover with a valid witness must be able to convince the verifier. A dishonest prover must not be able to prove a false statement except with negligible probability. And the proof must reveal nothing beyond what the verifier could already infer from the fact that the statement is true.
The last condition is the strange one. Formally, zero knowledge is shown by constructing a simulator that can produce the verifier’s view without access to the secret. If the simulated exchange cannot be distinguished from the real one, then the real exchange did not carry usable knowledge of the secret.
The name is easy to overread. Zero knowledge does not mean that nothing is revealed. The public statement, the rules, the fact that a proof was made, and often a good deal of metadata remain visible. The claim is narrower: the designated private witness is not disclosed.
The cave
The standard story uses a circular cave with a locked door at the back. Alice knows the word that opens the door. She walks into the cave and chooses either the left or right path. Bob stays outside, then calls out which path he wants her to return through.
If Alice knows the word, she can always come back through the requested side. If she does not, she can only guess correctly half the time. Repeating the test makes a lucky bluff exponentially less likely: after rounds, the chance is . Bob becomes confident that Alice knows the word without ever hearing it.
The cave protocol is interactive; Bob supplies a fresh challenge each round. Many deployed proof systems are non-interactive because the proof needs to be stored or checked later by anyone. Some systems get there by deriving the challenges from a cryptographic hash of the transcript. Others use different public parameters. The construction matters. “Non-interactive” is not one universal trick.
SNARKs and STARKs
The acronyms make this subject sound less approachable than it is.
A SNARK is a succinct non-interactive argument of knowledge. Succinct means that the proof stays small relative to the computation being proved. Non-interactive means the prover can produce one artifact that a verifier checks later. Argument of knowledge means the security claim is computational and includes the claim that a successful prover possesses a valid witness. Add zk- when the construction also hides that witness.
Some SNARKs use an elliptic-curve pairing and a trusted setup. Groth16 is the familiar example. That is not a defining property of every SNARK. Systems such as Halo 2 use different commitments and avoid a circuit-specific trusted setup. Treating “SNARK” as a single design with one proof size and one trust model hides most of the engineering choices that matter.
A STARK is a scalable transparent argument of knowledge. Transparent means it does not rely on secret setup material. STARK constructions use hashes rather than elliptic-curve pairings and are designed around post-quantum assumptions. Their proofs are generally larger, while their proving and verification behavior can scale well for large computations.
Neither family is simply better. The actual scheme, circuit, security assumptions, proof size, prover cost, verifier cost, and setup procedure decide whether it fits a particular job.
What they are useful for
Zcash uses zero-knowledge proofs in shielded transactions. The network can verify that value was conserved, that the spend was authorized, and that the same note was not spent twice without publishing the sender, receiver, or amount. The proof protects the transaction fields it was designed to hide; it does not automatically remove timing, network, wallet, or usage-pattern leakage.
Validity rollups use the same basic separation for a different reason. A rollup executes a batch of transactions away from the base chain, then posts a proof that the old state was transformed into the new state according to the rules. Ethereum can verify the proof instead of re-running the entire batch. Here the main benefit is compressed verification, not necessarily privacy. Data availability remains a separate problem.
Selective disclosure is another direct use. Given a credential signed by an issuer, a person can prove that an encoded birth date satisfies an age threshold without revealing the date. The proof does not make the credential true and does not decide whether the issuer should be trusted. It proves only that a valid credential exists and satisfies the rule placed in the circuit.
The same structure works for delegated computation. A prover runs a program and produces a proof that the output follows from the agreed program and inputs. The verifier checks the proof without repeating all of the work. Zero knowledge can also hide designated inputs, but that is not the same thing as computing directly over encrypted data. Those are different cryptographic problems.
The boundary
Proof generation can be expensive. Turning an ordinary program into a circuit or another proof-friendly representation is real engineering work. A mistake in that representation is especially dangerous because the proof system can then provide very strong evidence for the wrong claim.
Zero knowledge also does not repair a bad surrounding protocol. It does not make an authentication system unphishable by itself. It does not hide public metadata. It does not solve data availability, key management, or a compromised endpoint. Often a signature, a password-authenticated key exchange, or an ordinary authenticated connection is the simpler answer.
The useful change is more specific. We are accustomed to treating disclosure as the price of credibility: if I want you to believe me, I must show you the underlying evidence. Zero knowledge makes that trade optional in cases where the claim can be stated precisely enough to prove.
The original formal definition is in Goldwasser, Micali, and Rackoff’s The Knowledge Complexity of Interactive Proof Systems. The Halo 2 book gives a concrete account of modern proof-system terminology. The original STARK paper explains the transparent construction, and Ethereum’s rollup documentation shows validity proofs in a deployed system.
That is the part I find important. The point is not secrecy for its own sake. It is gaining control over exactly what a proof has to reveal.
