Wei Dai: Why privacy is one of the last barriers to mass adoption of public chains How to achieve on-chain privacy?

This article addresses the state of privacy in the context of public blockchains (aka decentralized ledgers, cryptocurrencies, and Web3). The first part covers why privacy is a key barrier to widespread blockchain adoption, and what are the different aspects of privacy. The second part investigates three different approaches to privacy: through zero-knowledge proofs, targeting only anonymity, and through a new abstraction called MOCCA.

Part 1: Why and what are the privacy properties of public blockchains?

Privacy – The Last Barrier to Blockchain Mass Adoption

Because the modern financial system works so well, we don’t have to worry about the security or privacy of day-to-day transactions. When you’re shopping at the supermarket, paying your rent by check, or taking out a short-term loan at the bank, you don’t have to worry about your transaction being publicly scrutinized by unrelated parties. In modern banking and credit card networks, transaction details (for the most part) stay within the relevant financial intermediaries and authorities. Users would (ideally) not have to worry about their sensitive information being leaked to the public, while authorities could (mostly) track down illegal activity.

Unfortunately, this is not the case with transactions on popular blockchains today. While blockchain technology promises to decentralize and democratize the current financial ecosystem, most systems fail to meet even the most basic level of privacy we expect. The transaction history of your pizza purchases may be permanently recorded, and all of your transactions are easily publicly accessible on Etherscan. While there are some privacy-focused projects out there, they are currently underutilized due to asymmetries in functionality and ease of use. This marks privacy as one of the key barriers to mass adoption of blockchain technology.

Privacy properties in a public blockchain environment are not an all-or-nothing function. Rather, it is a complex and multidimensional problem that requires caution when navigating. Let us first need to gain a deep understanding of what types of privacy properties are relevant for blockchain applications.

The feature axis of privacy

Axis A: Anonymity and confidentiality. Broadly speaking, there are two types of privacy in financial transactions: anonymity and confidentiality . When a nonprofit receives an anonymous donation, they do not get any information about the donor (anonymity), but they know the amount of donation received. When you check out at the pharmacy, your purchases are kept confidential – the people behind you don’t know what medicines you might be prescribing and the prices of those medicines, but they know you’re buying them.

Wei Dai: Why privacy is one of the last barriers to mass adoption of public chains How to achieve on-chain privacy?

Anonymity: Can people know that I am the originator of the transaction?
Confidentiality: Can people know the content of my transactions?

Axis B: On-chain applications and intermediary applications. One of the fundamental theories of blockchain and cryptocurrencies is the ability to conduct financial transactions without a trusted intermediary. Following in the footsteps of Bitcoin, almost all cryptocurrencies allow direct payments without intermediaries. Smart contract platforms such as Ethereum go a step further by enabling financial transactions other than payments, such as trading and lending, to take place without an intermediary. In this article, we use the term on-chain to describe functions and applications, such as payments, transactions, and lending, that users can use directly as a consensus node operator. (As a reminder: users typically do not run their own consensus nodes. For example, third-party RPC endpoint providers for Web3 wallets should be considered intermediaries in practice). Some examples of on-chain applications include Bitcoin and Zcash payments, Uniswap transactions, and Compound lending.

Wei Dai: Why privacy is one of the last barriers to mass adoption of public chains How to achieve on-chain privacy?

Unfortunately, intermediaries are still ubiquitous in the ecosystem. Exchanges like Coinbase are the intermediaries for the services they provide – users need to deposit assets on these exchanges to trade. Even some “decentralized” protocols rely on centrally operated intermediaries. For example, both dYdX and DiversiFi have centralized exchange operators. This is unlike on-chain counterparts such as Uniswap, which do not require interaction with servers outside the consensus network. Compared to Coinbase, dYdX and DiversiFi feature the removal of the trust needed to secure funds. Instead, users need to trust cryptography and code, especially STARKs, to keep their funds safe. Payment channel networks (such as Lightning Network) and roll-ups (such as Arbitrum, Optimism, Aztec, and Scroll) are two other types of intermediary applications. While most intermediaries are currently centralized, they can be designed to be decentralized, which is especially ideal for roll-ups applications as they compete directly with sidechains. For example, Zk-roll-ups could have a network of roll-up sequencers with some form of consensus mechanism, effectively making the roll-up a chain.

