All roads lead to MPC?Explore the end of privacy infrastructure

Author: EQ Labs Source: equilibrium Translation: Shan Oppa, Bitchain Vision

Part 1 of our Privacy Series covers what “privacy” means, how privacy in a blockchain network differs from web2 privacy, and why privacy is difficult to achieve in blockchain.

The main point of this article is that if the ideal final state is to have a programmable privacy infrastructure that can handle shared private state without any single point of failure, then all roads lead to MPC.We will also explore the maturity of MPC and its trust assumptions, emphasize alternative approaches, compare tradeoffs, and provide an industry overview.

Get rid of the shackles of the past and welcome the future

The existing privacy infrastructure in blockchain is designed to handle very specific use cases such as private payments or voting.This is a rather narrow view, mainly reflecting the current purpose of blockchain (transactions, transfers and speculation).As Tom Walpo said – Cryptocurrencies suffer from Fermi Paradox:

In addition to increasing personal freedom, we believe that privacy is a prerequisite for expanding the blockchain design space beyond current speculative metadata.Many applications require some private state and/or hidden logic to function properly:

• Hide state: The vast majority of financial use cases require (at least) to be kept confidential to other users, and without some hidden state, many multiplayer games will be significantly less fun (e.g. if everyone on the poker table can see each other’s cards).

• Hide logic: Some use cases require some logic to be hidden while still allowing others to use the application, such as matching engines, on-chain trading strategies, etc.

Empirical analysis (from web2 and web3) shows that most users are reluctant to pay extra fees or skip additional links to increase privacy, and we also agree that privacy itself is not a selling point.However, it does allow new and (hopefully) more meaningful use cases to exist above the blockchain—let us get rid of the Fermi paradox.

Privacy Enhancement Technology (PET) and Modern Password Solutions(“Programmable password”)It is the basic building block to realize this vision(For more information on the different solutions available and their tradeoffs, seeappendix).

Three assumptions that influence our view

Three key assumptions determine our view on how blockchain privacy infrastructure develops:

1. Encryption technology will be abstracted from the hands of application developers: Most application developers don’t want (or don’t know how to deal with) the encryption technology they need to handle privacy.I hope they implement their own encryption technology and build private application-specific chains(For exampleZcashorNamada) or in the public chain(e.g. Tornado Cash)A private application above is unreasonable.This is too complex and overhead, and currently limits most developers’ design space (cannot build applications that require some privacy assurance).Therefore, we think that the complexity of managing the encryption part must be abstracted from the hands of application developers.The two methods here are programmable privacy infrastructure (shared private L1/L2) or“Confidential as a Service”, the latter allows outsourcing confidential calculations.

2. Many use cases (probably more than we thought) require sharing private state: As mentioned earlier, many applications require some hidden state and/or logic to function properly.Shared private state is a subset of them, in which multiple parties calculate the same private state.While we can trust a centralized party to do this for us and stop there, ideally we want to do it with a trust minimization to avoid single point of failure.This is not possible with zero-knowledge proof (ZKP) alone – we need to leverage other tools such as trusted execution environment (TEE), fully homomorphic encryption (FHE), and/or multi-party computing (MPC).

3. Larger blocked sets maximize privacy: Most information is leaked when entering or exiting blocked sets, so we should minimize this.Building multiple private applications on the same blockchain can help strengthen privacy by increasing the number of users and transactions within the same blocked set.

The end of privacy infrastructure

Taking into account the above assumptions, what is the ultimate goal of blockchain privacy infrastructure?Is there a way to fit all applications?Is there a privacy enhancement technology that can dominate all applications?

Not exactly.All of these have different tradeoffs and we have seen them come together in various ways.Overall, we have identified 11 different approaches.

Currently, the two most popular ways to build privacy infrastructure in blockchain are to leverage ZKP or FHE.However, both have fundamental flaws:

