Chapter 16: -Protocols: The Simplest Zero-Knowledge Proofs

In 1989, a Belgian cryptographer named Jean-Jacques Quisquater faced an unusual challenge: explaining zero-knowledge proofs to his children.

The mathematics was forbidding. Goldwasser, Micali, and Rackoff had formalized the concept four years earlier, but their definitions involved Turing machines, polynomial-time simulators, and computational indistinguishability. Quisquater wanted something a six-year-old could grasp.

So he invented a cave.

The Children's Story

In Quisquater's tale, Peggy (the Prover) wants to prove to Victor (the Verifier) that she knows the magic word to open a door deep inside a cave. The cave splits into two paths (Left and Right) that reconnect at the magic door.

Peggy enters the cave and takes a random path while Victor waits outside. Victor then walks to the fork and shouts: "Come out the Left path!"

If Peggy knows the magic word, she can always comply. If she originally went Left, she walks out. If she went Right, she opens the door with the magic word and exits through the Left. Either way, Victor sees her emerge from the Left.

If Peggy doesn't know the word, she's trapped. Half the time, Victor shouts for the path she's already on (she succeeds). Half the time, he shouts for the other side (she fails, stuck behind a locked door).

They repeat this 20 times. A faker has a ≈ one-in-a-million chance of consistently appearing from the correct side. But someone who knows the word succeeds every time.

This story, published as "How to Explain Zero-Knowledge Protocols to Your Children," captures the essence of what we now call a -protocol: Commitment (entering the cave), Challenge (Victor shouting), Response (appearing from the correct side). Almost all modern cryptography, from your credit card chip to your blockchain wallet, is a mathematical version of this cave.

The paper became a classic, despite the fact that most children would probably stop listening after "takes a random path" to ask what "random" means. The cave analogy appears in nearly every introductory cryptography course regardless. What makes it so powerful is that it captures the structure of zero-knowledge: the prover commits to a position before knowing the challenge, then demonstrates knowledge by responding correctly.

This chapter develops the mathematics behind the cave. A prover commits to something random. A verifier challenges with something random. The prover responds with something that combines both randomnesses with their secret. The verifier checks a simple algebraic equation. If it holds, accept; if not, reject.

This is a -protocol. The name comes from the shape of the message flow: three arrows forming the Greek letter when drawn between prover and verifier. The structure is so pervasive that it appears everywhere cryptography touches authentication: digital signatures, identification schemes, credential systems, and as building blocks within the complex SNARKs we've studied.

Why study something so simple after the machinery of Groth16 and STARKs?

Because -protocols crystallize the core ideas of zero-knowledge. The simulator that we'll construct, picking the response first then computing what the commitment "must have been," is the archetype of all simulation arguments. The special soundness property (that two accepting transcripts with different challenges allow witness extraction) is the template for proofs of knowledge everywhere. And the Fiat-Shamir transform, which converts interaction into non-interaction, was developed precisely for -protocols.

Understand -protocols, and the zero-knowledge property itself becomes clear. This chapter prepares the ground for Chapter 17, where we formalize what "zero-knowledge" means. Here, we see it in its simplest form.

The Discrete Logarithm Problem

We return to familiar ground. Chapter 6 introduced the discrete logarithm problem as the foundation for Pedersen commitments. Now it serves a different purpose: enabling proofs of knowledge.

The setting is a cyclic group of prime order with generator . Every element can be written as for some . This is the discrete logarithm of with respect to . Computing from is hard; computing from is easy. This asymmetry, the one-wayness that made Pedersen commitments binding, now enables something new.

We use multiplicative notation throughout this chapter. In practice, most implementations use elliptic curves, where the group operation is written additively: becomes , becomes , and the Schnorr verification equation becomes . The mathematics is identical; only the symbols change.

The prover knows . The verifier sees but cannot compute directly. The prover wants to convince the verifier that they know without revealing what is.

The naive approach fails immediately. If the prover just sends , the verifier can check , but the secret is exposed. If the prover sends nothing, the verifier has no basis for belief. There seems to be no middle ground.

Interactive proofs create that middle ground.

Schnorr's Protocol

