Decoding the Holy Grail: Challenges and Solutions of On-Chain Fully Homomorphic Encryption
TechFlow Selected TechFlow Selected
Decoding the Holy Grail: Challenges and Solutions of On-Chain Fully Homomorphic Encryption
Fully Homomorphic Encryption (FHE) is hailed as the "holy grail of cryptography," but its current applications are limited by performance, development experience, and security concerns.
Navigating Web3 tides with focused insightsAuthors: Jeffrey Hu, Arnav Pagidyala
Core Insights
• Fully Homomorphic Encryption (FHE), often hailed as the "holy grail of cryptography," currently faces limitations in performance, developer experience, and security.
• As shown in the diagram above, building a truly confidential and secure shared state system requires combining FHE with Zero-Knowledge Proofs (ZKPs) and Multi-Party Computation (MPC).
• FHE is rapidly advancing; new compilers, libraries, hardware, and R&D efforts from Web2 companies (e.g., Intel, Google, DARPA) are significantly accelerating its development.
• As FHE and its surrounding ecosystem mature, we expect “verifiable FHE” to become standard. Decentralized applications (DApps) or rollups may choose to outsource computation and verification to FHE co-processors.
• A fundamental limitation of on-chain FHE is “who holds the decryption key.” Threshold decryption and MPC offer solutions to this constraint, but they typically involve trade-offs between performance and security.
Introduction
Blockchain’s transparency is a double-edged sword. While openness and observability are appealing, these very features deter enterprise adoption.
On-chain privacy has remained one of the most challenging problems in crypto for nearly a decade. Although many teams are building ZKP-based systems for on-chain privacy, none support shared encrypted states. This is because such systems operate as functions over a series of ZKPs, making it impossible to apply arbitrary logic to the current state. Thus, ZKPs alone cannot enable encrypted shared-state applications (e.g., a private Uniswap).
However, recent technological breakthroughs suggest that combining ZKPs with Fully Homomorphic Encryption (FHE) can enable fully general-purpose, encrypted decentralized finance (DeFi). How does this work? FHE is an emerging cryptographic field enabling arbitrary computations on encrypted data. As illustrated above, ZKPs can verify the integrity of user inputs and computations, while FHE handles the computation itself.
Although FHE is often called the "holy grail of cryptography," we aim to provide an objective analysis of the field, including its challenges and potential solutions. This technical report covers the following on-chain FHE topics:
1. FHE Schemes, Libraries, and Compilers
2. Secure Threshold Decryption
3. ZKPs for User Inputs and the Computing Party
4. Programmable, Scalable Data Availability (DA) Layer
5. FHE Hardware
FHE Schemes, Libraries, and Compilers
Challenge: Emerging FHE Schemes, Libraries, and Compilers
The fundamental bottleneck for on-chain FHE lies in underdeveloped tools and infrastructure. Unlike zero-knowledge proofs (ZKPs) or multi-party computation (MPC), FHE has only existed since 2009 and remains relatively immature.
Key limitations in the FHE developer experience include:
• Lack of user-friendly front-end languages allowing developers to code without deep knowledge of backend cryptography.
• Absence of full-featured FHE compilers capable of handling complex tasks (e.g., parameter selection, SIMD optimization for BGV/BFV, parallelization).
• Existing FHE schemes (especially TFHE) are approximately 1,000 times slower than plaintext computation.
To understand the complexity of integrating FHE, consider the typical developer workflow:
The first step in integrating FHE into an application is selecting an FHE scheme. The table below outlines the main options:
As shown, Boolean circuits (e.g., FHEW, TFHE) offer the fastest bootstrapping, avoid complex parameter selection, and support arbitrary computation—but are relatively slow. BGV/BFV suit general DeFi applications due to higher efficiency in high-precision arithmetic, though developers must know circuit depth upfront to set all parameters. CKKS supports homomorphic multiplication with acceptable precision loss, making it ideal for approximate use cases like machine learning.
Developers must carefully select an FHE scheme, as it affects all subsequent design decisions and future performance. Additionally, critical parameters—such as modulus size and polynomial degree—are essential for proper scheme configuration.
Next, consider libraries. The table below compares popular FHE libraries:
However, these libraries vary in compatibility with different FHE schemes and compilers, as shown below:
After choosing a scheme, developers must set parameters—a difficult task requiring knowledge of abstract algebra, FHE-specific operations (e.g., relinearization, modulus switching), and arithmetic/binary circuits. Proper parameter selection profoundly impacts performance and requires conceptual understanding of their effects.
At this point, developers might ask:
How large should my plaintext space be? What ciphertext size is acceptable? Where can I parallelize computation? And so on…
Moreover, although FHE supports arbitrary computation, developers must shift their programming mindset. For example, branching (if-else) based on variable values is impossible, as variables cannot be directly compared like plaintext data. Instead, code must be rewritten to compute all branch conditions simultaneously. Similarly, loops are also prohibited.
In short, integrating FHE into applications is nearly impossible for developers unfamiliar with the technology. Significant tooling and infrastructure are needed to abstract away FHE’s complexity.
Solutions:
1. Web3-Native FHE Compilers
Existing FHE compilers built by companies like Google and Microsoft:
• Are not optimized for performance, adding up to 1,000× overhead compared to hand-written circuits
• Are optimized for CKKS (i.e., ML), offering less benefit for BFV/BGV required in DeFi
• Are not built for Web3; lack compatibility with ZKP schemes or programmable blockchains
The Sunscreen FHE compiler changes this. It is a Web3-native compiler delivering top-tier performance for arithmetic operations (e.g., DeFi) without requiring hardware accelerators. Parameter selection—one of the hardest aspects of FHE implementation—is automated by Sunscreen, which also handles data encoding, key selection, relinearization, modulus switching, circuit setup, and SIMD operations.
As the field advances, we anticipate further optimizations across multiple compilers supporting additional high-level languages beyond Sunscreen.
2. New FHE Libraries
While researchers continue exploring novel efficient schemes, improved FHE libraries can make integration more accessible to developers.
Take FHE smart contracts as an example. While choosing among various FHE libraries can be difficult, on-chain FHE simplifies the choice, as Web3 predominantly uses a few programming languages.
For instance, Zama’s fhEVM integrates Zama’s open-source library TFHE-rs into a standard EVM, exposing homomorphic operations as precompiled contracts. This allows developers to use encrypted data in their contracts without modifying compilation tools.
For other use cases, additional infrastructure may be needed. For example, the C++ version of the TFHE library is less actively maintained than the Rust version. Although TFHE-rs supports C/C++ exports, C++ developers seeking better compatibility and performance may need to build their own TFHE library variant.
Finally, a core reason for the lack of FHE infrastructure is the absence of effective methods to build FHE-RAM. One possible direction is researching an FHE-EVM without certain opcodes.
Secure Threshold Decryption
Challenge: Insecure/Centralized Threshold Decryption
Every confidential shared-state system relies on encryption and decryption keys. Since no single party can be trusted, the decryption key is sharded across network participants via Multi-Party Computation (MPC).
One of the most challenging aspects of on-chain FHE is building a secure and high-performance threshold decryption protocol. Two primary bottlenecks exist:
(1) FHE-based computation introduces significant overhead, requiring high-performance nodes and inherently reducing the potential validator set size;
(2) Latency increases with the number of nodes participating in the decryption protocol.
Currently, FHE protocols assume an honest majority among validators. However, on-chain FHE implies smaller validator sets, increasing collusion and malicious behavior risks.
What if threshold nodes collude? They could bypass the protocol and decrypt anything—including user inputs and on-chain data. Worse, in current systems, decryption can occur undetected (“silent attacks”).
Solution: Improved Threshold Decryption or Dynamic MPC
Several approaches can mitigate threshold decryption drawbacks:
(1) Enable n/2 thresholds, making collusion harder;
(2) Run threshold decryption inside Hardware Security Modules (HSMs);
(3) Use a Trusted Execution Environment (TEE)-based threshold decryption network, controlled by a decentralized chain for dynamic key management.
Rather than relying solely on threshold decryption, using MPC may be more viable. A groundbreaking example is Odsy’s new 2PC-MPC—the first non-colluding, massively decentralized MPC algorithm usable in on-chain FHE.
Another approach: encrypt data only with the user’s public key. Validators perform homomorphic operations, and users decrypt results themselves when needed. While limited to specific use cases, this avoids threshold assumptions entirely.
In summary, on-chain FHE needs an efficient MPC implementation with these characteristics:
(1) Works even with malicious actors;
(2) Introduces minimal latency;
(3) Allows permissionless/flexible node participation.
ZKPs for User Inputs and the Computing Party
Challenge: Verifiability of User Inputs and Computation
In Web2, when requesting a computation, we fully trust a company to execute it as promised behind the scenes. In Web3, this model is inverted—we operate in a trustless environment where users should not have to trust anyone.
While FHE enables processing encrypted data, it cannot verify input correctness or computational integrity. Without verifiability, FHE has little utility in blockchain contexts.
Solution: ZKPs for User Inputs and the Computing Party
FHE allows arbitrary computation on encrypted data, while ZKPs let people prove statements without revealing underlying information. Their synergy manifests in three key ways:
1. Users must submit a proof that their input ciphertext is correctly formatted—conforming to the encryption scheme, not just arbitrary data.
2. Users must prove their plaintext input satisfies application-specific conditions (e.g., account balance > transfer amount).
3. Validator nodes (the computing party) must prove correct execution of FHE computation—known as “verifiable FHE,” analogous to ZKPs in rollups.
To explore ZKP applications further:
1. ZKPs for Ciphertext
FHE is based on lattice cryptography, meaning its primitives involve lattices that are post-quantum secure. In contrast, popular ZKPs (SNARKs, STARKs, Bulletproofs) do not rely on lattice-based cryptography.
To prove correct FHE ciphertext format, we need to show it satisfies a matrix-vector equation with small ring elements. This requires an efficient on-chain proof system tailored to lattice-based relations—an open research area.
2. ZKPs for Plaintext Inputs
Beyond proving ciphertext validity, users must prove their plaintext inputs meet application requirements. Fortunately, unlike the previous step, we can leverage general-purpose SNARKs, enabling developers to use existing ZKP schemes, libraries, and infrastructure.
However, the challenge lies in “connecting” the two proof systems—ensuring users employ the same input across both. Otherwise, malicious users could exploit the protocol. Bridging FHE and ZKP systems remains a formidable cryptographic challenge and an early-stage research frontier.
Sunscreen has laid groundwork here—its ZKP compiler supports Bulletproofs due to easier integration with SDLP. Research on connecting FHE and ZKP compilers continues to progress.
Mind Network leads in ZKP integration, ensuring trustless inputs and outputs while leveraging FHE for secure computation.
3. ZKPs for Correct Computation
FHE is extremely inefficient and costly on current hardware. As seen in the scalability trilemma, networks demanding high node resources struggle to achieve sufficient decentralization. A potential solution is “verifiable FHE,” where the computing party (validator) submits a ZKP proving honest transaction execution.
An early verifiable FHE prototype is demonstrated by SherLOCKED: FHE computation runs on Risc Zero’s Bonsai zkVM off-chain, returning results with ZKPs for on-chain state updates.
A recent example of an FHE co-processor: Aztec’s on-chain auction demo. Unlike existing FHE chains that use threshold keys to encrypt the entire state (making security dependent on the threshold committee), Aztec lets users control their own data, eliminating threshold security assumptions.
Lastly, developers must decide where to build FHE apps: on FHE-supported L1s, FHE rollups, or any EVM chain using an FHE co-processor. Each design involves trade-offs, but we favor well-designed FHE rollups (pioneered by Fhenix) or FHE co-processors, which inherit security benefits from Ethereum.
Until recently, fraud proofs over FHE-encrypted data were complex, but Fhenix.io recently demonstrated how to implement them using Arbitrum Nitro stack with FHE logic compiled to WebAssembly.
FHE Data Availability (DA) Layer
Challenge: Lack of Customizability and Throughput
While “storage” is commoditized in Web2, it is not in Web3. Given FHE’s >10,000× data inflation, determining where to store massive FHE ciphertexts is critical. If every DA node operator must download and store all FHE chain data, only institutional operators can participate—increasing centralization risk.
Regarding throughput, Celestia’s peak is 6.7 MB/s. Running any form of FHEML would require GB/s bandwidth. According to recent data from 1k(x), existing DA layers cannot support FHE due to design choices intentionally limiting throughput.
Solution: Horizontal Scaling + Customizability
We need a DA layer supporting horizontal scalability. Current DA architectures broadcast all data to every node—a major scalability bottleneck. In contrast, horizontal scaling reduces per-node storage as more DA nodes join, improving performance and cost with increased blockspace.
Additionally, given the massive size of FHE-related data, allowing developers to customize erasure coding thresholds makes sense. How confident are developers in the DA system’s guarantees—weighted by stake or decentralization?
EigenDA’s architecture offers a foundation for FHE-compatible DA. Its horizontal scalability, structural cost reduction, and decoupling of DA and consensus pave the way for FHE-level scalability.
Finally, a higher-dimensional idea: building optimized storage slots for FHE ciphertexts. Since ciphertexts follow specific encoding schemes, optimized storage could improve space efficiency and retrieval speed.
FHE Hardware
Challenge: Low-Performance FHE Hardware
A major barrier to on-chain FHE adoption is significant latency due to computational overhead, making FHE impractical on standard hardware. This stems from heavy memory interaction—processors must handle massive data volumes. Beyond memory access, complex polynomial calculations and time-consuming ciphertext maintenance operations add substantial overhead.
To understand FHE accelerator status, we must distinguish between application-specific and generalized FHE accelerators.
FHE’s computational complexity and hardware design center on the number of multiplications required by the application—called “homomorphic operation depth.” For specific applications, depth is known, so system parameters and computations are fixed. Thus, application-specific hardware is easier to design and often outperforms generalized accelerators. In contrast, if FHE must support arbitrary multiplications, bootstrapping is needed to remove accumulated noise. Bootstrapping is expensive, requiring significant chip memory, bandwidth, and compute—making hardware designs vastly different from application-specific ones. While industry leaders like Intel, Duality, SRI, and DARPA advance GPU and ASIC designs, these may not directly translate to blockchain-compatible FHE acceleration.
In terms of development cost, generalized hardware requires more capital for design and manufacturing than application-specific hardware, but its flexibility enables broader applicability. Conversely, if an application’s needs evolve and deeper homomorphic computation is required, application-specific hardware must integrate software techniques (e.g., MPC) to match generalized hardware capabilities.
Notably, accelerating on-chain FHE is far harder than specific use cases (e.g., FHEML), as it must support general computation rather than a narrow set. For example, fhEVM’s current testnet processes only single-digit TPS.
Given the need for blockchain-tailored FHE accelerators, another consideration is: How transferable is ZKP hardware to FHE?
ZKPs and FHE share some modules, such as Number Theoretic Transforms (NTT) and polynomial operations. However, NTT bit widths differ: ZKP hardware supports multiple widths (e.g., 64-bit, 256-bit), while FHE uses shorter operands via the Residue Number System. Second, NTT degrees in ZKPs are typically higher than in FHE. Due to these differences, designing a single NTT module satisfying both ZKP and FHE developer needs is difficult. Additionally, FHE faces unique bottlenecks like automorphisms, absent in ZKPs. One way to reuse ZKP hardware is offloading NTT computations to it while using CPUs or other hardware for remaining FHE operations.
Summarizing these challenges: FHE computation on encrypted data was once 100,000× slower than plaintext. Thanks to newer encryption schemes and hardware advances, performance has improved to roughly 100× slower.
Solutions:
1. Improved FHE Hardware
Many teams are building FHE accelerators, but few focus on generalized blockchain computation (e.g., TFHE). An example of a blockchain-specific accelerator is FPT, a fixed-point FPGA accelerator. FPT is the first to heavily exploit inherent noise in FHE computations, implementing TFHE bootstrapping entirely via approximate fixed-point arithmetic. Another promising project is BASALISC—a series of hardware accelerator architectures designed to dramatically accelerate FHE computations in the cloud.
As previously noted, a major FHE hardware bottleneck is excessive memory interaction. A potential workaround is minimizing memory access. Processor-in-Memory (PIM) or near-memory computation could help. PIM is a promising solution to the “memory wall” challenge, enabling memory to perform both storage and computation—potentially revolutionizing compute-memory relationships. Over the past decade, significant progress has been made in non-volatile memory (e.g., ReRAM, STT-MRAM, PCM). Using such memory, studies have shown notable performance improvements in machine learning and lattice-based public-key encryption.
2. Optimized Software and Hardware
Recent developments recognize software as a critical component in hardware acceleration. Notable FHE accelerators like F1 and CraterLake use compilers for hybrid software-hardware co-design.
As the field evolves, we can expect fully featured compilers co-designed with blockchain-targeted FHE compilers. These can optimize FHE programs based on cost models of respective schemes and integrate with FHE accelerator compilers—combining hardware-level cost models to enhance end-to-end performance.
3. Networked FHE Accelerators: From Vertical to Horizontal Scaling
Current FHE hardware acceleration efforts focus on “vertical scaling”—improving individual accelerators. “Horizontal scaling,” however, connects multiple FHE accelerators via a network, potentially boosting performance—similar to parallel ZKP proof generation.
A major challenge for networked FHE acceleration is data inflation—the significant increase in data size during encryption and computation—posing challenges for efficient intra- and inter-chip data transfer.
Data inflation poses a significant hurdle for horizontally connecting multiple FHE accelerators. Thus, co-designing FHE hardware with networking will be a promising research direction. For example, adaptive network routing for FHE accelerators could dynamically adjust data paths based on real-time computational load and network traffic, ensuring optimal data transfer rates and efficient resource utilization.
Conclusion
FHE will fundamentally reshape how we protect data across platforms, paving the way for an unprecedented era of privacy. Building such systems will require major advances in FHE, zero-knowledge proofs (ZKPs), and multi-party computation (MPC).
As we enter this new frontier, collaboration among cryptographers, software engineers, and hardware experts will be essential—not to mention policymakers and regulators, as compliance is the only path to mainstream adoption.
Ultimately, FHE will stand at the forefront of a digital sovereignty revolution—ushering in a future where data privacy and security are not mutually exclusive, but inseparable.
Special Thanks
We thank Mason Song (Mind Network), Guy Itzhaki (Fhenix), Leo Fan (Cysic), Kurt Pan, Xiang Xie (PADO), and Nitanshu Lokhande (BananaHQ) for their reviews. We encourage readers to explore the impressive work these individuals are doing in this space!
Join TechFlow official community to stay tuned
Telegram:https://t.me/TechFlowDaily
X (Twitter):https://x.com/TechFlowPost
X (Twitter) EN:https://x.com/BlockFlow_News
