FHE is the next step for ZK, a new chapter in cryptographic technology
The application scenarios and implementation are the breakthrough points for FHE to become the infrastructure of blockchain.Author: Zuo Ye
The development trajectory of cryptocurrency is exceptionally clear: Bitcoin created cryptocurrency, Ethereum created public chains, Tether created stablecoins, and BitMEX created perpetual contracts. These four creations serve as cryptographic primitives that build a trillion-dollar market, countless myths of sudden wealth, or the ever-remembered dream of decentralization.
However, the development trajectory of cryptographic technology is not as clear. Various consensus algorithms and intricate designs cannot compete with staking and multi-signature systems, which are the true pillars that maintain the operation of cryptographic systems. For example, after removing the decentralized staking of WBTC, most BTC L2s cannot exist. Babylon's native staking is an exploration in this direction, a $70 million exploration.
I attempt to outline a history of the development of cryptographic technology in this article, distinct from the various technological changes in the crypto industry, such as the relationship between FHE, ZK, and MPC. From a rough application process, MPC is used at the beginning, FHE can be used in the middle computation process, and ZK can ultimately prove. In terms of application timeline, ZK landed first, followed by the boom of the AA wallet concept, and MPC gained attention as a technical solution, accelerating its development. Only FHE, which was already prophesied by the gods in 2020, has only slightly caught fire in 2024.
MPC/FHE/ZKP
Unlike ZK and MPC, FHE is even different from all current cryptographic algorithms. Except for FHE, any symmetric or asymmetric encryption technology attempts to create a "hard-to-crack or uncrackable encryption system" to achieve absolute security. However, FHE's goal is to make the encrypted ciphertext functional; that is, encryption and decryption are important, but the content after encryption and before decryption should not be wasted.
Theoretical Completeness: Web2 Lands Before Web3
FHE is a foundational technology, and its theoretical exploration has been completed academically. Web2 giants have contributed significantly; for example, Microsoft's, Intel's, IBM's, and DARPA's supported Duality have prepared for software and hardware adaptation and development tools.
The good news is that the Web2 giants do not know what to do with FHE. Starting Web3 now is not too late. The bad news is that the adaptation of Web3 is approximately zero; mainstream Bitcoin and Ethereum cannot natively support FHE algorithms. Although Ethereum is a world computer, calculating FHE might take until the end of the world.
We mainly focus on the exploration of Web3, and it is essential to remember that Web2 giants are very enthusiastic about FHE and have already done a lot of foundational work.
This is because Vitalik has focused on ZK from 2020 to 2024.
Here, I would like to briefly explain my attribution for the explosive popularity of ZK. After Ethereum established the Rollup scaling route, the state compression function of ZK can significantly reduce the size of data transmitted from L2 to L1, which has enormous economic value. Of course, this is only theoretical; issues such as L2 fragmentation and sequencer problems, as well as the user fee harvesting problem of some L2/Rollup, are all new problems in development that can only be solved through continued development.
In summary, Ethereum needs to scale, establishing a Layer 2 development route, with ZK/OP series Rollups competing, forming a short-term OP and long-term ZK industry consensus, shaping the four giants: ARB/OP/zkSync/SatrkNet.
The economic nature is an important reason why ZK can be accepted by the crypto world, especially within the Ethereum system, even the only reason. Therefore, the upcoming characteristics of FHE technology will not be elaborated; the focus is on examining how FHE can improve the operational efficiency of Web3 or reduce the operational costs of Web3. Cost reduction and efficiency increase must occupy one of these aspects.
A Brief History and Achievements of FHE Development
First, it is essential to distinguish between homomorphic encryption and fully homomorphic encryption. Strictly speaking, fully homomorphic encryption is a special case of the former. Homomorphic encryption means "performing addition or multiplication calculations on ciphertext is equivalent to performing addition or multiplication calculations on plaintext," that is:
At this point, c and E(c), d and E(d) can be considered equivalent in value. However, it is essential to note two difficulties here:
The equality of plaintext and ciphertext actually means that the plaintext undergoes operations after adding some noise to obtain the ciphertext. If the deviation caused by the ciphertext is too large, it will lead to calculation failure. Therefore, controlling noise through various algorithms is key.
The overhead of addition and multiplication is enormous; ciphertext calculations may be more than 10,000 to 1,000,000 times that of plaintext calculations. Only by simultaneously achieving unlimited addition and multiplication calculations on ciphertext can it be called fully homomorphic encryption. Of course, various homomorphic encryptions have their unique value in their respective fields. Based on the degree of implementation, they can be classified as follows:
Partially Homomorphic Encryption: Only allows a limited set of operations on encrypted data, such as addition or multiplication. Somewhat Homomorphic Encryption: Allows a limited number of addition and multiplication operations.
Fully Homomorphic Encryption (FHE): Allows unlimited addition and multiplication operations, enabling arbitrary calculations on encrypted data.
The development history of fully homomorphic encryption (FHE) can be traced back to 2009 when Craig Gentry first proposed a fully homomorphic algorithm based on ideal lattices. Ideal lattices are a mathematical structure that allows users to define a set of points in a multidimensional space, where these points satisfy specific linear relationships.
In Gentry's scheme, ideal lattices are used to represent keys and encrypted data, allowing encrypted data to maintain privacy while using bootstrapping to reduce noise. Bootstrapping can be understood as "pulling one's own shoelaces tightly and flipping oneself over." In practice, this is achieved by adding another layer of encryption to the FHE-encrypted ciphertext to reduce noise while maintaining confidentiality, thus supporting complex computational operations.
(Bootstrapping is a crucial technological advancement for the practical application of FHE, but the mathematical knowledge will not be elaborated further.)
This algorithm is a milestone for FHE, as it was the first to prove the feasibility of FHE in engineering, but the overhead is enormous, taking even thirty minutes to compute a single step, making practical application nearly impossible.
After solving the problem from 0 to 1, the remaining task is large-scale practical application, which can also be understood as designing corresponding algorithms based on different mathematical assumptions. Besides ideal lattices, other security assumptions include LWE (Learning with Error) and its variants, which are currently the most common solutions.
In 2012, Zvika Brakerski, Craig Gentry, and Vinod Vaikuntanathan proposed the BGV scheme, which is one of the second-generation FHE schemes. Its most significant contribution is the modulus switching technique, which effectively controls the noise increase caused by homomorphic operations, thus constructing Leveled FHE, which can perform homomorphic computation tasks for a given computation depth.
Similar schemes include BFV and CKKS, especially the CKKS scheme, which can support floating-point operations but further increases the consumption of computational resources, still requiring better solutions.
Finally, there are the TFHE and FHEW schemes, particularly the TFHE scheme, which is Zama's preferred algorithm. We will briefly introduce it; in simple terms, the noise problem of FHE can be reduced through the bootstrapping first applied by Gentry, while TFHE can achieve efficient bootstrapping with guaranteed precision, thus having a good integration point with the blockchain field.
We will stop at this point in introducing each scheme; in reality, their differences are not a matter of superiority but rather different scenarios. However, they all require powerful software and hardware resource support. Even the TFHE scheme needs to solve hardware issues for large-scale application, making it nearly impossible to follow the path of "algorithms and software leading, hardware and modularization following" as seen in the ZK field. From the beginning, FHE must develop in sync with hardware, at least in the field of encryption.
Web 2 OpenFHE vs Web3 Zama
As mentioned earlier, Web2 giants are exploring and have formed some practical results. Here, we summarize them and introduce Web3 application scenarios.
To simplify, IBM contributed the Helib library, mainly supporting BGV and CKKS, while Microsoft's SEAL library primarily supports CKKS and BFV schemes. Notably, one of the authors of CKKS, Song Yongsoo, participated in the design and development of SEAL. OpenFHE is the most comprehensive, developed by DARPA-supported Duality, currently supporting mainstream algorithms such as BGV, BFV, CKKS, TFHE, and FHEW, making it the most complete FHE library available in the market.
Moreover, OpenFHE has explored collaboration with Intel's CPU acceleration library and called NVIDIA's CUDA interface to support GPU acceleration. However, CUDA's recent support for FHE has remained at 2018, and no updated support has been found. If there are any inaccuracies, please correct them.
OpenFHE supports both C++ and Python, with a Rust API in development, and is committed to providing simple, comprehensive modular and cross-platform capabilities. For Web2 developers, this is the simplest out-of-the-box solution.
For Web3 developers, it becomes more challenging.
Due to limited computational capabilities, most public chains cannot support the execution of FHE algorithms. Secondly, the Bitcoin and Ethereum ecosystems currently lack an "economic demand" for FHE. It is emphasized again that the demand for efficient data transmission from L2 to L1 stimulated the landing of ZK algorithms, and FHE cannot be pursued for its own sake; forcing a match with a hammer will only increase the landing costs.
FHE+EVM Working Principle
The following sections will detail the difficulties currently encountered and possible landing scenarios, primarily to give Web3 developers some confidence.
In 2024, Zama secured the largest funding in the crypto field related to the FHE concept, with $73 million led by Multicoin. Zama currently primarily has a TFHE algorithm library and supports the development of EVM-compatible chains with FHE functionality through fhEVM.
Next is the efficiency issue, which can only be solved through software and hardware collaboration. One is that EVM cannot directly run FHE contracts, which does not conflict with Zama's fhEVM scheme. Zama has built its own chain that can directly incorporate FHE functionality natively. For example, Shiba Inu also plans to build a Layer 3 based on the Zama scheme. Creating a new chain that supports FHE is not difficult; the challenge lies in how Ethereum's EVM itself can possess FHE contract deployment capabilities, which requires support from Ethereum's Opcode. The good news is that Fair Math and OpenFHE jointly held the FHERMA competition to encourage developers to rewrite EVM's Opcode, actively exploring the possibility of integration.
Another issue is hardware acceleration. It can be said that even if high-performance public chains like Solana natively support FHE contract deployment, it will still drag down their nodes. Native FHE hardware mainly includes Chain Reaction's 3PU™ (Privacy Processing Unit), which is an ASIC solution. Additionally, Zama or Inco are also exploring the possibility of hardware acceleration. For instance, Zama's current TPS is around 5, while Inco can achieve 10 TPS. Inco believes that using FPGA hardware acceleration can boost TPS to around 100-1000.
However, there is no need to worry too much about speed issues. Existing ZK hardware acceleration solutions can theoretically be modified to adapt to FHE schemes. Therefore, the following discussions will not overly design speed issues but will primarily focus on finding scenarios and solving EVM compatibility adaptation.
Dark Pool's Demise, FHE X Crypto's Future is Promising
When Multicoin led Zama's funding, they boldly claimed that ZKP is the past, and the future belongs to FHE. Whether this future will come true is always challenging. After Zama, Inco Network and Fhenix formed the fhEVM ecological invisible alliance, each focusing on different aspects but generally aligned in their commitment to integrating FHE and the EVM ecosystem.
It's better to be timely than early; let's start with a cold splash of water.
2024 may be a big year for FHE, while Elusiv, which started in 2022, has already ceased operations. Elusiv was initially a "dark pool" protocol on Solana, and now its codebase and documentation have been deleted.
Ultimately, FHE, as a component of technology, still needs to be used alongside technologies like MPC and ZKP. What we need to examine is how FHE can change the current paradigm of blockchain.
First, it must be acknowledged that simply believing that FHE will enhance privacy and thus possess economic value is inaccurate. From past practices, Web3 or on-chain users do not care much about privacy; they will only use related tools when privacy can provide economic value. For example, hackers use Tornado Cash to hide stolen funds, while ordinary users only use Uniswap because using Tornado Cash incurs additional time or economic costs.
The encryption cost of FHE itself further exacerbates the already weak operational efficiency on-chain. Only when this increased cost brings more significant benefits can the protection of privacy have the potential for large-scale promotion. For instance, in the direction of RWA, bond issuance and trading, in June 2023, China International issued "blockchain digital structured notes" to clients in the Asia-Pacific region through UBS, indicating in UBS's press release that it was conducted via Ethereum. However, mysteriously, the contract address and distribution address for this transaction cannot be found. If anyone can locate it, please supplement the relevant information.
This example can explicitly illustrate the importance of FHE. For institutional clients, they have a demand for using public chains like blockchain but do not want to disclose all information. Therefore, FHE's characteristic of displaying ciphertext and allowing direct buying and selling operations is more suitable than ZKP.
For individual retail investors, FHE is still a relatively distant underlying infrastructure. I can list several directions, such as anti-MEV, privacy trading, a more secure network, and preventing third-party snooping, etc. However, clearly, these are not first-order needs, and currently using FHE does slow down the network. It is more accurate to say that the main character of FHE has not yet arrived.
Ultimately, privacy is a demand that is neither urgent nor painful. As a public service, very few people are willing to pay a premium for privacy. We need to find scenarios where the computable characteristics of data encrypted with FHE can save costs or improve transaction efficiency, thus generating spontaneous market momentum. For example, there are many solutions for anti-MEV; centralized nodes can actually solve this. FHE does not directly address the pain points of the scenario.
Another issue is the problem of computational efficiency. On the surface, this seems to require hardware acceleration or algorithm optimization, but fundamentally, it is a lack of significant market demand and the project party's lack of motivation to compete. Computational efficiency is ultimately driven by competition. Taking ZK as an example, under the thriving market demand, the SNARK and STARK routes compete fiercely, and various ZK Rollups are racing to improve programming languages and compatibility, with ZK's development advancing rapidly under the influence of hot money.
Application scenarios and landing are the breakthrough points for FHE to become a blockchain infrastructure. If this step cannot be taken, FHE will never gain traction in the crypto industry, and major projects will only be able to play around in their own little corners.
From the practice of Zama and its friends, a consensus is to build new chains outside of Ethereum and reuse technical components and standards like ERC-20, forming an FHE L1/L2 link to Ethereum's encryption scheme. The advantage of this scheme is that it can be piloted first, creating foundational components for FHE. The disadvantage is that if Ethereum itself does not support FHE algorithms, then off-chain solutions will always be in a relatively awkward position.
Zama itself also recognizes this issue. In addition to the aforementioned FHE-related libraries, it has also initiated the FHE.org organization and sponsored related conferences, hoping to convert more academic results into engineering applications.
Inco Network's development direction is a "general privacy computing layer," essentially a model of outsourced computing services. Based on Zama, it has built an FHE EVM L1 network. An interesting exploration is collaborating with the cross-chain messaging protocol Hyperlane, which can deploy game mechanics from another EVM-compatible chain on Inco. When the game runs and requires FHE computation, it can call Inco's computing capabilities through Hyperlane, then only return the results to the original chain.
To realize such scenarios envisioned by Inco, it is necessary for EVM-compatible chains to trust Inco's credibility, and Inco's computing capabilities must be strong enough. In the high concurrency and low latency demands of blockchain games, whether it can operate well poses considerable challenges.
From this, it can be inferred that certain zkVMs can also take on the role of FHE computing outsourcing providers. For example, RISC Zero already possesses this capability, and the next collision between ZK products and FHE may spark more fireworks.
Furthermore, some projects hope to get a little closer to Ethereum, at least moving towards becoming part of Ethereum. Inco can realize L1 using the Zama scheme, while Fhenix can achieve EVM L2 using the Zama scheme. It is still under development, and many directions seem to be in play. It is uncertain what the final product will be; perhaps it will be an L2 focused on FHE capabilities.
Additionally, there is the previously mentioned FHERMA competition. Readers who are proficient in Ethereum development can give it a try, helping FHE land while also earning a reward.
Moreover, there are two intriguing projects, Sunscreen and Mind Network. Sunscreen is primarily operated by a single individual, Ravital, and aims to create a compiler solution suitable for FHE using the BFV algorithm. However, it has been in testing and experimental stages for a long time and is still some time away from practical application.
Finally, Mind Network's approach mainly focuses on the integration of FHE with existing scenarios, such as re-staking, but how to implement it will require time for validation.
Lastly, to recap the beginning of this section, Elusiv has now been renamed Arcium and has secured new funding, transforming into a "parallel FHE" solution, which aims to improve FHE from the perspective of execution efficiency.
Conclusion
This article seems to discuss the theory and practice of FHE, but the underlying thread is to clarify the development history of cryptographic technology itself. This is not entirely equivalent to the technologies used in cryptocurrency. ZKP and FHE have many similarities, one of which is that both aim to maintain privacy design while keeping the blockchain's public characteristics. The ZKP privacy scheme focuses on reducing the economic costs of interactions between L2 and L1, while FHE is still searching for its best scenarios.
Classification of Various Schemes
The road ahead is long and arduous; FHE is still seeking answers. It can be categorized into three types based on its proximity to Ethereum:
Type 1: Independent Kingdom, Communicating with Ethereum. Represented by Zama/Fhenix/Inco Network, primarily providing development foundations and encouraging the establishment of FHE L1/L2, suitable for certain niche fields.
Type 2: Plugging In, Integrating with Ethereum. Represented by Fair Math/Mind Network, although retaining some independence, the overall idea is to achieve deeper integration with Ethereum.
Type 3: Mutual Passage, Transforming Ethereum. If Ethereum cannot natively support FHE functionality, then exploration is needed at the contract level to distribute FHE's functionality across various EVM-compatible chains. Currently, there are no solutions that fully meet this standard.
Unlike ZK, which saw the emergence of one-click chain deployment and hardware acceleration practicality only in its later stages, FHE stands on the shoulders of ZK giants. Now, launching an FHE chain may be the simplest task, but communicating its value with Ethereum is the most challenging.
Daily self-reflection is essential in seeking the future coordinates of FHE in the blockchain world:
What scenarios must be encrypted and cannot use plaintext?
What scenarios require FHE encryption and cannot use other encryption methods?
What scenarios will users feel good after using FHE encryption and be willing to pay a higher cost?