• A privacy protocol based on ZK and with client proof can provide strong privacy guarantees, but does not allow multiple parties to calculate the same private state.This limits the expressive power, i.e. what types of applications a developer can build.

• FHE supports computing encrypted data and shared private state, but who did it?haveThe problem with this state is who owns the decryption key.This limits the strength of privacy protection and the extent to which we can believe today’s privacy will remain so tomorrow.

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

Note that although these two methods will eventually tend to blend, MPC uses differently:

• ZKP Network: MPC increases expression ability by implementing the calculation of shared private state.

• FHE Network: MPC improves security and strengthens privacy by distributing decryption keys to the MPC committee (rather than a single third party).

While the discussion began to turn to a more nuanced point of view, the assurances behind these different approaches were still underexplored.Given that our trust hypothesis boils down to the MPC hypothesis, three key questions that need to be asked are:

1. How strong is the privacy guarantee that the MPC protocol can provide in blockchain?

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

3. Does it make sense compared to other methods considering the strength of the guarantee and its overhead?

Let’s answer these questions in more detail.

Use MPC to analyze risks and weaknesses

Whenever the solution uses FHE, people always need to ask, “Who has the decryption key?”.If the answer is “network”, then the subsequent question is: “What real entities constitute this network?”.The latter question is related to all use cases that depend on MPC in some form.

Source:Zama’s speech at ETH CC

The main risk of MPC is collusion, that is, there are enough parties involved in maliciously colluding to decrypt data or misappropriate calculations.Collusion can be agreed off-chain and will only be revealed if the malicious party takes some obvious action (ransformation, minting tokens out of thin air, etc.).Needless to say, this has a significant impact on the privacy guarantees the system can provide.The risk of collusion depends on:

• How many malicious parties can this agreement bear?

• What are the networks?How credible are they?

• The number of different parties involved in the network and their distribution – Are there common attack vectors?

• Is the network license-free or license-needed (economic interests and reputation/legal basis)?

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

1. How strong is the privacy guarantee that the MPC protocol can provide in blockchain?

TLDR: Not as powerful as we hoped, but stronger than relying on a centralized third party.

The threshold required for decryption depends on the MPC scheme selected – largely the activity level(“Emission Delivery Guaranteed”)and security tradeoffs.You can take a very secure N/N scheme, but it will crash as long as there is a node offline.On the other hand, the N/2 or N/3 scheme is more robust, but the risk of conspiracy is higher.

Two conditions that need to be balanced are:

1. Secret information is never leaked (such as decryption keys)

2. Secret information never disappears (even if 1/3 of the participants suddenly leave).

The selected scheme varies by implementation.For example, Zama aims to be N/3, while Arcium is currently implementing an N/N scheme, but will also support a scheme with higher activity assurance (and greater trust assumptions) later.

On this trade-off, a compromise solution is to adopt a hybrid solution:

• High Trust CommitteeKey processing is performed with, for example, N/3 threshold.

• Calculation Committeeis rotational, for example, with an N-1 threshold (or multiple different computing committees with different characteristics for users to choose).

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

Another way to strengthen security is to run MPCs within trusted hardware to keep key sharing in a secure area.This makes it more difficult to extract or use key sharing for any operations other than protocol definitions.At least Zama and Arcium are exploring the TEE angle.

More subtle risks include edge cases such as social engineering, where for example, all companies in an MPC cluster have hired a senior engineer for more than 10 to 15 years.

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

From a performance perspective, the key challenge facing MPCs is communication overhead.It grows with the complexity of computing and the number of nodes in the network (needs more back and forth communication).For blockchain use cases, this has two practical implications:

1. Small Operator Sets: To make communication overhead controllable, most existing protocols are currently limited to small operator sets.For example, Zama’s decrypted network currently allows up to 4 nodes (although they plan to scale to 16).According to the initial benchmark released by Zama for its Decryption Network (TKMS), even if a cluster with only 4 nodes is only 0.5-1 second (the full e2e process takes longer).Another example is the MPC implemented by Taceo for Worldcoin’s iris database, which has 3 parties (assuming 2/3 honest parties).

   Source:Zama’s speech at ETH CC

