Bitcoin, launched almost 14 years ago, revolutionized financial transactions by eliminating intermediaries. The advent of Ethereum and smart contracts has further accelerated this trend, eliminating intermediaries from complex financial products like trading, lending, and options. However, the cost of removing intermediaries has often been the sacrifice of privacy. Our on-chain identity and transactions are easily tracked by centralized exchanges, on/off ramps, on-chain analytics companies, and many other entities. This on-chain transparency limits the expansion of Web 3 to many use cases such as enterprise payments, proprietary on-chain trading and many other applications.

This issue is not new and many projects, e.g., zCash, have tried to solve it since 2016 by introducing technologies such as Zero-Knowledge Proofs (ZKPs). Since then ZK tech has advanced at an insane rate. Furthermore, many other technologies such as Fully Homomorphic Encryption (FHE) and secure Multi-party Computations (MPC) are emerging to address more sophisticated scenarios of using private data on-chain, aka, Private State.

At Alliance we believe that on-chain privacy will enable use cases that were not possible before and hence will be a core theme in Web 3 in the next few years. If you are a founder building privacy infrastructure or applications that require private state, we would like to support you. You can reach out and apply to Alliance.

The Different Types of Private State

Using private data on-chain naturally means this data is encrypted. The privacy of that data depends on the ownership of the encryption/decryption key. This key, i.e., privacy key is often different from the regular Private Key, i.e, the key to sign transactions. The first only controls the privacy of the data, the later controls changing this data.

The ownership nature of the Privacy Key leads to different types of private states. The private state type significantly affects how this state can be represented on-chain and the best approach to handle this state. In general private state can be divided into Personal Private State (PPS) and Shared Private State (SPS)

Personal private state

This means that the data/state is owned by a single entity and only this entity can view it or change it. This entity can also decide to allow others to view the data, e.g., by sharing a viewing key to all or part of this data. Examples of this private state include:

• Private token balance
• Private credentials or personal information. this includes age, citizenship, investor-accreditation status, Twitter account or any other Web 2 data that can be utilized in Web 3
• Private transaction history

Shared Private State

A shared private state (SPS) is private data that multiple people can change/use for computing without breaking privacy. An SPS can be a state that is accessible by anyone and hence can be changed by any user. This can be the state of a dark pool AMM, the state of a private lending pool, etc. An SPS can also be limited to a small group of participants who can access or change the data. Examples of the later include the state of an on-chain multi-player where you only allow the active players to change the state. It can also include private inputs to an on-chain AI model, where only a few entities, e.g., model operator, can run compute over the private data.

SPS is harder to manage than personal private state. It’s always harder to reason about the kind of compute that can be performed on SPS and whether this compute can leak information about it. For instance, executing a trade against a dark-pool AMM can leak some information about the liquidity inside the pool.

ZKPs, FHE, and MPC

There are different possible approaches to handle on-chain private states. Each approach is suitable for a particular type of private state and hence a specific set of applications. In many cases, creating a useful application requires combining these approaches together.

Zero-Knowledge Proofs

The first approach that emerged to handle on-chain privacy was utilizing ZKPs. This approach is particularly suitable for personal private data. In this approach, the owner of the data can simply decrypt the data locally using their privacy key, do any required changes, encrypt the result using their key, and finally generate a ZKP to prove to the network their changes to the private state are valid.

This made ZK particularly suitable for payment networks, e.g., zCash, Iron Fish, and many others. In these architecture, when users transact using private assets, they do all the compute locally, i.e., spending UTXOs and creating new ones for the recipient, and modify their private token balances. As the computation and ZKP generation happen locally on the user’s device, the privacy of the balances and transaction history is protected. The network miners only see the generated ZKP and the new encrypted UTXO.

