FHE is the next step for ZK Cryptography

Source: Zuoye Waiboshan

The main line of cryptocurrency development is very clear. Bitcoin created cryptocurrency, Ethereum created public chains, 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.

The development trajectory of encryption technology is not very clear. Various consensus algorithms and various sophisticated designs are no match for pledge and multi-signature systems, and the latter are the real pillars to maintain the operation of encryption systems. For example, after the decentralized pledged WBTC is withdrawn, most BTC L2 cannot exist, and Babylon's native pledge is an exploration in this direction, an exploration worth 70 million US dollars.

In this article, I try to outline the development history of an encryption technology, which is different from various technological change processes in the encryption 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 for 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 caught fire slightly in 2024.

Different from 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 play a role, that is, encryption and decryption are important, but the content after encryption and before decryption should not be wasted.

Theory is complete, Web2 landed before Web3

FHE is a basic technology, and the theoretical exploration has been completed in academia. Web2 giants have made great efforts. For example, Duality supported by Microsoft, Intel, IBM and DARPA has been preparing for hardware and software adaptation and development tools.

The good news is that Web2 giants don’t know what to do with FHE, and it’s not too late for Web3 to start now. The bad news is that Web3’s adaptation is about 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 is on ZK from 2020 to 2024.

Here I would like to briefly explain my attribution to the popularity of ZK. After Ethereum established the expansion route with Rollup, ZK's state compression function can greatly reduce the size of data transmitted from L2 to L1, which has great economic value. Of course, this is only theoretical. Problems such as L2 fragmentation and sorter, and even some L2/Rollup harvesting user fees are new problems in development and can only be solved by continued development.

To summarize simply, Ethereum needs to expand capacity, establish the Layer 2 development route, and ZK/OP Rollup competes for beauty, forming an industry consensus of short-term OP and long-term ZK, shaping the four giants of ARB/OP/zkSync/SatrkNet.

Economic efficiency 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 "the addition or multiplication of ciphertext is equivalent to the addition or multiplication of plaintext", that is:

At this point, c and E(c), d and E(d) can be regarded as equal value, but please note that there are two difficulties here:

1. The equality of plaintext and ciphertext actually means that some noise is added to the plaintext and then the ciphertext is obtained by operation. If the deviation caused by the ciphertext is too large, the calculation will fail. Therefore, the key to various algorithms is to control noise.

2. Addition and multiplication are very expensive. The ciphertext calculation may be 10,000 to 1 million times more than the plaintext calculation. Only when an infinite number of addition and multiplication ciphertext calculations are achieved at the same time 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 implementation, 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 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 achieving arbitrary calculations 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, an ideal lattice is 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 and turning yourself over." In actual operation, the ciphertext encrypted by FHE 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 of FHE. It proved the feasibility of FHE in engineering for the first time, but the cost is huge. It even takes thirty minutes to calculate one step, which basically has no possibility of practical application.

After solving from 0 to 1, the only thing left is large-scale practical application, which can also be understood as carrying out corresponding algorithm design 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 scheme 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 of ciphertext noise caused by homomorphic operations, thereby constructing Leveled FHE, that is, such FHE can achieve homomorphic computing tasks of a given computing depth.

Similar to this, there are BFV and CKKS solutions. 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 TFHE and FHEW solutions, especially the TFHE solution, 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 introduced each solution briefly. In fact, the difference between them is not the difference between good and bad, but more about different scenarios. However, they basically need strong software and hardware resource support. 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 encryption field.

Web 2 OpenFHE vs Web3 Zama

As mentioned above, Web2 giants are 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 solutions. 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 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, but 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 two languages, C++ and Python. The Rust API is under development, and is committed to providing simple and comprehensive modularization and cross-platform capabilities. If you are a Web2 developer, then this is the simplest 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 data transmission between L2-->L1 that inspired the implementation of the ZK algorithm. FHE cannot be used for the sake of FHE. This is like hammering a nail with a hammer. Forcing a match will only increase the implementation cost.

The difficulties currently encountered and possible implementation scenarios will be detailed later. Here we mainly give Web3 developers some confidence.

In 2024, Zama received the largest FHE-related concept financing in the crypto field, with a $73 million investment led by Multicoin. Zama currently mainly has an algorithm library based on TFHE, followed by fhEVM to support the development of EVM-compatible chains with FHE functions.

The second is the efficiency problem, which can only be solved through software and hardware cooperation. One is that EVM cannot directly run FHE contracts, which does not conflict with Zama's fhEVM solution. Zama has built a chain by itself, 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 is how Ethereum EVM itself has the ability to deploy FHE contracts, which requires Ethereum's Opcode (operation code) support. The good news is that Fair Math and OpenFHE jointly held the FHERMA competition to encourage developers to rewrite EVM's Opcode, which is considered to be actively exploring the possibility of combination.

Another 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 belongs to the ASIC solution. Secondly, Zama or Inco are also exploring the possibility of hardware acceleration. For example, Zama's current TPS is about 5, Inco can achieve 10 TPS, and 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 problem. The existing ZK hardware acceleration solutions can theoretically be modified to adapt to the FHE solution. Therefore, the discussion below will not over-design the speed problem, but mainly look for scenarios and solve EVM compatibility adaptation.

Dark Pool is dead, FHE X Crypto has a promising future

