Sudhanshu Bhardwaj

Zero-Knowledge in Web3: A Technical Deep Dive into Real Privacy

This post is a continuation of my first experiment with zero-knowledge circuits. That one was personal and practical: can I build a privacy-preserving age verification system without leaking birthdates?

This one is broader—and more opinionated.

After actually implementing ZK circuits, you start seeing a big gap between what Web3 marketing claims ZK does and what ZK is realistically good at today. Privacy is one of the places where zero-knowledge genuinely shines—but only if you’re precise about the threat model, the trust assumptions, and the costs.

So let’s do a real technical deep dive into how ZK is used for privacy in Web3, what kinds of privacy it actually provides, and where people are overselling it.

No hype. No VC pitch decks. Just mechanisms.

First, Let’s Be Precise: What “Privacy” Means Here

When people say “ZK gives privacy”, they often mean wildly different things.

In practice, ZK is good at one specific thing:

Proving statements about private data without revealing the data itself.

That’s it. Everything else—anonymity, unlinkability, censorship resistance—comes from system design, not from ZK alone.

Here are the main privacy properties people try to get in Web3 systems:

  1. Data privacy – hide inputs (balances, identities, attributes)
  2. Selective disclosure – reveal facts without revealing values
  3. Anonymity – hide which user performed an action
  4. Unlinkability – prevent correlating multiple actions by the same user
  5. Confidential state – keep contract state private

ZK can help with all of these—but never automatically.

The Core Primitive: Verifiable Private Computation

Everything in ZK-based privacy systems reduces to this:

A prover convinces a verifier that a computation was executed correctly on private inputs.

Formally:

  • Public input: x
  • Private input (witness): w
  • Circuit: C(x, w) = 1

The prover shows: “There exists a w such that C(x, w) evaluates to true”, without revealing w.

That’s the entire game.

From this, Web3 builds higher-level privacy constructs.

Privacy Pattern #1: Shielded Transactions (The “Zcash Model”)

This is the most well-known application.

Instead of publishing:

  • sender
  • receiver
  • amount

You publish:

  • a ZK proof that:
    • inputs exist
    • inputs haven’t been spent before
    • outputs balance correctly
    • ownership constraints are satisfied

What the ZK circuit enforces

  • Conservation of value
  • Knowledge of secret keys
  • Correct nullifier computation
  • Membership in a commitment tree

What stays hidden

  • Who paid whom
  • How much
  • Which notes were spent

What’s still public

  • Proofs
  • Nullifiers
  • Commitment roots
  • Timing and gas usage

Important:
ZK hides transaction data, not network metadata. If your network layer leaks identity, ZK won’t save you.

Privacy Pattern #2: Anonymous Set Membership

This is where ZK starts becoming useful outside payments.

Problem:

“Prove I am an authorized user, without revealing which one.”

Mechanism:

  1. All authorized users commit to a value (e.g., public key)
  2. Commitments form a Merkle tree
  3. User proves:
    • knowledge of a leaf
    • inclusion in the tree
    • without revealing the leaf index

This shows up in:

  • Private voting
  • DAO governance
  • Whistleblower systems
  • Anonymous credentials

Subtle but critical point

ZK proves membership, not identity.

If you don’t add:

  • nullifiers
  • epoch-based keys
  • one-time commitments

Users can either:

  • vote multiple times
    or
  • be trivially linked across actions

Privacy breaks silently if you get this wrong.

Privacy Pattern #3: Selective Disclosure (ZK Credentials)

This is the cleanest non-crypto-bro use case.

Instead of:

“Here is my passport / ID / certificate”

You prove:

  • age ≥ 18
  • citizenship = X
  • degree issued by Y
  • KYC passed

How it works (simplified)

  • Issuer signs attributes
  • User commits to attributes
  • ZK proof shows:
    • signature is valid
    • attributes satisfy constraints
    • attributes remain hidden

This avoids:

  • data over-collection
  • reusable identifiers
  • centralized verification APIs

But—and this matters—issuers are still trusted.
ZK does not remove trust; it relocates it.

Privacy Pattern #4: Private Smart Contract State

This is where things get hard.

Public blockchains fundamentally want:

  • transparent state
  • deterministic execution
  • global verification

ZK flips that by:

  • keeping state encrypted or committed
  • proving state transitions are valid

Typical design

  • State stored as commitments
  • Users submit ZK proofs of valid transitions
  • Chain verifies proofs, not state

Problems

  • State explosion
  • Complex circuits
  • Key management
  • UX disasters
  • Debugging nightmares

This is technically impressive, but still very fragile.

Most “private smart contract platforms” today:

  • restrict programmability
  • accept performance trade-offs
  • leak metadata in practice

The Uncomfortable Truth: ZK ≠ Anonymity

ZK hides values, not behavior.

You can have perfect ZK proofs and still leak:

  • timing
  • transaction graph patterns
  • gas usage
  • access patterns
  • off-chain correlations

That’s why many “ZK privacy” systems fail under real adversaries.

Privacy requires:

  • ZK circuits
  • network-layer protections
  • wallet-level hygiene
  • protocol-level anti-linkability

Miss one layer, privacy collapses.

Trusted Setup, Transparency, and Real Risk

A lot of Web3 ZK systems rely on SNARKs with trusted setups.

The honest framing is:

  • Trusted setup is not evil
  • Undocumented setup assumptions are

If:

  • setup is multi-party
  • transcripts are public
  • parameters are updatable

Then risk is manageable.

But if:

  • setup is opaque
  • generated by one party
  • unverifiable

Then your privacy guarantees are theoretical.

This is not a cryptography issue.
It’s a governance and engineering issue.

Performance Reality (No Sugarcoating)

Let’s be honest about costs.

Typical trade-offs

  • Proof generation: slow
  • Verification: fast
  • Circuits: brittle
  • Tooling: immature
  • Audits: expensive

ZK is asymmetric by design.
That’s good for blockchains—but terrible for UX if you’re careless.

You don’t “just add ZK” to an app.
You design around it.

Where ZK Privacy Actually Makes Sense Today

From experience, ZK is worth it when:

  1. Data exposure is unacceptable
  2. Verification is public
  3. Trust assumptions are weak
  4. Proof generation is infrequent
  5. Users benefit from non-disclosure

Examples:

  • Credentials
  • Compliance proofs
  • Voting
  • Authorization
  • Asset ownership claims

It is not worth it for:

  • CRUD apps
  • real-time systems
  • low-stakes data
  • problems solved by TLS + signatures

The Mental Shift That Matters

ZK changes how you think about systems.

You stop asking:

“Who should I trust with this data?”

And start asking:

“How do I avoid sharing this data at all?”

That’s powerful—but dangerous if misapplied.

ZK reduces data exposure, not responsibility.

Final Take

Zero-knowledge is not a silver bullet. It’s not magic. It’s not a replacement for good system design.

But it is the first practical cryptographic tool that lets us build:

  • verifiable systems
  • without mass data leakage
  • without permanent identifiers
  • without blind trust

If Web3 ends up being useful for anything long-term, it won’t be because of tokens or yield curves.

It’ll be because we finally learned how to prove things without oversharing.

That alone is worth understanding—hype aside.

Next post idea: breaking down a real ZK protocol and mapping exactly where privacy holds and where it leaks. If I write it, it’ll be ugly and honest.