ZKPs, FHE, MPC: Private state management in blockchains

原文标题：ZKPs, FHE, MPC: Managing Private State in Blockchains

原文作者：Mohamed Fouda

Source: Medium

Compiler: Lynn, Mars Finance

Launched almost 14 years ago, Bitcoin revolutionized financial transactions by eliminating intermediaries. The advent of Ethereum and smart contracts has further accelerated this trend, eliminating intermediaries for trading, lending, and options for complex financial products. However, eliminating intermediaries often comes at the expense of privacy. Our on-chain identities and transactions are easily tracked by centralized exchanges, up-and-off ramps, on-chain analytics firms, 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 transactions, and many other applications.

This problem is not new, and many projects, such as zCash, have been trying to solve it since 2016 by introducing technologies such as zero-knowledge proofs (ZKPs). Since then, ZK technology has evolved at a frantic pace. In addition, many other technologies, such as fully homomorphic encryption (FHE) and secure multi-party computation (MPC), are emerging to address more complex scenarios using on-chain private data, aka private state.

At Alliance, we believe that on-chain privacy will enable previously impossible use cases and will therefore be a core theme of Web 3 for years to come. If you're a founder building a privacy infrastructure or an application that requires a private state, we're here to support you. You can contact the alliance and apply.

Different types of private states

Using private data on-chain naturally means that that data is encrypted. The privacy of that data depends on the ownership of the encryption/decryption key. This key (i.e., the privacy key) is usually different from the regular private key (i.e., the key that signs the transaction). The first controls only the privacy of the data, and the latter controls changing this data.

The ownership nature of privacy keys results in different types of private states. The type of private state significantly affects how that state is represented on the chain and the best way to handle it. Generally speaking, private states can be divided into individual private states (PPS) and shared private states (SPS)

Personal private status

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

• Private Token Balance
• Private credentials or personal information. This includes age, citizenship, investor verification status, Twitter account, or any other Web 2 data that can be used in Web 3
• Private Transaction History

Share private state

Shared Private State (SPS) is private data that multiple people can change/use for computation without disrupting privacy. SPS can be a state that can be accessed by anyone, so any user can change it. This can be the state of a dark pool AMM, the state of a private lending pool, etc. SPS can also be limited to a small subset of participants who are able to access or change the data. Examples of the latter include state in on-chain multiplayer, where you only allow active players to change state. It can also include private inputs to on-chain AI models where only a few entities, such as model operators, can run computations on private data.

SPS is more difficult to manage than individual private states. It is always difficult to infer the type of computation that can be performed on the SPS and whether that computation will leak information about it. For example, executing a trade against a dark pool AMM may reveal some information about the liquidity within the pool.

ZKP, FHE, and MPC

There are different possible ways to deal with on-chain private state. Each method is suitable for a specific type of private state and therefore for a specific set of applications. In many cases, creating a useful application requires a combination of these approaches.

Zero-knowledge proofs

The first way to deal with on-chain privacy is to leverage ZKP. This method is especially suitable for personal private data. In this approach, the owner of the data can simply decrypt the data locally using their privacy key, make any desired changes, encrypt the results with their key, and finally generate a ZKP to prove to the network that their changes to the private state are valid.

This makes ZK particularly well-suited for payment networks such as zCash, Iron Fish, and more. In these architectures, when a user transacts with a private asset, they do all the calculations locally, i.e., spend UTXO and create a new UTXO for the recipient, and modify their private token balance. Since the calculations and ZKP generation are done locally on the user's device, the privacy of balances and transaction history is protected. Network miners can only see the generated ZKP and the new cryptographic UTXO.

Although the calculations required to perform the payment are simple, the user experience for private payments is difficult due to the long generation time of ZKP. However, with the significant improvement of the ZK proof system, the proof generation time for simple payments on consumer hardware has dropped to less than 1 second. This also allows for the introduction of general-purpose programmability into zk-based systems. Aztec and Aleo are two great networks that bring universal programmability to zk-based chains. There are some differences between Aztec and Aleo, but both are largely based on the ZEXE model. In this model, each application must be implemented as a zk circuit. This requires the network to abstract ZK complexity for application developers and users. This requires the creation of high-level programming languages, such as Noir (Aztec) and Leo (Aleo), which can efficiently convert high-level code into zk circuits.

For example, Aztec uses Noir and its associated smart contract development framework Aztec.nr decompose each smart contract into a set of functions. Each function is implemented as a zk circuit. Users can perform generic calculations on their private data by downloading the necessary functions and performing the calculations locally on the device. This thread discusses the details of how Aztec smart contracts are executed.

Implementations like Aztec have significantly increased the usability of zk systems by introducing universal programmability. However, there are still some challenges associated with such systems:

