Written by: Zuo Ye
The main line of the development of cryptocurrency is extremely clear. Bitcoin created cryptocurrency, Ethereum created the public chain, Tether created stablecoins, and BitMEX created perpetual contracts. These four creations are like cryptographic primitives that have built a trillion-dollar market, countless myths of getting rich quickly, or the dream of decentralization that is always remembered by people.
The development trajectory of encryption technology is not very clear. Various consensus algorithms and various sophisticated designs are no match for the staking and multi-signature systems, which are the real pillars for maintaining the operation of encryption systems. For example, after the decentralized staking of WBTC is removed, most BTC L2s will not exist. Babylon's native staking is an exploration in this direction, an exploration worth 70 million US dollars.
In this article, I try to outline the development history of a cryptographic technology, which is different from various technological change processes in the cryptographic 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 intermediate calculation process, and ZK can be used for the final proof. From the application time sequence, ZK was the first to land, and then the AA wallet concept became popular. MPC was valued as a technical solution and its development accelerated. Only FHE had been predicted by God in 2020, but it only became slightly popular in 2024.
MPC/FHE/ZKP
Unlike ZK and MPC, FHE is even different from all current encryption algorithms. Except for FHE, any symmetric or asymmetric encryption technology is trying to create a "cryptographic system that is not easy or impossible to crack" to achieve absolute security, but the goal of FHE is to make the encrypted ciphertext work, that is, encryption and decryption are important, but the content after encryption and before decryption should not be wasted.
Theory is complete, Web2 is implemented before Web3
FHE is a basic technology and has been explored theoretically in academia. Web2 giants have made great efforts. For example, Duality, supported by Microsoft, Intel, IBM and DARPA, has been preparing for software and hardware adaptation and development tools.
The good news is that the giants of Web2 don’t know what to do with FHE, so it’s not too late for Web3 to start now. The bad news is that the adaptation of Web3 is approximately equal to 0. The mainstream Bitcoin and Ethereum are not natively compatible with the FHE algorithm. Although Ethereum is the world’s computer, it may take until the end of the world to calculate FHE.
We mainly focus on the exploration of Web3. Just remember that Web2 giants are very enthusiastic about FHE and have done a lot of basic work.
This is because Vitalik’s focus from 2020 to 2024 will be on ZK.
Here I would like to briefly explain why I attribute ZK's popularity. After Ethereum established the expansion route of Rollup, ZK's state compression function can greatly reduce the size of data transmitted from L2 to L1, which has huge economic value. Of course, this is only theoretical. Problems such as L2 fragmentation and sorting, and even the problem of some L2/Rollup collecting user transaction fees, are all new problems in development and can only be solved by continued development.
To put it simply, Ethereum needs to expand its capacity, which has established the Layer 2 development route. ZK/OP Rollups are competing with each other, forming an industry consensus of short-term OP and long-term ZK, and shaping the four giants of ARB/OP/zkSync/SatrkNet.
Economic feasibility is an important reason, or even the only reason, for ZK to be accepted by the crypto world, especially the Ethereum system. Therefore, the following FHE technical features will not be elaborated. The focus is on examining the directions in which FHE can improve the operating efficiency of Web3, or reduce the operating costs of Web3. Cost reduction and efficiency increase must account for one of them.
A brief history of FHE development and achievements
First, we need to distinguish between homomorphic encryption and fully homomorphic encryption. Strictly speaking, fully homomorphic encryption is a special case of the former. Homomorphic encryption means that "addition or multiplication of ciphertext is equivalent to addition or multiplication of plaintext", that is:
At this point, c and E(c), d and E(d) can be considered equal in value, but please note that there are two difficulties here:
The equality of plaintext and ciphertext is actually the result of adding some noise to the plaintext and then performing calculations on it to obtain the ciphertext. If the deviation caused by the ciphertext is too large, the calculation will fail. Therefore, noise control is the key to various algorithms.
The cost of addition and multiplication is huge. The ciphertext calculation may be 10,000 to 1 million times that of the plaintext calculation. Only when the ciphertext calculation of addition and multiplication is realized infinitely can it be called fully homomorphic encryption. Of course, various types of homomorphic encryption also have their unique value in their respective fields. According to the different degrees of realization, they can be divided into the following categories:
Partially homomorphic encryption: Only a limited set of operations, such as addition or multiplication, are allowed on the encrypted data. Somewhat homomorphic encryption: A limited number of addition and multiplication operations are allowed.
Fully homomorphic encryption: allows an unlimited number of addition and multiplication operations, thereby enabling arbitrary computation on encrypted data.
The development of fully homomorphic encryption (FHE) can be traced back to 2009, when Craig Gentry first proposed a fully homomorphic algorithm based on an ideal lattice. An ideal lattice is a mathematical structure that allows users to define a set of points in a multidimensional space where these points satisfy a specific linear relationship.
In Gentry's scheme, ideal lattices are used to represent keys and encrypted data, so that the encrypted data can maintain privacy while using bootstrapping to reduce noise. Bootstrapping can be understood as "pulling your own shoelaces hard to turn yourself over." In practice, the FHE-encrypted ciphertext is encrypted again to reduce noise and maintain confidentiality, thereby supporting complex computing operations.
(Bootstrapping is a very important technological advancement for the practical application of FHE, but the mathematical knowledge will not be expanded)
This algorithm is a milestone in FHE. It proved the feasibility of FHE in engineering for the first time. However, it is very expensive and it may take 30 minutes to calculate one step. It has basically no possibility of practical application.
After solving the problem from 0 to 1, what remains is large-scale practical application, which can also be understood as designing corresponding algorithms based on different mathematical assumptions. In addition to the ideal grid, LWE (Learning with Error) and its variants are also used for security assumptions, which is also the most common solution at present.
In 2012, Zvika Brakerski, Craig Gentry and Vinod Vaikuntanathan proposed the BGV scheme, which is one of the second-generation FHE schemes. Its most important contribution is the analog-to-digital conversion technology, which effectively controls the increase in ciphertext noise caused by homomorphic operations, thereby constructing Leveled FHE, that is, such FHE can realize homomorphic computing tasks of a given computing depth.
There are similar solutions such as BFV and CKKS. In particular, the CKKS solution can support floating-point operations, but it will further increase the consumption of computing resources, and a better solution is still needed.
Finally, there are the TFHE and FHEW schemes, especially the TFHE scheme, which is Zama's preferred algorithm. We briefly introduce it. In short, the noise problem of FHE can be reduced by the bootstrapping first applied by Gentry, while TFHE can achieve efficient bootstrapping and has guaranteed accuracy, so it has a good combination with the blockchain field.
We have only briefly introduced each solution. In fact, the difference between them is not the difference between good and bad, but more about different scenarios. However, basically they all need strong support from software and hardware resources. Even the TFHE solution needs to solve the hardware problem before it can be applied on a large scale. It is basically impossible to follow the path of "algorithms and software first, hardware and modularization follow up" in the ZK field. That is, FHE must develop synchronously with hardware from the beginning, at least in the field of encryption.
Web 2 OpenFHE vs Web3 Zama
As mentioned earlier, Web2 giants are all exploring and have achieved some practical results. Here we summarize them and introduce the application scenarios of Web3.
To simplify, IBM contributed the Helib library, which mainly supports BGV and CKKS. 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 one, developed by Duality supported by DARPA. It currently supports mainstream algorithms such as BGV, BFV, CKKS, TFHE and FHEW. It is estimated to be the most complete FHE library currently available on the market.
In addition, OpenFHE has also explored cooperation with Intel's CPU acceleration library and calling NVIDIA's CUDA interface to support GPU acceleration. However, CUDA's latest support for FHE stopped in 2018, and no updated support has been found for the time being. If there are any errors, please correct them.
OpenFHE supports C++ and Python, and the Rust API is under development. It is committed to providing simple, comprehensive modularity and cross-platform capabilities. If you are a Web2 developer, this is the easiest out-of-the-box solution.
If you are a Web3 developer, it will be more difficult.
Limited by weak computing power, most public chains cannot support the execution of the FHE algorithm. Secondly, the Bitcoin and Ethereum ecosystems currently lack the "economic demand" for FHE. Once again, it is the demand for efficient L2-->L1 data transmission that inspired the implementation of the ZK algorithm. FHE cannot be implemented for the sake of FHE. This is like using a hammer to hit a nail. Forced matching will only increase the implementation cost.
How FHE+EVM works
The following article will detail the current difficulties and possible implementation scenarios. This article is mainly to give Web3 developers some confidence.
In 2024, Zama received the largest FHE-related concept financing in the crypto field, $73 million led by Multicoin. Zama currently mainly has a TFHE algorithm library, followed by fhEVM to support the development of EVM-compatible chains with FHE functions.
The second is the efficiency issue, which can only be solved through cooperation between software and hardware. One is that EVM cannot run FHE contracts directly, which does not conflict with Zama's fhEVM solution. Zama has built its own chain and can directly add FHE functions natively. For example, Shiba Inu also wants to build Layer 3 based on Zama's solution. It is not difficult for the newly created chain to support FHE. The difficulty lies in how Ethereum EVM itself can have the ability to deploy FHE contracts, which requires Ethereum's Opcode (operation code) support. The good news is that Fair Math and OpenFHE jointly organized the FHERMA competition to encourage developers to rewrite EVM's Opcode, which is actively exploring the possibility of combination.
The other is hardware acceleration. It can be said that even if high-performance public chains such as Solana natively support FHE contract deployment, their nodes will be dragged to death. The native FHE hardware mainly includes Chain Reaction's 3PU™ (Privacy Protection Processing Unit), which is an ASIC solution. Secondly, Zama or Inco are also exploring the possibility of hardware acceleration. For example, Zama's current TPS is about 5, and Inco can achieve 10 TPS. Inco believes that using FPGA hardware acceleration can speed up TPS to about 100-1000.
However, there is no need to worry too much about the speed issue. In theory, the existing ZK hardware acceleration solutions can be modified to adapt to the FHE solution. Therefore, the discussion below will not over-design the speed issue, but will mainly focus on finding scenarios and solving EVM compatibility adaptation.
Dark Pool is dead, but FHE X Crypto has a promising future
When Multicoin led the investment in Zama, it boasted that ZKP was a thing of the past and the future belonged to FHE. Whether the future will come true or not, the reality is always difficult. After Zama, Inco Network and Fhenix formed the fhEVM ecological invisible alliance. They have different focuses, but the path is basically the same, that is, they are committed to the integration of FHE and EVM ecology.
It is better to arrive at the right time than to do it early. Let’s start with a basin of cold water.
2024 may be a big year for FHE, but Elusiv, which started in 2022, has ceased operation. Elusiv was originally a "dark pool" protocol on Solana, and now the code base and documentation have been deleted.
Ultimately, as part of a technical component, FHE still needs to be used together with technologies such as MPC/ZKP, and what we need to examine is how FHE can change the current paradigm of blockchain.
First of all, we must admit that it is not accurate to simply think that FHE has economic value because it enhances privacy. From past practices, Web3 or on-chain users do not care so much about privacy. They will only use related tools when privacy can provide economic value. For example, hackers will use Tornado Cash to hide stolen funds, while ordinary users will only use Uniswap because using Tornado Cash will incur extra time or economic costs.
The encryption cost of FHE is itself a further torture of the already weak operating efficiency on the chain. Only when this increase in cost will bring more significant benefits, can privacy protection be promoted on a large scale, such as in the direction of RWA? Bond issuance and trading. For example, in June 2023, Bank of China International issued "Blockchain Digital Structured Notes" to Asia-Pacific customers in Hong Kong through UBS, and pointed out in the UBS press release that it was conducted through Ethereum, but magically The contract address and distribution address of the transaction cannot be found. If anyone can find it, please add relevant information.
This example clearly illustrates the importance of FHE. For institutional clients, they have the need to use public chains such as blockchain, but are not suitable for or want to disclose all information. In this case, FHE, which displays ciphertext and can directly perform 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, private transactions, more secure networks, prevention of third-party snooping, etc., but obviously these are not the primary needs, and using FHE now will indeed slow down the network. It is better to be frank that FHE's protagonist moment has not yet arrived.
In the final analysis, privacy is a need that is neither painful nor itchy. As a public service, few people are willing to pay for the privacy premium. We need to find scenarios where the computable nature of data encrypted by FHE can save costs or improve transaction efficiency, thereby generating a spontaneous boost in the market. For example, there are many solutions to MEV, such as centralized nodes, which can actually solve the problem. FHE cannot directly address the pain points of the scenario.
Another issue is the issue of computing efficiency. On the surface, this seems to be a technical issue that requires hardware acceleration or algorithm optimization, but in essence this is because there is not much demand in the market and the project party has no motivation to expand. Computing efficiency is ultimately expanded. Taking ZK as an example, under the booming market demand, SNARK and STARK routes compete with each other. Various types of ZK Rollups are competing hard from programming languages to compatibility. The development of ZK is advancing by leaps and bounds under the impetus of hot money.
Application scenarios and implementation are the breakthroughs for FHE to become a blockchain infrastructure. If this step cannot be taken, FHE will never be able to gain momentum in the encryption industry, and major project parties can only play a supporting role and entertain themselves in their own small piece of land.
From the practice of Zama and his friends, a consensus is to build a new chain outside of Ethereum, and reuse technical components and standards such as ERC-20 on it to form an FHE L1/L2 encryption solution that links Ethereum. The advantage of this solution is that it can be tried first and the basic components of FHE can be built. The disadvantage is that if Ethereum itself does not support the FHE algorithm, then the off-chain solution will always be in a rather embarrassing situation.
Zama itself is aware of this problem. In addition to the FHE-related libraries mentioned above, it also launched the FHE.org organization and sponsored related conferences, hoping to transform more academic achievements into engineering applications.
The development direction of Inco Network is "universal privacy computing layer", which is essentially a computing outsourcing service provider model. It has built an FHE EVM L1 network based on Zama. An interesting exploration is to cooperate with the cross-chain message protocol Hyperlane. The game mechanism on another EVM-compatible chain can be deployed on Inco. When FHE calculations are needed during game operation, Inco's computing power is called through Hyperlane, and then only the results are sent back to the original chain.
To realize the scenario envisioned by Inco, it is necessary that the EVM-compatible chain is willing to trust Inco's credibility, and Inco's own computing power must be strong enough. Whether it can really work well in the high concurrency and low latency requirements of chain games is quite challenging.
By extension, some zkVMs can actually take on the role of FHE computing outsourcing providers. For example, RISC Zero already has this capability. The next collision between ZK products and FHE may produce more sparks.
Furthermore, some projects hope to get closer to Ethereum, or at least move towards becoming a part of Ethereum. Inco can use the Zama solution to implement L1, and Fhenix can use the Zama solution to implement EVM L2. It is still under development and seems to have many directions to go. I don’t know what the final product will be. Maybe it will be an L2 with FHE capabilities.
In addition, there is the FHERMA competition mentioned above. Readers who are programmers proficient in Ethereum development can give it a try. They can help implement FHE and win prizes.
In addition, there are two more amazing projects, Sunscreen and Mind Network. Sunscreen is mainly operated by Ravital alone. Its direction is to use the BFV algorithm to create a compiler solution suitable for FHE, but it has been in a testing and experimental state for a long time, and it will take some time before the product can be put into practical use.
Finally, Mind Network’s ideas are mainly focused on the combination of FHE and various existing scenarios, such as re-staking, but it will take time to verify how to achieve it specifically.
Finally, to recap the beginning of this section, Elusiv has now changed its name to Arcium, and has received new financing to transform into a "parallel FHE" solution, which aims to improve FHE in terms of execution efficiency.
Conclusion
This article seems to be talking about the theory and practice of FHE, but the underlying thread is to clarify the development history of encryption technology itself, which is not completely equivalent to the technology used in cryptocurrency. ZKP and FHE have many similarities, one of which is that they are both committed to keeping the blockchain private while maintaining its public nature. The ZKP privacy solution aims to reduce the economic cost of interaction between L2<>L1, while FHE is still looking for its best scenario.
Classification of each plan
The road ahead is long and arduous, and FHE is still exploring. It can be divided into three types according to the degree of relevance to Ethereum:
Type 1: Independent kingdom, communicating in ether. Represented by Zama/Fhenix/Inco network, it mainly provides development infrastructure and encourages self-built FHE L1/L2, which is applicable to certain niche areas;
Type 2: plug-in, integrated into Ethereum. Fair Math/Mind Network is a representative example. Although it retains a certain degree of independence, the overall idea is to achieve a deeper integration with Ethereum.
Type 3: Meet for communication and transform Ethereum. If Ethereum cannot natively support FHE functions, then it is necessary to explore at the contract layer and distribute FHE functions to various EVM-compatible chains. Currently, there is no solution that meets this standard.
Unlike ZK, which only developed in the later stages to achieve one-click chain launch and hardware acceleration, FHE stands on the shoulders of the ZK giant. Now launching an FHE chain may be the easiest thing, but how to communicate between itself and Ethereum is the most difficult.
Reflect on yourself three times a day and find the future coordinates of FHE in the blockchain world:
In what scenarios must encryption be used instead of plain text?
What scenarios require FHE encryption and cannot use other encryption methods?
In what scenarios would users feel good about using FHE encryption and be willing to pay higher fees?
To be continued, I will keep an eye on FHE!