The above classification of the two blockchain applications provides us with an additional axis to consider privacy issues: on-chain privacy versus privacy from intermediaries.

Wei Dai: Why privacy is one of the last barriers to mass adoption of public chains How to achieve on-chain privacy?

On-chain privacy : Is my information permanently recorded on-chain?

Privacy from Intermediaries: Has my information been disclosed to entities I entrust to act on my behalf (think your bank, transaction aggregators like Coinbase and 1inch)?

Put these axes together. By combining the two privacy feature axes, we derive four privacy concepts for blockchain applications: between anonymity and confidentiality, and between on-chain and intermediaries. Below is a table listing one privacy concern per category.

Questions for each privacy category are presented in the table

Questions for each privacy category are presented in the table


  • Anonymity: Can my transactions on Uniswap be linked to other activities I do on-chain, such as NFT transactions?
  • Confidentiality: Is the total amount of my transactions on-chain public information?

From an intermediary:

  • Anonymity: Can exchange operators (Coinbase, dYdX, etc.) block trades based on who is trading?
  • Confidentiality: Can exchange operators (Coinbase, dYdX, etc.) see and record transaction details?

Of course, to any of the above questions, the answer is that your information is permanently recorded on-chain and transmitted to intermediaries. Armed with this understanding, we can now gain insight into what privacy is for on-chain and intermediary blockchain applications.

Disclaimer 1: While most applications claim to be decentralized, on-chain smart contract development and access tends to be very centralized. For example, a single coding error can often lead to a multi-million dollar vulnerability, while decentralized exchange (DEX) transactions often go through a dwindling number of mining pools that exploit users’ transactions for their own profit (this is called MEV, i.e. Miner Extractable Value). We do not elaborate further on these issues here, as our focus is on privacy issues.

Disclaimer 2: An important dimension of privacy that we will not go into in depth is the interplay between privacy, regulation and compliance. Financial intermediaries are in many cases legally obligated not only to know their customers (KYC), but also to record and report certain financial transactions. Anti-Money Laundering (AML) is one of the main objectives. For example, cryptocurrency transparency recently helped the Justice Department recover $3.6 billion worth of funds stolen in the 2016 Bitfinex hack. We won’t touch on regulatory and compliance issues, but focus only on privacy issues at a technical and theoretical level in this article.

Part 2: How to Build Privacy-Preserving Blockchain Applications

Let’s look at payments first, as they mostly address privacy concerns and don’t require intermediaries. Zcash and Monero are two large-cap cryptocurrencies that offer both anonymity and confidentiality. They rely on zero-knowledge proofs and ring signatures, respectively, to provide varying degrees of anonymity and confidentiality. We have other ways to build privacy payments that are more efficient but require interaction, like Mimblewimble, or don’t require an ever-expanding set of UTXOs, like Quisquis and Anonymous Zether.

Outside of payments, however, the picture is less clear. For example, one of the most successful applications outside of payments is in the field of decentralized finance (DeFi). But currently we still don’t know or don’t have widely established privacy technologies for DeFi applications.

To fully reason about this problem, we first need to have a good theoretical model to talk about on-chain applications. General on-chain applications can be modeled as iterative computations, specified by a transition function f that computes (st′, output) ← f(st, input) for each starting state st and input .

Wei Dai: Why privacy is one of the last barriers to mass adoption of public chains How to achieve on-chain privacy?

Users can construct transactions as inputs before submitting them to consensus nodes for processing. To protect the user’s privacy during this process, we need to perform computations without revealing the user’s identity and input. There are three approaches: (1) push the computation off-chain, (2) keep the computation transparent but hide the identity of the originator, and (3) perform homomorphic computation on encrypted inputs with transparent outputs.