Despite the simplicity of computations needed to perform payments, the UX of private payments was hard due to long ZKP generation times. However, with significant improvements in zk proving systems, the time of proof generation for simple payments dropped below 1 sec on consumer hardware. This also allowed the introduction of general programmability to zk-based systems. Aztec and Aleo are two great networks that are bringing general programmabiltiy to zk-based chains. Aztec and Aleo has some differences but both are largely based on the ZEXE model. In this model, each application has to be implemented as a zk-circuit. This created a need for both network to abstract zk complexity for application developers, and users. This required the creation of high-level programming languages, e.g., Noir (Aztec) and Leo (Aleo), that can convert high-level code efficiently into zk circuits.

For instance, Aztec uses Noir and its associated smart contract development framework, Aztec.nr, to break every smart contract into a set of functions. Each function is implemented as a zk circuit. Users can perform general computing on their private data by downloading the necessary functions and performing the computing locally on their devices. The details of how Aztec’s smart contract execution were discussed in this thread.

Implementation like Aztec has significantly improved the usability of zk systems by introducing general programmability. However, such systems still have several challenges:

1. Any computing over private state has to happen on the client side. This degrades UX and requires users to have capable devices to use the network.
2. The zk approach is not suitable for handling shared private state. By default, all applications have public state. This makes it challenging to build applications such as information-incomplete games and private DeFi.
3. Harder composability, it’s not possible to execute transactions that require changing several private states as each state needs to be computed by a separate user. Such transactions need to be broken into pieces and each piece to be executed in a separate block.
4. There are also challenges on private data discoverability. If a user receives a transaction with a private state, they cannot discover this state unless they download the whole network private state, try to decrypt every piece of it using their privacy key. This creates a challenging UX for users even to do simple tasks like querying their balance as explained by this thread.

Suitable Applications for zk based systems

The strong privacy guarantees of zk makes it suitable for a considerable number of use cases

Anonymous Social Media

Some high-profile figures cannot share their true thoughts and experiences fearing social push back and canceling. This encourage a new type of social media where participants can privately proof certain traits about themselves, e.g,., on-chain wealth or owning a specific NFT, and use this proof to post anonymously without revealing their real identity. Examples include Whale Songs prototype by my colleague David,

Private on-chain credentials

A related example is allowing people who have certain credentials to anonymously participate in a DAO or anonymously vote for topics requiring specific expertise. A Web 3 example of that is HeyAnoun. A larger application domain is leveraging IRL credentials, e.g., IRL wealth, academic degrees, to participate anonymously in on-chain protocols. Onboarding private IRL credentials on-chain can enable multiple use cases such as uncollateralized DeFi lending, on-chain KYC, or geographical gating. ZK is suitable for these use cases because it allows the existence of specialized viewing keys for parts of the private state that can be used in specific circumstances, e.g., loan default.

The main challenge of onboarding IRL credentials on-chain is how to guarantee the authenticity of the IRL credentials/data. Some approaches such as zkEmail and TLSNotary address this issue via authenticating the web traffic to specific web domains and that the domain contains the required data.

Enterprise invoicing/payments

An important subset of private payments is enterprise payment. Companies often don’t want to reveal their business partners/suppliers or the contractual terms of their agreements. The transparency of on-chain payments has limited the enterprise adoption of stablecoin payments. With proper on-chain privacy, enterprises adoption of on-chain payments can be accelerated based on improved efficiency and cost-effectiveness compared to existing banking rails.

FHE approach

Fully Homomorphic Encryption allows performing computations over encrypted data and generating correct encrypted results without decrypting the data during the computation. This makes FHE particularly suitable for handling shared private states. With FHE, it’s possible to create on-chain applications that have private state, such as private AMM pools or a private ballot box. The private state exists on-chain in an encrypted format allowing any user to perform computing over this data. Incorporating FHE on-chain can enable and simplify numerous use cases that were not possible before such as private voting and information-incomplete games, e.g., Poker.

FHE advantages

A significant advantage of FHE is improving composability in multiple aspects.

