In the long run, the majority of onchain transactions will likely be private.
Crypto’s transparent nature has handcuffed many app developers. The design space of apps developers can build with sensitive user data is much more vast, from gaming to private order books to MEV infrastructure.
After data breaches more than doubled from 2015 to 2022, tech consumers now have heightened concerns about the protection and vulnerability of their personal data, in web3 and traditional tech. While mindfulness around privacy might ebb and flow, a larger trend is becoming clear: with the growth of mass data collection and data-based monetization, online footprints are becoming increasingly traceable to big tech giants and external adversaries targeting these honeypots.
In mature app categories, some incumbents are facing new privacy-first challengers; look no further than the rise of encrypted messaging apps, like Telegram and Signal, from 2019-2021. Within crypto, Brave has seen extremely impressive growth through the recent bear market, climbing to an ATH MAU of ~66 million in November 2023. To put that in perspective, that’s around 15% of Firefox’s 2022 user base. As such, numerous crypto projects are now competing to offer compelling productized tools and solutions that make it as simple as possible to build a private application.
Examples of leveraging privacy tech in crypto are seemingly endless. In consumer, we’re seeing exciting experiments with fully onchain private games like poker and fog of war. In DeFi, some are building “dark order books,” trading environments not viewable by public market participants. (For context, dark pools executed an estimated 40% of traditional equities volume in April 2019.) Darker liquidity can also drive more efficient market outcomes by reducing MEV. Many sophisticated trading firms are barred from executing complex strategies due to the entirely public nature of blockchains, so greater privacy could even open the doors for more professional financial players to enter the crypto ecosystem.
The perceived lack of user privacy in crypto remains a bottleneck to greater adoption. To adapt to new privacy expectations, crypto app builders must prioritize privacy from the outset.
So, how should crypto app builders navigate the landscape of privacy solutions?
Approaches to user privacy
The major generalizable approaches right now to building private applications are trusted execution environments (TEEs), zero knowledge (ZK), multi-party computation (MPC), and fully homomorphic encryption (FHE). Below is a brief overview of each approach, plus representative projects.
This entire field is still extremely early, so the following comparisons are merely projections of the development needed for each technology in the years to come. These approaches are also not equivalent or interchangeable; painting with a broad brush, they can roughly be grouped into specialized hardware (TEEs) and cryptography (ZK, MPC, FHE). Additionally, many of them effectively overlap. For example, FHE must be combined with ZK and/or MPC. With all that said, looking at each approach’s trajectory yields actionable insights about how the broader privacy category could evolve.
TEEs
Description: Trusted, secure offchain computation environments
Project(s): ARM TrustZone, AWS Nitro, Intel SGX, Secret Network
ZK
Description: Applying zero-knowledge cryptography to verify private data and computation
Project(s): Aleo, Aztec, Mina, Nocturne, Polygon Miden, Privacy Pools
MPC
Description: Joint computation on separate fragments of private data
Project(s): Nillion
FHE
Two critical factors for selecting infrastructure are privacy trust assumption and performance; these are both highly nuanced terms, and the two matrices below unpack both concepts. They show the assumptions made for data to remain private (they are extremely important for developers thinking of building private apps) and the tradeoffs involved with achieving a certain performance level.
Over time, we can expect market forces to drive more efficient technical outcomes for many of these technologies. Hardware acceleration and other catalysts will likely significantly improve the performance of the newer technologies, although the time horizon remains quite unclear. In the long term, each of these approaches could control their own corner of the market.
The chart below compares each along key dimensions, including: composability, meaning the ability for other apps to interact with private state; technological complexity; potential to create a decentralized protocol; current performance level, meaning the potential throughput; and optimal use case(s) based on dimensions mentioned before. This chart can be thought of as the tradeoffs made by each approach for its performance level.
As seen above, each approach comes with different sets of tradeoffs. One isn’t fundamentally better than the others, but each is best suited to a particular class of applications based on what it optimizes. For example, a company building a more centralized, dark order book could use TEEs, while a project building a private lending protocol could opt for FHE or ZK.
Note that many of these technologies can be combined, and their intersections are often some of the most interesting approaches. For example, ZKPs can be used to remove the operator function for TEE-based dark order books, and MPC is often used to distribute the encryption key in FHE. The aim of these categorizations is to distill the highest-level technical considerations of each isolated approach. Finally, there are obvious regulatory implications of this category with regards to potential illicit activity; it’s crucial for infrastructure builders to be mindful of compliance.
Pros and cons of each approach
TEEs
Trusted execution environments (TEEs) involve computing offchain in trusted, secure environments. TEEs are already used by many crypto organizations for a variety of tasks, and private applications are just one small use case. They can be software or hardware based, but are most commonly trusted hardware. Since this infrastructure is offchain and in isolated environments, transactions remain hidden from public market participants.
In practice, this could look like a trader posting an order without knowing the full order book and being matched if there’s liquidity on the other side of that trade in the pool, without either party revealing their bids or asks.
A notable application of TEEs so far has been dark order books, and similar infrastructure already exists in TradFi: “dark pools,” which are private exchanges outside of public markets, operated by some of the world’s largest financial institutions—Goldman Sachs’s Sigma X and Morgan Stanley’s MS Pool are two examples. Dark pools are used to limit market impact of large trades.
While highly performant, TEEs are the only effectively centralized approach mentioned in this post, which comes with various shortcomings. One critique is that they’re only a marginal improvement over most traditional hardware and come with similar sets of risks. Side channel attacks are a notable issue, and have occurred in the past; developers also need to rely quite heavily on manufacturer representations. That being said, they are extremely practical, easy to build with, and highly performant.
Pros:
Infrastructure is powerful, tested and built out
Performant compared to current alternatives
Cons:
Often need to bootstrap sufficient liquidity for applications like dark pools
Relies on centralized providers like AWS, Intel, etc, which—while rare—have been attacked / popped, and introduces censorship / deplatforming risk
ZK
Zero knowledge (ZK) can be used to prove the correctness of computation without revealing any information. ZK is an extremely far-reaching technology, and privacy is just a small use case. To date, ZK has largely been applied to scaling—move intensive computation offchain, then use ZKPs that verify the correctness of the computation. There are multiple ZK applications in privacy, but three major groups (while not entirely encompassing) are generalizable ZK, ZK L1s / L2s, and private pools.
First, developers leveraging ZK for privacy applications can start from scratch and construct proof circuits themselves, or use a zkVM. zkVMs provide an execution environment for arbitrary code and produce a ZKP receipt verifying the code was executed honestly without revealing any data about the actual computation. Importantly, generalizable zkVMs must be combined with a decentralized private computation (DPC) scheme like Zexe.
Second, ZK L1s and L2s allow users to transact with private state in one ecosystem, or move private onchain operations to these networks or layers. They have effectively built out a privacy-first zkVM. Examples are Aleo, Aztec, Mina, and others.
Finally, private pools obscure transactions on public chains. They use ZK to verify a user’s deposit address, hiding the flow of funds to a fresh withdrawal address. Private pools aren’t only for users, but can be integrated with certain applications.
Importantly, ZK essentially verifies private state, so there must still be a private execution environment for generating proofs; in many cases, this is client-side and directly on the user’s device (where the actual private data, in its raw form, is stored). An early example of ZK in privacy is decentralized identity, where a user can prove sensitive aspects of their identity without revealing the actual data publicly onchain.
Pros:
Can be very generalizable, and applied to many privacy use cases
Often very composable, meaning applications can tap into passive private state
Cons:
Computationally intense, and the tech is still early (although further along than FHE)
Often requires knowledge of a different programming language or ZK circuits
MPC
Secure multi-party computation (MPC) enables multiple parties to jointly run a computation on private data, where each holds only a fragment of the private data. With only one shard, the party can’t access the private data, and separate parties can’t access the rest of the data. There are many use cases of MPC in crypto—key management is a notable one—but privacy applications are beginning to emerge.
There are effectively two ways to structure these kinds of MPCs: 1) the user is the participant in the joint 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 execute; most projects take the second approach. It should also be mentioned that an obvious risk of MPC is collusion among the parties, which could piece together their shards to see the private data.
MPC can be best used for private computations (especially where the output is public) involving multiple parties, but not too many. Other technical approaches like FHE often rely on MPC, so if the number of parties is of significant size and properly distributed, and the computation is one-off and not terribly complex, MPC is likely sufficient. A decentralized poker game is an example of a good use case for MPC.
Pros:
Can be applied to many privacy use cases involving one-off computations
Cons:
Doesn’t scale particularly well with the number of parties
Can’t be used for high-throughput applications, as execution is quite slow
FHE
Fully homomorphic encryption (FHE) allows computation on encrypted, private state. In other words, users can transact onchain without revealing any information about the transaction. Practically, this could involve swapping tokens on a DEX or depositing in a lending pool, but there would be no public onchain data about which tokens were swapped or how much was deposited.
FHE alone is not a sufficient approach to privacy. Most approaches use some combination with MPC for sharding the encryption key, so there isn’t one centralized party capable of decrypting all private state. ZK is also often used to verify transactions—including both outputs and the validity of inputs, since all data is encrypted—so contracts can interact with private state without revealing the information.
The technology is still extremely early, and only a few years ago were schemes like TFHE released that enable all four main mathematical operations for an exact output, versus an approximate one. Additionally, hardware acceleration is required for any reasonable level of performance. FHE also does not scale particularly well with sequential rounds of computations; random noise is added to the encrypted data, which grows non-linearly with more computations. While in an earlier phase of development than other approaches mentioned, FHE is optimal for computations requiring high composability with few parties; examples include private lending markets and advanced consumer applications.
Pros:
Only approach with shared private state being fully onchain
Can be applied to most privacy use cases
Cons:
Performance is quite poor in current state
Relies on other technologies like ZK and MPC, which come with their own shortcomings and trust assumptions
Looking forward
Privacy infrastructure and applications are now a necessity in crypto, and are still in the initial stages of development. We expect the landscape of these solutions to keep rapidly multiplying.
Each privacy solution covered here comes with different tradeoffs and is best positioned for different suites of applications. The privacy category is so early and vast that it would be reductionist to say one single approach will win.
Zooming out, it’s inevitable that many new technologies will emerge relevant to privacy. This category is one of the most dynamic and fast moving, yet opaque in crypto. And this stage is clearly only the first era of innovation.
If you’re building in this category, whether at the infrastructure or application level, I’d love to chat: derek@variant.fund.
Special thanks to Ravital Solomon (Sunscreen), Sam Trautwein (Tristero), Shumo Chu, (Nebra), Weiking, Nicola Greco (Protocol Labs), and the teams at Aztec and Aleo. Importantly, the views expressed in this piece are not necessarily representations of theirs. Also, thanks to Mason Nystrom for making my data tables pretty and Dan Roberts for editing this piece.
Further reading:
https://blog.sunscreen.tech/an-intro-to-fully-homomorphic-encryption-for-engineers/
https://www.sec.gov/news/statement/shedding-light-dark-pools
https://scrt.network/blog/beyond-zk-guide-to-web3-privacy-part-2/
https://taiko.mirror.xyz/2O9rJeB-1PalQeYQlZkn4vgRNr_PgzaO8TWUOM5wf3M
+++
This post is for general information purposes only. It does not constitute investment advice or a recommendation or solicitation to buy or sell any investment and should not be used in the evaluation of the merits of making any investment decision. It should not be relied upon for accounting, legal or tax advice or investment recommendations. You should consult your own advisers as to legal, business, tax, and other related matters concerning any investment. Certain information contained in here has been obtained from third-party sources, including from portfolio companies of funds managed by Variant. While taken from sources believed to be reliable, Variant has not independently verified such information. Variant makes no representations about the enduring accuracy of the information or its appropriateness for a given situation. This post reflects the current opinions of the authors and is not made on behalf of Variant or its Clients and does not necessarily reflect the opinions of Variant, its General Partners, its affiliates, advisors or individuals associated with Variant. The opinions reflected herein are subject to change without being updated.
Variant is an investor in Aleo and Aztec.
