Data is the lifeblood of the digital world, with every app mining and exploiting personal data. Big tech’s control of user’s personal data has raised massive privacy concerns, which are exacerbated by the rise of Artificial Intelligence (AI) and Machine Learning (ML). These technologies demand more private data to improve, creating an unprecedented acceleration in data needs. However, users are increasingly skeptical of sharing their data, aware of how it can be weaponized against them. While demand for critical data is skyrocketing, willingness to share it is plummeting. This impasse threatens to hinder innovation and technological progress. ### **The only solution to mitigate privacy concerns while encouraging the public to share more data, is to widely implement privacy-preserving technologies (PETs).** While data is typically encrypted while in transit and at rest, it often remains exposed in plain text during computation (in use). Fully Homomorphic Encryption (FHE) offers a promising solution, enabling computations on encrypted data without decrypting it, thus maintaining privacy throughout the process. For an overview of the technological details, [check out part 1](https://www.lightshift.xyz/blog/homomorphic-encryption-part-1). Drawing parallel to the early internet, before TLS was widely implemented, nothing was encrypted, limiting online use cases. Only after the TLS was implemented, secure online banking and similar applications finally became possible. Today, it’s unthinkable to interact with online platforms that don't use TLS or other encryption protocols. Similarly, we can envision a future where the vast majority of computations are conducted on FHE-encrypted data, making it the default method for data both at rest and in use. Despite FHE’s potential in web2, it’s paramount to combine it with web3 technologies to prevent big tech and centralized entities from controlling private data. By integrating FHE and PETs with web3 rails, we can ensure a future where advanced technologies aren’t monopolized by big tech. ### **FHE, combined with other cryptographic technologies and web3, can create a future where privacy and self-sovereignty are the default.** Similarly, blockchains need to integrate privacy technologies like FHE to unlock broader mainstream adoption beyond the current use cases. ::: Beyond FHE | ZK | MPC | TEEs FHE is just one piece of the puzzle. Other PETs like Zero Knowledge Proofs (ZK), Multi-Party Computation (MPC), and Trusted Execution Environments (TEEs) also come into play. These technologies each have their own strengths and, when used together, provide strong solutions to the challenges of data privacy and security. The basic concept of ZK proofs is that one entity can prove the validity of a statement without revealing the statement itself. For example, someone can prove that they executed some transaction or computation, without exposing the transaction or computation information. ZKPs have been pivotal in blockchain scalability, being seen as an ultimate solution for Ethereum’s L2s scalability. However, they can be quite limiting when applications need more context than just verifying if something is valid. MPC is a set of cryptography tools and technologies that allow different parties to work together to compute a given function while keeping the inputs of the compute private. Usually, the output of the compute is revealed at the end of the computation.

