Source: Zuo Ye Wai Bo Mountain
The development trajectory of cryptocurrencies is exceptionally clear, with Bitcoin creating cryptocurrency, Ethereum creating public chains, Tether creating stablecoins, and BitMEX creating perpetual contracts. These four creations, like cryptographic primitives, have built a trillion-dollar market, countless stories of sudden wealth, or the decentralized dreams that people always remember.
However, the development trajectory of cryptographic technologies is not as clear. Various consensus algorithms and intricate designs are no match for staking and multi-signature systems, which are the true pillars that keep the cryptographic systems running. For example, without decentralized staking, most BTC L2s would not exist. Babylon’s native staking is an exploration in this direction, valued at $70 million.
In this article, I attempt to outline a history of cryptographic technology development, distinct from the various technological transitions in the cryptocurrency industry. For example, the relationship between FHE, ZK, and MPC. In a rough application process, MPC is used at the beginning, FHE can be used for intermediate calculations, and ZK can provide final proof. In terms of application timing, ZK was the first to be implemented, followed by the popularization of AA wallets, and the emphasis on MPC as a technical solution. However, FHE, despite being mentioned in 2020, only gained traction in 2024.
Unlike ZK and MPC, FHE is different from all current cryptographic algorithms. While other encryption technologies aim to create “difficult or impossible to crack” systems for absolute security, FHE’s goal is to make encrypted ciphertext useful. Encryption and decryption are essential, but the content before decryption should not be wasted.
Theoretical readiness: Web2 precedes Web3 implementation
FHE is a foundational technology that has already undergone academic exploration. Web2 giants like Microsoft, Intel, IBM, and DARPA have supported Duality in its hardware and software adaptations and development tools preparation.
A piece of good news is that Web2 giants do not yet know how to use FHE. Starting Web3 applications are not too late. However, the bad news is that Web3’s compatibility with FHE is close to zero. Mainstream cryptocurrencies like Bitcoin and Ethereum cannot natively support FHE algorithms. Even though Ethereum is a world computer, implementing FHE might be a challenge.
We primarily focus on Web3 exploration. It is essential to remember that Web2 giants are very interested in FHE, and they have done a lot of groundwork.
This is because Vitalik’s focus has been on ZK from 2020 to 2024.
I will briefly explain the reasons for ZK’s popularity. After Ethereum established the Rollup scalability route, ZK’s state compression function significantly reduces the data size transmitted from L2 to L1. This has significant economic value. However, challenges such as L2 fragmentation, sorting issues, and some L2/Rollup fee harvesting problems must be addressed through continuous development.
To summarize, Ethereum needs to scale, establishing a Layer 2 development path. ZK/OP-based Rollup solutions compete, forming an industry consensus of short-term OP and long-term ZK. This has led to the emergence of four major players: ARB/OP/zkSync/SatrkNet.
The economic viability is the crucial reason why ZK has been accepted by the encrypted world, especially the Ethereum ecosystem. Therefore, the discussion on FHE’s technical features will not be redundant. The focus is on how FHE can improve Web3’s operational efficiency or reduce its operational costs. Cost reduction and efficiency improvement are essential aspects to consider.
A Brief History of FHE Development and Achievements
First, let’s differentiate between homomorphic encryption and fully homomorphic encryption. Strictly speaking, fully homomorphic encryption is a special case of homomorphic encryption. Homomorphic encryption means that “addition or multiplication operations on ciphertext are equivalent to addition or multiplication operations on plaintext.” In this scenario, c and E(c), d and E(d) can be considered equivalent values. However, there are two challenges to note:
1. The equivalence between plaintext and ciphertext involves adding some noise to the plaintext before performing operations to obtain the ciphertext. If the deviation caused by the ciphertext is too significant, it may lead to calculation failure. Therefore, controlling noise through various algorithms is critical.
2. The costs of addition and multiplication are enormous. Ciphertext calculations may be 10,000 to 100,000 times larger than plaintext calculations. Fully homomorphic encryption allows an infinite number of additions and multiplications on ciphertext to be considered fully homomorphic encryption. Various types of homomorphic encryption have unique values in their respective fields, and based on the degree of implementation, they can be categorized as follows:
– Partially homomorphic encryption: Only allows limited operations on encrypted data, such as addition or multiplication.
– Somewhat homomorphic encryption: Allows a limited number of addition and multiplication operations.
– Fully homomorphic encryption: Allows an infinite number of addition and multiplication operations to perform any computation 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 multidimensional space that satisfy specific linear relationships. In Gentry’s scheme, ideal lattices are used to represent keys and encrypted data, allowing encrypted data to remain private and using bootstrapping to reduce noise. Bootstrapping can be understood as “tying one’s shoelaces tightly and flipping oneself over.” In practice, it involves encrypting the FHE ciphertext again to reduce noise and maintain confidentiality, supporting complex computational operations.
This algorithm was a milestone for FHE, proving its feasibility in engineering. However, the costs were enormous, taking up to thirty minutes to compute a single step, making practical application unlikely. From zero to one problem-solving, the remaining challenge is massive practical application, which involves designing algorithms based on different mathematical assumptions. Besides ideal lattices, security assumptions such as LWE (Learning with Error) and its variants are commonly used.
In 2012, Zvika Brakerski, Craig Gentry, and Vinod Vaikuntanathan proposed the BGV scheme, one of the second-generation FHE schemes. Its most significant contribution is the modulus conversion technique, effectively controlling the increase in noise from homomorphic operations and constructing Leveled FHE, allowing homomorphic computation tasks of a given computational depth to be achieved. Similar schemes include BFV and CKKS, with CKKS supporting floating-point operations, but further enhancing computational resource consumption, still requiring better solutions.
Finally, there are the TFHE and FHEW schemes, especially the TFHE scheme, which is Zama’s preferred algorithm. To briefly introduce it, FHE’s noise issue can be reduced through bootstrapping, as first used by Gentry. TFHE can efficiently perform bootstrapping, ensuring precision and providing good integration points with the blockchain domain.
The differentiation between these schemes stops here. In reality, their differences lie in the scenarios they are applied to, requiring robust software and hardware support. Even the TFHE scheme requires solving hardware issues for large-scale application. Following the ZK domain’s path of “algorithm and software first, hardware and modularization following” might not be feasible. FHE must develop synchronously with hardware from the beginning, at least in the encryption field.
Web2 OpenFHE vs. Web3 Zama
As mentioned earlier, Web2 giants are exploring and have made some practical progress. Here, we summarize their contributions and introduce Web3 application scenarios.
In a nutshell, IBM contributed the Helib library, mainly supporting BGV and CKKS, while Microsoft’s SEAL library mainly supports CKKS and BFV schemes. It is worth mentioning that Song Yongsoo, one of the authors of CKKS, participated in the design and development of SEAL. OpenFHE is the most comprehensive, developed by Duality supported by DARPA, currently supporting mainstream algorithms like BGV, BFV, CKKS, TFHE, and FHEW, making it the most comprehensive FHE library in the market.
OpenFHE has explored partnerships with Intel’s CPU acceleration libraries and called Nvidia’s CUDA interface to support GPU acceleration. However, CUDA’s support for FHE has not been updated since 2018, and if there are any inaccuracies, please correct them. OpenFHE supports two languages, C++ and Python, with Rust API currently in development, aiming to provide simple, comprehensive modularization and cross-platform capabilities. For Web2 developers, this is the simplest plug-and-play solution.
For Web3 developers, the challenge is more significant. Due to limited processing power, most public blockchains cannot support FHE algorithm execution. Secondly, the Bitcoin and Ethereum ecosystems currently lack “economic demand” for FHE. It is essential to emphasize that economic demands for efficient data transfer from L2 to L1 have sparked the implementation of ZK algorithms, rather than implementing FHE for the sake of it. This forced matching would only increase implementation costs.
FHE+EVM Working Principle
Subsequent sections will detail the challenges encountered and potential implementation scenarios. Here, we aim to provide Web3 developers with some confidence.
In 2024, Zama secured the largest financing deal in the cryptographic field involving FHE concepts, led by Multicoin with $73 million. Zama mainly relies on the TFHE algorithm library and supports the development of an EVM with FHE capabilities, known as fhEVM.
This rewrite aims to capture the essence of the original article while presenting it in a more creative and fluent manner.Title: The Future of FHE in the Blockchain World
Compatibility Chain
One of the issues to address is efficiency, which can only be solved through the collaboration of software and hardware. For example, the EVM cannot directly run FHE contracts, which is not in conflict with Zama’s fhEVM solution. Zama has built its own chain, which can natively incorporate FHE functionality, such as Shiba Inu also planning to build a Layer 3 based on the Zama solution. Creating a new chain that supports FHE is not difficult, but the challenge lies in how the Ethereum EVM can deploy FHE contracts itself, requiring Ethereum’s Opcode support. The good news is that Fair Math and OpenFHE have jointly organized the FHERMA competition to encourage developers to rewrite the EVM’s Opcode, thus actively exploring the possibilities of integration.
Another aspect is hardware acceleration. Even if high-performance public chains like Solana natively support FHE contract deployment, it can still strain their nodes. Native FHE hardware primarily includes Chain Reaction’s 3PUTM (Privacy Protection Processing Unit), an ASIC solution. Additionally, Zama and Inco are also exploring the possibility of hardware acceleration. For example, Zama’s current TPS is around 5, while Inco can achieve 10 TPS. Inco believes that using FPGA hardware acceleration can increase TPS to around 100-1000.
However, there is no need to overly worry about speed issues. Existing ZK hardware acceleration solutions can theoretically be modified to adapt to FHE solutions. Therefore, the discussion below will not excessively focus on speed issues but rather on finding scenarios and solutions for EVM compatibility.
In conclusion, the future looks promising for FHE X Crypto.
Multicoin boldly stated when leading Zama that ZKP is a thing of the past, and the future belongs to FHE. Whether this prediction will come true remains to be seen. After Zama, Inco Network and Fhenix formed an invisible alliance within the fhEVM ecosystem, each with its own focus but a shared goal of integrating FHE and EVM ecosystems.
It is better to be lucky than to be early. Let’s start with a reality check.
Perhaps 2024 will be the year of FHE, but Elusiv, which started in 2022, has already ceased operations. Elusiv was originally the “dark pool” protocol on Solana, but now its codebase and documentation have been deleted.
Regarding FHE, it is essential to recognize that simply assuming that FHE will enhance privacy and therefore have economic value is inaccurate. Based on past practices, Web3 or on-chain users are not overly concerned about privacy. Privacy tools are only used when they provide economic value. For example, hackers may use Tornado Cash to conceal stolen funds, while regular users may use Uniswap because using Tornado Cash requires additional time or economic costs.
The encryption cost of FHE further burdens the already fragile operational efficiency of the blockchain. Privacy will only have the potential for widespread adoption when the increased costs lead to significant benefits. For example, in June 2023, China International issued “blockchain digital structured notes” to Asia-Pacific clients through Credit Suisse in Hong Kong, with the transaction reportedly conducted on Ethereum. However, the contract address and distribution address for this transaction cannot be found. If anyone can locate this information, please provide it.
This example illustrates the importance of FHE. For institutional clients who have a need to use public chains like blockchain but do not want to disclose all their information publicly, FHE’s encrypted display and ability to conduct transactions directly make it more suitable than ZKP.
However, for individual retail investors, FHE is still a distant foundational infrastructure. While it has potential use cases such as combating MEV, enabling privacy transactions, creating a more secure network, and preventing third-party snooping, these are not immediate priorities. Additionally, using FHE currently slows down the network, so it is safe to say that FHE’s time in the spotlight has not yet arrived.
Ultimately, privacy is a lukewarm demand. As a public service, few people are willing to pay a premium for privacy. We need to find scenarios where the computational properties of FHE-encrypted data can save costs or improve transaction efficiency, thereby creating market-driven momentum. For example, there are many solutions to combat MEV, and centralized nodes can actually address this issue; FHE alone may not directly address the pain points of these scenarios.
Another issue is the problem of computational efficiency. While it may seem like a technical problem that requires hardware acceleration or algorithm optimization, fundamentally, there is not enough market demand. Projects lack the drive to invest in computational efficiency, which ultimately relies on market incentives. Taking ZK as an example, under robust market demand, SNARK and STARK routes compete, and various ZK Rollup solutions are actively developed, pushing the boundaries of programming languages and compatibility. The development of ZK is accelerated by hot money.
The applications and implementation of FHE will be the breakthrough for it to become a foundational infrastructure in the blockchain world. If this step cannot be taken, FHE will never gain a foothold in the encryption industry, and major projects will only be able to dabble in their own little corners for amusement.
Through the practices of Zama and its friends, it is clear that Ethereum’s current inability to support FHE functionality natively requires exploration at the contract level to distribute FHE capabilities across various EVM-compatible chains. Currently, there is no solution that fully meets this standard.
Unlike ZK, which only introduced one-click chain issuance and hardware acceleration in its later stages, FHE stands on the shoulders of the ZK giant. While launching a new FHE chain may be the easiest part, bridging the gap between FHE and Ethereum is the real challenge.
Self-reflection is essential in the blockchain world when seeking the future coordinates of FHE:
Which scenarios require encryption and cannot use plaintext?
In which scenarios is FHE encryption necessary and other encryption methods are not suitable?
In which scenarios do users feel good about using FHE encryption and are willing to pay higher fees?
To be continued. I will continue to keep an eye on FHE!
In conclusion, FHE is still searching for its place in the blockchain world. We can categorize the approaches based on their association with Ethereum into three types:
Type 1: Independent Kingdom, Communicating with Ethereum. Represented by Zama/Fhenix/Inco Network, these projects focus on providing foundational development tools and encourage building FHE L1/L2 chains, suitable for specific niche areas.
Type 2: Integrating with Ethereum. Represented by Fair Math/Mind Network, while maintaining some independence, these projects aim for deeper integration with Ethereum.
Type 3: Transforming Ethereum. If Ethereum cannot natively support FHE functionality, exploration at the contract layer is essential to disperse FHE features across EVM-compatible chains. Currently, there is no solution that fully meets this standard.
While ZK development progressed to include one-click chain issuance and practical hardware acceleration in its later stages, FHE is standing on the shoulders of the ZK giant. While launching a new FHE chain may be the easiest part, bridging the gap between FHE and Ethereum is the real challenge.
Daily self-reflection is crucial to finding the future of FHE in the blockchain world. By exploring the necessity of encryption, the suitability of FHE encryption in various scenarios, and the user acceptance of FHE encryption, we can pave the way for the integration of FHE into the blockchain ecosystem.
Various Approaches:
The journey ahead for FHE is still full of uncertainties. Based on their degree of association with Ethereum, FHE approaches can be classified into three types:
Type 1: Independent Kingdom, Communicating with Ethereum. Projects like Zama/Fhenix/Inco Network focus on providing development tools and building FHE L1/L2 chains, suitable for specific niche areas.
Type 2: Integrating with Ethereum. Projects like Fair Math/Mind Network aim for deeper integration with Ethereum while retaining some independence.
Type 3: Transforming Ethereum. Projects exploring the distribution of FHE features across EVM-compatible chains in the absence of native FHE support from Ethereum belong to this category.
