A valid proof is not automatically a private protocol
A ZK proof establishes its written statement, not the surrounding system privacy claim. A trust-and-leakage ledger makes the gap reviewable.
A valid proof is not automatically a private protocol
A proof can be sound and zero-knowledge for a relation while the product still exposes the property it claims to hide. The missing question is: what exact public statement does the verifier learn, and what does the surrounding protocol leak while establishing it?
Consider eligibility without identity. An abstract circuit might establish:
I know (credential, path, secret) such that
credential opens under an accepted root,
policy(credential attributes) = true, and
nullifier = H(scope, secret).
The verifier still learns the root, policy encoding, scope, and nullifier. A small or curated root can narrow the witness set; a policy can uniquely identify a holder; a global scope can link every action. The proof establishes the existence of a witness for this public statement. It does not establish that the issuer checked the right real-world attribute, that the root was honestly governed, or that transport and fee metadata are unlinkable.
Keep four claims separate
- Validity: this verification key accepted this proof and public input.
- Soundness: under named cryptographic and setup assumptions, acceptance implies a witness exists.
- Witness privacy: the transcript exposes no witness information beyond the public inputs in the proof model.
- Application privacy: observers cannot infer the protected real-world fact after issuance, inputs, metadata, and repeated use are considered.
Only the first is ordinarily visible on a ledger. Recursive proofs change verification topology and cost; they do not repair an omitted predicate or a revealing public input. An outer proof can only attest to the inner statement it actually verifies.
Publish a trust-and-leakage ledger
A deployment should name its trusted issuers and root governance, setup/parameter provenance, public-input semantics, linkability surfaces (nullifiers, commitments, timing, addresses, fees), and availability/coercion assumptions. This ledger identifies what no circuit can fix. A valid proof of membership in a maliciously curated root is still only proof of membership in that root.
A practical review asks: if the witness changed but public inputs, observable metadata, and application behavior stayed fixed, could the relevant observer tell? If not, state the model that makes that claim true. If yes, name the correlation channel rather than allowing ZK to stand in for an end-to-end privacy guarantee.

0 comments
No replies yet.