Claus Schnorr discovered the canonical solution in 1989. The protocol is three messages, two exponentiations for the prover, two exponentiations for the verifier.

Both parties know a group , a generator , and the public value . The prover alone knows the witness . The protocol proceeds in three moves:

  1. Commitment. The prover samples a random and computes . The prover sends to the verifier.

  2. Challenge. The verifier samples a random and sends to the prover.

  3. Response. The prover computes and sends to the verifier.

  4. Verification. The verifier checks whether . Accept if yes, reject otherwise.

sequenceDiagram
    participant P as Prover (knows w)
    participant V as Verifier

    Note over P: Sample r ← ℤq
    Note over P: Compute a = gʳ
    P->>V: a (commitment)

    Note over V: Sample e ← ℤq
    V->>P: e (challenge)

    Note over P: Compute z = r + w·e
    P->>V: z (response)

    Note over V: Check gᶻ = a · hᵉ
    Note over V: Accept / Reject

That's the entire protocol. The diagram above makes the shape visible: three arrows zigzagging between prover and verifier. Let's understand why it works.

Completeness. An honest prover with the correct always passes verification:

The algebra is straightforward. The commitment hides ; the response reveals a linear combination of and ; but one equation in two unknowns doesn't determine either.

Soundness. A prover who doesn't know can cheat only by guessing the challenge before committing. Once they send , they're locked in. For a random , there's exactly one that satisfies the verification equation (namely ). A cheating prover who doesn't know cannot compute this .

More precisely: suppose a cheater could answer two different challenges and for the same commitment . Then we'd have:

Dividing these equations:

The extractor computes from the known exponents:

This is well-defined since and is prime. To verify: .

This extraction is a proof technique, not something the verifier can actually do. In a real execution, the prover answers only one challenge, so stays hidden. But the argument shows that anyone who could answer two challenges for the same commitment must already know . Contrapositively, someone who doesn't know cannot reliably answer even a single random challenge. This property is called special soundness: two accepting transcripts with different challenges allow extracting the witness. It is why -protocols prove you know something, not merely that something exists.

There is a clean geometric way to see this. Schnorr's protocol is secretly proving you know the equation of a line. In , think of as the slope and as the y-intercept. The prover commits to the intercept (, hidden as ). The verifier picks an x-coordinate (). The prover reveals the y-coordinate (). In a single execution, the verifier learns one point on the line, which is consistent with infinitely many slopes, so stays hidden. But if an extractor could rewind and obtain a second point on the same line (same intercept , since was fixed), two points would determine the slope.

Honest-verifier zero-knowledge (HVZK). Here is where things become subtle. What follows is a restricted form of zero-knowledge that assumes the verifier behaves honestly (samples uniformly at random). Chapter 17 formalizes the full definition, which must handle malicious verifiers. For now, consider a simulator that doesn't know but wants to produce a valid-looking transcript . The simulator proceeds backwards:

  1. Sample (the challenge first!)
  2. Sample (the response, uniform and independent)
  3. Compute (the commitment that makes the equation hold)

Check: .

