Zero-Knowledge Proofs and Privacy
A zero-knowledge proof lets one party prove a defined statement without revealing the secret used to prove it. The verifier learns that the statement passed. It should not learn the hidden witness behind the proof.
That is narrower than anonymous communication. A proof can hide a wallet note or credential field while the application still exposes an IP address, account identifier, timing pattern, or public input. Privacy depends on the whole system, not the proof alone.
What the proof guarantees
Zero-knowledge proof systems are judged by three core properties. Completeness means an honest prover with a valid witness can convince the verifier. Soundness means a false statement should not pass except with a small defined probability. Zero-knowledge means the verifier can learn that the statement is true without learning the witness.
The statement must be precise. A payment system might prove that inputs exist, the spender can authorize them, and the values balance. A credential system might prove that a signed date of birth meets an age threshold. The proof does not establish facts that were never encoded into that statement.
| Layer | Can establish | Does not establish by itself |
|---|---|---|
| Cryptographic statement | A valid witness satisfies the programmed rules | That the rules match the user’s intended claim |
| Transaction | Hidden values balance under the protocol | That the wallet or device is uncompromised |
| Credential | An issuer-signed field meets a condition | That the issuer collected little data |
| Application | A proof verifies | That IP addresses, logs, or public inputs stay private |
Interactive proofs and succinct proofs
The original academic definition described an interaction between a prover and verifier. Blockchain systems need proofs that can be posted and checked later, so they commonly use non-interactive constructions. A prover creates one proof. Any verifier can check it against the public statement.
SNARK means succinct non-interactive argument of knowledge. Succinct proofs are small and cheap to verify compared with repeating the hidden computation. Different SNARK systems make different assumptions. Some require a trusted setup. Others avoid a per-application ceremony or avoid trusted setup entirely. Treat “ZK” as a family of techniques, not one security design.
Zcash shows both the power and the limits
Zcash combines a Bitcoin-like transparent pool with shielded pools. Its protocol uses zero-knowledge proofs to validate shielded spends without revealing which prior note was spent. Shielded output notes are encrypted for recipients. Public nullifiers prevent a note from being spent twice without identifying the note commitment that created it.
A shielded transaction does not make every field disappear. The chain still records commitments, nullifiers, proofs, and transaction structure. Moving value between a transparent pool and a shielded pool reveals the transferred amount. The Zcash specification says transparent transfers have essentially the same privacy properties as Bitcoin.
Zcash has also changed proving systems over time. Sprout and Sapling used setup ceremonies. Orchard uses Halo 2, and its protocol specification describes a single proof covering the actions in an Orchard bundle. Do not apply old trusted-setup claims to every current shielded transaction.
Wallet behavior matters. Shielded-to-shielded transfers avoid the transparent turnstile. A wallet can still leak data through remote node queries, address reuse outside the shielded protocol, device compromise, or an exchange account tied to the funds. See the Zcash shielded setup guide for the operational details.
Private smart contracts remain difficult
Aztec applies zero-knowledge proofs to private state and smart-contract execution on an Ethereum layer 2. Its Alpha network is live, but Aztec’s own documentation calls the software early and unaudited. It warns that transaction side-effect counts are visible, third-party node queries are not privacy-preserving, and application design can leak private information.
Those warnings matter beyond Aztec. A valid proof can coexist with an identifiable network request. Public contract calls can reveal relationships. A distinctive transaction shape can narrow the set of possible users. Cryptography can protect selected values while metadata identifies the person using them.
Selective disclosure is not anonymous identity
A credential issuer can sign attributes after checking a passport or other evidence. A holder can then prove a narrow predicate, such as being over 18, without sending the full credential to each verifier. This can reduce repeated disclosure.
It does not erase the issuer’s records. The issuer may know the holder’s identity. A verifier may require an account, log the proof request, or accept only named issuers. Revocation checks can create more metadata. The system can minimize disclosure to the verifier without making the holder anonymous.
Questions to ask before trusting a ZK system
- What is public? Read the exact statement, public inputs, transaction fields, and network calls.
- What is hidden? Confirm which witness values the proof protects and what the application logs.
- Which assumptions apply? Check the proving system, setup process, audits, and upgrade path.
- Who can link activity? Include credential issuers, wallet providers, RPC nodes, exchanges, and account operators.
- What happens at the edges? Transparent deposits, withdrawals, public contract calls, and identity-bound accounts can undo cryptographic privacy.
Sources
Frequently Asked Questions
What does a zero-knowledge proof hide?
It hides the secret witness used to prove a defined statement. It does not automatically hide network metadata, public inputs, wallet activity, or information leaked by the surrounding application.
Are all Zcash transactions private?
No. Zcash supports transparent and shielded value pools. Transfers between transparent and shielded pools reveal the transferred value. Shielded-to-shielded use provides the strongest on-chain privacy.
Do modern Zcash shielded transactions need a trusted setup?
The Orchard shielded protocol uses Halo 2 and does not rely on the older Sprout or Sapling trusted setup ceremonies. Older shielded pools used different proving systems and assumptions.
Can zero-knowledge proofs replace identity checks?
They can support selective claims such as proving that a signed credential contains an age above a threshold. The issuer still sees the original evidence, and the verifier must accept the issuer and proof system.