The transparent ledger of cryptography has fundamentally changed the way we see trusted systems. As the old axiom goes, “don’t trust, verify,” and transparency allows us to do exactly that. If everything is open, any falsification can be flagged. However, this same transparency has proven to be one of the limits to usability. Certainly, some things should be open - settlement, reserves, reputation (and arguably identity) - but there is no world in which we want everyone’s complete financial and health records to be public alongside their personal information.

The Need for Privacy in Blockchains

Privacy is a basic human right. Without privacy, there can be no freedom or democracy.

Just as the early internet needed encryption (or SSL) to enable secure e-commerce and protect user data, blockchains need robust privacy techniques to reach their full potential. SSL allowed websites to encrypt data in transit, ensuring that sensitive information like credit card numbers couldn’t be intercepted by malicious actors. Similarly, blockchain needs privacy to protect transaction details and interactions while maintaining the integrity and verifiability of the underlying system.

Privacy on blockchains isn’t just about protecting individual users - it’s crucial for enterprise adoption, compliance with data protection regulations, and unlocking new design space. No company in the world wants every employee to see how much others are paid, or competitors to be able to stack rank their most valuable customers and poach them. Moreover, certain industries like healthcare and finance have strict regulatory requirements around data privacy that must be met for blockchain solutions to be a viable tool.

A Map for Privacy-Enhancing Technologies (PETs)

As the blockchain ecosystem has evolved, several key PETs have emerged, each with its own strengths and trade-offs. These technologies - Zero-Knowledge Proofs (ZK), Multi-Party Computation (MPC), Fully Homomorphic Encryption (FHE), and Trusted Execution Environments (TEE) - lie across six key axioms.

1. Generalizability: How easily the solution can be applied to a wide range of use cases and computations.
2. Composability: How easily can this technique be combined with others to mitigate downsides or unlock new design spaces.
3. Computational Efficiency: How efficiently the system can perform computations.
4. Network Efficiency: How well the system scales with increased participants or data size.
5. Decentralization: How distributed the security model is.
6. Cost: Practically, what the cost of privacy is.

Much like the blockchain trilemma of scalability, security, and decentralization, achieving all six attributes at once has proven challenging. However, recent advancements and hybrid approaches are pushing the boundaries of what’s possible, bringing us closer to comprehensive, affordable, and performant privacy solutions.

Now that we have a map, we’ll briefly survey the landscape and explore the future prospects of these PETs.

Map of the PETs Landscape

I suppose I owe you some definitions at this point. Note: I assume that you’ve also been aggressively reading Dune and have been viewing everything through melange-tinged eyes!

• Zero Knowledge (ZK) is a technique which allows verification that a computation took place and achieved a result without revealing what the inputs were.
  • Generalizability: Medium. Circuits are highly application specific, but that’s being worked on with hardware based abstraction layers like Ulvatana and Irreducible and generalized interpreters (Nil’s zkLLVM).
  • Composability: Medium. It works in isolation with a trusted prover, but the prover must see all the raw data in a networked setup.
  • Computational Efficiency: Medium. With real ZK applications like Leo Wallet coming online, proving is seeing exponential gains through novel implementations. We expect further advancements as customer adoption grows.
  • Network Efficiency: High. Recent advances in folding have introduced huge potential for parallelization. Folding is essentially a much more efficient way to construct iterative proofs, so it can build on work previously done. Nexus is one to watch here.
  • Decentralization: Medium. Theoretically, proofs can be generated on any hardware, though practically, GPUs are seeing a preferred use here. Despite hardware becoming more uniform, this can be further decentralized on the economic level with an AVS such as Aligned Layer. Inputs are only private if combined with other techniques (see below).
  • Cost: Medium.
    • High initial implementation costs for circuit design and optimization.
    • Moderate operational costs, with expensive proof generation but efficient verification. A notable contributing factor to this cost is proof storage on Ethereum, but this can be mitigated with other approaches such as using data availability layers like EigenDA or an AVS.
  • Analogy for the Dune-pilled: Imagine Stilgar needs to prove to Duke Leto that he knows the location of a spice field without revealing its actual location. Stilgar takes a blindfolded Leto on an ornithopter, circles above the spice field until the sweet smell of cinnamon fills the cabin, then guides him back to Arrakeen. Leto now knows Stilgar can find the spice, but he doesn’t know how to get there himself.
• Multi-Party Computation (MPC) is where multiple parties can compute a result together without revealing their individual inputs to each other.
  • Generalizability: High. Accounting for specialized flavors of MPC (such as secret sharing, etc).
  • Composability: Medium. MPC is secure, but composability decreases with complexity, as complexity introduces exponentially more networking overhead. However, MPC has the ability to handle private inputs from more than one user in the same computation, which is a fairly common use case.
  • Computational Efficiency: Medium.
  • Network Efficiency: Low. The number of participants scales how much networking must be done quadratically. Nillion and others are working to address this. Erasure coding / Reed-Solomon codes - or loosely, splitting data into shards and then saving those shards - can be leveraged here as well to reduce errors, although it’s not a traditional MPC technique.
  • Decentralization: High. Though it’s possible actors can collude, compromising security.
  • Cost: High.
    • Moderate to high implementation costs.
    • High operational costs due to communication overhead and computational requirements.
  • Analogy for the Dune-pilled: Consider the Great Houses of the Landsraad ensuring they have adequate spice reserves between them so that they can come to each other’s aid, but they don’t want to reveal their individual reserves. The first house can send a message to the second, adding a large random number to their actual reserves. The second house then adds their actual number of reserves and so forth. When the first house receives the final total, they just subtract their large random number, and reveal the actual, total amount of spice in reserve.