1. Any private state-based computation must be done on the client side. This degrades the user experience and requires the user to have a capable device to use the network.
2. The zk method is not suitable for handling shared private state. By default, all applications have a public state. This makes it challenging to build applications such as games and private DeFi with incomplete information.
3. Composability is more difficult, and it's not possible to execute transactions that require multiple private states to be changed, as each state needs to be computed by a separate user. Such transactions need to be split into multiple parts, and each part is executed in a separate block.
4. The discoverability of private data also faces challenges. If a user receives a transaction with a private state, they can't discover that state unless they download the entire network private state and try to decrypt each part of it with their privacy key. This results in a challenging user experience for users, even performing simple tasks such as querying balances (as described in this thread).

Suitable applications for ZK-based systems

ZK's strong privacy guarantee makes it suitable for quite a few use cases

Anonymous social media

Some well-known figures are unable to share their true thoughts and experiences, fearing social resistance and cancellation. This has encouraged a new type of social media where participants can privately prove certain characteristics of themselves, such as on-chain wealth or owning a specific NFT, and use this proof to post anonymously without revealing their true identity. Examples include my colleague David's Whale Song prototype,

Private on-chain credentials

A relevant example is allowing people with certain qualifications to participate anonymously in DAOs or vote anonymously on topics that require specific expertise. HeyAnoun is an example of Web 3. A larger area of application is the use of IRL credentials (e.g., IRL wealth, degrees) to participate anonymously in on-chain protocols. Adding private IRL credentials on-chain can enable a variety of use cases, such as unsecured DeFi lending, on-chain KYC, or geo-gating. ZK is suitable for these use cases because it allows for the existence of a private view key that can be used for a private state portion of a specific situation, such as a loan default.

The main challenge in adding IRL credentials to the chain is how to guarantee the authenticity of IRL credentials/data. Some methods, such as zkEmail and TLSNotary, work around this by verifying web traffic for a particular web domain and that the domain contains the required data.

Business Invoices/Payments

An important subset of private payments is corporate payments. Companies often don't want to disclose the contractual terms of their business partners/suppliers or their agreements. The transparency of on-chain payments restricts the adoption of stablecoin payments by businesses. With proper on-chain privacy, businesses can accelerate on-chain payment adoption by making them more efficient and cost-effective compared to existing banking tracks.

FHE method

Fully homomorphic encryption allows the encrypted data to be computed and produce the correct cryptographic results without the need to decrypt the data during the computation. This makes FHE particularly well-suited for dealing with shared private state. With FHE, on-chain applications with private status can be created, such as private AMM pools or private ballot boxes. The private state exists on-chain in an encrypted format, allowing any user to perform computations on this data. Incorporating FHE on-chain enables and simplifies many previously impossible use cases, such as private voting and games with incomplete information, such as poker.

FHE Advantage

A significant advantage of FHE is the improved composability in several ways.

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

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

The third advantage of FHE is the improved developer experience. Although developers still need to update their mindset to properly handle private state, the hurdle is much lower than with zk systems. First of all, the FHE system can operate using the same account model as the smart contract chain. Second, FHE operations can be added on top of existing VM implementations, allowing users to use the same development frameworks, tools, wallets, and infrastructure they're used to. This is the case with Zama's fhEVM implementation, which simply adds cryptographic variables and FHE operations as precompilation. Counterintuitively, this advantage is essential for the growth of on-chain private applications, and developers are key to creating interesting applications that attract users. A seamless developer experience can attract more developers into the FHE space.

Limitations of PHE

Privacy trust assumptions

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

Potential privacy breaches

Performing multiple calculations on encrypted data can be privacy-breaking. For example, transactions executed on a dark AMM pool can reveal some information about the pool's current liquidity structure.

The computational complexity of the FHE calculation

Even with advanced implementations, FHE operations are typically 1000 to 1,000,000 times more computationally expensive than conventional calculations. This complexity limits the possible throughput of on-chain FHE applications. Current estimates from Inco Network indicate that the throughput of FHE operations is between 1-5 TPS. With GPU and FPGA acceleration, throughput can be increased by 10-50x.

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

The right application for the FHE system

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

Information is not a complete game. Examples here include card games, such as poker, where the state of the deck is accessible and can be modified by multiple players.

Private voting, FHE simplifies the implementation of secret ballots, which can change the results of the vote count without knowing the results of previous votes

The implementation of private AMMs, private AMMs, or private DeFi pools is often simplified by representing the pool state as cryptographic variables.

MPC method

Multi-party computation (MPC) is well-known and popular in the crypto industry for specific use cases of asset custody. Some of the biggest companies in the space, such as Fireblocks, have built successful businesses around concurrent hosting using secure MPC. Additionally, many wallet-as-a-service providers (e.g., Coinbase, 0xPass) utilize MPC to improve wallet security and user experience.

