TLDR:

• FHE vs. ZKP:Fully Homomorphic Encryption (FHE) offers a more flexible solution than ZKPs for blockchain, enabling private data validation. Their combination could transform confidential decentralized finance (DeFi).

• Challenges in FHE Implementation: Implementing FHE on blockchain involves overcoming hurdles like developing advanced FHE schemes, creating user-friendly libraries and compilers, establishing secure threshold decryption, optimizing data availability, and enhancing hardware.

• Choosing FHE Schemes and Libraries: For effective FHE use, developers must select appropriate schemes and libraries, considering the trade-offs between computational efficiency and accuracy. New Web3 FHE libraries and compilers aid immensely.

• Advances in Secure Threshold Decryption: Key to FHE’s success is secure decryption, with emerging solutions including N/2 threshold decryption and hardware-based security enhancements.

Introduction
Fully Homomorphic Encryption (FHE) is one of the most promising areas of blockchain research, enabling data to be proven as valid without revealing any of the underlying data details.

While zero-knowledge proofs (ZKPs) have gained widespread attention as of late, and are great for certain use cases, they are insufficient for the creation of confidential computing blockchain applications. FHE has many advantages over ZK technology and use cases could include a private Uniswap, trustless gaming applications, private payments, and much more which we’ve covered elsewhere.

It turns out that combining both ZKPs and FHE could create a fully generalizable, confidential system. ZKPs can prove the integrity of data and computation, while FHE can process arbitrary computations over encrypted data that remains secure throughout its entire journey.

This will fundamentally shift the blockchain landscape, but both are emerging technologies and FHE currently faces 5 major challenges.

1. Nascent FHE Schemes, Libraries, and Compilers: a need for technological advancements and a computing paradigm shift.
2. Secure Threshold Decryption
3. ZKPs for User Inputs + Computing party
4. Data Availability Optimization: the need for a secure, performant, and cost-efficient DA layer for FHE.
5. FHE Hardware: optimized software/hardware and FHE accelerator advancements.

This is a 2-part series that will illustrate the rapid steps being taken to address each of these challenges so that FHE can be easily implemented into the developer workflow.

Challenge 1: Nascent FHE Schemes, Libraries and Compilers

First, let’s look at each term in turn:

1. Schemes: standardized and systematic approaches that help developers manage data or code to efficiently solve problems. This could include architectural designs, patterns, and best practices.
2. Libraries: collections of pre-written code that programmers can use to efficiently perform common tasks or access specific functionalities.
3. Compilers: these translate high-level programming languages into low-level machine code that can be easily executed on a blockchain platform.  Developers require a fully functional FHE compiler that handles complexities on their behalf, such as parameter selection.

Various challenges exist. For instance, existing FHE schemes (particularly TFHE) are around 1000x slower compared to plain computation. Developers need easy-to-use front-end libraries that abstract away the low-level FHE complexities, and a fully functional FHE compiler that handles complexities on their behalf.

We’ll cover the challenges associated with each, before showcasing how the appropriate solution is nearly here.

FHE Schemes

To begin implementing FHE into one’s application, the appropriate scheme must be chosen, which can be summarized in the table below.

While not all terms may be familiar to the reader, they may be worth further exploration if of interest.

Each of the above has inherent trade-offs, such as BGV/BFV being ideal for DeFi, but requiring knowledge of a circuit’s depth in advance. While FHEW/TFHE could also be used in DeFi, BGV/BFV are considered more efficient due to batching operations whereby multiple computations are batched together.

Developers must choose their scheme very carefully as it will impact other design decisions and future application performance, though for blockchain purposes, Exact Arithmetic tends to be most beneficial.

FHE Libraries

Depending on the chosen scheme, there are different libraries available to aid in the front-end programming experience.

Each scheme has a different relationship with each library, and the developer must also set parameters for their choices.

Another challenge for developers is that writing FHE programs requires a mental shift. For instance, one cannot write a branch (if-else) depending on a variable in the program, because programs cannot directly compare the variables like plain data. They also cannot write loops in their code for the same reason.

Solution: Web3 FHE Libraries & Compilers