Privacy of off-chain computing through ZKP

Zero-knowledge proofs (ZKPs) were an important development in the field of theoretical computer science and cryptography in the late 1980s (Chapter 1 of this lecture notes gives a good survey). A special form of Zero-Knowledge Proof (ZKP) used in the blockchain environment is often referred to academically as NIZK, i.e. Non-Interactive Zero-Knowledge. When proofs are succinct, they are often called SNARGs (or SNARKs), or succinct non-interactive arguments (knowledge). Other features of interest are transparency (STARKs) and universality , which allow proof systems to be used for multiple pathways without a trusted setup, or to use a universal trusted setup.

The core application of ZKPs on public blockchains is the ability to perform verifiable, off-chain computations. Typically, validators are end users (in the case of ZK application platforms) or intermediaries (ZK roll-up), and validators are the blockchain, the set of validators. A straightforward way to use ZKP for general computations is to directly prove the correctness of state transitions. In detail, the user proves off-chain that, for a particular on-chain state st , the user has an input that, when applied to check the state st , results in a new state st’ with some kind of output , and then the consensus node overwrites Verify the validity of proposed state transitions before the old state. This is the approach taken by ZK application platforms like Mina Snapps and Aleo, which were inspired by the academic work of Zexe.

Wei Dai: Why privacy is one of the last barriers to mass adoption of public chains How to achieve on-chain privacy?

The key difference between the transparent chain application and the above architecture is that the former naively believes that an update (st’, output, π) is only valid for the application state st that the user uses to generate the update . If multiple users interact with the same application without coordination, this results in a “race condition”. To elaborate on the concept, assume that there are two valid transactions building against the same on-chain state st0 , updating it to st1 and st2 respectively . When the first transaction is recorded on-chain, the on-chain state is updated to st1 . Therefore, the second transaction is verified with the new state st1 , not st0 , which is likely to invalidate it.

Notably, one can bypass this race condition by splitting application state into independent parts or by eliminating shared on-chain state altogether. This makes these ZK-application platforms ideal for specific applications that do not require shared state between users (such as ZKPass), but for most on-chain applications that require such shared state, especially ones like Constant Function Market Makers (CFMMs) On-chain DeFi protocols are not so suitable. For these applications, using ZKPs throughout application state transitions is a bit of a “bear breaking a stick” solution due to race conditions. However, there is a workaround, and that is to add an intermediary or transaction operator so that the application state is private to the operator rather than shared among all users. Unfortunately, there is no known way to hide transaction information from these intermediaries without resorting to the other solutions discussed later in this article. In summary, exchanges on the ZK application platform, such as Aleo and Mina, implement the following privacy features.

The table details the privacy features of exchanges that can be built on ZK application platforms such as Mina and Aleo

The table details the privacy features of exchanges that can be built on ZK application platforms such as Mina and Aleo

On-chain :

  • Anonymity: yes
  • Confidentiality: yes

From an intermediary:

  • Anonymity: yes
  • Confidentiality: No

Anonymity of Computation on Transparent Chain

Adding privacy to on-chain applications is hard. What if we were not trying to provide confidentiality, but just anonymity? This is already possible using existing tools: using tumblers and mixers such as CoinJoin and Tornado Cash, people can fund new pseudo-anonymous addresses for anonymity. Unfortunately, the selective nature of these tools means they are exploited more by malicious users than legitimate ones. For example, CoinJoin is used by Colonial Pipeline ransomware, while Tornado Cash is often used to fund anonymous addresses to help DeFi hackers.

There are two projects trying to establish anonymity by default on a transparent smart contract platform. The first is Aztec Connect, an emerging Ethereum “zkzk-rollup” that provides transaction anonymity when transacting with supported layer-1 applications. The roll-up contract interacts with the first-layer DeFi protocol on behalf of second-layer users (whose identities are hidden both on-chain and from the roll-up provider), providing anonymity to these second-layer users.

