中文版 · Blockchain learning guide · Previous article
Blockchain learning · Article BC018
A zero-knowledge proof can let a verifier check a precisely defined claim while withholding private supporting information, under the proof system’s stated security model. The useful question is not “is this zero knowledge?” in isolation. It is: what exact statement is checked, which inputs are public, which information remains private, and what assumptions connect that statement to the application?
This article is a statement-design lab. We will specify a fictional allocation claim, test missing conditions, and inspect what a successful proof would still reveal. We will not construct or generate an actual cryptographic proof. Checking the toy arithmetic by hand demonstrates the intended relation, not the zero-knowledge property of a real implementation.
For the broader mathematical context, see How Mathematics Works: Cryptography. This lesson develops the separate skill of auditing a proof’s claim and privacy boundary.
Choose your reading route
In this guide
- 1. Separate the statement from its supporting witness
- 2. Define a fictional allocation claim
- 3. Write the public-input and witness inventories
- 4. Test the relation before discussing privacy
- 5. Remove one condition and see the claim weaken
- 6. “Zero knowledge” does not erase public deductions
- 7. Three guarantees, with different jobs
- 8. What the allocation claim does not establish
- 9. Bind context and freshness deliberately
- 10. Review implementation and cost claims separately
- 11. A statement-review exercise
- Frequently asked questions
- Sources and next reading
Begin with public inputs and private witnesses if the terminology is new. Continue through the allocation example to see how a claim becomes a checklist of constraints. For application review, focus on missing conditions, public disclosure, replay, and the final statement card.
You need only elementary integer arithmetic. No personal records, financial transactions, secret keys, or production proof tools are involved.
Back to contents · Next section
1. Separate the statement from its supporting witness
A proof system works with a specified relation: a rule describing which combinations of public and private inputs are valid. The public inputs select the particular claim being checked. The private supporting information is commonly called a witness; implementations may also include intermediate values in that term.
For example, “I know an input that hashes to this public digest” separates the public digest from the private input. It does not require hiding the existence of the digest or the fact that the verifier is checking this relation.
The halo2 Book’s proof-systems chapter distinguishes the relation, its circuit implementation, public inputs and witness. It also separates ordinary soundness from knowledge soundness. This matters when an application wants evidence that a prover knows supporting information, rather than only that suitable information exists.
Do not describe every zero-knowledge proof as hiding the statement itself. Many applications deliberately publish the claim and its public inputs while protecting the witness. Whether a protocol protects additional information depends on its precise construction and security definition.
Back to contents · Next section
2. Define a fictional allocation claim
A fictional workshop distributes twelve demonstration cards between two trays. Each tray may contain an integer number of cards from 0 through 9. The workshop wants to publish the total and show that the allocation meets the limits, without publishing the exact ordered pair of counts.
Call the first tray’s count x and the second tray’s count y. The intended arithmetic conditions are:
- x is an integer from 0 through 9.
- y is an integer from 0 through 9.
- x plus y equals the public total, 12.
By themselves, these conditions are easy for anyone to satisfy. A person can choose 6 and 6. If the application wants a claim about a previously recorded allocation, it needs a connection to that allocation, not merely evidence that some convenient pair exists.
We therefore add a public commitment C to the ordered pair. For this conceptual lab, assume an appropriately specified commitment scheme with the required hiding and binding properties, including its secret randomness and encoding rules. We do not replace that assumption with a plain hash of one of seven guessable pairs.
The witness includes x, y and the private information needed to open C. The relation must check that this witness opens the particular public commitment and satisfies the range and sum conditions. There is no concrete commitment value or cryptographic proof in the exercise; the commitment is an explicitly assumed component of the design.
Back to contents · Next section
3. Write the public-input and witness inventories
Our statement card records the following public inputs: the commitment C, the total 12, the upper limit 9, and the identifier of the precisely specified relation or verification program. The application also records which workshop round and accepted commitment entry the claim concerns.
The private witness contains the ordered counts x and y and the required commitment-opening information. A real circuit may require additional intermediate witness values, depending on how it represents the operations. Those implementation details must still support the intended relation.
Now write the claim in ordinary language: “There are integer counts in the allowed ranges that open this accepted commitment and sum to 12.” If the application requires a proof of knowledge of that opening, it must select and verify a system offering the relevant knowledge property; the word proof alone is not enough.
Keep the application’s acceptance conditions alongside the mathematical statement. Is C the commitment registered for this round? Is the verifier using the intended relation version? Is the submission authorized? These checks may occur inside or outside the proof according to the actual protocol, but they cannot simply be omitted.
This inventory prevents a common mistake: assuming that because a value appears on the same webpage as a proof, it must have been bound into the proof or checked by the accepting application.
Back to contents · Next section
4. Test the relation before discussing privacy
List the allowed ordered pairs when the public total is 12:
- 3 and 9.
- 4 and 8.
- 5 and 7.
- 6 and 6.
- 7 and 5.
- 8 and 4.
- 9 and 3.
There are seven. Order matters because the trays have different names. All seven satisfy the range and sum rules, but only an opening consistent with the specific commitment should satisfy the complete relation under the binding assumption.
For a paper check, use the witness 4 and 8 and assume its commitment-opening check succeeds. Four lies in the permitted range, eight lies in the permitted range, and their sum is twelve. This demonstrates a valid arithmetic witness under the assumption. Showing the numbers to the class is not a zero-knowledge protocol; it is a way to inspect the intended constraints.
Next try 2 and 10. The sum is twelve, but the second range condition fails. Try 4 and 7: both ranges pass, but the sum fails. A correct verifier for the intended relation should not accept either candidate merely because most of the checks pass.
These small negative tests are valuable because a sophisticated proof system cannot compensate for an application that asks it to prove the wrong relation.
Back to contents · Next section
5. Remove one condition and see the claim weaken
First remove the commitment-opening condition. A prover can then choose any convenient valid pair, regardless of what was recorded earlier. The proof may correctly establish the weaker arithmetic statement while failing the application’s intended link to a specific allocation.
Now keep the commitment but remove the ranges. The integer pair 20 and minus 8 sums to 12. If such values are admitted by the remaining relation, the proof no longer establishes that each tray’s count is allowed.
Representation creates another possible gap. Many circuits perform arithmetic over a finite field rather than ordinary unbounded integers. In a separate toy field with modulus 101, 100 plus 13 has remainder 12. That modular equality is true, but both proposed counts violate the intended 0-to-9 ranges.
A production design must implement the intended integer constraints and encoding correctly. In our toy, valid counts sum to at most 18, below 101, so the stated bounds would also prevent this particular wraparound confusion. This is a hand-checkable illustration, not guidance for choosing a production field or range-proof implementation.
Finally, remove the relation-version check in the application. A valid proof for an older, weaker relation might be mistaken for a proof under the stronger policy. The verification key, circuit identity, public-input schema and application acceptance policy must refer to the intended statement.
Back to contents · Next section
6. “Zero knowledge” does not erase public deductions
With total 12 and both counts between 0 and 9, an observer already knows that each count is at least 3. That conclusion follows from the public constraints alone. It is not a leak caused by a defective proof.
Now change the public total to 18 while keeping the same bounds. Only the ordered pair 9 and 9 remains. Even an ideal zero-knowledge protocol cannot hide information logically forced by the statement the application deliberately reveals.
This is why privacy review must inspect public inputs, outputs and repeated queries. Asking enough related questions can narrow the possibilities, even if every individual proof satisfies its formal zero-knowledge definition. A policy that reveals totals across overlapping groups may disclose more than its designer expected.
A properly hiding commitment is also a separate assumption from the proof’s zero-knowledge property. If the application publishes a plain digest of a tiny candidate set, someone may test candidates without attacking the proof. A private witness cannot repair information already disclosed by another field.
The right privacy question is therefore: what can the observer infer from the entire authorized transcript and surrounding data? “The witness was never printed” is a useful fact, but not a complete answer.
Back to contents · Next section
7. Three guarantees, with different jobs
Completeness concerns acceptance when honest participants use valid inputs under the system’s specified conditions. Soundness limits a cheating prover’s ability to make a verifier accept a false statement. Zero knowledge concerns what the verifier learns about the private supporting information beyond what the permitted statement and public information already convey.
These properties have precise definitions and may be perfect, statistical or computational in different systems. The ZKProof Community Reference, version 0.3 discusses those distinctions. It is dated 17 July 2022 and explicitly identifies itself as an incomplete draft, not a completed universal standard.
The terminology also distinguishes proofs from arguments, depending on computational assumptions about adversaries. Introductory writing often uses “proof” broadly; a technical evaluation should inspect the actual guarantees rather than infer them from a product label.
For our workshop, a sound proof of a badly specified relation is still the wrong evidence. A privacy-preserving proof can still reveal an overly informative public total. A mathematically complete construction can still be implemented incorrectly. Each layer has a different question to answer.
Back to contents · Next section
8. What the allocation claim does not establish
Suppose a workshop operator enters fictional counts into the commitment instead of counting the physical trays. A valid proof can establish consistency with those committed numbers. It cannot observe the trays or certify that the operator measured them honestly.
If real-world accuracy matters, the application needs an appropriate source or attestation process, with its own trust assumptions. A zero-knowledge proof may help verify properties of authenticated data without revealing all of it, but it does not create the original authentication or observation merely by existing.
Similarly, a proof about C does not establish that C is the current accepted commitment. A blockchain application must connect the proof to the appropriate recorded state and apply its update rules. An old valid proof can remain valid for its old public inputs while being inappropriate for today’s request.
The proof also does not promise that every necessary underlying file is available, that the user interface is honest, or that the prover’s machine never disclosed the witness elsewhere. A remotely hosted proving service may receive the witness if the workflow sends it there. Privacy from the final verifier is not automatically privacy from every service in the generation path.
These are design questions, not reasons to reject the technology. A useful proof can reduce disclosure substantially when its statement and boundaries match the task.
Back to contents · Next section
9. Bind context and freshness deliberately
Imagine a proof created for workshop round A being copied into round B. If the accepting application checks only a generic arithmetic relation, it may miss that the claim concerns a different commitment or purpose.
The design should identify which context is bound into the relation or surrounding authenticated protocol and which acceptance state prevents inappropriate reuse. Simply displaying a round label next to the proof does not bind it. Nor does adding a public field to a user interface guarantee that the verification program actually checks it.
Knowledge claims need particular care. A transferable proof originally generated by someone else should not automatically authenticate the current presenter as the original prover. The halo2 Book notes replay and related protocol concerns when discussing knowledge soundness.
For this lab, do not invent a custom anti-replay mechanism. Write the requirement: “The application must verify the correct commitment and round, and apply its defined authorization and reuse policy.” A real protocol must then specify how that requirement is achieved.
Notice how the statement card becomes more useful than the slogan “prove without revealing.” It exposes exactly where the mathematical relation ends and the application decision begins.
Back to contents · Next section
10. Review implementation and cost claims separately
A circuit is an implementation of a relation, not the English sentence itself. Reviewers need evidence that the constraints actually express the intended ranges, sums, commitment opening, and public-input binding. Testing ordinary examples alone may miss unconstrained variables or boundary errors.
A proof system also has its own parameter and setup assumptions. Some constructions require carefully generated setup material; others have different setup models. No broad name such as zero knowledge eliminates all trust assumptions. Select the actual construction before evaluating them.
Performance is similarly specific. Proof generation, verification, memory, proof size, public-input size and on-chain costs can behave differently. A short proof need not be cheap to generate, and privacy does not imply succinctness. Claims should name the system, workload and measurement conditions.
For the fictional allocation task, first ask whether the privacy benefit justifies the added implementation and review burden. If the counts are already public and harmless, a normal signed report may be sufficient. If confidentiality matters, compare the proof approach with the real disclosure requirements rather than adopt it because its name sounds advanced.
Back to contents · Next section
11. A statement-review exercise
For each proposed acceptance message, identify the overclaim and replace it with a narrower conclusion.
Message A: “The proof passed, so the two physical trays contain exactly the committed counts.”
Answer: the proof checks the specified relation about committed values. Physical observation needs separate evidence.
Message B: “The total is 18 and both counts are at most 9, but neither count can be inferred because the proof is zero knowledge.”
Answer: the public constraints force both counts to be 9. That deduction is available without learning anything extra from the proof.
Message C: “The sum check passed, so both counts are valid.”
Answer: only if the intended range constraints were also correctly enforced. The pair 20 and minus 8 shows why a sum alone is insufficient.
Message D: “A valid proof for last month’s commitment authorizes this month’s update.”
Answer: not without the appropriate context, authorization and state checks. Mathematical validity under old public inputs does not establish current applicability.
Message E: “The prover used a cloud service, so the witness remained private from everyone.”
Answer: inspect where witness data was sent and processed. Zero knowledge toward the verifier does not automatically hide it from a proving service that received it.
Message F: “We used an advanced proof system, so the circuit must implement the intended policy.”
Answer: the relation-to-circuit translation needs separate review. A strong system can prove a weaker or mistaken statement very reliably.
Back to contents · Next section
Frequently asked questions
Is this encryption of the witness?
No. The goal is to verify a claim without disclosing the private supporting information under the proof’s model. It is not simply a ciphertext that the verifier later decrypts.
Does every zero-knowledge proof have a tiny proof size?
No. Zero knowledge is a privacy property. Succinctness and efficiency are additional properties of particular constructions.
Does a proof prove that its input data is true?
It proves the specified relation under its assumptions. Real-world provenance, accepted state and application authorization require the evidence the relation or surrounding protocol actually checks.
Did the seven-pair exercise generate a zero-knowledge proof?
No. It enumerated valid arithmetic witnesses and tested the intended claim. A real proof needs a specified construction, implementation, parameters and security analysis.
Back to contents · Next section
Sources and next reading
Sources checked on 12 October 2026, Singapore time. The allocation relation, seven ordered pairs, total-18 deduction and modulus-101 counterexample are original teaching examples. The commitment scheme is an explicit assumption rather than an implemented algorithm.
- The halo2 Book: Proof systems, for relation, circuit, witness and knowledge-soundness terminology.
- ZKProof Community Reference v0.3, dated 17 July 2022, an explicitly incomplete community draft covering security and implementation distinctions.
- How Mathematics Works: Cryptography, for the existing broader foundation.
Return to the inclusion-proof lesson when a claim depends on membership in a particular accepted commitment. Continue to multisignatures and threshold signatures to examine a different question: how several participants can share control over an authorization.