2. 

3. Licensed Operator Sets: In most cases, the operator sets are licensed.This means we rely on reputation and legal contracts, not economic or crypto-security.The main challenge with a set of permissionless operators is the inability to know if people collude off-chain.Additionally, it requires periodic booting or reallocating key shares so that nodes can dynamically enter/exit the network.While the permissionless operator set is the ultimate goal and how the PoS mechanism is extended to achieve threshold MPCs (e.g., Zama), the permission route seems to be the best way forward at the moment.

Alternative Method

A comprehensive privacy portfolio includes:

• FHE is used for delegating privacy calculations

• ZKP is used to verify that the FHE calculation is executed correctly

• MPC for threshold decryption

• Each MPC node runs within TEE for enhanced security

This is complex, introducing many unexplored extremes, with a lot of overhead and may not be practical for many years to come.Another risk is that people may have a false sense of security by superimposing multiple complex concepts together.The more complexity and trust assumptions we add, the harder it is to infer the security of the overall solution.

Is this worth it?Maybe worth it, but it is also worth exploring other methods that may lead to significantly better computing efficiency, while privacy guarantees will only be slightly weaker.As Seismic’s Lyron points out – we should focus on the simplest solutions to meet our criteria for the level of privacy and acceptable tradeoffs needed, rather than over-designing just for it.

1. Directly use MPC for general calculations

If both ZK and FHE eventually return to the MPC’s trust assumption, why not directly use MPC for calculations?This is a reasonable question, and it is something that teams such as Arcium, SodaLabs (used by Coti v2), Taceo and Nillion are trying to do.Note that MPC comes in many forms, but among the three main methods, we are referring here to the basis ofSecret sharingandGarbage Circuit (GC)rather than a FHE-based protocol that uses MPC for decryption.

While MPC has been used for simple calculations such as distributed signatures and more secure wallets, the main challenge in more general computing with MPC is communication overhead (increasing with the complexity of the calculation and the number of nodes involved).

There are ways to reduce overhead, such as preprocessing offline in advance (i.e. the most expensive part of the protocol) – both Arcium and SodaLabs are exploring this.The calculation is then performed in the online phase, which consumes some data generated in the offline phase.This greatly reduces the overall communication overhead.

The following table for SodaLabs shows 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 much work to be done to improve efficiency and extend the operator set beyond a few nodes.

Source: SodaLabs

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

2. Trusted execution environment

Recently, interest in TEE has rekindled, which can be used alone (a private blockchain or coprocessor based on TEE) or in combination with other PETs such as ZK-based solutions (using TEE only).Performs calculation of shared private state).

While TEEs are more mature in some ways and introduce less performance overhead, they are not without their drawbacks.First, TEE has different trust assumptions (1/N) and provides hardware-based rather than software-based solutions.The criticism that people often hear is a vulnerability around SGX’s past, but it is worth noting that TEE ≠ Intel SGX.TEE also needs to trust hardware providers, which are expensive (which most people can’t afford).One solution to the risk of physical attacks could be to run TEEs in space to handle critical missions.

Overall, TEE seems to be more suitable for proofs or use cases that only require short-term privacy (threshold decryption, dark disk ledger, etc.).Security seems less attractive for permanent or long-term privacy.

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

Intermediary privacy can provide privacy to prevent access from other users, but privacy guarantees come entirely from trust in third parties (single point of failure).While it is similar to “web2 privacy” (preventing privacy from other users), it can be strengthened with additional guarantees (encryption or economical) and allows verification to be performed correctly.

An example is the Private Data Availability Committee (DAC); members of the DAC store data off-chain, and users trust them to properly store data and perform state transition updates.Another form is the licensed sequencer proposed by Tom Walpo.