1. Multiple transactions/users can change the same private state within the same block. For instance, multiple swaps can use the same dark pool.
2. A single transaction can change multiple private states. For instance, a swap transaction can utilize multiple dark AMM pools to complete a swap.

Another advantage is improved user experience. In FHE the computations over private state are performed by the network validators who can deploy specialized hardware to perform these computations faster.

A third advantage of FHE is improved developer experience. Although developers still have to update their mental models to properly handle private state, the barrier is much lower than zk systems. Firstly, FHE systems can operate with the same account model that the smart-contract chains use. Secondly, FHE operations can be added on top of existing VM implementations, allowing the users to use the same development frameworks, tooling, wallets, and infra that they are used to. This is the case for the fhEVM implementation from Zama that have simply added the encrypted variables and FHE operations as precompiles. Counter-intuitively, this advantage is critical for the growth of on-chain private applications, developers are the key to create interesting applications that attract users. A seamless developer experience can attract more developers to the FHE space.

Limitations of FHE

Privacy Trust Assumptions

FHE chains require global encryption/decryption keys for all the private state. This is critical to achieve composability. Typically these keys are maintained by the validator group to be able to decrypt results of FHE operations over private state. This means that the validator group is also trusted not to break the privacy of existing private states.

Potential Privacy Leakage
Performing multiple computations over the encrypted data can break privacy. For instance, trades executed on a dark AMM pool can reveal some information about the pool current liquidity structure.

Computational complexity of FHE compute

Even with advanced implementations, FHE operations are often 1000x to 1,000,000x more computationally expensive than regular computations. This complexity limits the possible throughput of on-chain FHE applications. Current estimates from Inco Network indicates a throughput between 1–5 TPS for FHE operations. With GPU and FPGA acceleration, this throughput can be accelerated by 10–50x.

Source: https://eprint.iacr.org/2021/1402.pdf

Suitable Applications for FHE systems

FHE systems are particularly suitable for applications that require high degree of composability

Information-incomplete games. Examples here include card game, e.g, poker, where the status of card deck is accessible and can be modified by multiple players.

Private voting, FHE simplifies the implementation of secret polls when votes can change the voting tally without knowing the previous voting result

Private AMM, the implementation of private AMMs or private DeFi pools in general is simplified by representing the pool state as encrypted variable .

MPC approach

Multi-party Computing (MPC) has been known and popular within the crypto industry for the specific use case of asset custody. Some of the largest companies in the space, e.g., Fireblocks have built successful businesses around using secure MPC for concurrency custody. Further, many wallet-as-a-service providers, e.g, Coinbase, 0xPass, utilize MPC to improve wallet security and UX.

However, MPC can be used for more than securing private keys. In general, MPC solves the problem of performing compute over private inputs, i.e., data, and only revealing the output of the computations without breaking the privacy of the inputs. In the specific context of asset custody, the private inputs are the shards of the private key. The owners of these shards collaborate to perform “computing” over these private inputs. The computing here is generating a transaction signature. The multi parties here collectively generate and decrypt the signature without any of them getting access to the private inputs, i.e., the private key.

The same way, MPC allows any type of computing over private data without revealing it. This allows MPC to handle private state in a blockchain context. One example of that is decentralized AI training over private data sets. Different data owners and compute providers can collaborate to perform MPC-based AI training over the private data sets to calculate the model weights. The output of the computing, i.e., weights are decrypted by the MPC group after the training phase to create the completed AI model.

Many MPC implementations achieve strong privacy guarantees for the data privacy, i.e., honest minority, which means that it has similar privacy guarantees to zk systems. MPC can also look similar to FHE as it allows performing computing over an SPS meaning it can allow composability. However compared to FHE, MPC has has some limitations

1. The computing can only be performed by the entities who are part of the MPC group. No one outside this group can perform any computations over the data
2. To achieve honest minority guarantees, all of the MPC parties need to cooperate to perform the MPC. This means that the computing can be censored by any member of the MPC group. This limitation can be relaxed by reducing the MPC threshold, i.e., The number of entities required to do the computation. However, the price here is that the privacy of the data can be broken by a coordination between a smaller number of participants.

