Cryptography Says FHE is the Next Step for ZK

The development path of cryptocurrencies is clear: Bitcoin introduced cryptocurrency, Ethereum introduced public chains, Tether created stablecoins, and BitMEX introduced perpetual contracts, together building a trillion-dollar market with countless wealth stories and dreams of decentralization.

The trajectory of cryptographic technology is less clear. Various consensus algorithms and sophisticated designs are overshadowed by staking and multi-signature systems, the true pillars of cryptosystems. For example, without decentralized staking, most BTC L2 solutions would not exist. Babylon’s $70 million exploration of native staking exemplifies this direction.

This article attempts to outline the development history of cryptographic technology, distinct from the various technological changes in the crypto industry, such as the relationship between FHE, ZK, and MPC. From a rough application perspective, MPC is used initially, FHE for intermediate computations, and ZK for final proof. Chronologically, ZK was first, followed by the rise of AA wallets, then MPC gained attention and accelerated development, while FHE, predicted to rise in 2020, only started gaining traction in 2024.

MPC/FHE/ZKP

FHE differs from ZK, MPC, and all current encryption algorithms. Unlike symmetric or asymmetric encryption technologies, which aim to create “unbreakable” systems for absolute security, FHE aims to make encrypted data functional. Encryption and decryption are important, but the data between encryption and decryption should also be useful.

Theoretical Foundation and Web2 Adoption Before Web3

FHE is a fundamental technology with completed theoretical exploration, thanks to significant contributions from Web2 giants like Microsoft, Intel, IBM, and DARPA-supported Duality, which have prepared software and hardware adaptations and development tools.

The good news is that Web2 giants also don’t know exactly what to do with FHE. Starting from now, Web3 is not late. The bad news is that Web3 adaptation is almost zero. Mainstream Bitcoin and Ethereum cannot natively support FHE algorithms. Although Ethereum is called the world computer, calculating FHE might take forever.

We focus on Web3 exploration, noting that Web2 giants are keen on FHE and have done extensive groundwork.

This is because from 2020 to 2024, Vitalik’s focus has been on ZK.

Here I briefly explain my attribution of ZK’s rise. After Ethereum established the Rollup scaling path, ZK’s state compression function greatly reduced the data size from L2 to L1, offering enormous economic value. This is theoretical; L2 fragmentation, sequencer issues, and user fee problems are new challenges that development will address.

In summary, Ethereum needs to scale, establishing the Layer 2 development path. ZK/OP rollups are competing, forming a short-term OP and long-term ZK consensus, with ARB, OP, zkSync, and StarkNet emerging as major players.

Economic value is crucial for ZK’s acceptance in the crypto world, especially Ethereum. Therefore, FHE’s technical characteristics won’t be detailed here. The focus is on examining where FHE can improve Web3 efficiency or reduce operational costs, either by lowering costs or increasing efficiency.

FHE Development History and Achievements

First, distinguish between homomorphic encryption and fully homomorphic encryption. Strictly speaking, fully homomorphic encryption is a special case. Homomorphic encryption means “addition or multiplication of ciphertexts is equivalent to addition or multiplication of plaintexts.” This equivalence faces two challenges:

1. Noise control: Plaintext-to-ciphertext equality involves adding noise, and excessive noise deviation can cause calculation failure. Controlling noise algorithms is key.
2. Computational cost: Addition and multiplication are expensive, with ciphertext calculations potentially being 10,000 to 1,000,000 times more costly than plaintext. Achieving unlimited additions and multiplications is the hallmark of fully homomorphic encryption. Various homomorphic encryption methods have unique values, categorized as follows:

• Partially homomorphic encryption: Allows limited operations on encrypted data, like addition or multiplication. Somewhat homomorphic encryption: Allows a limited number of additions and multiplications.
• Fully homomorphic encryption: Allows unlimited additions and multiplications for any encrypted data computations.

The development of fully homomorphic encryption (FHE) dates back to 2009 when Craig Gentry proposed a fully homomorphic algorithm based on ideal lattices, a mathematical structure enabling users to define a set of points in a multidimensional space satisfying specific linear relationships.