The second is academic work at FLAX. It proposes to redesign an Ethereum-like smart contract platform to support built-in anonymity for end users. At its core, FLAX proposes an anonymous version of the ERC20 token standard that allows for anonymous and atomized token usage authorization. Interestingly, no new cryptography is required to implement these “anonymous ERC20s”. One can use the same technology in any of the previously mentioned privacy payment schemes like Zcash, Monero or Zether inside the token contract.

Below is a table outlining the privacy features of the solutions discussed above. We omit the intermediary column here because there are no intermediaries involved, except for Aztec Connect, which has the potential to provide anonymity from intermediaries (roll-up providers), depending on the degree of decentralization and the exact nature of these providers behavior.

The privacy features of tubler, mixer, Aztec Connect and FLAX are detailed in the table

The privacy features of tubler, mixer, Aztec Connect and FLAX are detailed in the table


  • Anonymity: Yes (optional in case of tumblers and mixers, default in case of Aztec Connect and FLAX).
  • Confidentiality: No

Privacy of on-chain computations via MOCCA

What would happen if we could encrypt the application state and user input on-chain, but still be able to compute on it and even come up with a public unencrypted output? Let us call such a desirable feature the Magical On-Chain Confidential Computing Device (MOCCA).

Wei Dai: Why privacy is one of the last barriers to mass adoption of public chains How to achieve on-chain privacy?

Intuitively, MOCCA provides the best possible privacy for the state transition function f . They can be computed on-chain, given the necessary encrypted inputs, and the computation should produce an encrypted and updated state, as well as some transparent output value. Specifically, the state and inputs of the program are encrypted on-chain, so that the only consensus operation that can be done is the transition of the computational state, which means that only the information of the application’s intent is decrypted and made transparent. Assuming for a moment that we have such a magic box, it would be easy to replicate the functionality of an on-chain application while providing privacy properties. Because application designers can design their applications to publish only relevant information as transparent outputs, such as spot prices or reserve amounts.

Wei Dai: Why privacy is one of the last barriers to mass adoption of public chains How to achieve on-chain privacy?

There are two ways to build a MOCCA, through trusted hardware and through cryptography. In either case, we can hope to implement privacy-preserving decentralized applications without intermediaries, with the following properties.

Privacy features of apps from MOCCA are detailed in the table

Privacy features of apps from MOCCA are detailed in the table


  • Anonymity: yes
  • Privacy: Yes (exact privacy depends on app design)

MOCCA from Trusted Hardware. The first solution is to utilize a trusted execution environment, specifically Intel SGX. This was first described in Ekiden’s academic work and is the approach taken by Oasis and Secret Network. There are already some apps running on these platforms, like Secret Swap. However, Intel SGX is known to be flawed.

MOCCA from Cryptography. Can we build a Turing-complete MOCCA using only cryptography? It turns out that the answer is yes, and cryptographers have discovered all the individual pieces of the puzzle.

The first piece of the puzzle is the generation and re-sharing of the threshold key. We know how to generate and manage Shamir secret shares in a dynamic consensus set as nodes join and leave, even for large consensus sets. These allow any number of “t” of the “n” consensus nodes to act as if they were together the key holder for a public key encryption scheme or a signature scheme. These advances were proposed to prevent previous runs (eg Ferveo) and to build compact light clients (eg chain-key cryptography), respectively.

Additive MOCCA and Exchange. The second piece of the puzzle is threshold homomorphic encryption. Well-known and deployed public key encryption schemes such as ElGamal and Paillier are additively homomorphic and support Shamir secret sharing as a key. Using them, we can build a MOCCA that supports addition.

It turns out that we can already build on-chain exchanges (specifically Constant Function Market Makers, or CFMMs) using an additive-only MOCCA. This is a genius observation of Penumbra, which exploits the additive homomorphism of ElGamal encryption to aggregate transactions and decrypts through a threshold to reveal the net value of a batch of transactions. This provides confidentiality of transactions in the form of differential privacy.