Both FHE libraries and compilers have already been developed by leading technology firms such as Google and Microsoft, but primarily use the CKKS scheme which is focused on Machine Learning. These cannot adequately support ZKP schemes nor the intricacies of program chaining, which involves the sequential connection of multiple computer programs or software modules. Instead, DeFi-specific schemes such as BFV/BGV are needed. Fortunately, these Web3 FHE libraries and compilers now exist and are addressing all of the above challenges.

1. FHE Libraries

Zama’s open source TFHE-rs (Fully Homomorphic Encryption over the Torus) library enables the creation of FHE-based smart contracts in Solidity for Zama’s fhEVM. Additionally, there are ongoing developments in the TFHE ecosystem, with libraries like TFHE Rust and TFHE C++ (though the latter is still in the process of being fully developed).

2. FHE Compilers

Sunscreen FHE Compiler is a recently emerged Web3 compiler designed for DeFi use cases, allowing developers to program in Rust. It relies on Microsoft’s SEAL library and utilizes the BFV scheme.  Sunscreen simplifies the complexities mentioned earlier by offering features such as automatic parameter selection, circuit setup, data encoding, key selection, and more. Notably, it has demonstrated high performance among FHE compilers.

Moreover, the ongoing development of other FHE compilers signals positive advancements in this field, with the expectation of continued optimizations in the future.

Challenge 2: Secure Threshold Decryption

Given that FHE provides the computation of encrypted data, there’s a need to have a secure encryption and decryption key for the data to start its journey or arrive at its destination.

Therefore, there’s a need for an extremely secure and yet efficient threshold decryption protocol. This refers to a protocol or mechanism used to collectively decrypt data in a secure and distributed manner. It ensures that multiple parties must cooperate to decrypt information, making it difficult for any single entity to corrupt the process.

Currently, there are two bottlenecks here:
1. Overhead: FHE-based computation is complex and therefore requires high-performance nodes, which reduces the potential number of eligible nodes.
2. Latency: While more nodes improve decentralization, this also increases latency.

We therefore require a decryption technique that a) minimizes the chances of collusion (given that we may have a smaller set of nodes), b) is permissionless for new nodes, and c) is low-latency.

Solution: Threshold Decryption or Dynamic MPC

We see a few potential threshold decryption solutions:
1. N/2 threshold decryption: this means that more than half of the participants must cooperate in the decryption process, making it harder for malicious actors to collude.
2. Hardware Security Module (HSM) threshold decryption: these are specialized devices designed to protect cryptographic keys and perform secure operations, which adds an extra layer of security.
3. Trusted Execution Environment (TEE) threshold decryption: a secure environment for executing code involving sensitive data.

Alternatively, we could use Multiparty Computation (MPC), the common wallet security technique. An example of a possible technique that could be used for FHE is a variation of a traditional MPC implementation known as the 2PC-MPC algorithm. It requires all validators to participate, with 2/3 of validators (plus the user) required to generate a signature. One potential trade-off is that MPC may be more computationally complex and with more participants, which affects latency. This is an area of on-going research and may improve over time.

In summary, both threshold decryption and MPC variations such as the 2PC-MPC algorithm are being rapidly developed and show great promise for on-chain FHE.

Conclusion

The above covered two significant challenges currently hindering the implementation of on-chain FHE: lackluster FHE schemes, libraries, and compilers, as well as the need for secure, high-speed, and permissionless decryption techniques.

FHE libraries are required for developers to access pre-written code needed in their workflow. Various FHE libraries have been developed, such as Zama’s TFHE which enables programming in the fhEVM language.

FHE compilers are also required or turning high-level programming languages into low-level machine code required for on-chain FHE. The Sunscreen FHE Compiler is the leader thus far, but many others are also being developed, rapidly enhancing the developer experience

Last of all, secure threshold decryption is required in a highly secure, low-latency, and permissionless manner. Various possible threshold architectures exist, while MPC is also possible. The 2PC-MPC algorithm is one such MPC implementation that appears to satisfy all necessary requirements.

This concludes the first part of the article. There are still three more challenges that we will cover in part 2:
1. ZKPs for Correct Computations: FHE requires ZKPs that verify correct node behavior
2. Data Availability Optimization: Encrypted FHE data is stored in ciphertext format, which is much more efficiently stored by an FHE-compatible data availability layer.
3. FHE Hardware: FHE requires significant computational overhead. Optimized hardware and software, and FHE accelerators can both address this.

Visit our website to learn more, and stay connected with us via both Twitter and Discord.