THE ESSENTIALS

  • Validity concerns whether a specified claim is supported; zero knowledge concerns what the proof reveals beyond the public statement.
  • A system can use zero-knowledge proofs while publishing transaction data through other parts of its design.
  • Evaluate the statement, private inputs, public outputs and surrounding application before treating a ZK label as a privacy guarantee.

The letters ZK appear in discussions about faster blockchains, private payments and digital identity. Those applications share cryptographic techniques, but they do not promise the same experience.

A useful starting question is: What is being proved, and what remains public? A proof can establish that a computation follows specified rules while the surrounding application openly publishes its inputs, outputs or transaction history.

Correctness and privacy are related design choices. They are not interchangeable labels.

Begin with the statement and the witness

A proving system works with a statement and supporting information often called a witness. Some information is public to the verifier; some may remain private.

Consider a hypothetical membership application. Its public statement is that the sender belongs to an approved group. The private witness supplies the information needed to demonstrate membership without naming the member. The verifier is meant to learn the claim’s validity, not the hidden membership secret.

The original Goldwasser, Micali and Rackoff paper introduced a way to reason about the additional knowledge communicated in a proof. It is a technical definition of information exposure, not a statement that nothing at all is visible.

For example, a system proving that an account exceeds a public balance threshold still reveals that threshold result. Repeating the question with many thresholds can reveal more through the application’s chosen outputs. The proof can satisfy its definition while the product asks overly revealing questions.

Three properties answer different questions

Jens Groth’s 2016 paper, particularly section 2.2, distinguishes the underlying properties. In plain language:

Source referenceCryptX

Three different cryptographic guarantees

Definitions for proving systems; not certification of a deployed application

Completeness
Honest proofs succeed
Soundness
False claims resist cheating
Zero knowledge
No extra witness disclosure

Measurement / reference: Groth, EUROCRYPT 2016, section 2.2; Zcash specification September 15, 2026

Retrieved / checked:

Method: Plain-language reference mapping of distinct definitions. Computational arguments depend on their stated adversary model and assumptions.

Limits: Public statements and information exposed outside the proof remain visible. No implementation audit or proof-validity audit is claimed.

For computational arguments, soundness is defined against adversaries with specified computational limits and relies on the relevant assumptions. “Argument of knowledge” adds a technical requirement concerning a witness; it does not mean that the verifier receives that witness.

These distinctions matter when reading an announcement. A smaller proof, faster verifier or newly supported computation is not automatically an improvement in application privacy.

Why a ZK rollup can expose transactions

A validity rollup uses proofs to support claims about changes to its state. The verifier checks the encoded relationship between the previous state, the batch computation and the resulting state.

Ethereum’s rollup documentation explains the separate role of transaction or state data needed to reconstruct and interact with the system. Publicly available data supports important properties such as independent state reconstruction. The presence of a validity proof does not erase information published through that data layer.

A hypothetical rollup might prove that a batch correctly updates balances and also publish enough information to observe transfers. Its proof can reduce the work required to check execution without concealing who sent what.

Conversely, a privacy-focused application needs an explicit design for hidden values, authorized disclosures and metadata. The relevant question is the network’s actual data model, not whether its name includes ZK.

Public outputs set the privacy boundary

The Zcash specification, version v2026.7.0-191-g0fae78 dated September 15, 2026, describes primary and auxiliary inputs in section 4.1.13. Its definition protects information about auxiliary inputs beyond what the statement implies.

That qualification is essential. If an application deliberately makes an amount a public input, a zero-knowledge proof does not make that amount secret. If a user posts identifying information alongside a proof, the proof does not remove the post.

Imagine an employee proving eligibility for a benefit. The proof might conceal their employee number, but a login account could still identify them to the website. Payment timing or a unique transaction amount could create further links outside the proof.

This is why a privacy assessment should name the observer. Hidden from other users, hidden from a public blockchain and hidden from the application operator are different goals.

A concrete application asks a narrow question

Semaphore V4 illustrates a specific use: someone can send a message as a provable group member without disclosing which identity in the group they use. The protocol also supports a mechanism to prevent repeated signaling in the relevant scope.

That is more informative than a generic claim of anonymity. It tells a reader which relationship the proof checks and one form of abuse the system addresses.

It does not establish that the group admitted only eligible people, that every person holds exactly one identity, or that the interface collects no identifying information. Those require additional mechanisms and evidence. A proof of membership in a poorly managed group faithfully proves membership in that group.

Read performance claims with their units

Groth’s 2016 construction describes a proof containing three group elements. That is a result for a particular construction and model. It is not three bytes, a universal proof size for every ZK system, or a measurement of an application’s total storage and network traffic.

A product comparison should identify the proof system, security parameters, workload, setup assumptions and what the measurement includes. Proof generation time, verification time, public input size and data publication costs are distinct quantities.

Likewise, a published audit needs a version and scope. Neither the existence of a research paper nor this explanatory article certifies a deployed implementation.

A practical way to evaluate the label

Ask for a short description of the public statement, the private witness, the public outputs and the parties who can see supporting data. Then ask how the implementation connects that proof to the intended business rule.

A useful claim might be: “This proves membership without publishing the member’s identity, while the message itself remains public.” It states a property that can be examined.

The broader phrase “powered by zero knowledge” leaves the most important part unanswered: zero additional knowledge about which information, for which observer, under which assumptions?

Sources & transparency

  1. Goldwasser, Micali and Rackoff — 1985 extended abstract ↗
  2. Jens Groth — EUROCRYPT 2016 accepted manuscript, section 2.2 ↗
  3. Zcash protocol specification — version v2026.7.0-191-g0fae78, September 15, 2026 ↗
  4. Ethereum — Zero-knowledge rollups ↗
  5. Semaphore V4 — protocol overview ↗

Prepared with AI assistance using the sources above. No individual human reviewer is claimed. How we use AI.

This article is educational and is not a recommendation to buy, sell or hold an asset. Jurisdiction and product terms matter.

Suggest a correction