Gentry’s scheme uses ideal lattices to represent keys and encrypted data, enabling encrypted data to function while maintaining privacy. Bootstrapping reduces noise, understood as “pulling oneself up by one’s bootstraps.” Practically, it means re-encrypting FHE ciphertext to reduce noise while maintaining confidentiality and supporting complex operations. (Bootstrapping is crucial for FHE’s practical use but won’t be detailed further.)

This algorithm is a milestone, proving FHE’s feasibility in engineering but with enormous costs, requiring thirty minutes for one computation step, making it impractical.

After solving the 0 to 1 problem, the next step is large-scale practicality, involving designing algorithms based on different mathematical assumptions. Besides ideal lattices, LWE (Learning with Errors) and its variants are common schemes.

In 2012, Zvika Brakerski, Craig Gentry, and Vinod Vaikuntanathan proposed the BGV scheme, a second-generation FHE scheme. Its key contribution is modulus switching technology, effectively controlling noise increase from homomorphic operations, and constructing Leveled FHE for given computational depths.

Similar schemes include BFV and CKKS, especially CKKS, which supports floating-point operations but increases computational resource consumption, requiring better solutions.

Finally, TFHE and FHEW schemes, especially TFHE, Zama’s preferred algorithm. Briefly, FHE’s noise problem can be reduced through Gentry’s bootstrapping. TFHE achieves efficient bootstrapping with precision assurance, well-suited for blockchain integration.

We stop at introducing various schemes. Their differences are not about superiority but different scenarios, generally requiring robust software and hardware support. Even the TFHE scheme needs to solve hardware problems for large-scale applications. FHE must develop hardware synchronously from the start, at least in cryptography.

Web 2 OpenFHE vs Web3 Zama

As mentioned, Web2 giants are exploring and achieving practical results, summarized here with Web3 application scenarios.

Simplifying, IBM contributed to the Helib library, mainly supporting BGV and CKKS. Microsoft’s SEAL library supports CKKS and BFV. Notably, CKKS author Song Yongsoo participated in SEAL’s design and development. OpenFHE is the most comprehensive, developed by DARPA-supported Duality, supporting BGV, BFV, CKKS, TFHE, and FHEW, possibly the most complete FHE library on the market.

OpenFHE has explored cooperation with Intel’s CPU acceleration library and used NVIDIA’s CUDA interface for GPU acceleration. However, CUDA’s latest support for FHE stopped in 2018, with no updates found. Corrections are welcome if mistaken.

OpenFHE supports C++ and Python languages, with Rust API in development, aiming to provide simple, comprehensive modular and cross-platform capabilities. For Web2 developers, this is the simplest out-of-the-box solution.

For Web3 developers, the difficulty increases. Limited by weak computing power, most public chains cannot support FHE algorithms. Bitcoin and Ethereum ecosystems currently lack “economic demand” for FHE. The demand for efficient L2—>L1 data transmission inspired ZK algorithm landing. FHE for FHE’s sake is like hitting nails with a hammer, forcing a match, increasing costs.

FHE+EVM Working Principle

The following sections will detail current difficulties and possible landing scenarios, mainly giving Web3 developers confidence. In 2024, Zama received the largest FHE-related funding in cryptography, led by Multicoin, raising $73 million. Zama has a TFHE algorithm library and fhEVM supporting FHE-capable EVM-compatible chain development.

Efficiency issues can only be solved through software-hardware cooperation. One issue is that EVM cannot directly run FHE contracts, not conflict with Zama’s fhEVM solution. Zama built a chain natively integrating FHE features. For example, Shiba Inu plans a Layer 3 chain based on Zama’s solution. Creating a new chain supporting FHE is not difficult, but enabling Ethereum EVM to deploy FHE contracts requires Ethereum’s Opcode support. The good news is that Fair Math and OpenFHE co-hosted the FHERMA competition, encouraging developers to rewrite EVM’s Opcode, and exploring integration possibilities.

