Navigating privacy on public blockchains: utility and sovereignty

This article covers the three main approaches to on-chain privacy, TEE, MPC and ZK, and compares them on two axes: utility and sovereignty. Utility means what each approach can practically provide today, leaving far-fetched ideas like indistinguishability obfuscation out of scope. Sovereignty means the level of ownership the data source keeps over its data.

My argument, up front, and what the diagram above depicts (the area of each tier is its utility richness, its height the sovereignty it provides): MPC is the approach that takes us closest to both ultimate utility and ultimate sovereignty. Never 100 percent of either, but far beyond what the Internet gives us today, and sufficient for very nearly every legitimate use case.

One caveat: this article does not address performance. Performance has many metrics and each approach has many implementations, so it deserves a treatment of its own. The title, for those who recognize it, is a tribute to Wei Dai's excellent post on on-chain privacy.

Zero-knowledge proofs

ZK is the earliest form of on-chain privacy, first designed and deployed by the Zerocash and Zcash pioneers. Done right, zero knowledge achieves the greatest, arguably the ultimate, level of sovereignty. We believe Zcash reaches that level today, with "we believe" meaning: as long as the cryptographic assumptions hold. It was not always the case; the first two versions of Zcash provided sovereignty closer to the MPC level, and what made the third version great was dropping the trusted-setup assumption.

The limitation is structural: zero knowledge works over a single source of private data. You can prove your own transfer is authentic and does not double-spend, without revealing your address or amount, because the proof depends only on your secret and the public state of the chain. But you cannot prove an argument that depends on other people's private data. Think of private elections, sealed-bid auctions, dark pools. In a sealed-bid auction, no bidder can prove their bid is the highest, because nobody knows the other bids. Even ecosystems that lean heavily on ZK for privacy end up reaching for MPC when they build these applications; Renegade's dark pool is a good example.

A subtler and often overlooked issue is concurrency. Each ZK proof is anchored to a snapshot of the public state, typically a Merkle root of the shielded pool. Under peak demand, transactions race and invalidate one another, and users must recompute and resend. The Kachina line of work is meant to mitigate this, among other contributions.

Trusted execution environments

A TEE is a secure area of a processor that protects the code and data inside it, even against privileged system software. Through attestation, a TEE can prove to a remote user that it is running genuine, unmodified code. Together, TEEs and attestation enable hardware-backed wallets, identity systems and confidential contract execution.

The problem is what TEEs were never designed for: an attacker with physical access to the machine. In that setting it has been shown again and again that both confidentiality and integrity collapse; the hardware provides no guarantee at all. In the past year alone there have been at least four published attacks on production TEEs, several from Daniel Genkin's group; the TEE.fail account tracks them.

The mitigation the TEE community leans on, deploying enclaves in public clouds and trusting the cloud operator not to touch the hardware, is weak. It reintroduces single points of failure: one compromised machine, one zero-day, one insider with a screwdriver, and privacy is gone for everyone. It also makes availability entirely dependent on the cloud providers.

That said, honesty requires a concession: for some workloads we still have no sufficiently performant pure-cryptographic solution. LLM training and inference, and algorithms that depend on random memory access such as graph search, are the main examples. A lot of current research is aimed at closing this gap, and I expect MPC to cover these workloads too in time.

Multi-party computation

MPC protocols let a group of nodes compute on encrypted data without decrypting it. The application logic dictates what is revealed and to whom: a private ERC-20, for instance, reveals the new balances of sender and receiver only to the sender and receiver, respectively.

Since blockchain users cannot be expected to run an MPC protocol themselves, every practical deployment is MPC as a service: a designated set of N nodes accepts encrypted inputs through smart-contract transactions and performs the confidential workload defined in the contract, whether that is a private token transfer, an AMM, or anything else.

The three main ways to implement MPC for blockchains are secret sharing, fully homomorphic encryption and garbled circuits. They differ in the encryption format, in how the confidential workload is applied to encrypted data, and in how decryption works, and those choices carry heavy implications for performance, security, scalability and architecture. At Soda Labs we chose garbled circuits as the main building block, combined with other cryptographic techniques, because it gives the most cost-effective solution for throughput and latency.

In practice you also do not want all N nodes involved in every workload; that would make the network as slow as its slowest node and fragile to a single crash. So deployments define a threshold T, the minimum number of nodes that must engage for a workload to proceed. This is where the trust model lives: alongside the cryptography, these protocols carry a threshold assumption, namely that no more than T nodes are compromised at once. Operators tune N and T to fit their trust model, performance requirements and network design.

It is sometimes argued that the threshold assumption makes MPC's sovereignty inadequate, since T colluding nodes could in principle reveal private data without user consent. I disagree. MPC cannot match the sovereignty of trustless-setup zero knowledge, but with a large node set spread across jurisdictions, it provides a level of sovereignty far beyond anything in Web2 today, and sufficient for every blockchain use case I can think of.

The takeaway

MPC, possibly in combination with ZK and TEE, is the only path forward for achieving on-chain privacy with real utility and robust data protection.

I hope this offered some clarity as you navigate the fascinating, and often wild, world of blockchain privacy. Thoughts and feedback are always welcome.

For the full comparison with sources, see our technology taxonomy.