The Future of Privacy Tech in Blockchain

By Duncan Nevada, a Hack VC Research Partner

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.

So, if you’re working on either novel use cases, technologies, or methodologies, please reach out. We’d love to work with you, or at the very least learn from you and brainstorm together.

Acknowledgments

Massive thank you to Rand Hindi at Zama, David Sneider at Lit Protocol, Makena Walsh, Guy Zyskind and Guy Itzhaki at Fhenix, Liam McDonald from Fairblock, Barron Caster from Leo Wallet, Naveen at Tari, and Miguel de Vega, Alex Page and Andrei Lapets at Nillion.

The information herein is for general information purposes only and does not, and is not intended to, constitute investment advice and should not be used in the evaluation of any investment decision. Such information should not be relied upon for accounting, legal, tax, business, investment, or other relevant advice. You should consult your own advisers, including your own counsel, for accounting, legal, tax, business, investment, or other relevant advice, including with respect to anything discussed herein.

This post reflects the current opinions of the author(s) and is not made on behalf of Hack VC or its affiliates, including any funds managed by Hack VC, and does not necessarily reflect the opinions of Hack VC, its affiliates, including its general partner affiliates, or any other individuals associated with Hack VC. Certain information contained herein has been obtained from published sources and/or prepared by third parties and in certain cases has not been updated through the date hereof. While such sources are believed to be reliable, neither Hack VC, its affiliates, including its general partner affiliates, or any other individuals associated with Hack VC are making representations as to their accuracy or completeness, and they should not be relied on as such or be the basis for an accounting, legal, tax, business, investment, or other decision. The information herein does not purport to be complete and is subject to change and Hack VC does not have any obligation to update such information or make any notification if such information becomes inaccurate.

Past performance is not necessarily indicative of future results. Any forward-looking statements made herein are based on certain assumptions and analyses made by the author in light of his experience and perception of historical trends, current conditions, and expected future developments, as well as other factors he believes are appropriate under the circumstances. Such statements are not guarantees of future performance and are subject to certain risks, uncertainties, and assumptions that are difficult to predict.