Another issue is hardware acceleration. High-performance public chains like Solana natively supporting FHE contract deployment could overwhelm their nodes. Native FHE hardware includes Chain Reaction’s 3PU™ (Privacy Protecting Processing Unit), an ASIC solution. Zama and Inco are exploring hardware acceleration possibilities. For example, Zama’s current TPS is around 5, Inco achieves 10 TPS, and Inco believes FPGA hardware acceleration can boost TPS to 100-1000.

Speed concerns need not be excessive. Existing ZK hardware acceleration solutions can adapt to FHE solutions. Thus, discussions will not over-design speed issues but focus on finding scenarios and solving EVM compatibility.

Dark Pool Collapse: FHE X Crypto Future Promising

When Multicoin led the investment in Zama, they boldly proclaimed that ZKP is a thing of the past and FHE represents the future. Whether this prediction will come true remains to be seen, as reality is often challenging. Following Zama, Inco Network and Fhenix formed a hidden alliance in the fhEVM ecosystem, each focusing on different aspects but generally working towards integrating FHE with the EVM ecosystem.

Timing is key, so let’s start with a dose of realism.

2024 may be a big year for FHE, but Elusiv, which started in 2022, has already ceased operations. Elusiv was initially a “dark pool” protocol on Solana, but now its code repository and documentation have been deleted.

Ultimately, FHE, as part of a technical component, still needs to be used alongside technologies like MPC/ZKP. We need to examine how FHE can change the current blockchain paradigm.

First, it’s essential to understand that simply thinking FHE will enhance privacy and thus have economic value is inaccurate. From past practices, Web3 or on-chain users do not care much about privacy unless it provides economic value. For instance, hackers use Tornado Cash to hide stolen funds, while regular users prefer Uniswap because using Tornado Cash incurs additional time or economic costs.

The encryption cost of FHE further burdens the already weak on-chain efficiency. Protecting privacy can only be promoted on a large scale if this cost brings significant benefits. For example, bond issuance and trading in the RWA direction. In June 2023, BOC International issued “blockchain digital structured notes” through UBS in Hong Kong for Asia-Pacific clients, claiming to use Ethereum, yet the contract address and distribution address cannot be found. If anyone can locate it, please provide the information.

This example highlights the importance of FHE. Institutional clients need to use public blockchains but do not want to disclose all information. Therefore, FHE’s feature of displaying ciphertext, which can be directly traded, is more suitable than ZKP.

For individual retail investors, FHE is still a relatively distant underlying infrastructure. Potential use cases include anti-MEV, private transactions, more secure networks, and preventing third-party snooping. However, these are not primary needs, and using FHE now indeed slows down the network. Frankly, FHE’s key moment has not yet arrived.

Ultimately, privacy is not a strong demand. Few people are willing to pay a premium for privacy as a public service. We need to find scenarios where FHE’s encrypted data’s computable features can save costs or improve transaction efficiency, generating market-driven momentum. For example, there are many anti-MEV solutions, and centralized nodes can solve the problem. FHE does not directly address the pain points.

Another issue is computing efficiency. On the surface, this is a technical problem requiring hardware acceleration or algorithm optimization, but fundamentally, it is a lack of market demand, with no incentive for project parties to compete. Computing efficiency results from the competition. For example, in the booming market demand, SNARK and STARK routes compete, with various ZK Rollups fiercely competing from programming languages to compatibility. ZK’s development has been rapid under hot money’s push.

Application scenarios and implementation are the breakthrough points for FHE to become a blockchain infrastructure. Without taking this step, FHE will never gain momentum in the crypto industry, and major projects can only tinker in their small domains.

From the practices of Zama and its partners, a consensus is to create new chains outside Ethereum and reuse ERC-20 and other technical components and standards to form FHE L1/L2 chains linked to Ethereum. This approach allows for early testing and building of FHE’s basic components. The disadvantage is that if Ethereum does not support FHE algorithms, external chain solutions will always be awkward.

