What a zero-knowledge proof actually proves

The one-sentence version

A zero-knowledge proof lets a prover convince a verifier that a statement is true while revealing nothing beyond the fact that it is true. That sentence is accurate, and it hides almost everything that matters in practice.

The interesting questions are all about the word statement: who wrote it, what it actually says, and what the verifier does once it is convinced.

Statement, witness, relation

Every proof system works with the same three pieces.

• The public input is what both sides can see: a hash, a Merkle root, a public key, a threshold.
• The witness is what only the prover knows: a password, a credential, a path through a Merkle tree, the amounts in a transaction.
• The relation is the rule connecting them, written as a circuit or a program.

The claim is always the same shape: "I know a witness that, together with this public input, satisfies this relation." So a proof never says "this person is over 18". It says "I know some data that makes this particular circuit accept this particular public input." Whether that matches "this person is over 18" depends entirely on the circuit, and on where the data came from.

The three properties

A proof system is judged on three guarantees.

• Completeness. If the statement is true and the prover follows the protocol, the verifier accepts.
• Soundness. If the statement is false, no prover can make the verifier accept, except with negligible probability. Most systems used in practice give knowledge soundness: a prover who convinces the verifier must actually know a witness, not merely know that one exists.
• Zero knowledge. The verifier learns nothing it could not have produced on its own. Formally, a simulator without the witness can produce transcripts that look exactly like real ones.

Deployed systems are almost always non-interactive: the prover sends one proof and leaves. Interactive protocols are made non-interactive with the Fiat–Shamir transform, which replaces the verifier's random challenges with a hash of everything sent so far. That step is also where subtle bugs live. If the hash does not cover every public value, a prover can pick inputs after seeing the challenge.

A small circuit

The classic example, in Circom: prove you know a secret whose Poseidon hash is a given public value.

pragma circom 2.1.6;
include "circomlib/circuits/poseidon.circom";

template KnowsPreimage() {
    signal input secret;   // private: the witness
    signal input hash;     // public: what the verifier sees

    component h = Poseidon(1);
    h.inputs[0] <== secret;
    hash === h.out;        // the whole statement is this one constraint
}

component main {public [hash]} = KnowsPreimage();

A proof from this circuit says exactly one thing: the prover knows a field element whose Poseidon hash equals hash. It does not say who the prover is, when the secret was chosen, or whether anyone else knows it too.

What the proof does not prove

Most failures in deployed zero-knowledge systems are not breaks of the underlying cryptography. They are gaps between what the circuit says and what everyone assumes it says.

That the inputs are true about the world

A proof about a credential is only as good as the credential. If the circuit checks an issuer's signature, the proof inherits the issuer's trust. You have moved the question from "is this data true?" to "do we trust whoever signed it?" That is usually a good trade, but it is a trade, and it should be written down.

That the circuit says what you meant

Circuits are systems of constraints, and a value nothing constrains can be anything. In Circom, <-- assigns a value to a signal without adding a constraint. Sometimes that is necessary; often it is a bug.

signal inv;
inv <-- 1 / x;     // computes a value, constrains nothing
inv * x === 1;     // without this line, a prover can choose any inv

An under-constrained circuit still produces valid proofs. They are proofs of a weaker statement than the one on the whiteboard, and nothing in the verifier will tell you.

That it is bound to this use

A proof that is not tied to a context can be replayed. Systems bind a proof to its purpose by putting the context into the public inputs: a recipient address, an application identifier, a nonce.

For one-person-one-action rules, they add a nullifier: a value derived deterministically from the prover's secret and the application. The same person always produces the same nullifier inside one application, so a second attempt is visible, while two different applications see values they cannot link.

That the setup was honest

Some proof systems need a structured reference string produced in a setup ceremony. If every participant colluded and kept their secret randomness, they could forge proofs. Multi-party ceremonies reduce this to "at least one participant was honest", which is a strong guarantee, and still an assumption you should be able to name. Transparent systems such as STARKs avoid it entirely; choosing a proof system covers what that costs.

Reading a zero-knowledge claim

When a product says it uses zero-knowledge proofs, five questions get you most of the way to knowing what that means.

1. What exactly is the statement, written as a relation rather than a marketing line?
2. What are the public inputs, and does the verifier check every one of them?
3. Where does the witness come from, and who vouches for it?
4. What stops the same proof, or the same person, being used twice?
5. Which proof system, which setup, and which assumptions does soundness rest on?

If those have clear answers, the proof probably means what it says. If they don't, the cryptography can be flawless and the system still wrong.

If you would rather write circuits than read about them, Rump Gurukul builds these ideas from first principles, through to an application of your own.