Variant: Building in the Dark, Mapping the Current Crypto-Privacy Landscape
Original author: Derek Walkush, investment partner at Variant Fund
Original compilation: Luffy, Foresight News
In the future, most on-chain transactions may be private.
The transparency of cryptocurrencies inhibits many application developers. The design space for developers to build applications using sensitive user data is vast, from games to privacy order books to MEV infrastructure.
Data breaches more than doubled from 2015 to 2022, and technology consumers are now more concerned about the protection of their personal data. While privacy concerns may ebb and flow, a larger trend is becoming clear: As the collection of massive data and the commercialization of data grows, online footprints are increasingly easier to trace back to the big tech giants and those targeting these honeypots. External opponents.
Within mature app categories, some existing apps are facing new privacy-first challengers—just look at the rise of encrypted messaging apps like Telegram and Signal from 2019 to 2021. In the cryptocurrency space, Brave has seen impressive growth during the recent bear market, climbing to 66 million ATH MAU in November 2023. To put things into perspective, thats roughly 15% of Firefoxs 2022 user base. As a result, many crypto projects are now competing to deliver compelling productized tools and solutions that make building privacy applications as easy as possible.
There are countless examples of leveraging privacy technologies in cryptocurrencies. On the consumer side, we’re seeing exciting experiments with full-chain privacy games like poker and fog of war. In the DeFi field, some people are building dark order books, which are trading environments that cannot be viewed by public market participants. (For a little background, in April 2019, dark pool execution volume accounted for approximately 40% of traditional equity trading volume.) Dark pool liquidity can also drive more efficient market outcomes by reducing MEV. Due to the fully public nature of blockchain, many established trading firms are prohibited from executing complex strategies, so private trading could open the door for more professional financial players to enter the crypto ecosystem.
Cryptocurrencies’ lack of user privacy remains a bottleneck in expanding adoption. To adapt to new privacy expectations, crypto app builders must prioritize privacy from the start.
So, how should crypto app builders navigate privacy solutions?
Ways to protect user privacy
The main common methods currently used to build private applications are Trusted Execution Environment (TEE), Zero Knowledge (ZK), Multi-Party Computation (MPC) and Fully Homomorphic Encryption (FHE). Below is a brief overview of each approach, along with representative projects.
The entire field is still in its very early stages, so the following comparisons are only predictions of how each technology will develop over the next few years. Nor are these methods equivalent or interchangeable; to summarize, they can be broadly divided into dedicated hardware (TEE) and cryptography (ZK, MPC, FHE). Furthermore, many of them actually overlap. For example, FHE must be used in conjunction with ZK or MPC. That being said, by examining the trajectory of each approach, we can draw insights into how privacy more broadly evolves.
TEE
Description: Trusted and secure off-chain computing environment
Projects: ARM TrustZone, AWS Nitro, Intel SGX, Secret Network
ZK
Description: Apply zero-knowledge cryptography to authenticate private data and computations
Projects: Aleo, Aztec, Mina, Nocturne, Privacy Pools
MPC
Description: Perform joint calculations on separate pieces of private data
Project: Nillion
FHE
Description: Computation of encrypted data
Projects: Fhenix, Inco, Sunscreen, Zama
Two key factors in choosing infrastructure are privacy trust assumptions and performance. These are very nuanced terms, and the diagram below explains both concepts. They illustrate the assumptions that data remains private (which are extremely important for developers considering building privacy applications) and the trade-offs involved in achieving a specific level of performance.
Over time, we can expect market forces to lead to more efficient outcomes for many of these technologies. Hardware acceleration and other catalysts may significantly improve the performance of the new technology, although the time frame remains fairly unclear. In the long run, each of these approaches could have a place in the market.
The chart below compares each of the key dimensions, including: composability, meaning the ability of other applications to interact with the privacy state; technical complexity; potential to create decentralized protocols; current performance levels, meaning potential throughput; and the best use cases based on the previously mentioned dimensions. The chart can be viewed as the tradeoffs each method makes for its level of performance.
As shown above, each approach has different trade-offs. No one will outright beat the others, but each has specific categories of applications where its appropriate. For example, a company building a more centralized dark order book can use TEE, while a project building a privacy lending protocol can choose FHE or ZK.
Note that many techniques can be combined, and their intersections are often some of the most interesting approaches. For example, ZKP can be used to remove operator functionality from TEE-based dark order books, while MPC is often used to distribute encryption keys in FHE. The purpose of these classifications is to distill the highest-level technical considerations for each individual approach. Finally, this category has clear regulatory implications for potentially illegal activity; it is critical for infrastructure builders to pay attention to compliance.
Pros and Cons of Each Method
TEE
Trusted Execution Environment (TEE) involves off-chain computing in a trusted, secure environment. TEEs are already used by many cryptographic organizations for a variety of tasks, and privacy applications are just one small use case. They can be software or hardware based, but hardware is the most common. Because the infrastructure is off-chain and in an isolated environment, transactions remain hidden from public market participants.
In practice, this may look like a trader posting an order without knowing the full order book, and matching if there is liquidity on the other side of the trade in the pool, without either party revealing their bid or ask price.
One notable application of TEEs so far is dark order books, and similar infrastructure already exists in TradFi: “dark pools,” private trading venues outside of public markets and operated by some of the world’s largest financial institutions: Goldman Sachs Sigma X and Morgan Stanleys MS Pool are two examples. Dark pools are used to limit the impact of large transactions on the market.
Although TEE has high performance and is the only effective centralized method mentioned in this article, it has various shortcomings. One criticism is that they are only minor improvements over most traditional hardware and carry similar risks. Side-channel attacks are a notable issue and have occurred in the past; developers also need to rely heavily on the manufacturers representatives. Having said that, they are still very practical, easy to build and perform well.
advantage:
Infrastructure is functional, tested, and operational
Excellent performance compared to current alternatives
shortcoming:
It is often necessary to bootstrap sufficient liquidity for applications such as dark pools
Reliance on centralized providers such as AWS and Intel, which are occasionally attacked and introduce censorship/de-platforming risks
ZK
Zero-knowledge (ZK) can be used to prove the correctness of calculations without revealing any information. ZK is an extremely far-reaching technology, and privacy is only a small use case. To date, ZK has been primarily used for blockchain scaling—moving intensive computation off-chain and then using ZKP to verify the correctness of the computation. There are many ZK applications in the privacy field, which are roughly divided into three categories: general ZK, ZK L1/L2 and privacy pool.
First, developers using ZK for privacy applications can build their own proof circuits from scratch, or use zkVM. zkVM provides an execution environment for arbitrary code and generates ZKP receipts to verify whether the code is executed honestly without leaking any data about the actual calculation. Importantly, the generalizable zkVM must be combined with decentralized privacy computing (DPC) schemes such as Zexe.
Second, ZK L1 and L2 allow users to transact with privacy status within an ecosystem or transfer privacy on-chain operations to these networks. They effectively built a privacy-first zkVM. For example Aleo, Aztec, Mina, etc.
Finally, privacy pools mask transactions on the public chain. They use ZK to verify users deposit addresses and hide the flow of funds to new withdrawal addresses. Privacy pools are not only available for users, but can also be integrated with certain applications.
Importantly, ZK essentially verifies private states, so there must still be a private execution environment to generate proofs. In many cases this is client-side and directly on the users device (where the actual private data is stored in its raw form). An early example of ZK’s approach to privacy is decentralized identity, where users can prove sensitive aspects of their identity without exposing the actual data on-chain.
advantage:
Highly versatile and suitable for many privacy use cases
Highly composable, meaning applications can enter passive privacy states
shortcoming:
Computationally intensive, the technology is still in its early stages (although further than FHE)
Often requires knowledge of different programming languages or ZK circuits
MPC
Secure multi-party computation (MPC) enables multiple parties to jointly perform computations on private data, where each party holds only a portion of the private data. One party cannot access private data, and different parties cannot access the remaining data. MPC has many use cases in cryptography (key management being a noteworthy example), but privacy applications are only starting to emerge.
There are actually two ways to build this type of MPC: 1) the user is a participant in the federated computation, or 2) the user delegates the transaction to another party. The first is ideal from a trust assumption perspective, but is logistically more difficult to implement; most projects adopt the second approach. It should also be mentioned that an obvious risk with MPC is collusion between parties who may combine their shards to view private data.
MPC is best suited for privacy computations involving multiple parties. Other technical approaches, such as FHE, often rely on MPC, so if the number of parties is large and appropriately distributed, and the computation is one-off and not very complex, then MPC may be sufficient. Decentralized poker games are a good use case for MPC.
advantage:
Can be applied to many privacy use cases involving one-time computations
shortcoming:
Does not scale well with the number of parties involved
Cannot be used for high-throughput applications because execution is quite slow
FHE
Fully Homomorphic Encryption (FHE) allows computation on encrypted private states. In other words, users can conduct transactions on-chain without revealing any information about the transaction. When a user exchanges tokens on a DEX or deposits into a lending pool, no information is revealed about which tokens were exchanged or how many tokens were deposited.
But FHE alone is not enough to protect privacy. Most methods use some combination with MPC to shard encryption keys so that no single centralized party can decrypt all privacy states. ZK is also often used to verify transactions, including the validity of outputs and inputs, so contracts can interact with private states without leaking information.
The technology is still in its very early stages, with schemes such as TFHE, released just a few years ago, enabling both exact and approximate output for all four major mathematical operations. Additionally, hardware acceleration is necessary for any reasonable level of performance. FHE also does not scale particularly well in consecutive rounds of calculations. There is random noise in the encrypted data, and the data will grow non-linearly as calculations increase. Although FHE is in an earlier stage of development than the other mentioned methods, it is optimal for computations that require high composability with a small number of participants, such as privacy lending markets and high-volume consumer applications.
advantage:
The only way to share private state on-chain
Can be applied to most privacy use cases
shortcoming:
Performance is poor in its current state
Relies on other technologies such as ZK and MPC, which have their own shortcomings and trust assumptions
expect
Privacy infrastructure and applications are now a necessity for cryptocurrencies and are still in the initial stages of development. We expect these solutions to develop rapidly and have a promising future.
Each privacy solution presented here has different trade-offs and is suitable for different application scenarios. The privacy category has emerged so early and is so large that it is premature to say that a single approach will win.
In the long run, many new privacy-related technologies will inevitably emerge. This category is one of the most dynamic and rapidly growing, yet opaque, in the cryptocurrency space. And the current stage is clearly only the first era of innovation.
Special thanks to Ravital Solomon (Sunscreen), Sam Trautwein (Tristero), Shumo Chu (Nebra), Weiking, Nicola Greco (Protocol Labs) and the Aztec, Aleo team. The views expressed in this article do not necessarily represent their views.