Suitable Applications for MPC systems

Dark Pool CLOBs

One of the first real applications of MPC in DeFi is the implementation of Dark Pool CLOBs. In this system, traders are able to place limit or market orders without priori knowledge of the state of the order book. Order matching happens via MPC over the private data, i.e, existing order book. Renegade Finance is one of the companies building such a system.

Decentralized Inference of proprietary AI models

Some applications, e.g., DeFi AI-based strategy managers or Web 3 Credit scoring, can deploy MPC to perform inference using proprietary models. In this architecture, the AI model weights are private. The weights can be securely shared among a number of compute nodes such that each has only a subset of model weights. The nodes can collaborate to perform AI inference on updated on-chain events to make decisions and submit transactions that execute the DeFi strategy.

Training of open AI models using proprietary data

A common example here is training medical diagnosis models using private health records. In this case, the model creators, companies, and data owners, i.e, patients, can collaborate using MPC to run the training process over the private data without breaking the privacy of the private data. Networks such as Bittensor and Nillion can enable such use cases.

Pseudo-permissionless Shared Private State

With careful design, MPC can be used to handle pseudo-permissionless SPS. For instance, the state of a dark AMM pool and the computing over this state can be constructed as an MPC between a number of entities. Users who want to interact with the AMM have to share their transactions with the MPC group to perform the computations on their behalf. The advantage of this approach is that each SPS can have a different set of privacy keys (compared to global keys in the case of FHE). The risk of this approach is the possibility of censorship by the MPC group. However, with careful economic design, this risk can be mitigated.

Competition or Synergies

The discussed approaches of handling on-chain private state seem competitive at first-glance. However, if we put aside the financial incentives of the different teams building these networks, zk, FHE and MPC are actually complementary technologies.

On one hand, zk systems offer stronger privacy guarantees because the “unencrypted” data never leaves the user’s device. Further, it’s impossible for anyone to run any compute over this data without the owner’s permission. The price for this strong privacy guarantees is weaker composability.

On the other hand, FHE facilitates stronger composability but weaker privacy. The privacy risk stems from trusting an entity or a small number of entities with the global FHE decryption keys. Despite that risk and because composability is a core ingredient in crypto, FHE can enable privacy in many important use cases like DeFi.

MPC implementation offers a unique middle ground between the zk and FHE approaches. MPC allows computing over shared private data. Hence, it offers more composability than ZKPs. However, the compute over this private state is limited to a small set of participants and not permissionless (unlike FHE).

Given how ZKPs, MPC and FHE differ in their applications pace, practical applications often require combining these technologies. For instance, Renegade Finance combines MPC and ZKPs to enable building a Dark Pool CLOB that also guarantees that participants have sufficient capital to cover their hidden orders. Similarly, the on-chain Poker game, zkHoldem combines ZKPs and FHE.

We expect privacy-focused networks to combine these technologies under the hood to offer developers on these ecosystems with all the tools they need to build applications seamlessly. For instance, Aztec can combine some form of MPC in the network to handle shared private state. Similarly, Inco Network can utilize ZKPs to allow for private addresses and private transaction history.

With this vision of a privacy centric future, Alliance is looking forward to supporting founders building this future. If you are building in this domain, reach out and apply to Alliance.

Disclaimer：

1. This article is reprinted from [Alliance], All copyrights belong to the original author [Mohamed Fouda]. If there are objections to this reprint, please contact the Gate Learn team, and they will handle it promptly.
2. Liability Disclaimer: The views and opinions expressed in this article are solely those of the author and do not constitute any investment advice.
3. Translations of the article into other languages are done by the Gate Learn team. Unless mentioned, copying, distributing, or plagiarizing the translated articles is prohibited.