Turing-complete MOCCA from Threshold FHE. To implement MOCCA for more general computations, we certainly need Fully Homomorphic Encryption (FHE). Since Genry first built FHE in 2009, the efficiency of FHE schemes has steadily improved in theory and practice over the past decade, and is likely to continue to improve (e.g., accelerated by mining hardware). However, FHE by itself is not the complete solution, as holding the decryption key still enables any party to obtain all information ever published on-chain under the corresponding encryption key. This is where previous efforts to deploy FHE in a blockchain environment, such as NuCypher and smartFHE, fall short in providing privacy-preserving on-chain applications.

Fortunately, we know how to construct FHE schemes with threshold decryption, where the decryption key is secretly shared by Shamir. Specifically, each consensus node can independently perform computations on encrypted program states and inputs, resulting in encrypted new program states and encrypted outputs. Most importantly, in order to release transparent outputs, consensus nodes can perform threshold decryption of encrypted outputs through one round of communication . The threshold property here guarantees that as long as validators below the threshold are malicious (at any epoch), then only expected information (i.e. transparent outputs) are released, while inputs and program state are never decrypted.

Combining the above content, we can build a MOCCA purely relying on cryptography for the general Turing-complete state transition function. Of course, many technical details need to be modified. (As far as I know, this exact usage of threshold FHE in a blockchain context has not been described elsewhere. I would appreciate if I could point out previous work that I am missing)


Privacy is one of the final barriers to mass adoption of public blockchains. Privacy can be divided into two characteristic axes: anonymity and confidentiality , on-chain privacy and privacy from intermediaries . There are three categories of methods to achieve privacy.

First, using zero-knowledge (ZK) proofs (specifically STARKs or general-purpose SNARKs), we can achieve on-chain anonymity and on-chain secrecy by moving computation to off-chain intermediaries, sacrificing privacy from intermediaries (e.g. Mina Snapps and Aleo).

Second, without relying on intermediaries, we can add anonymity (without confidentiality) to existing on-chain application ecosystems without major changes to application design (e.g. CoinJoin, Tornado Cash, Aztec Connect and FLAX).

Finally, this paper proposes an abstraction called MOCCA, a magical on-chain confidential computing device that can perform computations on encrypted data and publish transparent outputs. MOCCA can be used to build general on-chain anonymous and confidential applications without intermediaries. MOCCA can be built from trusted execution environments (Oasis and Secret Network) or relying on “threshold cryptography for blockchains”. Specifically, threshold additive homomorphic encryption (ElGamal) can be used to build additive MOCCA to achieve on-chain exchanges (Penumbra) with anonymity and secrecy (different privacy properties); threshold fully homomorphic encryption (FHE) can be used for Build a generic MOCCA to enable any privacy-preserving on-chain application (proposed in this post).

The ZK method is currently receiving the most attention in the industry. However, in my opinion, more attention should be given to the second and third methods. Adding easy-to-use anonymity to current smart contract architectures is a nice middle ground between privacy and functionality (someone should build FLAX!). Furthermore, we should promote long-term research and development efforts on threshold FHE to support general privacy-preserving applications. Nor are these approaches exclusive, and we can have application platforms that support all three types of computation: transparent on-chain, private off-chain (ZKPs), and “opaque” on-chain (MOCCAs). If you are interested in any of the above, please contact me.


Many thanks to Alex Evans and Guillermo Angeris for helpful editorial comments. Thanks to Adrian Brink for coining the term “opaque” to describe on-chain computation of encrypted data.

Posted by:CoinYuppie,Reprinted with attribution to:https://coinyuppie.com/wei-dai-why-privacy-is-one-of-the-last-barriers-to-mass-adoption-of-public-chains-how-to-achieve-on-chain-privacy/
Coinyuppie is an open information publishing platform, all information provided is not related to the views and positions of coinyuppie, and does not constitute any investment and financial advice. Users are expected to carefully screen and prevent risks.

Like (0)
Donate Buy me a coffee Buy me a coffee
Previous 2022-02-18 08:19
Next 2022-02-18 08:23

Related articles