As any cryptographer will tell you, FHE is part of a subset of MPC algorithms, 2-party in this case. TEEs are secure enclaves within a CPU or GPU. The enclaves allow for computations to be performed without the owner of the hardware being able to inspect the memory nor tamper with the code. Effectively, the TEE data cannot be read or processed outside the enclave. TEEs also offer a remote attestation, which allows entities (i.e: smart contracts) to verify the integrity of a node and the application running inside the enclave. TEN gives a good overview of TEEs [here](https://whitepaper.ten.xyz/obscuro-whitepaper/technical-background.html). ::: ## The Rise of FHE: A Privacy Paradigm Shift FHE has numerous use cases in the “real” world, but combined with web3 rails, it has the potential to address countless issues and concerns with current web2 applications. Consider Alice, a therapist with thousands of notes from her assessments with patients. She wants to run an AI model on her data to find insights but lacks the compute capacity. Normally, Alice couldn’t share this data with a cloud provider due to privacy concerns. With FHE, she can encrypt the data and use a provider like AWS without worrying about data leakage. Or can she? ::: Verifiability | ZK & FHE Even with FHE, she faces challenges. How can she ensure the cloud provider is actually running the requested model, hardware, and inputs? This is where web3 solutions come in. Using ZK proofs of compute, hardware, and inputs, Alice can verify the provider’s actions and improve her security assumptions. ZK technologies are extremely valuable to improve the security of FHE systems. ZK proofs can be used to verify the inputs to the schemes, verifying the computations being performed, as well as a number of other parameters that could be used to exploit the user and their data. ::: But what if the cloud provider decides to stop serving Alice, increases prices, or locks her out from the data? FHE alone can’t prevent these issues—users can still be censored by their providers. Even if data is encrypted, centralized providers can run algorithms that may leak information. A decentralized compute/storage network prevents this by distributing control and ensuring no single entity controls the data/compute. ## Access Managment & Threshold FHE If Alice wants to share specific data with a fellow therapist, she would need to trust the cloud provider for access management, potentially having to share her encryption keys. This is where MPC and Threshold signing help. While MPC can be used to distribute any type of compute across different nodes, the more interesting application to use in combination with FHE is using MPC threshold signing. **Threshold signing is a method where a digital signature can only be generated if a minimum number (threshold) of participants from a larger group collaborate.** This technique ensures that no single participant can create a valid signature on their own. This is extremely valuable as it allows for decryption to be distributed across a network, as well as for a network to manage access levels without the data owner needing to share any keys. These examples highlight the need for a holistic solution combining multiple cryptography technologies. Blockchain plays a crucial role in tying everything together, providing the overall coordination and incentivization layer. Smart contracts can verify proofs, manage transactions, and control access, eliminating the need for a centralized intermediary. ## Unlocking Privacy-Preserving AI AI & ML are potentially the most transformational technologies of our generation, with the potential to solve some of society’s most challenging issues, from advancing disease treatment research to optimizing energy sources and productivity. Accessing domain-specific data is essential for AI's progress beyond public datasets. Meanwhile, this data is extremely valuable, and its creators and holders—both individuals and enterprises—are justifiably skeptical about sharing it. FHE and PETs are critical for AI & ML. **FHE unlocks privacy-preserving AI by enabling models to perform inference over encrypted data.** Tools like [Concrete ML](https://github.com/zama-ai/concrete-ml) allow developers to turn ML models into their homomorphic equivalents, massively simplifying the use of FHE for data scientists, who can use the tool without formal cryptography knowledge. ![](https://lightshift-website.s3.amazonaws.com/1721325834354_FHE-PET.png) *Source: [Bagel Network](https://blog.bagel.net/p/with-great-data-comes-great-responsibility)* Let’s consider Sam, an AI entrepreneur aiming to help the world by developing an AI model for patients that can’t afford psychotherapy. The model functions as an AI “therapist”. But why would patients trust Sam’s model? How can they be sure their data won’t be misused or sold? Enter FHE. It allows patients to encrypt their therapy records locally using an encryption algorithm (E) with a public key (pk), resulting in an encrypted record mr’= E(pk,mr). The patient can then send the encrypted record to the model for inference without revealing any details. Due to FHE’s properties, the inference is applied to mr’ without leaking any of the data. The AI “therapist” provides advice based on the encrypted data, which remains secure. Patients can decrypt the result using the public key (pk) on their end. It's important to note that the neural network N must be designed and trained to work with the specific FHE scheme and its parameters. Before this scenario is possible, Sam needs a vast amount of patient data to train his AI model. But why would any patients share their data? How can they be assured it won’t be exploited or used against them? FHE addresses these concerns by enabling secure data sharing and computation, crucial for training AI models without compromising privacy. Circling back to the earlier discussion, for patients to fully trust Sam with the FHE-encrypted data, a holistic solution with web3 must be implemented. Integrating ZK proofs can verify the computations on the data during training, while a crypto network can incentivize data sharing and ensure patients are compensated for their data. Furthermore, tracking data access and flows onchain ensures that Sam is not providing access to untrusted entities. At a time where AI models are [reaching improvement plateaus](https://www.wsj.com/tech/ai/ai-training-data-synthetic-openai-anthropic-9230f8d8) due to a lack of training data, FHE can vastly expand the usable data pool and act as a huge catalyst for growth. ## Enhancing Privacy with Encrypted Searches Consider Cathy, a small hedge fund manager with amazing return multipliers. Cathy uses the Bloomberg terminal to research potential investments, looking into their historical data and competitors. What stops Bloomberg from selling this information to Citadel, who can then front-run Cathy on her trades? FHE can be used to implement [Private Information Retrieval (PIR)](https://en.wikipedia.org/wiki/Private_information_retrieval) solving such a problem. PIR allows queries to a database without revealing the query details. Google, for example, learns a lot about users through their search queries and uses this information for targeted ads. This is their cash cow. PIR and encrypted search can protect users’ searches from being exploited by entities like Google. ## Enabling Secure Data Collaboration, Exploration & Analysis ::: Enterprise Uses | TEEs FHE unlocks secure data collaboration between entities without requiring mutual trust, thus enhancing data composability, allowing secure sharing of data previously siloed. Doctors would be able to share data insurance providers to get better premiums for users, without compromising data privacy. Or, a data sharing marketplace could allow users to share and monetize their data and allow specific computations, all while keeping the data private.

This enhancing privacy works not only amongst separate entities but also within companies. FHE transforms data exploration and analysis, allowing large corporations to run algorithms on customer data to optimize pricing, identify client personas, etc, without breaking users' privacy. A data scientist at a big corporation can now run a huge suite of analysis on client data, without accessing decrypted information TEEs present a number of downsides like recent exploits and dependence on hardware providers. It’s also hard to see space for TEEs when the above cryptography techniques are combined for a holistic approach. However, TEEs are already extremely performant and are a solution that enterprise players are familiar with. Making it a good short-term solution. Long-term, TEEs can still have space on implementations of extremely complex computations where FHE and ZK are either not efficient or too expensive. ::: In Brazil, [Banco Bradesco](https://banco.bradesco) is already [leveraging FHE](https://ibm-research.medium.com/top-brazilian-bank-pilots-privacy-encryption-quantum-computers-cant-break-92ed2695bf14) to enhance operational efficiency by using encrypted financial data for accurate predictions. By encrypting transaction data and prediction models, the bank ensures predictions are as accurate as traditional methods while safeguarding client privacy. This innovation allows institutions to streamline processes securely, setting new standards for data-driven operations. ## Enhancing Blockchain Security with FHE Blockchain’s promise of transparency often clashes with the need for user privacy. Consequently, on-chain privacy remains a huge challenge, as explained [in this article](https://wdai.us/posts/navigating-privacy/) by Wei Dai. PETs need web3 but blockchains also need on-chain privacy. The most evident issue is that all on-chain transactions are recorded publicly for everyone to read. It’s quite evident that this “feature” limits the amount of on-chain use cases. Going back to the TLS reference, **users want privacy and they won’t adopt blockchain solutions until on-chain privacy is the default.** Before diving deeper, it’s worth giving some context on why it’s so hard to do privacy on-chain. The difficulty spans mainly from the need for shared state in blockchains. [Mohammad Fouda](https://medium.com/alliancedao/zkps-fhe-mpc-managing-private-state-in-blockchains-17cc3661007d) has a great explanation on that. On-chain state can generally be divided into personal state (i.e., token balance) and shared state (i.e: AMMs, Lending pools, etc). Similarly, private state can also be divided into personal private state (PPS) and shared private state (SPS). PPS is controlled and viewed by a single entity (i.e., private token balance). SPS involves private data that multiple entities can change or use without compromising privacy, such as in dark pool AMMs or private lending pools. ::: Onchain Privacy | ZK | MPC | TEEs While solutions like Zcash and Monero address PPS, managing SPS is more challenging. Implementing solutions to compute over private state without leaking information or reducing security is difficult.

FHE, specifically with tools like fhEVM, offers solutions through private smart contracts. Unlike Monero or Zcash, which provide privacy for native coins, FHE can expand privacy to general smart contracts. ZKPs have been used for on-chain privacy for a long time. One of the first implementations was Zcash, which uses ZK and the UTXO architecture to enable private transactions, but is limited to native tokens. In the case of Zcash, and most ZKP-based private blockchains, the ZKP generation happens client-side on a given user's device. Network miners only observe the ZKP and the encrypted UTXO.

More recently, the massive decrease in ZK proof generation time allowed for the creation of ZK-based private blockchains like Aztec and Aleo. However, ZKPs are quite inflexible, making it infeasible to manage shared private states. This limits their effectiveness for general-purpose privacy solutions. When comparing FHE to MPC for onchain use cases, it’s relevant to separate compute and decryption/encryption.

Onchain FHE implementations require threshold signing since the encryption/decryption of the state must be distributed across nodes. Without a signing network, any individual node could decrypt the whole state or other less secure solutions(aka multi-sigs) would have to be implemented. Threshold FHE can ensure that the rules set by the developer for encryption/decryption are respected. No single party can unilaterally decrypt the state. This would break the intent for encrypting the onchain state in the first place.

On the compute level, generally on MPC algorithms, the inputs and computation are private. The output however, is usually public to the network’s nodes. Onchain, this is not ideal since the state should stay private even after computation. MPC also adds latency overhead since nodes must communicate with each other throughout the computation process. More generally, most MPC implementations tend to be done for specific use cases and functions, making it more challenging to implement general purpose solutions (i.e: smart contracts). TEEs have fallen out of favor since major exploits were found in the [hardware](https://medium.com/initc3org/tee-based-smart-contracts-and-sealing-pitfalls-eccd5d751329) and on some blockchain implementations ([Secret network exploit](https://blockworks.co/news/secret-network-crypto-transactions-not-so-secret-after-all)).

Given its characteristics, TEEs can be used to create privacy blockchains or privacy co-processors as the transaction data can only be decrypted for validation within the enclave.

TEE based networks are extremely dependent on TEE hardware providers. Intel has historically been the only producer of such CPUs, creating a single point of failure. As it happened, once a vulnerability is found, it can take out a whole network. If TEE powered hardware devices become more widespread, the technology can present an interesting short term solution for onchain privacy. ::: ## Identity and KYC FHE introduces flexible, private Decentralized Identifiers ([DIDs](https://www.w3.org/TR/did-core/)), suitable for complex interactions with multiple users. Traditionally, achieving privacy with DIDs has been challenging, especially in sectors requiring stringent compliance. Onchain identity can be a huge unlock, especially for vulnerable populations lacking traditional identity assets like passports, which restricts their access to bank accounts, jobs and more. Bringing DIDs on-chain allows users to control their identity assets, with blockchain verifying their authenticity. This also enhances asset composability across dapps. Onchain identity is still a huge bottleneck for web3 adoption. Most web2 companies like JP Morgan, can’t legally interact onchain without knowing their counterparties. Privacy preserving onchain identity is essential for mass adoption while also limiting excessive surveillance. Unlike other technologies, FHE enables encrypted storage of DIDs with controlled decryption permissions. [Holonym](https://holonym.id/), a project building privacy-preserving identity and compliance solutions, is [developing a network](https://paragraph.xyz/@holonym/announcing-mishti-network) for this, which could unlock numerous use cases across healthcare, finance, law, and more. Patient identities could be managed while complying with data protection regulations, or customer identities could be verified for KYC purposes while protecting sensitive personal information. ## Voting & Governance FHE technology could transform confidential voting processes, extending well beyond well-known examples like blockchain-based governance. Without privacy, on-chain voting is simply not feasible as everyone can see each other’s votes, risking censorship, retaliation and blackmail. While DAOs are already using solutions to address this, like [Cicadia](https://a16zcrypto.com/posts/article/building-cicada-private-on-chain-voting-using-time-lock-puzzles/), they are far from the end-game. FHE can be the foundation for secure, private voting in national elections, ensuring both transparency and voter anonymity. Emerging real-world applications aim to enhance electoral integrity while safeguarding individual privacy. This technology has the potential to boost democratic participation and make voting processes more fair, secure and accessible. ## Confidential IP Rights Management Another use case is having a platform where intellectual property rights are registered and transferred with complete confidentiality, protecting both the details of the IP and the identities of the owners. Leveraging fhEVM, an onchain IP registry would encrypt all aspects of intellectual property—ownership, licensing agreements, and transfer history. An approach like this would not only secure sensitive information but create new possibilities for digital rights management, changing how IP transactions are conducted and safeguarded. ## DarkPools: Bringing Large-Scale Trading Onchain ::: Onchain Darkpools | With ZK DarkPools, a crucial building block of TradFi, also offer a great use case that none of the ZK-based privacy chains have yet been able to successfully execute. Sunscreen aims to change this by using FHE to encrypt trading data—ask prices, tokens, order size, spread—within DarkPools. They would then run the orderbook’s algorithm to find matches over the encrypted orders. Leveraging FHE, Sunscreen’s implementation is actually superior to TradFi’s as it ensures not even the trading venue has access to the decrypted trading data. Let’s take the example from a [“private” Uniswap](https://ethresear.ch/t/why-you-cant-build-a-private-uniswap-with-zkps/7754) with ZK. Uniswap is a constant product exchange. The contract holds a balance of two tokens, token a and token b. It lets users deposit token a and withdraw some amount of token b defined by the ratio in the pools between bal(token_a) and bal(token_b).

In a “private” implementation of Uniswap, users need to deposit Token A and withdraw Token B. In order to prove that they have correctly withdrawn they need to know what the current balance of Token A and Token B are. However, if users know the current state, they can observe other users' interactions and infer what these users have done.

Consider then, a [scenario](https://ethresear.ch/t/why-you-cant-build-a-private-uniswap-with-zkps/7754), where a trader knows the state but I can’t see users actions. If a pool has 1 ETH and 1 DAI. Let's say another user executes a trade. The trader doesn’t know what but, the new state of the system is 2 ETH and 0.5 DAI. Since the trader knows the “old” and “new” state, the trader infers that the user deposited 1 ETH and removed 0.5 DAI. ## Enhanced Privacy and Fairness in Gaming As any blockchain gaming nerd knows, playing poker or similar games on-chain is infeasible, as playing cards can be seen by anyone by checking the chain’s state. Previous attempts to solve this challenge with ZK were largely unsuccessful since it’s unfeasible to implement a shared-privacy state with ZK.FHE allows computations over encrypted game state, keeping player state, actions and game outcomes private. Inco has curated [some nice examples](https://fhevm-explorers.notion.site/fhEVM-Novel-Use-Cases-c1e637b0ca5740afa7fe598407b7266f) of this in practice. In the future, game developers can leverage FHE to safeguard player data and ensure fair gameplay. ## Mitigating MEV FHE can also significantly improve “bad” MEV capture. Recently, privacy technologies have surfaced as a potential solution for MEV with [Flashbots](https://writings.flashbots.net/suave-tee-coprocessor) and [Hashcloack](https://collective.flashbots.net/t/frp-10-distributed-blockbuilding-networks-via-secure-knapsack-auctions/1955) presenting different implementations for it. If mempools and transaction data are private, it is harder for a searcher to sandwich and employ other MEV extraction techniques. While implementing an FHE solution doesn’t entirely solve the issue, it can reduce the attack vectors for MEV extraction. ## Future Possibilities Imagine sharing financial data with the government to automate tax returns, while maintaining complete privacy. Picture a fitness app aiding groundbreaking research without exposing personal details. Envision banks tackling fraud detection while safeguarding sensitive information. These scenarios aren't just speculative—they're well within reach thanks to advancements to PETs and web3 technologies. PETs, paired with web3 tech, are indispensable, unleashing innovation while safeguarding privacy and ensuring data security. Together, they pave a way for a future where privacy, security, and self-sovereignty are the norm, transforming our digital landscape.

A New Paradigm in Privacy: Homomorphic Encryption - Part 2