When Multicoin led the investment in Zama, it boasted that ZKP is a thing of the past and the future belongs to FHE. Whether the future will come true or not, reality is always difficult. After Zama, Inco Network and Fhenix formed the fhEVM Ecological Invisible Alliance, each with its own focus, but basically the same path, that is, to integrate FHE and EVM ecology.

It is better to do it early than to come late, so let's start with a basin of cold water.

2024 may be a big year for FHE, but Elusiv, which started in 2022, has stopped running. Elusiv was originally a "dark pool" protocol on Solana, and now the code base and documents have been deleted.

In the final analysis, FHE, as part of the technical components, still needs to be used together with technologies such as MPC/ZKP, and what we need to examine is in what aspects FHE can change the current paradigm of blockchain.

First of all, it must be admitted that it is not accurate to simply think that FHE will enhance privacy and therefore have economic value. From past practice, 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 cost extra time or economic costs.

The encryption cost of FHE itself is a further torture to the already weak operating efficiency of the chain. Only when this cost increase will bring more significant benefits, privacy protection will have the possibility of large-scale promotion, such as RWA-directed bond issuance and trading. For example, in June 2023, Bank of China International issued "blockchain digital structure 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 the magical thing is that the contract address and distribution address of the transaction cannot be found. If anyone can find it, please add relevant information.

This example can clearly illustrate the importance of FHE. For institutional clients, they have the need to use public chains such as blockchain, but they are not suitable for or want to disclose all information. Then FHE, which displays ciphertext and can directly perform buying and selling operations, will be 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 transactions, more secure networks, and prevention of third-party snooping, but obviously these are not the primary needs, and using FHE now will indeed slow down the network. It is better to frankly say that FHE's protagonist moment has not yet arrived.

In the final analysis, privacy is a painless demand. As a public service, few people are willing to pay for the privacy premium. We need to find scenarios where the computable characteristics of data encrypted by FHE can save costs or improve transaction efficiency, thereby generating a spontaneous boost to the market. For example, there are many solutions to anti-MEV, such as centralized nodes, which can actually solve the problem. FHE cannot directly hit the pain points of the scenario.

Another problem is the problem of computing efficiency. On the surface, this is a technical problem that requires hardware acceleration or algorithm optimization, but in essence, this is because the market does not have much demand, and the project side has no motivation to roll. After all, computing efficiency is rolled out. Let’s take ZK as an example. Under the booming market demand, SNARK and STARK routes compete with each other. Various ZK Rollups are rolling up their sleeves from programming languages ​​to compatibility. The development of ZK is advancing by leaps and bounds under the urging of hot money.

Application scenarios and implementation are the breakthrough points for FHE to become the infrastructure of blockchain. 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 build the basic components of FHE. The disadvantage is that if Ethereum itself does not support the FHE algorithm, then the off-chain solution will always be in a relatively embarrassing situation.

Zama himself also recognizes this problem. In addition to the FHE-related libraries mentioned above, he 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. Based on Zama, the FHE EVM L1 network is built. An interesting exploration is to cooperate with the cross-chain message protocol Hyperlane, which can deploy the game mechanism on another EVM-compatible chain on Inco. When the game needs to use FHE computing, Inco's computing power is called through Hyperlane, and then only the result is transmitted back to the original chain.

To realize such scenarios envisioned by Inco, it is necessary to meet the EVM-compatible chain's willingness to believe in Inco's credibility, and Inco's own computing power must be strong enough. In the high concurrency and low latency requirements of chain games, whether it can really work well is quite challenging.

From this, 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 have more sparks.

Furthermore, some projects hope to get closer to Ethereum, at least towards becoming 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. It seems that there are many directions it wants to go. I don’t know what product will be finally landed. Maybe it will be an L2 with FHE capabilities.

In addition, there is the FHERMA competition mentioned above. Readers who are proficient in Ethereum development can try it. They can help FHE land and get bonuses.

In addition, there are two more magical projects, Sunscreen and Mind Network. Sunscreen is mainly operated by Ravital alone. The direction is to use the BFV algorithm to create a compiler solution suitable for FHE, but it has been in a long-term testing and experimental state, 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 how to achieve it specifically still needs time to verify.

Finally, let’s recap the beginning of this section. Elusiv is now renamed 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 public while maintaining privacy design, while the ZKP privacy solution aims to reduce the economic cost of interaction between L2 <> L1, while FHE is still looking for its best scenario.

The road is long and arduous, and FHE is still exploring. It can be divided into three types according to the degree of association with Ethereum:

1. Type 1: Independent kingdom, communicating with Ethereum. Represented by Zama/Fhenix/Inco network, it mainly provides development infrastructure and encourages self-built FHE L1/L2, which is suitable for certain niche areas;

2. Type 2: Plug-in and integrate into Ethereum. Represented by Fair Math/Mind Network, although it retains a certain degree of independence, the overall idea is to integrate more deeply with Ethereum.

3. Type 3: Meet for communication and transform Ethereum. If Ethereum cannot natively support FHE functions, it is necessary to explore at the contract layer and distribute FHE functions to various EVM-compatible chains. There is currently no solution that meets this standard.

Unlike ZK, which only developed to a late stage to launch a chain with one click 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 with Ethereum is the most difficult.

Reflect on yourself three times a day and find the future coordinates of FHE in the blockchain world:

1. What scenarios must be encrypted and cannot use plain text?

2. What scenarios require FHE encryption and cannot use other encryption methods?

3. What scenarios make users feel good after using FHE encryption and are willing to pay higher fees?

To be continued, I will keep paying attention to FHE!