However, MPC is used for more than just protecting private keys. In general, MPC solves the problem of performing computations on private inputs (i.e., data) and only exposes the output of the computation without breaking the privacy of the input. In the specific scenario of asset custody, the private input is the shard of the private key. The owners of these shards collaborate to perform "calculations" on these private inputs. The calculation here is to generate a transaction signature. Multiple parties work together to generate and decrypt signatures, and neither party has access to the private input, the private key.

Similarly, MPC allows any type of computation on private data without revealing it. This allows MPC to handle private state in the context of the blockchain. One example is decentralized AI training through private datasets. Different data owners and compute providers can collaborate to perform MPC-based AI training on private datasets to calculate model weights. The computed output, i.e., weights, is decrypted by the MPC group after the training phase to create a complete AI model.

Many MPC implementations implement strong privacy guarantees for data privacy, i.e., the honest minority, which means that it has similar privacy guarantees as zk systems. MPC also looks similar to FHE in that it allows calculations to be performed through SPS, which means it can be composable. But MPC has some limitations compared to FHE

1. Calculations can only be performed by entities that belong to the MPC group. No one outside of the group can perform any calculations on the data
2. In order to achieve an honest minority guarantee, all MPC parties are required to cooperate in the execution of the MPC. This means that any member of the MPC group can review the calculations. This restriction can be eased by reducing the MPC threshold, which is the number of entities required to perform the calculation. However, the trade-off here is that coordination between a smaller number of participants can compromise the privacy of the data.

The right application for the MPC system

暗池 CLOB

The first real application of MPC in DeFi was the implementation of the dark pool CLOB. In this system, a trader can place a limit or market order without having to know the status of the order book beforehand. Order matching takes place via MPC on private data (i.e. existing order book). Renegade Finance is one of the companies that build such systems.

Decentralized inference for proprietary AI models

Some applications, such as DeFi AI-based policy managers or Web 3 credit scoring, can deploy MPC to perform inference using proprietary models. In this architecture, AI model weights are private. Weights can be securely shared across multiple compute nodes so that each compute node has only a subset of model weights. Nodes can collaborate on AI inference on updated on-chain events to make decisions and submit transactions that execute DeFi strategies.

Train open AI models using proprietary data

A common example here is the use of private health records to train a medical diagnostic model. In this case, the model creator, the company, and the data owner (i.e., the patient) can use MPC to collaborate to run the training process on private data without compromising the privacy of the private data. Networks such as Bittensor and Nillion can enable such use cases.

Pseudo-permissionless sharing of private countries

By careful design, MPC can be used to deal with pseudo-permissionless SPS. For example, the state of a dark AMM pool, and the computation of that state, can be built as an MPC between multiple entities. Users who want to interact with the AMM must share their transactions with the MPC group to perform calculations 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 that it may be subject to scrutiny by the MPC panel. However, this risk can be mitigated with careful economic design.

Competition or synergy

At first glance, the approach in question for handling on-chain private state seems competitive. However, if we put aside the financial incentives of the different teams building these networks, zk, FHE, and MPC are actually complementary technologies.

On the one hand, the ZK system offers stronger privacy guarantees, as "unencrypted" data never leaves the user's device. In addition, it is impossible for anyone to make any calculations on this data without the owner's permission. This strong privacy guarantee comes at the cost of weak composability.

FHE, on the other hand, is more composable but less private. The privacy risk stems from trusting an entity or a small number of entities with a global FHE decryption key. Despite this risk, and because composability is a core element of cryptocurrency, FHE can enable privacy in many important use cases such as DeFi.

MPC implementations provide a unique middle ground between zk and FHE approaches. MPC allows computation to be performed on shared private data. As a result, it offers more composability than ZKP. However, the calculation of this private state is limited to a small group of participants and is not permissionless (unlike FHE).

Given the differences in application speed between ZKP, MPC, and FHE, real-world applications often require a combination of these technologies. For example, Renegade Finance combines MPC and ZKP to build a dark pool CLOB while guaranteeing that participants have enough funds to pay for their hidden orders. Similarly, the on-chain poker game zkHoldem combines ZKP and FHE.

We expect privacy-centric networks to combine these technologies behind the scenes, giving developers in these ecosystems all the tools they need to build applications seamlessly." For example, Aztec can incorporate some form of MPC in the network to handle shared private state. Similarly, Inco Network can leverage ZKP to allow private addresses and private transaction history.

With a privacy-centric vision for the future, Alliance looks forward to supporting its founders in building that future. If you are building in this domain, please contact Alliance and apply.