The Blockchain Privacy Limitations of Zero Knowledge Proofs (ZKP)
Maybe you’ve heard Zero Knowledge Proofs (ZKPs) discussed in conjunction with blockchain privacy. And it’s true. They are a helpful tool for scaling privacy.
But they can’t address all of our privacy needs. ZKPs are limited in the type of privacy they can offer and the use cases they can serve, especially for smart contract applications.
Let’s take a look at why this is the case, and how ZKPs can be combined with other technologies to create a comprehensive privacy solution.
What are Zero Knowledge Proofs?
Zero knowledge proofs make it possible for users to prove they know something without revealing any details about it. For this to work, there must be a “prover/tester” and a “verifier”.
There’s a popular story of a cave that helps explain ZKPs:
Two friends, Alice and Jorge, find a cave. The cave has two paths in & out that lead to the middle, where there’s a door. There’s a code on this door that, supposedly, connects the two paths.
Jorge says he knows the code on the door. Alice would like to buy the code from him but wants proof that he knows it. Jorge can’t tell her the code straight away to prove it. So they both agree to a “zero knowledge” exchange test.
Alice will tell Jorge to enter the cave via one of the paths. If he really has the code, he’ll be able to exit via the other path.
The uses & benefits of Zero Knowledge Proof for blockchain
Zero Knowledge Proofs are a powerful technology.
So far, they’ve proven useful for functions like identifying users and checking signatures. ZCash leverages zero knowledge and is able to offer solid transactional privacy.
Zero Knowledge technology also helps with scalability. With ZKPs, a packet of information can be replaced by a lightweight “proof”, relieving blockchain congestion and speeding up transactions. This makes ZKPs suitable to build a highly scalable layer 1, or layer 2 scaling solution like zero-knowledge rollups.
What are the privacy limitations of Zero Knowledge Proofs?
To make DeFi private, a user needs to be able to trade with a trustless agent—like a DEX based on smart contracts—while keeping their data private at all times. And this isn’t possible with ZKPs.
Privacy breaks down for ZKPs when we move from transactions into the realm of secure computation.
Guy Zyskind explains how this works in practice:
A centralized party (often called the sequencer) executes all transactions (and computations) off-chain. This means that clients interact directly with this sequencer instead of the blockchain and send it their non-encrypted input data. The sequencer, after running all computations, produces a succinct proof and sends it to the blockchain alongside the outputs (usually the updated state). The blockchain, which acts as the verifier, verifies that the proof is correct, and if so, applies the state changes without learning the clients’ data directly. All general-purpose blockchain ZK solutions use this scaling method.
It’s simple. If you can see your data, you can prove it. You can’t prove similarities or differences with another person’s data. Who or what does that? The sequencer generates a proof over all participant data.
But if a user needs to trust an off-chain, centralized sequencer with their data… we’re back to the basic problem of Web2.
There are also theoretical concerns about information leakage on the infrastructure layer. For example, ZKPs don’t protect against transaction size analysis or various other forms of metadata leakage, which could potentially reveal information about ZKP transactions.
In short, ZKPs are great for keeping secrets locally (like a peer-to-peer transaction). But they can’t keep that same data private on a global/network scale.
This is, in large part, because zero knowledge proofs can’t make a smart contract or a DEX private. And why, unfortunately, ZKPs aren’t a fix-all for privacy.
When Zero Knowledge Proofs are combined with other blockchain privacy solutions
Zero knowledge proofs grow more robust and private when combined with additional blockchain privacy solutions.
For example, a builder might combine ZKPs with multi-party computation to build a fully private application. There are also hardware-based solutions (trusted execution environments, TEEs)—although you probably don’t need additional ZKPs when using TEEs.
Multi-party computation makes up for ZKPs shortcomings by enabling computation over encrypted i.e. private data. Hence, you can keep data private at the smart contract level.
For example, the internal state of a DEX could be encrypted, with MPC allowing you to perform computations over the data and update it without ever decrypting it. This keeps the data private at all times.
In that scenario, ZKP can help in its areas of strength: verifying user identity, signing, and lightweight transactions.
The future of Web3 privacy isn’t one-size-fits-all
Every privacy solution has its trade-offs. And no matter what you might have heard, there’s no single solution that can address all our privacy needs and has zero risk.
That’s why we’re building a constellation of privacy solutions for builders and users: Secret 2.0. Watch our short Secret 2.0 video if you’d like to learn more.
Want to dive deeper into the topic of different privacy solutions? Read our Beyond ZK Pt. 2 article for a more in-depth explanation.