While this approach makes a big trade-off in terms of privacy assurance, it may be the only viable alternative (at least for now) in terms of cost and performance.For example, Lens Protocol plans to use private DACs to implement private information flow.For use cases such as on-chain social, the trade-off between privacy and cost/performance may be reasonable at the moment (considering the cost and overhead of alternatives).

4. Invisible address

An invisible address can provide a similar privacy guarantee as creating a new address for each transaction, but the process is automatically performed on the backend and is not disclosed to the user.For more information, see this overview of Vitalik or this article that digs into different approaches.The main players in this field include Umbra and Fluidkey.

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

In addition, the privacy guarantees provided by invisible addresses are not as powerful as other alternatives.Anonymity can be broken through with simple clustering analysis, especially when incoming and outgoing transfers are not within a similar range (e.g., $10,000 is received, but the average daily transaction costs $10-100).Another challenge with invisible addresses is upgrading keys, which now require individual upgrades for each wallet (key storage summary can help solve this problem).From a user experience perspective, if the account does not have fee tokens (such as ETH), the invisible address protocol also requires the account abstraction or payer to pay for the fee.

Risks to our argument

Given the rapid pace of development and the general uncertainty of different technological solutions, we believe there are some risks in the argument that MPC will be the final solution.We may not end up needing some form of MPC, the main reasons include:

1. Shared private state is not as important as we think: in this case, 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 that show that ZK-based systems work well in orphan use cases, such as the private payment protocol Payy.

2. Performance tradeoffs are not worthy of the benefits of privacy protection: One might say that the trust assumption of an MPC network with 2-3 licensors is not much different from a single centralized player, and that a significant increase in cost/overhead is notWorth it.This may be true for many applications, especially low-value, cost-sensitive applications (such as social or gaming).However, there are also many high-value use cases where collaboration is currently very expensive (or impossible) due to legal issues or coordination friction.The latter is where MPC and FHE-based solutions can shine.

3. Specialization beats general design: Building new chains and guiding the user and developer community is very difficult.Therefore, universal privacy infrastructure (L1/L2) may be difficult to gain attention.Another issue involves specialization; a single protocol design is difficult to cover the entire trade-off space.In this world, solutions that provide privacy for existing ecosystems (confidentiality as a service) or dedicated use cases (such as payment) will prevail.However, we are skeptical of the latter because it brings complexity to application developers who need to implement some encryption techniques themselves (rather than abstracting them out).

4. Regulation continues to hinder trials of privacy solutions: This is a risk for anyone building privacy infrastructure and applications with certain privacy guarantees.Non-financial use cases face less regulatory risks, but it is difficult (impossible) to control what is built on top of a license-free privacy infrastructure.We are likely to address technical issues before we resolve regulatory issues.

5. For most use cases, the overhead of MPC and FHE-based solutions is still too high: While MPCs are primarily affected by communication overhead, the FHE team relies heavily on hardware acceleration to improve its performance.But if we can infer the development of dedicated hardware on the ZK side, it will take much longer than most people think before we get FHE hardware available for production.Teams dedicated to FHE hardware acceleration include Optalysys, fhela and Niobium.

Summary

Ultimately, the strength of the chain depends on its weakest link.In the case of programmable privacy infrastructure, ifWe want it to handle shared private state without single point of failure, and then the trust guarantee comes down to the guarantee of MPC.

While this post sounds like a criticism of MPC, that’s not the case.MPC has greatly improved the current situation of relying on centralized third parties.We believe that the main problem is that there is false confidence in the entire industry and the problem is covered up.Instead, we should face the problem head-on and focus on assessing potential risks.

However, not all problems need to be solved using the same tools.Although we believe MPC is the ultimate goal, other approaches are also viable options as long as the overhead of MPC-driven solutions remain high.We are always worth considering which approach is best suited to the specific needs/characteristics 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, everything is not necessarily a nail.