Zama also recognizes this problem. Besides the aforementioned FHE-related libraries, it initiated the FHE.org organization and sponsored related conferences to translate more academic achievements into engineering applications.

Inco Network’s development direction is a “universal privacy computing layer,” essentially a computing outsourcing service provider model. It built an FHE EVM L1 network based on Zama. An interesting exploration is cooperation with the cross-chain messaging protocol Hyperlane, which can deploy game mechanisms from another EVM-compatible chain on Inco. When the game requires FHE computation, Hyperlane calls Inco’s computing power and then returns only the results to the original chain.

To realize such scenarios envisioned by Inco, EVM-compatible chains must trust Inco’s credibility, and Inco’s computing power must be strong enough to handle the high concurrency and low latency demands of blockchain games, which is highly challenging.

Extending this, some zkVMs can also serve as FHE computing outsourcing providers. For instance, RISC Zero has this capability. The next step in the collision between ZK products and FHE may spark more ideas.

Further, some projects aim to be closer to Ethereum or become part of it. Inco can use Zama’s solution for L1, and Fhenix can use Zama’s solution for EVM L2. Currently, they are still developing, with many potential directions. It’s unclear what product they will eventually land on. It might be an L2 focusing on FHE capabilities.

Additionally, there is the FHERMA competition mentioned earlier. Ethereum-savvy developers in the audience can try it, helping FHE land while earning bonuses.

There are also intriguing projects like Sunscreen and Mind Network. Sunscreen, mainly operated by Ravital, aims to develop a suitable FHE compiler using the BFV algorithm but remains in testing and experimental stages, far from practical application.

Finally, Mind Network focuses on combining FHE with existing scenarios like re-staking, but how this will be achieved remains to be seen.

In conclusion, Elusiv has now been renamed Arcium and received new funding, transforming into a “parallel FHE” solution to improve FHE’s execution efficiency.

Conclusion

This article appears to discuss the theory and practice of FHE, but the underlying theme is to clarify the development history of cryptographic technology. This is not entirely the same as the technology used in cryptocurrencies. ZKP and FHE have many similarities, one being their effort to maintain blockchain transparency while preserving privacy. ZKP aims to reduce economic costs in L2 <> L1 interactions, while FHE is still searching for its best application scenario.

Solution Classification:

The path ahead is long and challenging. FHE continues its exploration. Based on its relationship with Ethereum, it can be divided into three types:

1. Type 1: Independent Kingdoms Communicating with Ethereum. Represented by Zama/Fhenix/Inco Network, they mainly provide development components and encourage the creation of FHE L1/L2 for specific fields.
2. Type 2: Plug-ins Integrating with Ethereum. Represented by Fair Math/Mind Network, they retain some independence but generally aim for deeper integration with Ethereum.
3. Type 3: Joint Journey Transforming Ethereum. If Ethereum cannot natively support FHE, exploration at the contract layer is needed to distribute FHE functions across EVM-compatible chains. Currently, no solution meets this standard well.

Unlike ZK, which only saw practical chain launching and hardware acceleration in later stages, FHE stands on the shoulders of ZK giants. Creating an FHE chain is now the simplest task, but integrating it with Ethereum remains the most challenging.

Reflect daily on FHE’s future position in the blockchain world:

1. Which scenarios must use encryption instead of plaintext?
2. Which scenarios require FHE encryption over other methods?
3. In which scenarios do users feel good after using FHE encryption and are willing to pay higher fees?

Disclaimer:

1. This article is reprinted from WeChat Official Account: Zuoye Waibo Shan, originally titled “FHE is the Next Step for ZK, Says Cryptography,” copyrighted by the original author [Zuoye]. If you have any objections to the reprint, please contact the Gate Learn team, and the team will handle it promptly according to relevant processes.
2. The views and opinions expressed in this article are solely those of the author and do not constitute any investment advice.
3. Other language versions of the article are translated by the Gate Learn team and should not be copied, disseminated, or plagiarized without mentioning Gate.io.