All roads lead to MPC? Exploring the endgame of privacy infrastructure

Many use cases (probably more than we think) require shared private state: As mentioned before, many applications require some hidden state and/or logic to function properly. Shared private state is a subset of this, where multiple parties compute on the same private state. While we could trust a centralized party to do this for us and call it a day, ideally we want to do this in a trust-minimized way to avoid single points of failure. This cannot be achieved with zero-knowledge proofs (ZKPs) alone - we need to leverage other tools such as Trusted Execution Environments (TEEs), Fully Homomorphic Encryption (FHE), and/or Multi-Party Computation (MPC). Larger shielding sets maximize privacy: Most information is leaked when entering or exiting a shielding set, so we should try to minimize this. Building multiple private applications on the same blockchain can help strengthen privacy guarantees by increasing the number of users and transactions within the same shielding set. The End of Privacy Infrastructure Given the above assumptions, what is the ultimate goal of blockchain privacy infrastructure? Is there a way that works for all applications? Is there a privacy-enhancing technique that can rule them all? Not exactly. All of these have different trade-offs, and we’ve seen them combined in various ways. In total, we have identified 11 different approaches.

Currently, the two most popular approaches to building privacy infrastructure in blockchains are to leverage ZKPs or FHE. However, both suffer from fundamental flaws:

• ZK-based privacy protocols with client-side proofs can provide strong privacy guarantees, but do not allow multiple parties to compute on the same private state. This limits expressiveness, i.e., what types of applications developers can build.  

• FHE enables computation on encrypted data and shared private state, but raises the question of who owns that state, i.e., who has the decryption key. This limits the strength of the privacy guarantees, and how much we can trust that what is private today will still be private tomorrow.

If the ideal end state is to have programmable privacy infrastructure that can handle shared private state without any single point of failure, then both paths lead to MPC:

Note that while these two approaches will eventually converge, MPC serves different purposes:

• ZKP networks: MPC increases expressive power by enabling computation over shared private state.

• FHE Networks: MPC improves security and strengthens privacy guarantees by distributing decryption keys to a committee of MPCs instead of a single third party.

While the discussion is starting to move toward more nuanced views, the guarantees behind these different approaches remain underexplored. Given that our trust assumptions boil down to those of MPC, three key questions to ask are:

1. How strong are the privacy guarantees that MPC protocols provide in blockchains?

2. Is the technology mature enough? If not, what are the bottlenecks?

3. Does it make sense compared to other approaches given the strength of the guarantees and the overhead they introduce?

Let’s answer these questions in more detail.

Analyzing Risks and Weaknesses with MPC

Whenever a solution uses FHE, one always needs to ask: “Who owns the decryption key?”. If the answer is “the network,” then the follow-up question is: “What real entities make up this network?”. The latter question is relevant to all use cases that rely on MPC in some form.

Source: Zama on ETH CC

The main risk of MPC is collusion, where enough parties maliciously collaborate to decrypt data or steal computations. Collusion can be agreed upon off-chain and is only revealed if the malicious party takes some obvious action (extortion, minting tokens out of thin air, etc.). Needless to say, this has a significant impact on the privacy guarantees that the system can provide. The risk of collusion depends on:

• How many malicious parties can the protocol withstand?

• What parties make up the network? How trustworthy are they?

• The number of different parties participating in the network and their distribution - are there common attack vectors?

• Is the network permissionless or permissioned (economic interests vs reputation/legal basis)?

• What are the penalties for malicious behavior? Is the collusion game theoretically optimal?

1. How strong are the privacy guarantees that MPC protocols provide in blockchains?

TLDR: Not as strong as we would like, but stronger than relying on a centralized third party.  

The threshold required for decryption depends on the chosen MPC scheme - it's largely a trade-off between liveness ("guaranteed output delivery") and security. You can have a very secure N/N scheme, but it will break if just one node goes offline. On the other hand, N/2 or N/3 schemes are more robust, but have a higher risk of collusion.  

The two conditions that need to be balanced are:

1. Secret information can never be leaked (e.g. decryption keys)

2. Secret information can never disappear (even if 1/3 of the parties suddenly leave).

The chosen scheme varies by implementation. For example, Zama is targeting N/3, while Arcium is currently implementing an N/N scheme, but will later support schemes with higher liveness guarantees (and greater trust assumptions). 

A compromise on this trade-off boundary is to adopt a hybrid solution:

• High-trust committees for key handling with, for example, an N/3 threshold.

• The computation committee is rotated, e.g. with an N-1 threshold (or multiple different computation committees with different characteristics for the user to choose from).  

While this is theoretically attractive, it also introduces additional complexity, such as how the computation committee interacts with the high-trust committee.