• Fully Homomorphic Encryption (FHE) allows computations to be performed on encrypted data without decrypting it first.
  • Generalizability: High.
  • Composability: High for single user inputs. Must be combined with other techniques for multi-user, private inputs.
  • Computational Efficiency: Low. Though advancements from the mathematical layer down through the hardware layer are being optimized in unison, which will be a huge unlock. Zama and Fhenix are doing a lot of excellent work here.
  • Network Efficiency: High.
  • Decentralization: Low. In part due to the computational requirements and complexity, but as advancements are made, FHE decentralization may approach ZK’s decentralization.
  • Cost: Very High.
    • High implementation costs due to complex cryptography and strict hardware requirements.
    • High operational costs due to intensive computations.
  • Analogy for the Dune-pilled: Imagine a device similar to a Holtzman shield, but for numbers. You can put numerical data into this shield, activate it, and give it to a Mentat. The Mentat can perform calculations on the shielded numbers without ever seeing them. When they’re done, they return the shield to you. Only you can deactivate the shield and see the result of the calculations.
• Trusted Execution Environments (TEEs) are a secure enclave, or area within a computer’s processor, where sensitive operations can be performed, isolated from the rest of the system. TEEs are unique in that they rely on silicon and metal rather than polynomials and curves. As such, while they might be a formidable technology today, the rate of improvement should theoretically be lower as it’s bounded by expensive hardware.
  • Generalizability: Medium.
  • Composability: High. But less secure due to the potential of side channel attacks.
  • Computational Efficiency: High. Near server-side efficiency, so much so that NVIDIA’s newer H100 chipset line ships with a TEE.
  • Network Efficiency: High.
  • Decentralization: Low. Though constrained to specific chipsets such as Intel’s SGX, which implies vulnerability to side channel attacks.
  • Cost: Low.
    • Low implementation costs if using existing TEE hardware.
    • Low operational costs due to near-native performance.
  • Analogy for the Dune-pilled: Picture the navigation chamber of a Spacing Guild Heighliner. Even the Guild’s own navigators can’t see or interfere with what’s happening inside when it’s in use. A Navigator enters this chamber to perform the complex calculations necessary for folding space, and the chamber itself ensures that everything done inside is kept private and secure. The Guild provides and maintains the chamber, guaranteeing its security, but they can’t see or interfere with the Navigator’s work inside.

Practical Use Cases

Maybe it’s best we don’t need to contend with spice cartels and instead just need to make sure privileged data such as key material stays privileged. So to ground this in reality, some practical use cases today of each technique are as follows.

ZK is a good fit where we need to verify that some process generated the correct result. It’s an excellent privacy technique when combined with others but to use it on its own sacrifices trustlessness and is more akin to compression. Oftentimes we use it to verify that two states are identical (i.e. “uncompressed” layer 2 state and the block header, which is posted to the layer 1, or a proof that a user is over the age of 18, without revealing the user’s actual underlying Personally Identifiable Information.)

MPC is often used for key management. This could be a private key or a decryption key used in conjunction with other techniques, but it’s also used in distributed random number generation, (smaller) confidential compute operations, and oracle aggregation. In essence, anything that uses multiple parties that shouldn’t collude to do lightweight aggregation-based computation is a good fit.

FHE is a good fit when simple, generic computations need to be done without the computer seeing the data (i.e. credit scoring, smart contract games of Mafia, or ordering transactions in a mempool without revealing the transactions’ contents.)

Finally, a TEE is a good fit for more complicated operations if you’re willing to trust the hardware. For example, this is the only viable solution for private foundation models (LLMs that exist inside enterprises or financial/healthcare/national security institutions). The tradeoff is that because TEEs are the only hardware-based solution, theoretically the rate at which the drawbacks are mitigated should be slower and more expensive than the other techniques.

What Lies Between

It’s apparent that there is no perfect solution, and it’s unlikely that one technique will grow to be that perfect solution. Hybrid approaches are exciting in that they may use the strengths of one to mitigate the weaknesses of the other. The table below shows some of the design spaces that can be unlocked by combining the different approaches. The actual approaches are wildly different (i.e. combining ZK and FHE likely requires finding the right curve parameters, whereas combining MPC and ZK likely requires finding a certain class of setup parameters to reduce eventual networking round trips), but if you’re building and want to talk, hopefully this can provide some inspiration.

Simply put, performant, generalizable privacy unlocks a myriad of applications, including gaming (nod to Baz at Tonk’s excellent writing), governance, fairer transaction lifecycles (Flashbots), identity (Lit), non-financial services (Oasis), collaboration, and coordination. This is part of why we find Nillion, Lit Protocol, and Zama so exciting.

Conclusion

In summary, we see that the potential is vast, but we’re still in the early stages of exploring what’s possible. Individual technologies might be approaching some semblance of maturity, but stacking techniques is still a field ripe for exploration. The applicable quiver of PETs will be highly tailored to the domain, and as an industry, there’s still so much more we can do.

Disclaimer：

1. This article is reprinted from [[Hack VC
2. ](https://blog.hack.vc/the-future-of-privacy-tech-in-blockchain/)], All copyrights belong to the original author [Duncan Nevada]. If there are objections to this reprint, please contact the Gate Learn team, and they will handle it promptly.
3. Liability Disclaimer: The views and opinions expressed in this article are solely those of the author and do not constitute any investment advice.
4. Translations of the article into other languages are done by the Gate Learn team. Unless mentioned, copying, distributing, or plagiarizing the translated articles is prohibited.