The transcript is valid. And its distribution is identical to a real transcript:

  • In a real transcript: is uniform (verifier's randomness), is uniform (because is uniform), and is determined.
  • In a simulated transcript: is uniform (simulator's choice), is uniform (simulator's choice), and is determined.

Both distributions have and uniform and independent, with determined by the verification equation. They are identical.

More formally, let denote the distribution of real transcripts and the simulator's output. Both are distributions over . In : where . In : where . In both cases, and are uniform and independent (in the real case, is uniform because is uniform and independent of ). The value is then uniquely determined by the verification equation . Since both distributions have identical marginals on and is a deterministic function of , we have (perfect equality, not just computational indistinguishability).

The transcript reveals nothing about that the verifier couldn't have generated alone.

In real execution, events unfold forward: Commitment → Challenge → Response. The simulator reverses this. It picks the answer first (), invents a question that fits (), then back-calculates what the commitment "must have been" (). This temporal reversal is invisible in the final transcript. Anyone looking at cannot tell whether it was produced forward (by someone who knows ) or backward (by someone who doesn't). If a transcript can be faked without the secret, then having the secret cannot be what makes the transcript convincing. The transcript itself carries no information about .

A Concrete Computation

Let's trace through Schnorr's protocol with actual numbers, then see how a simulator fakes a transcript.

Work in (order 10) with generator . The prover knows , and the public value is .

Real transcript: The prover samples , computes , and sends it. The verifier sends challenge . The prover computes (note: we reduce modulo the group order 10, not the prime 11). Verification: and . Both sides match.

The transcript is .

Simulated transcript: A simulator who doesn't know picks and (both uniform), then computes (since ). The simulated transcript is , identical to the real one. The simulator produced a valid proof without knowing . This is HVZK in action: the transcript carries no information about the witness.

Pedersen Commitments and -Protocols

Schnorr's protocol proves knowledge of a single discrete log. But in practice, we often need to prove knowledge of values hidden inside commitments. Chapter 6 introduced Pedersen commitments: commits to message with blinding factor , where are generators with unknown discrete log relation. -protocols let us go further and prove things about committed values.

This is not a coincidence. Schnorr's protocol and Pedersen commitments are algebraically the same construction. In Schnorr, the prover commits to and later reveals (a linear combination of the randomness and the secret). In Pedersen, the committer computes (a linear combination of two generators weighted by the message and randomness). Both rely on the same hardness assumption; both achieve the same hiding property.

Recall from Chapter 6: a Pedersen commitment is perfectly hiding (reveals nothing about ) and computationally binding (opening to a different value requires solving discrete log). The additive homomorphism lets us compute on committed values.

What Chapter 6 couldn't address: how does a prover demonstrate they know the opening without revealing it? This is precisely what -protocols provide.

Proving Knowledge of Openings

Schnorr handles one exponent; Pedersen commitments involve two: . To prove knowledge of the opening , we need the two-dimensional generalization. The structure mirrors Schnorr exactly (commit, challenge, respond) but now with two secrets handled in parallel:

  1. Commitment. Prover samples and sends .

  2. Challenge. Verifier sends random .

  3. Response. Prover sends and .

  4. Verification. Check .

This is just two Schnorr protocols glued together. One proves knowledge of the message part (, committed via ), the other proves knowledge of the randomness part (, committed via ). The same challenge binds them, ensuring the prover cannot mix-and-match unrelated values.

The analysis parallels Schnorr's protocol:

Completeness.

Special soundness. Two transcripts with the same but different challenges yield: From which both and can be extracted.

HVZK. Simulator picks uniformly, sets .

The prover demonstrates knowledge of the commitment opening without revealing what that opening is.

Proving Relations on Committed Values

The homomorphic property enables proving statements about committed values without revealing them.

For addition, given commitments , we can prove that the committed values satisfy .

Consider the product . Expanding the Pedersen structure:

If the relation holds, the exponent vanishes:

The combined commitment collapses to a pure power of . To prove the relation holds, the prover demonstrates knowledge of this exponent (a single Schnorr proof with base and public element ).

Multiplication is harder. Pedersen commitments aren't multiplicatively homomorphic. Given , , , how do we prove ?

The key insight is to change bases. Observe that:

If , then can also be viewed as:

Now substitute :

This expresses as a "Pedersen commitment with base " to the value with blinding factor .

The prover runs three parallel -protocols:

  1. Prove knowledge of opening (standard Pedersen opening)
  2. Prove knowledge of opening (standard Pedersen opening)
  3. Prove knowledge of opening with respect to bases

The third proof links to the second because the same appears. This linking requires careful protocol design, but the core technique is -protocol composition with shared secrets.

Fiat-Shamir: From Interaction to Non-Interaction

Interactive proofs are impractical for many applications. A signature scheme cannot require real-time communication with every verifier. A blockchain proof must be verifiable by anyone, at any time, without the prover present.

The Fiat-Shamir transform removes interaction. The idea is elegant: replace the verifier's random challenge with a hash of the transcript.

In Schnorr's protocol:

  1. Prover computes
  2. Instead of waiting for verifier's , prover computes (or for domain separation)
  3. Prover computes
  4. Proof is

Verification:

  1. Recompute
  2. Check

The transform works because is modeled as a random oracle: a function that returns uniformly random output for each new input. The prover cannot predict before choosing . Once is fixed, the hash determines deterministically. The prover faces a random challenge, just as in the interactive version.

In practice, is a cryptographic hash function like SHA-256. The random oracle model is an idealization (hash functions aren't truly random functions) but the heuristic is empirically robust for well-designed protocols.

Schnorr signatures are the direct application. Given secret key and public key :

  • Sign message : Compute , , . Signature is .
  • Verify: Check where .

Schnorr patented his signature scheme in 1989 (U.S. Patent 4,995,082). NIST needed a standard and designed DSA, later ECDSA, specifically to work around the patent. The result was a signing equation that includes a modular inversion . This non-linearity is the algebraic cost of the workaround: you cannot simply add ECDSA signatures, because the inverses don't combine.

The patent expired in 2008, and Schnorr signatures finally entered widespread use as EdDSA (Ed25519), now standard in TLS, SSH, and cryptocurrency systems. Bitcoin launched in 2009, but ECDSA was already the entrenched standard, so Satoshi used it. Ethereum launched in 2015 with ECDSA as well: audited Schnorr implementations on secp256k1 simply did not exist yet, and Ethereum still uses ECDSA today. It took until the 2021 Taproot upgrade for Bitcoin to adopt Schnorr. The linearity of enables what ECDSA cannot:

  • Batch verification: check many signatures faster than individually by taking random linear combinations (Schwartz-Zippel ensures invalid signatures can't cancel)
  • Native aggregation: multiple signers can combine signatures into one. MuSig2 produces a single 64-byte signature for parties that verifies against an aggregate public key
  • ZK-friendliness: no modular inversions, so Schnorr verification is cheap inside arithmetic circuits

Composition: AND and OR

-protocols compose cleanly, enabling proofs of complex statements from simple building blocks.

For AND composition, to prove "I know such that AND such that ":

  1. Run both protocols in parallel with independent commitments
  2. Use the same challenge for both
  3. Check both verification equations

If the prover knows both witnesses, they can respond to any challenge. If they lack either witness, they can't respond correctly.

OR composition is more subtle. To prove "I know OR " (without revealing which):

  1. For the witness you don't know, simulate a transcript (using the honest-verifier simulator from the zero-knowledge property)
  2. For the witness you do know, commit honestly to
  3. When you receive the verifier's challenge , set
  4. Respond honestly to using your witness

The verifier checks:

  • Both verification equations hold

As an example, suppose Alice knows the discrete log of but not . She wants to prove she knows at least one of them.

  1. Simulate the unknown: Alice picks and at random, then computes . This is a valid-looking transcript for .

  2. Commit honestly for the known: Alice picks and computes . She sends to the verifier.

  3. Split the challenge: The verifier sends . Alice sets .

  4. Respond honestly: Alice computes and sends .

The verifier checks and , plus . Both equations hold. The verifier cannot tell which transcript was simulated; the simulated is statistically identical to an honest execution.

You can prove you know one of two secrets without revealing which. Ring signatures, anonymous credentials, and many privacy-preserving constructions build on this technique.

Key Takeaways

  1. Three messages suffice for zero-knowledge proofs of knowledge. Commit → Challenge → Response. The commitment must come before the challenge; reversing this order destroys soundness.

  2. Special soundness: two accepting transcripts with different challenges enable witness extraction. This makes -protocols proofs of knowledge, not merely proofs of existence.

  3. Zero-knowledge via simulation: pick the challenge and response first, compute what the commitment must have been. If a transcript can be faked without the secret, the transcript carries no information about the secret.

  4. Schnorr is the archetype. Every -protocol in this chapter is a variation on : Pedersen openings run two Schnorr proofs in parallel, relations on committed values reduce to Schnorr proofs after algebraic simplification.

  5. Fiat-Shamir removes interaction by hashing the commitment to derive the challenge. This yields Schnorr signatures and non-interactive proofs.

  6. Composition builds complex proofs from simple ones. AND runs protocols in parallel with a shared challenge. OR uses simulation for the unknown witness; the verifier cannot tell which branch is real.

  7. Minimal assumptions: -protocols require only the discrete logarithm assumption. No pairings, no trusted setup, no hash functions beyond Fiat-Shamir.