Another way to increase security assurance is to run MPC inside trusted hardware so that the key shares are kept inside a secure enclave. This makes it more difficult to extract or use the key shares for anything outside of what the protocol defines. At least Zama and Arcium are exploring the TEE angle.

More subtle risks include edge cases such as social engineering, e.g. all companies in the MPC cluster have employed a senior engineer for more than 10-15 years.  

2. Is the technology mature enough? If it is not mature enough, what is the bottleneck?

From a performance perspective, the key challenge facing MPC is the communication overhead. It grows with the complexity of the computation and the number of nodes in the network (more round trips are required). For blockchain use cases, this has two practical implications:

1. Small operator sets: To keep the communication overhead manageable, most existing protocols are currently limited to small operator sets. For example, Zama's decryption network currently allows up to 4 nodes (although they plan to expand to 16). According to the initial benchmarks published by Zama for its decryption network (TKMS), even with a cluster of only 4 nodes, decryption takes 0.5-1 seconds (the full e2e process takes longer). Another example is Taceo's implementation of MPC for Worldcoin's Iris database, which has 3 parties (assuming 2/3 honest parties).

   Source: Zama's speech at ETH CC

2. 

3. Permissioned Operator Sets: In most cases, operator sets are permissioned. This means we rely on reputation and legal contracts rather than economic or cryptographic security. The main challenge with permissionless operator sets is that there is no way to know if people are colluding off-chain. Additionally, it requires regular bootstrapping or redistribution of key shares so that nodes can dynamically enter/exit the network. While permissionless operator sets are the ultimate goal, and research is underway on how to scale PoS mechanisms to achieve threshold MPC (e.g. Zama), the permissioned route seems to be the best way forward for now.

Alternative Approaches

A comprehensive privacy portfolio includes:

• FHE for delegated privacy computation

• ZKP for verifying that FHE computations are performed correctly

• MPC for threshold decryption

• Each MPC node runs inside a TEE for enhanced security

Is it worth it? Maybe, but it’s also worth exploring other approaches that might lead to significantly better computational efficiency with only slightly weaker privacy guarantees. As Seismic’s Lyron points out — we should focus on the simplest solution that meets our criteria for desired privacy levels and acceptable tradeoffs, rather than overengineering just for the sake of it.

1. Use MPC directly for general computation

If both ZK and FHE ultimately revert to the trust assumptions of MPC, why not just use MPC for computation? This is a reasonable question, and one that teams like Arcium, SodaLabs (used by Coti v2), Taceo, and Nillion are trying to do. Note that MPC comes in many flavors, but of the three main approaches, we are referring here to protocols based on secret sharing and garbled circuits (GC), not FHE-based protocols that use MPC for decryption. While MPC has been used for simple computations like distributed signatures and more secure wallets, the main challenge in using MPC for more general computations is the communication overhead (which increases with the complexity of the computation and the number of nodes involved). There are ways to reduce the overhead, such as doing preprocessing offline ahead of time (i.e. the most expensive part of the protocol) - both Arcium and SodaLabs are exploring this. The computation is then performed in the online phase, which consumes some of the data produced in the offline phase. This significantly reduces the overall communication overhead.

The table below from SodaLabs shows an initial benchmark of how long it takes to execute different opcodes 1,000 times in its gcEVM(in microseconds). While this is a step in the right direction, there is still a lot of work to be done to improve efficiency and expand the operator set beyond a few nodes.

Source: SodaLab s

The benefit of a ZK-based approach is that you only use MPC for use cases that require computation on shared private state. FHE competes more directly with MPC and relies heavily on hardware acceleration.

2. Trusted Execution Environments

Recently, there has been a resurgence of interest in TEEs, both on their own (TEE-based private blockchains or coprocessors) and in conjunction with other PETs like ZK-based solutions (using TEEs only for computation on shared private state).

While TEEs are more mature in some ways and introduce less performance overhead, they are not without their drawbacks. First, TEEs have different trust assumptions (1/N) and offer a hardware-based solution rather than a software-based solution. An often-heard criticism is around past vulnerabilities with SGX, but it’s worth noting that TEEs ≠ Intel SGX. TEEs also require trust in the hardware provider, which is expensive (and unaffordable for most people). One solution to address the risk of physical attacks might be to run TEEs in space to handle critical tasks.  

Overall, TEEs seem more suitable for proofs or use cases that only require short-term privacy (threshold decryption, dark ledgers, etc.). For permanent or long-term privacy, the security guarantees seem less attractive.

3. Private DACs and other approaches that rely on trusted third parties to protect privacy

