Zero Knowledge in Blockchain: How to Keep Privacy and Trust at the Same Time

The Myth of Anonymity

Many people believe that blockchain equals anonymity. In reality, it’s quite the opposite. A blockchain is decentralized, but every transaction is public. Anyone can open a block explorer and see:

• where the funds came from.
• the exact amount.
• where they were sent.

Addresses don’t come with names attached, but with enough context it’s often possible to link an address to a real person. Compare this with the banking system: your transactions are hidden from the public, but the bank sees everything — and it can freeze or control your account at any time.

In blockchain, we escape the control of banks, but we get radical transparency. The challenge is clear: how can we keep the system decentralized and trustworthy, but still protect user privacy?

The Colored Balls

Here’s a classic illustration with Alice and Bob. Alice is holding two balls: one red, one green. Bob is color‑blind and cannot distinguish their colors, but he needs to be sure that Alice really has two balls of different colors. He also cannot simply trust Alice’s word.

To test this, Bob hides the balls behind his back, then shows Alice one of them. After that, he may or may not swap it for the other ball before showing it again. Alice must answer whether it’s the same ball or a different one. If the balls are truly different colors, Alice will always answer correctly. If they are the same color, she would only be guessing.

Bob learns one crucial fact: Alice can genuinely see the difference. But he learns nothing about what the difference is. This is exactly how ZK works in blockchain: you prove knowledge of something without revealing the thing itself.

What a Proof Really Is

Note: To follow the upcoming sections more easily, it helps if the reader has a basic understanding of what a hash is.

In ZK systems, data is split into:

• Public inputs: visible to everyone (for example, “hashed transaction data”).
• Private inputs: known only to the prover (like a private key, balance, or other hidden values).

Mathematics ties these two sets together so that:

• The proof confirms “I know the private inputs that match the public inputs”.
• But the private inputs themselves are never revealed.

Think of it like a digital signature that only exists if you really know the private inputs.

Secrets and Nullifiers

Often when creating a hash of transaction data (such as amount, recipient, etc.), additional hidden elements are included to make the hash secure. These hidden elements are usually random values, so that each transaction looks unique and cannot be predicted.

• Secret: a random hidden value that is never revealed. It is combined with the transaction details when computing the hash, so that no one can simply guess or reconstruct valid data from the public hash. This randomness ensures the hash cannot be forged, even though the hash itself is public.
• Nullifier: also typically a random value, but one that is revealed only when spending or receiving. The network checks that the nullifier has not been used before — preventing double-spending — but without exposing the secret. The nullifier links the act of spending without linking back to the private details.

Smart Contract Verification

A smart contract can check a ZK-proof:

• It receives the proof.
• It verifies it with a built-in function.
• If valid, the contract knows the rule was followed.

The contract is never given the private inputs themselves. It can only confirm that the valid private inputs were known to whoever created the proof.

A Real-World Example

Suppose Alice wants to send funds to Bob in a way that prevents anyone from linking them together. Here’s how it works step by step:

• Alice takes the transfer amount, Bob’s address, a random secret, and a random nullifier. She combines these to create a hash.
• In this setup, the amount and the hash are public inputs, while the recipient (Bob’s address), the secret, and the nullifier are private inputs.
• Alice then creates a proof that shows she knows the private inputs consistent with the public ones, and sends a transaction with funds plus this proof to the contract.
• The contract checks the proof, accepts the specified amount, and stores the hash in its state.

Next, Alice prepares a proof for Bob to actually withdraw the funds:

• For this withdrawal proof, the public inputs are the hash, the amount, the recipient address (Bob), and the nullifier.
• Alice gives this proof to Bob, and Bob submits it to the contract.
• The contract verifies that the proof is valid, that the private inputs (though never revealed) must have been known by whoever created the proof, and that the hash exists in the contract’s records.
• The contract then pays the funds to Bob and marks the nullifier as used, preventing any double-spending.

This way, Alice sends funds without ever revealing Bob’s address, and Bob receives them without revealing from whom they came — while the contract still enforces correctness with full confidence. It is one of the most straightforward and simple ways to apply ZK in blockchain, but it is far from the only one.

The Linkability Problem

• An attentive reader might notice that the simple example above doesn’t fully solve the challenge. In both the deposit and withdrawal, the hash was public, and so Alice and Bob could still be linked directly. This simplification was intentional, to keep the example easy while introducing the core ideas. One common solution uses a Merkle tree (I don’t assume the reader already knows what a Merkle tree is, which is why I avoided adding this detail earlier in the simple example). Individual hashes are leaves of the tree. Bob then submits a proof that, without revealing the specific hash, shows he knows it and can prove its path up to the root. This makes verification a little more complex. But it removes the direct link between deposit and withdrawal by hiding the exact hash.
• The second issue is the amount. If we know exactly how much Alice sent and how much Bob received, the link is again clear. This too has solutions: for example, the system may allow only fixed denominations, or Alice may keep a balance inside the system so that the withdrawal amount can differ from the deposit.
• The third issue is timing. If Alice sends funds and shortly after Bob withdraws, with no other activity in between, it’s easy to connect them. The solution here is to introduce random delays or rely on higher overall system activity. The more users interact, the harder it becomes to match senders and receivers.

Popular Real-World Uses of ZK in Blockchain

• Zcash: one of the first cryptocurrencies to implement zero-knowledge proofs for private transactions.
• Tornado Cash: a mixer on Ethereum that uses ZK to break the link between depositors and withdrawers.
• zkSync and Polygon zkEVM: scaling solutions for Ethereum that use ZK-proofs to batch transactions and reduce fees.
• StarkNet: a ZK-based layer‑2 network focusing on scalability and efficiency.
• Mina Protocol: a blockchain that uses recursive ZK-proofs to keep the entire chain lightweight.

Conclusion

Zero Knowledge Proofs are the bridge between privacy and trust: they make it possible for decentralized systems to be both private and reliable at the same time.