Zero-knowledge proofs: proving without revealing data

To get into an adults-only event, you show your entire ID: name, date of birth, number, photo, sometimes your address. The doorman only needed to know one thing: whether you are 18 or older.

A zero-knowledge proof (ZKP) is a cryptographic technique that solves exactly this mismatch. It makes it possible to convince someone that a statement is true without revealing the data behind it. This article explains the idea, gives examples and points out where it is used and where it falls short.

What a zero-knowledge proof is

There are always two roles. The prover wants to convince. The verifier wants to be sure before accepting.

NIST, the U.S. standards institute, sums up the tool this way: proving that one knows the secret solution to a problem without revealing the solution (NIST, Privacy-Enhancing Cryptography). The “secret” has a technical name: the witness. The public statement is the instance.

NIST’s own example is a good one to remember. The instance is a number N, and the statement is “N is a valid RSA signing key”. The witness is the two secret prime numbers P and Q that, multiplied, give N. A zero-knowledge proof convinces the verifier that these primes exist and meet the rules, without handing over P or Q (NIST, zero-knowledge proofs).

Where the idea came from

The definition used to this day comes from a 1985 paper by Shafi Goldwasser, Silvio Micali and Charles Rackoff, “The Knowledge Complexity of Interactive Proof Systems”, published in its final version in 1989 (ethereum.org; Goldwasser, Micali and Rackoff).

The authors’ starting point is simple. An ordinary proof usually carries more knowledge than necessary. To prove that a route passes through every city on a map, for example, it is enough to show the route, but then you have handed over the route, not just the information that it exists. The paper proposes measuring how much knowledge a proof conveys and defines zero-knowledge proofs as those that convey nothing beyond the validity of the statement.

The three required properties

According to the Ethereum documentation, a protocol only deserves the name if it has three properties (ethereum.org):

• Completeness. If the statement is true and both sides follow the protocol, the verifier accepts.
• Soundness. If the statement is false, a dishonest prover cannot convince an honest verifier, except with negligible probability.
• Zero knowledge. The verifier learns nothing beyond “the statement is true”.

Note the phrase “negligible probability”. The proof is not an absolute certainty like a theorem on paper. It is a statistical certainty so high that, in practice, cheating does not pay.

An example to understand it: the cave

The best-known explanation is the Ali Baba cave, used by ethereum.org itself. Imagine a circular cave with a single entrance that splits into two passages, A and B. At the back, the passages meet at a door locked by a secret word.

Peggy (the prover) says she knows the word. Victor (the verifier) wants to be sure, but Peggy does not want to reveal the word.

1. Victor waits outside. Peggy goes in and picks a passage, without him seeing which one.
2. Victor comes to the entrance and shouts: “come out through passage A” (or B, at random).
3. If Peggy knows the word, she can always come out the requested side, opening the door if necessary.

Someone who does not know the word only gets it right when, by luck, they were already in the right passage: half the time. Repeating the challenge 20 times, the chance of an impostor getting every one right falls below one in a million. Victor is convinced. And he has learned nothing about the word.

This is the interactive model: a back-and-forth of questions and answers. It has a practical problem. It only convinces whoever took part. To an outside observer, Peggy and Victor could have arranged everything in advance.

Non-interactive proofs: a single message

The next step was non-interactive proofs, proposed by Manuel Blum, Paul Feldman and Silvio Micali. The prover sends a single message, and anyone with the system’s public parameters can check it (ethereum.org).

This is what makes the technique useful on blockchains. The proof can be published and verified by a smart contract, by thousands of computers, at any time, without any conversation with whoever generated it.

Two families dominate current use:

• SNARKs (succinct non-interactive arguments of knowledge). They produce small proofs that are fast to verify, but depend on a trusted setup: a ceremony in which participants create parameters and must discard the randomness used. If someone keeps that material, they can forge proofs. The elliptic-curve cryptography behind them may also be threatened by future quantum computers.
• STARKs (scalable transparent arguments of knowledge). They do away with the trusted setup and rely on hash functions, considered resistant to quantum computing. In exchange, the proofs are larger and cost more to verify.

Both descriptions follow the Ethereum documentation (ethereum.org).

Where zero-knowledge proofs are used

The list below follows the use cases cited by ethereum.org. The examples are meant to illustrate the technique and are not a recommendation of any service.

• Scalability. Zero-knowledge rollups execute transactions off the main network and send Ethereum a proof that the new state is correct. The network checks the proof instead of redoing all the calculations (ethereum.org, ZK-rollups). How they work is detailed in Rollups: how they expand network capacity, and the context in Layer 1 and layer 2.
• Identity. Proving an attribute, such as citizenship or legal age, without exposing the document. Ethereum.org cites Bhutan’s national digital identity as an example.
• Proof of personhood. Showing that you are a unique person in a system without saying who you are.
• Authentication. Proving that you belong to a group or have an access right without sending a password or personal data.
• Voting. Tallying votes without revealing each person’s vote, which makes vote-buying harder. Ethereum.org notes that the design it cites still requires trusting the coordinator of the tally.
• Private payments. Networks and tools that hide the sender, recipient or amount of transactions.

NIST adds a less visible use: proofs serve to ensure that participants in other cryptographic protocols are following the rules, as in multi-party computation (NIST, zero-knowledge proofs).

Limits and risks

Zero-knowledge proofs are not magic. The Ethereum documentation lists the main costs and risks (ethereum.org):

• Generation cost. Creating proofs requires a lot of computing power, sometimes specialized and expensive machines. This can concentrate proof production in a few operators.
• Verification cost. Verifying a SNARK proof on Ethereum costs about 500,000 units of gas, the network’s processing fee, and STARKs cost more.
• Trust in the initial setup. With SNARKs, you need to trust that whoever took part in the ceremony destroyed their secret share.
• Quantum threat. SNARKs based on elliptic curves may become vulnerable in the future.

There are also limits that math does not solve. In the editorial team’s assessment, three deserve attention:

• The proof only guarantees what was programmed. If the circuit describing the rule has a bug, the proof will confirm a wrong rule with the same conviction. That is why these systems undergo audits, with the limitations explained in Smart contract audits.
• Bad input stays bad. A proof of legal age is only as reliable as the document it came from and whoever issued it.
• Privacy belongs to the whole system. Metadata, such as timing, network address or usage patterns, can identify someone even when the proof reveals nothing.

Why this matters beyond crypto

NIST treats zero-knowledge proofs as one of the tools of privacy-enhancing cryptography, alongside techniques such as multi-party computation and fully homomorphic encryption. The institute follows the field to produce reference material that may, in the future, underpin standards. Between 2019 and 2024, it collaborated with ZKProof, an open academic and industry initiative that gathers technical material on the subject (NIST, PEC; NIST, zero-knowledge proofs).

The practical appeal is the same as in the doorman example: hand over only the answer that is needed. For those who collect data, keeping less means having less to lose in a breach.

Key takeaways

• A zero-knowledge proof convinces that something is true without revealing why. It must be complete, sound and leak no information.
• The non-interactive version is what makes use on blockchains possible: a single proof, checkable by anyone.
• Uses range from rollups to identity and voting, but the technique has high costs, may depend on a trusted setup and does not protect against badly written rules, poor source data or leaks through metadata.