Privacy by intermediaries can provide privacy that prevents access by other users, but the privacy guarantee comes entirely from trust in the third party (a single point of failure). While it is similar to "web2 privacy" (privacy that prevents other users), it can be strengthened with additional guarantees (cryptographic or economic) and allows verification of correct execution.

Private Data Availability Committees (DACs) are an example; members of the DAC store data off-chain, and users trust them to correctly store the data and perform state transition updates. Another form is the permissioned sequencer proposed by Tom Walpo.

While this approach makes a big tradeoff in terms of privacy guarantees, it may be the only viable alternative for low-value, high-performance applications in terms of cost and performance (at least for now). For example, Lens Protocol plans to use a private DAC to enable private information flows. For use cases such as on-chain social, the tradeoff between privacy and cost/performance may be reasonable at present (given the cost and overhead of the alternatives).

4. Stealth Addresses

Stealth addresses can provide similar privacy guarantees as creating a new address for each transaction, but the process is automated on the backend and not visible to users. For more information, see this overview by Vitalik or this article that dives deeper into different approaches. Major players in the field include Umbra and Fluidkey.

While stealth addresses provide a relatively simple solution, the main drawback is that they can only add privacy guarantees to transactions (payments and transfers), not general computations. This makes them different from the other three solutions mentioned above.  

In addition, the privacy guarantees provided by stealth addresses are not as strong as the other alternatives. Anonymity can be broken with simple cluster analysis, especially when incoming and outgoing transfers are not in similar ranges (e.g., receiving $10,000, but spending an average of $10-100 per day in transactions). Another challenge with stealth addresses is upgrading keys, which today needs to be done individually for each wallet (key storage aggregation can help solve this problem). From a user experience perspective, stealth address protocols also require account abstraction or payers to pay fees if the account does not have a fee token (e.g., ETH).

Risks to Our Argument

Given the rapid pace of development and the general uncertainty of different technical solutions, we believe there are some risks to the argument that MPC will be the final solution. We may not need some form of MPC in the end, for a few reasons:

1. Sharing private state is not as important as we think: In this case, a ZK-based infrastructure is more likely to win because it has stronger privacy guarantees and lower overhead than FHE. There are already some use cases where ZK-based systems work well in isolated use cases, such as the private payment protocol Payy.

2. The performance tradeoff is not worth the privacy benefits: One could argue that the trust assumptions of an MPC network with 2-3 permissioned parties are not much different than a single centralized actor, and the large increase in cost/overhead is not worth it. For many applications, especially low-value, cost-sensitive ones (such as social or gaming), this may be true. However, there are also many high-value use cases where collaboration is currently very expensive (or impossible) due to legal issues or high coordination friction. The latter is where MPC and FHE-based solutions can shine.

3. Specialization trumps general design: It is very difficult to build a new chain and bootstrap a community of users and developers. As a result, general privacy infrastructure (L1/L2) may have difficulty gaining traction. Another issue concerns specialization; it is difficult for a single protocol design to cover the entire trade-off space. In this world, solutions that provide privacy to existing ecosystems (confidentiality-as-a-service) or specialized use cases (e.g. payments) will prevail. However, we are skeptical of the latter because it creates complexity for application developers, who need to implement some cryptography themselves (rather than abstracting it away).

4. Regulation continues to hinder experimentation with privacy solutions: This is a risk for anyone building privacy infrastructure and applications with some privacy guarantees. Non-financial use cases face less regulatory risk, but it is difficult (impossible) to control what is built on top of permissionless privacy infrastructure. We will most likely solve the technical problems before we solve the regulatory problems.

5. For most use cases, the overhead of schemes based on MPC and FHE is still too high: While MPC is primarily affected by communication overhead, the FHE community is heavily relying on hardware acceleration to improve its performance. However, if we can extrapolate the development of specialized hardware on the ZK side, it will take much longer than most people think before we get production-ready FHE hardware. Teams working on FHE hardware acceleration include Optalysys, fhela, and Niobium.

To summarize

Ultimately, a chain is only as strong as its weakest link. In the case of programmable privacy infrastructure, ifwe want it to be able to handle shared private state without a single point of failure, then the trust guarantees come down to those of MPC.

While this post may sound critical of MPC, it is not. MPC greatly improves the current status quo of reliance on centralized third parties. We believe that the main problem is that there is false confidence throughout the industry and the problems are covered up. Instead, we should face the problem head-on and focus on assessing the potential risks.

However, not all problems need to be solved with the same tools. Although we believe that MPC is the ultimate goal, other approaches are viable options as long as the overhead of MPC-driven solutions remains high. It is always worth considering which approach is best suited to the specific needs/features of the problem we are trying to solve, and what trade-offs we are willing to make.

Even if you have the best hammer in the world, not everything is a nail.