Abstract
Fully Homomorphic Encryption (FHE) enables computations on encrypted data without decryption, ensuring data privacy in cloud computing and preventing sensitive information leakage. In recent years, significant progress has been made in FHE research, resulting in the development of various FHE schemes and supporting libraries. However, FHE incurs substantial computational overhead, with execution times exceeding plaintext computation by 4-5 orders. As a result, optimized FHE programs can be several hundred times faster than their unoptimized counterparts, underscoring the critical importance of efficient FHE programming. However, the restricted set of primitive operations, numerous cryptographic parameters, and complexities in ciphertext management present significant challenges, rendering FHE programming prohibitively complex for users without cryptographic expertise. To address these challenges, numerous FHE programming tools, commonly referred to as FHE compilers, have been developed. These compilers aim to simplify FHE programming by allowing users to write standard plaintext programs, which are then automatically converted into ciphertext programs. They handle ciphertext management and parameter selection automatically, lowering the barrier for users. This paper systematically reviews existing FHE compilers, examining their techniques and effectiveness to explore the current state of the art and identify areas for future research. First, we analyze the challenges of FHE programming that compilers aim to address. We then outline a typical workflow of FHE compilers, classify compilers based on the problems they solve, and compare tools within each category. Finally, we provide a summary of the current state of research on FHE compilers and propose directions for future advancements in FHE programming tools.
Introduction
Fully Homomorphic Encryption (FHE) is a cryptographic scheme that enables direct computation on encrypted data without requiring decryption. When decrypted, the result of these computations is identical to (or approximate) performing the same operations on the original plaintext data. FHE enables end-to-end encrypted data processing, ensuring data security even in untrusted environments, as illustrated in Figure 1. A variety of FHE schemes have been proposed over the years, with notable examples including BGV(Brakerski et al. 2014), BFV(Clet et al. 2021), GSW(Gentry et al. 2013), CKKS(Cheon et al. 2017), and TFHE(Chillotti et al. 2020). Given its powerful privacy-preserving capabilities, FHE has been widely adopted across various domains, with numerous applications being developed(Hong et al. 2021; Lee et al. 2022; Podschwadt and Takabi 2020; Han et al. 2018).
Implementing FHE-based applications without proper tooling is challenging, as it requires extensive expertise in both cryptography and high-performance numerical computation. To address this complexity, many FHE libraries have been developed, with widely-used ones including HElib(Halevi and Shoup 2021), SEAL(Chen et al. 2017), HEAAN(snucrypto 2023), Lattigo(Mouchet et al. 2020), OpenFHE(Badawi et al. 2022), and PALISADE(PALISADE 2020). These libraries implement the underlying cryptographic operations and provide a high-level API for key generation, encryption, decryption, and homomorphic primitive operations such as addition and multiplication, significantly simplifying FHE program development.
While FHE libraries have significantly streamlined the development of FHE-based applications, implementing FHE programs remains challenging and requires substantial expertise in the underlying cryptographic schemes for several reasons. First, developers must configure numerous FHE parameters that determine both the correctness and performance of their programs. Second, beyond basic arithmetic operations, programmers must carefully manage ciphertexts to control noise growth. Third, FHE computations on CPUs are typically 4-5 orders of magnitude slower than their plaintext counterparts (Zhu et al. 2023). To reduce this computational overhead, developers must effectively utilize Single Instruction Multiple Data (SIMD) features available in schemes such as BFV and CKKS. Suboptimal implementation can result in severely degraded performance. Even for FHE experts, developing highly optimized FHE programs for specific applications remains challenging, as exemplified by Lee et al. (2022)’s FHE ResNet-20 implementation, which builds upon years of prior research (Brutzkus et al. 2019; Gilad-Bachrach et al. 2016; Juvekar et al. 2018; Lee et al. 2022).
In response to these challenges, recent years have witnessed the emergence of higher-level tools, particularly FHE compilers, designed to translate conventional programs into FHE implementations. Unlike traditional CPU compilers that generate libraries or executables, FHE compilers typically produce programs based on homomorphic encryption libraries. While CPU compilers generate machine instructions defined by the Application Binary Interface (ABI), most FHE compilers function as source-to-source compilers or transpilers, generating code that utilizes FHE library APIs, with some compilers directly producing executables.
FHE compilers offer dual advantages: they significantly lower the barrier to entry, enabling non-experts to develop FHE programs without extensive cryptographic knowledge, and they often generate code that outperforms manually optimized implementations by experts (Dathathri et al. 2019, 2020). These compilers increasingly incorporate sophisticated optimizations previously available only to domain experts. Unlike hardware accelerators (Kim et al. 2023; Samardzic et al. 2022; Kim et al. 2022; Samardzic et al. 2021; Kim et al. 2022; Agrawal et al. 2023; Yang et al. 2023; Fan et al. 2023; Jung et al. 2021), compiler-based optimizations are device-agnostic and introduce minimal overhead.
The field has seen proliferation of FHE compilers across various schemes. For the BGV scheme, Alchemy (Crockett et al. 2018) has been developed. The BFV scheme is supported by multiple compilers including Marble (Viand and Shafagh 2018), E3 (Chielle et al. 2018), SEALion (Elsloo et al. 2019), RAMPARTS (Archer et al. 2019), Porcupine (Cowan et al. 2021), Coyote (Malik et al. 2023), and HECO (Viand et al. 2023). The CKKS scheme is addressed by nGraph-HE2 (Boemer et al. 2019a, b), CHET (Dathathri et al. 2019), AHEC (Chen et al. 2020), EVA (Dathathri et al. 2020), Hecate (Lee et al. 2022), ELASM (Lee et al. 2023), FHE-Booster (White et al. 2023), HeLayers (Aharoni et al. 2023), Reserve(Lee et al. 2024), DaCapo (Cheon et al. 2024), Fhelipe (Krastev et al. 2024), HALO(Cheon et al. 2025), and Orion(Ebel et al. 2025). Boolean schemes are supported by Cingulata (Carpov et al. 2015), Lobster (Lee et al. 2020), T2 (Gouert et al. 2023), Google’s transpiler (Gorantala et al. 2021), and CONCRETE (Chillotti et al. 2020). Some compilers support multiple schemes (Gouert et al. 2023; Chielle et al. 2018; Boemer et al. 2019a), and most can be extended to similar schemes with moderate effort.
To better understand the current challenges and potential of FHE compiler research, we survey literature on CKKS homomorphic encryption compilers published between 2019 and 2025 in leading conferences in the fields of security and compilers (e.g., PLDI, ASPLOS, CGO, Security), present a comprehensive analysis of representative compilers, examining their techniques and effectiveness, and discuss future research directions. We focus on the CKKS scheme and its RNS variant, RNS-CKKS (Cheon et al. 2018), which are particularly well-suited for machine learning (ML) workloads (Viand et al. 2021). Their suitability stems from superior packing efficiency — a single ciphertext can encrypt a vector of tens of thousands of elements, offering a capacity approximately ten times greater than BGV/BFV and thousands of times greater than TFHE — and direct support for real/complex numbers, including rounding operations.
This paper is structured as follows: Section Background introduces the CKKS scheme, covering its constraints and noise model, which provide the foundation for subsequent discussions on compiler techniques. Section Main challenges of writing FHE programs outlines the challenges in FHE programming that compilers aim to address. Section Typical workflow of FHE compilers details a typical workflow of FHE compilers. Section Overview of FHE compilers provides an overview of the FHE compilers included in this survey. Section Key aspects of FHE compilers categorizes and analyzes FHE compiler techniques. Finally, Section Other compilers briefly introduces additional FHE compilers.
Related work
Existing surveys on homomorphic encryption are summarized in Table 1.
Comprehensive surveys on FHE. (Marcolla et al. 2022) remains the most comprehensive survey of FHE to date, covering the evolution of schemes, security and known attacks, applications in machine learning, Internet of Things (IoT), and cloud computing, as well as available libraries, hardware accelerators, and compilers. For compilers, it identifies key challenges and, in Table 4, lists (as of 2021) most FHE compilers together with the schemes they support, their input languages, and maintenance status. (Liu et al. 2025) is the most detailed survey of the CKKS scheme, reviewing the evolution of bootstrapping algorithms, precision-improvement techniques, major variants such as RNS-CKKS, applications, and open-source implementations.
Survey on HE, FHE schemes and the CKKS scheme. (Fontaine and Galand 2007) reviewed homomorphic encryption (HE) schemes prior to the first FHE construction, and therefore only covered Partially Homomorphic Encryption (PHE). In 2017, (Martins et al. 2017) presented a broad survey of both PHE and emerging Fully Homomorphic Encryption (FHE) schemes, including performance comparisons and an identification of attack types. (Acar et al. 2018) likewise surveyed PHE and FHE, with greater emphasis on implementations, reported runtimes, and open problems. However, neither (Martins et al. 2017) nor (Acar et al. 2018) included the now widely used CKKS and TFHE schemes. (Doan et al. 2023) also surveyed PHE and FHE and, unlike the earlier two, covered CKKS and TFHE. It added more extensive discussion of parameter selection to guide practitioners and compared performance across schemes using existing libraries, concluding that PHE remains significantly faster and, among FHE schemes, CKKS is typically the most efficient.
Survey on acceleration of FHE schemes. Primitive-level acceleration techniques fall into two classes: algorithmic optimizations and hardware mappings (which retain the algorithm but implement it more efficiently on CPUs, GPUs, FPGAs, ASICs, etc.). (Latibari et al. 2023) reviewed hardware accelerators for multiple FHE schemes (CKKS, BFV, BGV, TFHE) across CPU, FPGA, GPU, and ASIC platforms, analyzing their main design concepts. Its limitations include sparse coverage of post-2022 work, omitting notable systems such as Ark (Kim et al. 2022) and SHARP (Kim et al. 2023). (Gong et al. 2024) surveyed acceleration from both algorithmic (NTT, bootstrapping, encoding) and hardware (CPU, GPU, FPGA, ASIC, and Processing-in-Memory) perspectives. Its coverage (2019–2022) is broader than (Latibari et al. 2023) but still excludes more recent systems such as SHARP (Kim et al. 2023) and GME (Shivdikar et al. 2023). (Zhang et al. 2024) analyzed 14 FHE accelerators (cuHE/cuFHE, nuFHE, HEAT, HEAX, HEXL, HEXL-FPGA, 100\(\times\), F1, CraterLake, BTS, ARK, Poseidon, FAB, TensorFHE), tracing their evolutionary trajectory and comparing NTT and key-switching performance for the open-source HEXL, HEXL-FPGA, and 100\(\times\). A notable contribution is its forward-looking outlook on future research directions–for example, advocating unified support for both word-wise and bit-wise FHE schemes, subsequently exemplified by Trinity (Deng et al. 2024).
Surveys on HE applications. (Alharbi et al. 2020) reviewed applications of homomorphic encryption in vehicular communication, cloud computing, signal processing, healthcare, electronic voting, blockchain, and data mining. (Bansal 2021) focused on cloud computing, electronic voting, and the Internet of Things. (Wood et al. 2020) provided an overview of FHE applications in medicine and bioinformatics, including logistic regression, naïve Bayes, decision trees, neural networks, sequence comparison, genetic testing, and secure genome-wide association studies.
Survey on FHE libraries. Several studies compare FHE libraries. Tsuji and Oguchi (2024) measure execution time and memory usage for major primitive operations in Lattigo and OpenFHE across BFV, BGV, and CKKS. Pal et al. (2023) focus on CKKS, comparing execution time and power consumption for primitive operations and a 3-layer neural network across SEAL (Chen et al. 2017), HEaaN (CryptoLab 2022), Lattigo (Mouchet et al. 2020), and OpenFHE (Badawi et al. 2022). Gouert et al. (2023) benchmark multiple FHE libraries and schemes by compiling a common set of programs via the T2 compiler and executing them across libraries to compare runtimes (summarized in Table 1). Zhu et al. (2023) use a CNN benchmark to compare execution times of SEAL, OpenFHE, and HElib under CKKS.
Surveys on FHE compilers. Surveys dedicated specifically to FHE compilers are scarce. Viand et al. (2021) provided a systematic survey and evaluation of then-available FHE libraries and prominent compilers, assessing accessibility (documentation, examples, maintenance) and comparing runtime performance on several benchmarks. In 2025, (Lewington 2025) evaluated two promising compilers–the CKKS compiler EVA (Dathathri et al. 2020) and the TFHE compiler Google Transpiler (Gorantala et al. 2021)–using polynomial evaluation, Fibonacci evaluation, and a bioinformatics genomic comparison workload (Edit and Hamming distance). It compared usability, expressiveness, and performance, concluding that EVA offers superior usability due to its simpler Python front end, while the Google Transpiler attains greater expressiveness owing to the flexibility of TFHE (e.g., supporting Hamming and edit distance computations that EVA cannot express). In tasks both can express, the Transpiler lags EVA in performance.
Our contribution. Despite numerous HE surveys, dedicated analyses of FHE compilers remain limited, and no existing survey dissects their underlying innovations. This survey differs in three respects: 1) Whereas prior work largely adopts an end-user perspective, we analyze compiler techniques and design innovations to outline a research roadmap. 2) We incorporate influential compilers released after Viand et al. (2021) (2021). 3) We focus on the CKKS scheme, currently the most widely adopted in machine learning and an especially active locus of compiler research.
Background
Section CKKS scheme and primitive operations introduces the fundamental concepts of the CKKS scheme, covering its encryption and decryption processes as well as the homomorphic primitive operations it supports. Section Constraints and scale management operations describes the constraints that operands of primitive operations must satisfy, as well as the scale management operations employed to meet these constraints. Section Noise model of RNS-CKKS presents the noise model of the RNS-CKKS scheme. Table 2 summarizes the key notations used throughout the paper.
CKKS scheme and primitive operations
In the CKKS scheme, a message is an unencrypted complex vector of length \(n\), where \(n\) represents the number of slots. Through encoding, this message is transformed into an \(N-1\) degree polynomial \(\mu \in \mathcal {R}_{Q}\), where \(N\) is a power of 2, \(Q\) is the ciphertext modulus, and \(n \le N/2\). The security level \(\lambda\) exhibits a positive correlation with \(N\) and a negative correlation with \(Q\). For a fixed security level (e.g., 128-bit), each value of \(N\) corresponds to an upper bound on the bit-width of \(Q\). The encoding process involves multiplying the real-coefficient polynomial by a scaling factor \(\Delta\) and rounding the result to obtain an integer-coefficient polynomial. The secret key is defined as \((1, s)\), where \(s\) is a polynomial with coefficients in \(\{0, 1, -1\}\). The public key consists of a polynomial pair \((- a \cdot s+e, a) \in \mathcal {R}_{Q}^{2}\), where \(a\) is uniformly sampled from \(\mathcal {R}_{Q}\), and \(e\) is a small-coefficient error polynomial sampled from a discrete Gaussian distribution. Encryption generates a ciphertext \(\text {ct}=(- a \cdot s+e+\mu , a) \in \mathcal {R}_{Q}^{2}\), while decryption computes \((-a\cdot s+e+\mu , a) \cdot (1,s) = e+\mu\). The decrypted result includes an error term \(e\), making it an approximation of the original message. The scaling factor \(\Delta\) inversely affects the magnitude of the approximation error: a larger \(\Delta\) yields a smaller approximation error.
The polynomial modulus \(Q\) typically spans hundreds to thousands of bits. To circumvent inefficient large-number operations, prominent homomorphic encryption libraries (Badawi et al. 2022; Chen et al. 2017; Mouchet et al. 2020) implement the Residual Number System (RNS) variant of the CKKS scheme (RNS-CKKS) (Cheon et al. 2018). This variant decomposes \(Q\) into a product of small word-size primes \(Q= \prod _{i=1}^{L} q_{i}\), where polynomial coefficients are represented in RNS as \(L\) numbers within \(q_{i}\). Consequently, polynomials in \(\mathcal {R}_{Q}\) can be represented by \(L\) polynomials with word-size coefficients.
A fundamental property of homomorphic encryption is its support for FHE primitive operations in Table 3, satisfying \(\text {Decrypt}(f(\textbf{ct})) \approx f(\mu )\), which enables direct computation on ciphertexts. Among these operations, HMult and HRot incorporate the KeySwitch operation, which transforms a ciphertext encrypted under one secret key into a ciphertext under another. Due to KeySwitch’s substantial computational overhead, HMult and HRot exhibit significantly longer latency compared to other FHE operations, as evidenced in Table 4. Additionally, KeySwitch requires an evaluation key \(\text {evk}\), where all HMult operations share a common multiplication key \(\text {evk}_{\text {mult}}\), while each distinct rotation amount \(r\) in HRot necessitates a separate rotation key \(\text {evk}_{\text {rot}}^{(r)}\).
The multiplication operations PMult, CMult, and HMult present a scaling challenge: when both operands have scaling factor \(\Delta\), the resulting ciphertext’s scaling factor becomes \(\Delta ^{2}\). Without proper management, the scales and noise of ciphertexts would grow exponentially with the program’s multiplicative depth. To mitigate this issue, Rescale operations must be strategically inserted. Rescale divides both the ciphertext’s scaling factor and modulus by a predetermined value. In the RNS-CKKS scheme, Rescale eliminates the last prime in \(q_{1}, q_{2}, \ldots , q_{\ell }\). The level \(\ell\) denotes the remaining number of moduli in the ciphertext’s modulus, initially set to \(L\) and decreasing by 1 after each Rescale operation. Consequently, the ciphertext’s level \(\ell\) progressively decreases during homomorphic computations due to multiplication operations.
To support unlimited multiplications, Bootstrapping is essential for elevating the ciphertext’s level to \(L_{\text {eff}}\). Bootstrapping consists of multiple FHE operations, including numerous HMult and HRot operations. Due to its internal multiplication operations, bootstrapping consumes \(L_{\text {boot}}\) levels from the initial budget of \(L\) levels. This leaves an effective \(L_{\text {eff}} = L - L_{\text {boot}}\) levels for subsequent computations. Typical values for \(L_{\text {eff}}\) range from a few to approximately a dozen. Bootstrapping operations are computationally intensive, requiring several tenths of a second to multiple seconds, and demand dozens of rotation keys. For instance (Kim et al. 2023), in applications such as homomorphic encryption logistic regression (HELR) (Han et al. 2019), Bootstrapping accounts for over 50% of the total computation time. This proportion exceeds 80% in applications like ResNet-20 (Lee et al. 2022) and sorting (Hong et al. 2021).
Constraints and scale management operations
Operands of primitive operations must satisfy the following two key constraints.
- Constraint 1:
-
Operands of binary operations (PAdd, HAdd, PMult, HMult) must have the same level.
- Constraint 2:
-
Operands of addition (PAdd, HAdd) must have the same scaling factors.
To satisfy these constraints, scale management operations detailed in Table 5 are essential. These operations modify the scaling factor and/or level of ciphertexts, as shown in Table 5. Note that scale management operations serve only to ensure correctness by satisfying constraints and do not alter the underlying values stored in ciphertexts. Consider, for example, the computation of \(x^{2}+x\). Assuming \(\Delta \approx q_{i}\) and a Rescale operation follows \(x^{2}\), the level of \(x^{2}\) becomes one less than that of \(x\). To satisfy Constraint 1, we must apply a ModSwitch operation to \(x\) to decrease its level by 1 while maintaining its scaling factor, thereby satisfying both Constraint 1 and Constraint 2.
Noise model of RNS-CKKS
In addition to the initial encryption noise (Section CKKS scheme and primitive operations), operations HMult, HRot, and Rescale introduce additional noise into the resulting ciphertext (Kim et al. 2022; Lee et al. 2023). Table 6 quantifies both the introduced noise and the estimated total noise in the output ciphertext.
Main challenges of writing FHE programs
Writing homomorphic encryption programs poses significant challenges. This section analyzes the main challenges in developing FHE programs, which are key obstacles that FHE compilers need to address.
Challenge 1: describing FHE programs with appropriate primitive operations
The first challenge in developing FHE programs lies in effectively utilizing the FHE primitives outlined in Table 3 to construct programs. This challenge encompasses several key aspects: First, FHE primitives offer a limited set of operations. Second, these primitives operate on extensive vectors (ranging from thousands to tens of thousands of elements), necessitating efficient slot utilization and computational optimization. Third, determining optimal tensor layouts presents another significant consideration for program efficiency.
Limited FHE Primitives. FHE programs rely on homomorphic primitive operations for computation. These primitives are highly constrained, limited to vector element-wise addition, element-wise multiplication, and rotation shifts. Many operations that are computationally trivial for CPUs become expensive in FHE contexts. For instance, accessing a single vector element requires both masking (multiplying a ciphertext with a plaintext vector of 1s and 0s) and rotation. While PMult is computationally straightforward, it consumes levels, and HRot is computationally expensive. Similarly, vector shuffling, which is inexpensive for CPUs, requires multiple rotations, masking, and addition operations in FHE, potentially requiring tens to hundreds of rotations and consuming numerous levels (Halevi and Shoup 2018).
Utilization of SIMD-pattern. FHE primitives operate on long vectors, with ciphertexts containing thousands to tens of thousands of slots, raising questions about optimal slot utilization and computational efficiency. Consider convolution as an example: implementing it naively using the algorithm in Listing 1a would require numerous rotation and masking operations, making it impractical. In contrast, Juvekar et al. (2018) proposed single-input single-output (SISO) convolution, completing the operation with only \(k^{2}-1\) rotations (\(k\) being the kernel size) and \(k^{2}\) PMult operations between image ciphertext and filters, eliminating the need for maskingFootnote 1. Such sophisticated implementations can improve efficiency by orders of magnitude, though designing these non-intuitive optimizations presents significant challenges.
Data Layout and conversion. Selecting optimal layouts for tensors is crucial in FHE programming as it can dramatically improve slot utilization and reduce the number of operations. Consider a \(128 \times 128\) matrix-vector multiplication: storing each matrix row in a separate ciphertext would be tremendously inefficient, utilizing only 128 slots per ciphertext and requiring 128 multiplications. Instead, the entire matrix can be packed into one ciphertext. Figure 2 illustrates this approach using a scaled-down example, where the matrix size is 4 and \(n=16\). In Figure 2b, matrix \(A\) is stored in row-major order, with vector \(v\) replicated to match \(A\)’s shape, requiring only one multiplication and 14 rotations. This approach minimizes ciphertext and plaintext counts while improving computational efficiency.
However, challenges arise when the output ciphertext in Figure 2b becomes an operand in another matrix-vector multiplication \(B \cdot y\). Converting its layout to match \(x\) would require 127 rotations and 128 masking operations, exceeding the cost of the matrix multiplication itself. An alternative solution is to pack \(B\) in column-major layout, as shown in Figure 2c, which avoids expensive layout conversion and retains the same computational cost as in Figure 2b. This example demonstrates that FHE programming must consider both initial data layouts and potential layout transformations during computation, as conversion costs are substantial. This complexity greatly increases the difficulty of manual programming efforts.
Challenge 2: complying with the constraints of FHE
Section Constraints and scale management operations presents the constraints that homomorphic primitive operations must satisfy and the additional scale management operations required to meet these constraints. While choosing the most intuitive scale management operation insertion strategy may seem appealing, it often yields suboptimal results.
Consider Constraint 2, inserting a Rescale operation after each multiplication represents the most straightforward approach (ALWAYS-RESCALE). However, Figure 3 demonstrates the inefficiency of this strategy through an example (Dathathri et al. 2020) computing \(x^2 + x\), where \(x\) has a scaling factor of \(2^{30}\). Figure 3b illustrates the computation process using ALWAYS-RESCALE, where a Rescale operation following multiplication creates a level difference of 1 between \(x^2\) and \(x\). To satisfy Constraint 1, an additional ModSwitch operation must be applied to \(x\). In contrast, Fiugre 3c presents an alternative scale management approach that omits the Rescale operation on \(x^2\), maintaining its scaling factor at \(2^{60}\). By applying \(\operatorname {Upscale}(2^{30})\) to \(x\), both terms achieve identical scaling factor values. This approach reduces level consumption by one compared to 3b, making it more efficient.
The placement of Bootstrap operations presents another critical consideration, as demonstrated in Figure 4 (Krastev et al. 2024). Given a ResNet computation segment in Figure 4a, the intuitive approach in Figure 4b inserts Bootstrap operations before multiplication whenever operands reach level 0 (LAZY-BOOSTRAP). However, this strategy presents two significant drawbacks: (1) redundant Bootstrap operations for each distinct rotate shift result, and (2) more critically, when summing with the Residual at level 0, the results of three multiplications must undergo ModSwitch to level 0, effectively nullifying the benefits of three Bootstrap operations. Given the substantial computational overhead of Bootstrap operations, this inefficiency is particularly problematic. The approach in Figure 4b offers a superior solution by performing Bootstrap before rotate shift operations, requiring only one Bootstrap while achieving a final level of 9, substantially outperforming approach LAZY-BOOSTRAP.
These examples underscore the complexity of ciphertext maintenance, where suboptimal placement of scale management operations and Bootstrap operations can significantly impact performance. A primary objective of the compiler is to optimize the placement of scale management operations and Bootstrap to enhance both the performance and precision of homomorphic programs.
Challenge 3: parameter selection
FHE programs involve numerous cryptographic parameters. The CKKS scheme incorporates several crucial parameters: the number of polynomial terms (\(N\)), the initial level of ciphertexts (\(L\)), the bit length of small primes (\(q_{j}\)) (\(B\)), and various implementation-specific optimization parameters, such as the decomposition number (\(\texttt{dnum}\)) in KeySwitch. These parameters and their combinations significantly influence the correctness, security, and performance of FHE programs through complex interdependent relationships.
Different parameter configurations can cause the latency of FHE programs to increase by several times (Cheon et al. 2018). The computational complexity of homomorphic operations scales proportionally with \(N\). For instance, when \(N=16384\), the computational cost doubles compared to \(N=8192\). However, \(N\) also affects the security level, and insufficient \(N\) values may compromise security requirements. Moreover, \(N\) determines the vector length in FHE applications, leading to varying utilization of slots.
The computational overhead of primitive operations is proportional to \(\ell\), suggesting that a reduced \(L\) decreases computational costs. However, as discussed in Section Constraints and scale management operations, homomorphic multiplications decrease the level. Insufficient \(L\) may result in inadequate multiplicative depth for completing the FHE workload.
Regarding \(B\), larger values enhance the precision of FHE programs, e.g., improving neural network accuracy. However, as explained in Section CKKS scheme and primitive operations, at a fixed security level, \(N\) constrains the upper bound of \(Q\), consequently reducing \(L\). Conversely, an inadequate \(B\) value compromises application precision and may yield incorrect results.
Parameter selection critically affects noise control and program correctness in CKKS, presenting unique challenges compared to BFV and BGV schemes. This distinction arises from two key factors: First, CKKS cannot completely eliminate noise from ciphertexts, resulting in approximate rather than exact decryption results. In contrast, BFV and BGV schemes achieve exact message recovery when noise remains below the threshold. Second, unlike other schemes where bootstrapping reduces ciphertext noise, CKKS bootstrapping merely enables continued multiplication operations without reducing the noise. Consequently, inserting scale management operations to satisfy homomorphic program constraints does not guarantee noise reduction, significantly impacting precision and correctness. For example (Kim et al. 2023), ResNet-20 (Lee et al. 2022) achieves 89.53% accuracy with \(B=33\), but accuracy deteriorates to 10.87% with \(B=31\), indicating complete program failure.
Different applications have varying requirements: some, like neural networks (Podschwadt and Takabi 2020; Lee et al. 2022), are relatively precision-tolerant but demand greater multiplication depth, while others, such as sorting (Hong et al. 2021), are highly precision-sensitive. These diverse requirements necessitate application-specific parameter optimization, presenting a significant challenge in navigating the extensive parameter space.
Typical workflow of FHE compilers
A typical workflow of FHE compilers is shown in Figure 5. Depending on the specific FHE compiler, input programs may either consist of low-level FHE primitive operations, as listed in Table 3, or resemble high-level programming languages. Examples of the latter include tensor programs, such as those written in PyTorch (Paszke et al. 2019), or standard scalar programs. FHE compilers parse the input program into an in-memory representation, which varies between compilers. For instance, the in-memory representation in EVA is an abstract semantic graph, whereas Hecate and ELASM use a graph of units, where each unit has a consistent scale and level.
The compiler then applies transformation passes at the primitive operations level to optimize the program by expressing it with more efficient primitive operations. Not all compilers include this step; some focus solely on scale management and parameter selection without modifying the primitive operations. Next, the compiler inserts scale management operations and Bootstrap to ensure the program satisfies the constraints outlined in Section Constraints and scale management operations. Additionally, it determines all the evaluation keys required by the program. Following this, the compiler selects the FHE parameters, ensuring they meet the target security level (typically 128-bit). Finally, the compiler generates the output program, which may take the form of source code files utilizing APIs of the target backend libraries, or as executables linked to the target backend libraries. In less common cases, FHE compilers may operate independently of any FHE libraries and produce standalone executables.
Key aspects of FHE compilers
In this section, we analyze how the FHE compilers listed in Table 7 address three key challenges in FHE programming through various techniques and contributions. We first present an overview of FHE compilers in Section Overview of FHE compilers. Subsequently, our analysis focuses on five main categories: scale management (Section Scale management), bootstrapping insertion (Section Bootstrapping insertion), data layout optimization (Section Data layout), SIMD parallelization (Section SIMD), and parameter selection (Section Parameter selection).
Overview of FHE compilers
Table 7 summarizes the FHE compilers discussed in this survey along with their key properties. This survey primarily focuses on compilers that support the RNS-CKKS scheme or can be readily extended to it, highlighting representative methods developed over the past five years, including CHET (Dathathri et al. 2019), EVA (Dathathri et al. 2020), Porcupine (Cowan et al. 2021), Hecate (Lee et al. 2022), Coyote (Malik et al. 2023), HECO (Viand et al. 2023), ELASM (Lee et al. 2023), Reserve (Lee et al. 2024), DaCapo (Cheon et al. 2024), and Fhelipe (Krastev et al. 2024). The sole exception is Coyote, which cannot be easily adapted to CKKS (as explained in Section Coyote). Additional compilers, including AHEC (Chen et al. 2020), HeLayers (Aharoni et al. 2023), nGraph-HE2 (Boemer et al. 2019b, a), Alchemy (Crockett et al. 2018), T2 (Gouert et al. 2023), and FHE-Booster (White et al. 2023), are discussed in Section Other compilers. Several compilers, including Cingulata(Carpov et al. 2015), SEALion(Elsloo et al. 2019), Alchemy(Crockett et al. 2018), Ramparts(Archer et al. 2019), Marble(Viand and Shafagh 2018), and E3(Chielle et al. 2018), have been thoroughly analyzed in SoK(Viand et al. 2021) and thus are not revisited here. Additionally, Lobster(Lee et al. 2020), Google’s transpiler(Gorantala et al. 2021), and CONCRETE(Chillotti et al. 2020), which focus on boolean schemes, fall outside this survey’s scope.
Current FHE compilers aim to address one or more challenges outlined in Section Main challenges of writing FHE programs. Based on their primary contributions and frontend programs, they can be categorized into three groups:
-
1.
FHE compilers addressing Challenge 2, without addressing Challenge 1: This group includes EVA, Hecate, ELASM, DaCapo, Reserve, and HALO. Among these, DaCapo and HALO implements automatic bootstrapping insertion, while others focus on managing scale operations such as Rescale, ModSwitch, and Upscale. Scale management is discussed in Section Scale management, and bootstrapping insertion is detailed in Section Bootstrapping insertion. Their frontend languages support arithmetic operations corresponding directly to FHE primitives listed in Table 3, with data types limited to ciphertext vectors, plaintext vectors, floats, and integers. All vector lengths are fixed to the number of slots in a ciphertext (\(n\)). While users must still express their programs using FHE primitive arithmetic operations, these compilers abstract away details such as scale management and parameter selection.
-
2.
FHE compilers addressing Challenge 1 with tensor language frontends: This group includes CHET, Fhelipe and Orion, which focus on data layout selection and tensor conversion. Their approaches are examined in Section Data layout. Fhelipe and Orion also propose methods for optimal bootstrapping insertion, discussed in Section 4.3.
-
3.
FHE compilers addressing Challenge 1 with scalar program frontends: This group includes Porcupine, Coyote, and HECO, which provide frontends for normal scalar programs with statically sized loops (e.g., Listing 1a) rather than tensor operations. These compilers focus on leveraging FHE SIMD capabilities while minimizing latency. Their methodologies are analyzed in Section SIMD.
Compilers in Groups 2 and 3 abstract FHE details from users by incorporating existing methods for scale management and parameter selection.
For Challenge 3, all compilers support automatic parameter selection. Table 7 lists compilers explicitly providing parameter selection methods in their respective papers, including CHET, EVA, and Fhelipe. These methods are discussed in Section Parameter selection, while limitations in existing parameter selection techniques are reviewed in Section Discussion and future directions.
Regarding frontends, most compilers accept Python DSLs as input programs. In the Input Program column, “Low-level” indicates programs restricted to FHE primitive operations (Table 3). “NN models” denotes compilers specialized for neural networks rather than general-purpose use. “Tensor programs” refers to general-purpose compilers using tensors as the primary data type, supporting tensor operations. “High-level” describes programs resembling standard code, including scalar operations and control flow. Due to FHE constraints, loop and branch conditions cannot depend on secret data. In the Program Size column, “Small” denotes compilers limited to kernel generation (\(\le 12\) instructions) unsuitable for large programs due to long compilation times. “Medium” indicates a lack of bootstrapping support, limiting program depth. “Large” signifies bootstrapping support, enabling deep and complex programs.
For the backend, most compilers target SEAL, a mature, widely-used library under active maintenance. However, SEAL lacks bootstrapping interfaces, limiting many compilers to small, shallow applications and preventing support for tasks such as homomorphic logistic regression training (Han et al. 2018) and ResNet-20 inference (Lee et al. 2022). Compilers supporting bootstrapping rely on alternative libraries. For instance, DaCapo uses the GPU-accelerated RNS-CKKS library HEaaN (CryptoLab 2022), while Fhelipe utilizes Lattigo.
Scale management
Scale management, which involves inserting operations defined in Table 5 at strategic positions, ensures FHE programs meet the constraints outlined in Section Constraints and scale management operations. This represents one aspect of ciphertext maintenance (Challenge 2), with Bootstrapping insertion — discussed in Section Bootstrapping insertion — being the other. Scale management significantly impacts both the performance and accuracy of FHE programs. Optimal scale management enables the use of smaller FHE parameters (primarily \(L\) and \(N\)), reducing overall program latency. It also allows heavy operations (HMult, HRot) to execute at lower levels, thereby decreasing their individual latencies. Furthermore, proper scale management minimizes the deviation between the output and the plaintext result.
We examine four FHE compilers that introduce novel scale management methods. EVA (Section EVA) was the first compiler to prioritize scale management optimization, establishing fundamental techniques that subsequent compilers have adopted. Hecate (Section 4.2) extends EVA’s framework with two key innovations: (1) introducing the Downscale operation and its derivative proactive Rescale mechanism, and (2) employing a cost model-driven search procedure to determine optimal scale management configurations. ELASM (Section 4.2), building on Hecate, introduces the scale-to-noise ratio (SNR) concept and noise-aware waterline, enabling users to balance error rates against latency. The Reserve compiler (Section 4.2) leverages a backward reserve analysis to eliminate the search procedure, significantly reducing compilation time while achieving performance comparable to Hecate.
EVA
EVA first converts the input FHE program into an abstract semantic graph as its internal representation. It then applies three rules sequentially: WATERLINE-RESCALE, EAGER-MODSWITCH, and MATCH-SCALE to manage scale and satisfy constraints. WATERLINE-RESCALE inserts Rescale operations to prevent scaling factor expansion. EAGER-MODSWITCH inserts ModSwitch operations to ensure all homomorphic binary operations satisfy Constraint 1. MATCH-SCALE inserts Upscale operations on addition operands to ensure all addition operations satisfy Constraint 2.
WATERLINE-RESCALE. This rule operates on two key principles: (1) Rescale operations always divide by \(s_{f}\), the maximum modulus allowed by FHE libraries, and (2) the scaling factor of ciphertexts after Rescale must not fall below the waterline \(s_{w}\). Rescale operations are inserted after homomorphic multiplication, subject to the condition that the post-Rescale scaling factor remains above \(s_{w}\). This approach minimizes level consumption while maintaining reasonable precision by controlling ciphertext error. Common FHE libraries — SEAL(Chen et al. 2017), Lattigo(Mouchet et al. 2020), and OpenFHE(Badawi et al. 2022) — use \(s_{f}=2^{60}\). The waterline \(s_{w}\) is set to the maximum of all input scaling factor values. In EVA, users can specify different input scaling factor values for both ciphertexts and plaintexts. WATERLINE-RESCALE requires only a single forward pass.
EAGER-MODSWITCH. This rule employs a backward pass starting from the output node. From the backward perspective, a node’s children are its input operands, and its parents are the nodes dependent on it. Level-order traversal ensures all parent nodes are visited before processing any node. Each node maintains a ‘rlevel’ (reverse level) attribute: for rescale nodes, node.rlevel = parent.rlevel + 1; otherwise, node.rlevel = parent.rlevel, with root.rlevel = 0. When parent nodes have different rlevels, ModSwitch operations are inserted between the node and its parents with lower rlevels to equalize them. In Figure 6, while Figure 6b demonstrates the simpler LAZY-MODSWITCH approach of applying ModSwitch to the higher-level input during homomorphic addition, Figure 6c shows EAGER-MODSWITCH. Though both consume the same levels, Figure 6c performs homomorphic addition at lower levels, yielding better performance.
MATCH-SCALE. This rule performs a forward pass to handle homomorphic addition. When operands have different scaling factor values \(s_{1}\) and \(s_{2}\), where \(s_{1} Downscale > ModSwitch, as Rescale divides scaling factor by \(s_{f}\), Downscale divides scaling factor by \(\frac{s}{s_{w}}\) (where \(\frac{s}{s_{w}}4:(2,10) indicates insertion of two Rescale operations and Upscale(10). ELASM’s cost function differs from HECATE’s by considering both latency and error: \(\sqrt{T} \cdot \left( 60+\log _2 E\right)\), where \(T\) represents latency and \(E\) represents error. The space exploration workflow remains consistent with HECATE’s approach.
Experimental results show that at equivalent latency, ELASM achieves 4.2 bits \((18.1 \times )\) and 5.7 bits \((51.2 \times )\) lower error compared to HECATE and EVA on average. At equivalent error levels, ELASM demonstrates 16.7% and 24.9% lower latency than HECATE and EVA on average. The improved precision stems from strategic Upscale insertion and noise-aware waterline ensuring adequate scaling factor for high-noise operations. Performance improvements result from noise-aware waterline enabling lower waterlines for low-noise operations, allowing reduced homomorphic parameters. ELASM provides error-latency control through the SNR parameter, with users able to increase SNR for enhanced precision or decrease it for improved performance. Experiments demonstrate \(R^2\) values exceeding 0.95 for linear fitting between SNR parameter and error across all benchmarks. Similar to HECATE, ELASM exhibits extended compilation times, requiring hundreds of seconds for LeNet-scale benchmarks.
Reserve
Similar to Hecate, Reserve is motivated by the observation that EVA is performance-oblivious and heavy operations exhibit varying latencies across different levels. To avoid excessive compilation time like Hecate, this work adopts a static analysis approach as EVA instead of search procedures. However, a forward pass manner inherently cannot evaluate the total program cost, as it lacks visibility into succeeding operations and current levels. To address these limitations, this work implements a backward pass approach by introducing a novel scale management concept reserve.
Reserve (\(r\)) is defined as the coefficient modulus over the current scale of a ciphertext or plaintext, i.e., \(r=s_{f}^{\ell } / m\), representing the available scale budget of a ciphertext. For conciseness, logarithmic notation is employed: let \(\omega =\log _{s_{f}}{s_{w}}\) and \(\rho =\log _{s_{f}}r\). From the definition of reserve, we derive \(\ell =\rho + \log _{s_{f}}{m}\). Since waterline \(s_{w}\) serves as the lower bound of scale, \(\log _{s_{f}}m \ge \omega\), therefore \(\ell \ge \rho + \omega\). Due to WATERLINE-RESCALE, \(\ell < \rho +\omega +1\). Therefore, \(\lceil \rho +\omega \rceil\) is the level of the ciphertext after scale management and is called principal level.
Using reserve, the constraints in Section Constraints and scale management operations can be expressed as:
-
Operands of additions must maintain identical reserves
-
Operands of HMult must satisfy \(\ell =\lceil \rho _{1}+ \omega \rceil = \lceil \rho _{2}+\omega \rceil\)
Plaintexts are assigned a default scale of \(s_{w}\). All unary operations, additions (HAdd and PAdd), and Rescale preserve the ciphertext’s reserve. The invariant property of reserve over Rescale is critical for decoupling scale analysis from placing scale management operations. For \(\text {Upscale}(s)\), the output reserve is defined as \(r_{\text {out}}=\frac{r_{\text {in}}}{s}\). In PMult operations, \(r_{\text {out}}=\frac{r}{s_{w}}\), equivalently \(\rho _{\text {out}}=\rho -\omega\). For HMult operations, \(r_{\text {out}}=\frac{q^{\ell }}{m_{\text {result}}}=\frac{q^{\ell }}{m_{1}\cdot m_{2}}= \frac{q^{\ell }}{(q^{\ell }/r_{1}) \cdot (q^{\ell }/r_{2})}=\frac{r_{1}\cdot r_{2}}{q^{\ell }}\), yielding \(\rho _{\text {out}}=\rho _{1}+{\rho }_{2}-\ell\).
The performance optimization consists of two main phases:
-
1.
Reserve analysis, which determines the reserve and the level for all ciphertexts. This process begins by cost estimation and prioritizing allocation ordering to ensure heavier operations receive higher priority. Subsequently, reserve allocation is performed, computing all ciphertext reserves through a backward pass. Finally, reserve redistribution is executed to reassign reserves, prioritizing heavy operation chains to minimize their levels. The reserve analysis produces a local-optimal solution, at each reserve allocation step, the reserve analysis produces an optimal solution for the given reserve allocation results of the previous steps.
-
2.
Rescale placement, which statically analyzes various rescale placement costs to determine optimal positioning while ensuring program compliance with all constraints.
Notably, reserve analysis operates independently of placement scale management operations, achieving the desired decoupling.
We illustrate these steps using Figure 10, which computes \(x^3 \cdot \left( y^2 + y\right)\), as shown in Figure 10a. In this context, \(s_{f} = 2^{60}\) and \(s_{w} = 2^{20}\), resulting in \(\omega = \frac{1}{3}\).
Cost estimation: Operation costs correlate with levels, necessitating preliminary level estimation. Levels are estimated using \(1+ \text {depth} \cdot \omega\), where depth represents the number of multiplications from the current operation to the program output. This assumes each multiplication increases scale by \(s_{w}\), providing a minimal estimation since waterline represents the scale’s lower bound. Given that \(1+ \text {depth} \cdot \omega\) yields real numbers rather than integers, costs are estimated by interpolation. Figure 10c presents depth, level, and cost estimations based on the cost table in 10b. For instance, \(y^{2}\) has a depth of 2 (accounting for multiplications in \(y^{2}\) and \(q\)), resulting in a level of \(1+2*\frac{1}{3}=1\frac{2}{3}\) and an interpolated cost of \(92*\frac{2}{3}+44* \frac{1}{3}=76\).
Prioritizing allocation ordering: Priority is assigned to chains containing the most expensive operations. Figure 10d illustrates the reserve allocation sequence. The chain containing \(x^{2}\) receives highest priority due to its maximum cost. Because reserve analysis is performed in a backward manner, succeeding operations are prioritized even if they have a lower estimated cost.
Reserve allocation: The process initiates with the program output’s reserve, set to 0 to minimize levels and optimize performance. For unary operations and additions, input operands inherit the output’s reserve. PMult operations assign input ciphertext reserves as \(\rho _{\text {out}}+\omega\). For HMult, the level of operands will be \(\ell =\lceil \rho _{\text {out}} + 2\omega \rceil\), and reserves of inputs satisfy \(\rho _{1}+\rho _{2}=\rho _{\text {out}}+\ell\). Initially, reserves are distributed equally between operands: \(\rho _{1}=\rho _{2}=\frac{\rho _{\text {out}}+\ell }{2}\), subject to potential redistribution, they may be reallocated during the following reserve redistribution step. PMult and HMult operations may introduce level mismatches where input operands’ principal levels (\(\lceil \rho +2\omega \rceil\)) differ from output levels (\(\lceil \rho +\omega \rceil\)). When multiple reserve-ins exist, the largest value is selected, as larger reserves can be converted to smaller ones via Upscale, but not vice versa. Figure 10e presents the initial reserve allocation of Figure 10a. For example, As theoutput, \(q\)’s reserve-out is 0, and as an HMult operation, its input level is \(\lceil 0+2\cdot \frac{1}{3}\rceil =1\), and the reserves of its inputs are set equally \(\frac{0+1}{2}=\frac{1}{2}\) initially. For \(x^{3}\), the input level \(\lceil \frac{1}{2}+2*\frac{1}{3} \rceil =2\) mismatches its output levels \(1\), resulting a level mismatch.
Reserve redistribution: This step tries to reassign reserves of operands of HMult and prioritize heavy operation chains to further reduce the levels of heavy operations. Figure 10f shows reserve redistribution result of Figure 10e. There are two level mismatches in Figure 10e, \(x^{3}\) and \(y^{2}\). Since \(x^{3}\) is prioritized over \(y^{2}\) according to Figure 10d, \(x^{3}\) is considered first. To make \(\lceil \rho +2\omega \rceil =\lceil \rho +\omega \rceil =1\) where \(\omega =\frac{1}{3}\) and \(0 \le \rho \le 1\), we get \(0 \le \rho \le \frac{1}{3}\), so the newly allocated reserve-out of \(x^{3}\) is \(\frac{1}{3}\). After this redistribution, the input level of \(x^{3}\) changes from 2 to 1, while input levels of others do not change, so \(x^{3}\) can be computed at a lower level where other operations are not affected and latency is reduced. There is a new level mismatch in \(x^{2}\), which cannot be fixed by reserve redistribution, as \(\lceil \rho _{1}+\omega \rceil =\lceil \rho _{2}+\omega \rceil\) must be satified during redistibution, and under this constraint, \(\rho _{1}+\rho _{2}=\ell +\omega =1+\frac{1}{3}\) and \(\lceil \rho _{1}+\omega \rceil =\lceil \rho _{1}+2\omega \rceil\) does not have a solution.
Rescale placement: Scale management operations, previously unconsidered, are now positioned to ensure program constraint compliance. Three scenarios necessitate scale management operations:
-
1.
Level mismatches require Rescale insertion, as exemplified by \(x^{2}\).
-
2.
When an operand’s user level falls below the operation level, Rescale insertion becomes necessary. For instance, \(x^{3}\)’s level 1 versus \(x\)’s level 2 necessitates a Rescale after \(x\).
-
3.
When an operand’s user reserve falls below the operation reserve, Upscale insertion is required post-operation. For example, \(x^{3}\)’s reserve-in of \(\frac{2}{3}\) versus \(x\)’s \(4/3\) necessitates an Upscale after \(x\).
Figure 10g depicts the program after initial scale management operation insertion. To further optimize costs, the algorithm attempts to hoist Rescale operations to later points, evaluating cost differentials while considering the scale management operations’ inherent costs. For instance, Rescales following \(x^{2}\) and \(x\) can be delayed until after \(x^{3}\), eliminating one Rescale operation. The final optimized program is shown in Figure 10h.
The performance-aware approach combines the advantages of both EVA and Hecate. It achieves superior performance compared to EVA, approaching the efficiency of Hecate’s search procedure-based approach. Simultaneously, it maintains compilation efficiency comparable to EVA, requiring only several graph traversals and completing within seconds.
Summary
Table 8 presents a comparative analysis of EVA, Hecate, ELASM, and Performance-aware compilers. These compilers were evaluated using a consistent set of benchmarks. For latency and compilation time measurements, we focused exclusively on LeNet-5 rather than using the geometric mean of all benchmarks, as the other benchmarks are significantly smaller in scale. The latency and compilation time comparisons are more meaningful with larger input programs. Note that the latency measurements exclude context generation, encryption, and decryption times.
Among these compilers, EVA employs the simplest scale management methods while achieving notable effectiveness. Although Hecate demonstrates superior performance compared to EVA, it incurs significantly longer compilation times. ELASM outperforms other compilers by delivering optimal performance for a given output error threshold and achieving minimal output error for a specified latency constraint. Additionally, ELASM offers unique user control over the latency-error tradeoff through SNR settings, allowing users to adjust latency based on their precision requirements. However, ELASM’s compilation time, while faster than Hecate’s, remains substantially higher than both EVA and Reserve. The Reserve compiler nearly matches the best performance metrics while maintaining compilation times comparable to EVA.
Bootstrapping insertion
Bootstrapping insertion represents another critical aspect of ciphertext maintenance (Challenge 2) with two significant implications. First, compilers lacking automated bootstrapping management cannot effectively support large programs that consume multiple levels, such as ResNet-20. Second, given that bootstrapping operations are computationally expensive, optimizing their frequency significantly impacts the performance of FHE programs (Section CKKS scheme and primitive operations).
This section examines the bootstrapping insertion management methods implemented in DaCapo(Cheon et al. 2024) (Section DaCapo), Fhelipe(Krastev et al. 2024) (Section 4.3), HALO(Cheon et al. 2025) (Section 4.3), and Orion(Ebel et al. 2025) (Section 4.3). These contemporary works share methodological similarities and address comparable challenges (Section Main challenges of writing FHE programs).
While FHE-Booster(White et al. 2023) pioneered automatic bootstrapping insertion in compilers, it is surpassed by the aforementioned works in terms of compilation time, performance, and scalability. Rather than detailing FHE-Booster’s methodology here, a brief overview is provided in Section Other compilers.
DaCapo
DaCapo employs three core strategies for selecting Bootstrapping insertion points to address problems in Section Challenge 1: describing FHE programs with appropriate primitive operations: liveness analysis, bypass edge analysis, and cost-aware optimization.
To address Problem (1) in Figure 4, DaCapo utilizes liveness analysis to quantify the number of live-out variables at each potential insertion point. Live-out variables are ciphertexts that exist before a given point and remain in use afterward. To resolve Problem (2) in Figure 4, DaCapo performs Bootstrapping on all live-out variables at the selected point (except for long-lived variables, which will be discussed later). Consequently, DaCapo prioritizes points with minimal live-out variables. This liveness analysis enables DaCapo to avoid inserting Bootstrapping operations at dataflow divergence points, instead favoring program points either before divergence or after convergence. Figure 11 illustrates the number of live-out variables at various points in an example program (part of ResNet).
However, not all live-out variables require Bootstrapping in subsequent computations. As shown in Figure 11, variable A in Conv1 is a live-out variable for most points but only participates in addition operations within the residual block, consuming no levels and thus requiring no Bootstrapping. To eliminate unnecessary Bootstrapping operations, DaCapo introduces bypass edge analysis, which excludes long-lived (temporarily unused) ciphertexts from live-out counts, thereby improving Bootstrapping management efficiency. Figure 11 presents the adjusted live-out counts after excluding long-lived ciphertexts. This analysis expands the candidate points from just Aa and Ae edges to include Aa, Ab, Tc, Ad, and Ae. This example demonstrates how bypass edge analysis effectively increases the pool of available candidate points.
Cost-aware analysis builds on the observation that Bootstrapping insertion positions influence the levels of subsequent operations, affecting their latency. For example, although both C2 and C3 in Figure 11 require a single bootstrapping operation, inserting at C2 incurs a lower cost by enabling subsequent HMult and HRot operations to execute at reduced levels. DaCapo employs cost-aware analysis based on profiled latencies of RNS-CKKS operations to identify the minimal-cost plan.
DaCapo comprises two main components: a candidate selector and a bootstrapping planner. The candidate selector identifies potential insertion points, while the bootstrapping planner determines the optimal cost-minimizing plan from these candidates.
The candidate selector operates in three phases: bypass edge analysis, liveness analysis, and candidate filtering.
Bypass edge analysis produces a set of long-lived variables, denoted as BypassEdges. The process involves traversing all edges and, for each edge, simulating a Bootstrapping operation after its starting point. By examining operations between the edge’s start and end points, any node which has a scaling factor \(> S_{\text {th}}\) is classified as a long-lived variable and added to the BypassEdges set. The threshold \(S_{\text {th}}\) is a user-defined parameter, set to \(s_{f}^{L_{\text {eff}}/2}\) in DaCapo. This parameter significantly impacts compilation performance: an excessive \(S_{\text {th}}\) fails to identify certain long-lived variables, leading to superfluous Bootstrap operations and and less candidate points, while an insufficient \(S_{\text {th}}\) may incorrectly classify variables as long-lived.
Liveness analysis generates two outputs: CandidatesSet and Coverage of points. CandidatesSet[i] contains points where the difference between live-out variables and long-lived variables equals i. A point’s Coverage indicates the first operation that cannot be computed due to insufficient levels after Bootstrapping at that point. This analysis is implemented using traditional compiler data-flow analysis techniques.
Candidate filtering identifies the minimum threshold where inserting Bootstrapping operations at all points in \(\bigcup _{i=1}^{\texttt {threshold}} \texttt {CandidatesSet}[i]\), combined with Hecate’s scale management, satisfies all operational level constraints. The output, Candidates, is defined as \(\bigcup _{i=1}^{\texttt {threshold}} \texttt {CandidatesSet}[i]\).
The bootstrapping planner employs dynamic programming to select a subset of Candidates as insertion points that minimize total cost, with cost estimations derived from Table 4. For each \(\texttt {to} \in \texttt {Candidates}+ \text {ReturnOp}\), it computes \(\texttt {MinCost}[\texttt {to}]\) and \(\texttt {BestPlan}[\texttt {to}]\). \(\texttt {MinCost}[\texttt {to}]\) represents the minimum cost from program initiation to to, including Bootstrapping and scale management operations. \(\texttt {BestPlan}[\texttt {to}]\) maintains the optimal Bootstrapping insertion points from program start to to. \(\texttt {MinCost}[\texttt {to}]\) updates for every \(\texttt {from} \in \texttt {Candidates}\) preceding to that satisfies \(\texttt {to}\ \textrm{before}\ \texttt {from.Coverage}\):
Here, \(\text {cost}(\texttt {from},\texttt {to})\) represents the cumulative computational cost between points from and to, including scale management operations but with no Bootstrapping operations in between.
When \(\texttt {MinCost}[\texttt {to}]\) updates via from, BestPlan updates accordingly:
The final \(\texttt {BestPlan}[\operatorname {ReturnOp}]\) determines the program’s complete set of Bootstrapping insertion points.
DaCapo demonstrates scalability across large neural networks, including ResNet-20(He et al. 2016), ResNet-40(He et al. 2016), AlexNet(Krizhevsky et al. 2012), VGG-16(Simonyan and Zisserman 2015), SqueezeNet(Iandola et al. 2016), and MobileNet(Howard et al. 2017). Compared to manual implementations, DaCapo achieves an average speedup of \(1.21\times\). This performance advantage stems from DaCapo’s comprehensive consideration of factors that programmers might overlook, such as optimal Bootstrapping insertion in polynomial evaluations—a challenging task for users given FHE libraries’ API constraints(Badawi et al. 2022; Mouchet et al. 2020).
Compilation time varies from tens to thousands of seconds depending on input program size. For ResNet-20, the smallest benchmark, compilation requires 33.0 seconds, while AlexNet compilation takes 1163.8 seconds. The most computationally intensive components are bypass edge detection and bootstrapping plan determination. Bypass edge detection exhibits \(\textrm{O}\left( n^{2}\right)\) time complexity, where \(n\) represents the operation count. The bootstrapping planner operates with \(\textrm{O}(D \times d \times n)\) complexity, where \(D\) denotes the number of Bootstrapping candidates and \(d\) represents the maximum number of Bootstrapping candidates within a single candidate’s coverage.
Fhelipe
Fhelipe(Krastev et al. 2024) is a contemporary work to DaCapo, sharing similar algorithmic approaches. Both utilize a cost model and employ dynamic programming to determine optimal Bootstrapping insertion positions, with equivalent dynamic programming equations. Both methods also avoid applying Bootstrapping to bypass edges (termed "shortcut edges" in Fhelipe).
Compared to DaCapo, Fhelipe implements a simpler candidate selection process, inserting Bootstrapping operations at depth boundaries—either bootstrapping all edges crossing a boundary or none of them. Depth boundaries is illustrated in Figure 4a, which addresses Problem 2 in Figure 4. Thus, the optimization problem reduces to determining which depth boundaries require Bootstrapping operations.
Fhelipe employs the following dynamic programming equation for depth boundary selection: Fhelipe employs the following dynamic programming equation for depth boundary selection:
Here, \(i\) represents depth, ranging from 0 to the entire program’s multiplicative depth. \(dp[i]\) denotes the minimum cost of computing all nodes up to depth i with both Bootstrapping and scale management operations (where Fhelipe adopts EVA’s scale management methodology), while \(b[i]\) represents the cost of bootstrapping all ciphertexts crossing boundary i. \(c[i][j]\) denotes the computational cost for all values at depth \(i\) at level \(j\), estimated using CraterLake’s per-operation costs (Samardzic et al. 2022).
This equation is fundamentally equivalent to Equation (4.3.1), where \(i\) corresponds to to, \(i-l\) to from, and \(\sum _{j=0}^{j<l} c[i-j][j]\) represents the aggregate cost of operations between boundaries \(i-l\) and \(i\).
Like DaCapo, Fhelipe notices the bypass edges issue (termed shortcut edges) but adopts a simpler approach by only omitting Bootstrapping for bypass edges flowing from higher- to lower-level nodes, thus avoiding complex bypass edge analysis.
Fhelipe introduces an additional optimization: operations not involving scale changes can be conceptually relocated from depth \(i\) to \(i+1\) without compromising correctness, potentially reducing \(b[i]\). For instance, in Figure 4a, rotation operations at depth 1 can be considered at depth 2, reducing Bootstrapping operations from three to one between boundaries 1 and 2.
Fhelipe supports various applications including ResNet-20, RNN(Podschwadt and Takabi 2020), and HELR(Han et al. 2019). Compared to LAZY-BOOTSTRAP, Fhelipe achieves an average \(3.5\times\) speedup. Fhelipe’s Bootstrapping insertion algorithm exhibits near-linear time complexity, lower than DaCapo’s due to its simplified policy. For ResNet-20, a common benchmark between the two approaches, DaCapo requires 33.0 seconds for compilation, while Fhelipe completes in 14.7 secondsFootnote 2.
HALO
While HALO (Cheon et al. 2025), like DaCapo, Fhelipe, and Orion, manages the insertion of Bootstrap, its objective differs. HALO is specifically designed to manage bootstrap insertion for dynamic loops. In dynamic loops, the number of iterations cannot be predetermined because the loop’s termination condition depends on a ciphertext, rendering static unrolling infeasible. Consequently, the bootstrap insertion strategies employed by DaCapo, Fhelipe, and Orion are unsuitable for such scenarios. For instance, in Figure 12a, the loop variable K is a ciphertext, preventing the loop from being fully unrolled statically.
HALO begins by transforming the loop into a type-matched loop. This ensures that for every variable, its type (either plaintext or ciphertext) remains consistent across all iterations. Furthermore, for ciphertext variables, their levels also remain constant throughout the iterations.
To prevent type changes within a loop, HALO inspects for such occurrences. If a variable’s type changes, HALO peels the first iteration. For example, consider Figure 12a: if a is initially a plaintext and y a ciphertext, the operation a = a + y changes a from plaintext to ciphertext. By peeling the first iteration, as shown in Figure 12b, a consistently remains a ciphertext within the subsequent loop body.
To prevent changes in ciphertext levels, HALO bootstraps all loop-carried variables—variables modified within an iteration and read in a subsequent iteration—at the beginning of the loop. This process is illustrated in Figure 12c.
To further enhance performance, HALO introduces three bootstrapping-aware loop optimizations.
Without these optimizations, the number of Bootstrap inserted at the loop’s commencement is at least equal to the count of loop-carried variables. In Figure 12c, y and a are loop-carried variables, necessitating two Bootstrap per iteration. For more complex scenarios, such as multivariate regression involving potentially nine loop-carried variables, bootstrapping each individually incurs substantial overhead.
To address this, HALO packs all loop-carried variables into a single ciphertext, which is then bootstrapped. This approach means that only a single bootstrapping operation is now required, even with multiple loop-carried variables (assuming their combined representation fits within \(N/2\) slots). Following Bootstrap, the individual loop-carried variables are unpacked, as illustrated in Figure 12d. According to the sparse packing technique (Cheon et al. 2018), if a vector’s length is less than \(N/2\) (and is a factor of \(N/2\)), its elements are repeated to fill the \(N/2\) available slots. Packing, therefore, essentially involves masking each constituent ciphertext and then summing them. Conversely, unpacking entails masking followed by multiple homomorphic rotations (HRot) and additions (HAdd) to restore each original ciphertext to its sparsely-packed format. Consequently, the packing and unpacking operations themselves consume two levels.
To ensure full utilization of the recovered levels, HALO employs loop unrolling to further decrease the frequency of Bootstrap. Figure 12e demonstrates a scenario with an unrolling factor of 2, which halves the number of Bootstrap within the loop. The unrolling factor is determined as follows: first, the maximum multiplicative depth per iteration, \(\text {depth}_{\text {max}}\) (taking the maximum if different ciphertexts have varying depths), is identified. The unrolling factor is then calculated as \(\text {floor}(\text {depth}_{\text {limit}}/\text {depth}_{\text {max}})\), where \(\text {depth}_{\text {limit}}=L_{\text {eff}}-2\), and the subtraction of 2 accounts for the level consumption due to packing and unpacking.
To further prevent the wastage of recovered levels, HALO adaptively sets the target level \(L_{\text {eff}}\) of Bootstrap, rather than invariably using the maximum permissible level \(L-L_{\text {boot}}\). This optimization offers the benefit of reduced bootstrapping latency, as a lower target level corresponds to lower latency. The determination of the bootstrap target level leverages EVA’s EAGER-MODSWITCH mechanism (Section EVA). Initially, the target level is set to its maximum. After scale management, if the bootstrap inserted at the loop’s start is immediately followed by a ModSwitch operation, the bootstrap target level is adjusted to be the maximum level minus the difference in levels before and after the ModSwitch. As illustrated in Figure 12f, the target level for bootstrapping at the loop beginning is reduced from 10 to 7.
HALO exclusively manages the bootstrapping required for dynamic loop-carried dependencies. For bootstrapping operations needed outside of these dynamic loops, or for other bootstrapping requirements within the loop bodies not addressed by HALO’s loop-carried variable management, DaCapo is employed. As HALO eliminates the need to unroll dynamic loops, the code size is significantly reduced. This, in turn, substantially decreases DaCapo’s compilation and analysis time for managing the remaining bootstrapping instances.
Benchmarking on seven machine learning programs, which embed flat and nested loops with varying iteration counts, reveals that HALO achieves a 27% performance speedup in the compiled FHE program compared to DaCapo. Because DaCapo necessitates full loop unrolling whereas HALO does not, HALO reduces the code size by up to 11.0\(\times\) relative to DaCapo. This reduction in code size enables HALO to improve compilation time by a geometric mean of 209.12\(\times\).
Orion
Orion also introduces a bootstrap placement policy. Since Orion is designed for private neural inference, this policy allows for a more simplified bootstrap placement. Specifically, Orion confines bootstrap placements to occur exclusively between network layers, where a network layer is defined as either a linear transformation or a polynomial evaluation. This simplification is justified: linear transformations in Orion consume only a single level and thus do not require internal Bootstrap. While polynomial evaluations consume multiple levels, Orion avoids inserting Bootstrap within them. This decision stems from the fact that polynomial evaluations generate multiple intermediate ciphertexts; bootstrapping all of them would substantially increase the overall count of Bootstrap.
The core idea of Orion’s policy is illustrated in Figure 13. Figure 13a depicts a simple 3-layer neural network composed of three fully connected (fc) layers. Orion constructs a level digraph, as shown in Figure 13b. In this digraph, each network layer corresponds to a row, and each possible input level for that layer corresponds to a node within that row. A valid level \(\ell\) satisfies \(d \le \ell \le L_{\text {eff}}\), where \(d\) is the layer’s multiplicative depth. For example, since fc1 consumes one level, its valid level range is \(1 \le \ell \le 3\). Nodes and edges in the level digraph are assigned weights. A node’s weight signifies the computational cost of its corresponding layer at that specific input level. An edge’s weight represents the cost of Bootstrap if one is required; otherwise, its weight is zero. Orion then finds the shortest path (i.e., the path with the lowest total weight) from any input node to any output node in the level digraph, thereby minimizing the inference latency.
The situation becomes more complex for residual blocks, as shown in Figure 13c. Orion identifies single-entry, single-exit (SESE) regions (Johnson et al. 1994) bounded by pairs of fork and join nodes. Here, a fork (join) node is any node with more than one child (parent). A residual block naturally forms such an SESE region, where {input} acts as the fork node and {+} acts as the join node. Orion treats each SESE region as a distinct subproblem. Orion constructs two separate level digraphs: one for the backbone path and one for the residual connection, as depicted in Figure 13d. Subsequently, Orion merges these two level digraphs to form an aggregate level digraph. For any pair of corresponding entry and exit nodes in the SESE region (i.e., the fork and join nodes), the weight of the edge connecting them in the aggregate digraph is the sum of the total weights of the shortest paths between these nodes within the backbone digraph and the residual digraph, respectively. For instance, in Figure 13d, the weight of the edge in the aggregate digraph from \(\mathtt {\{input\}}_{\ell =0}\) to \(\mathtt {\{+\}}_{\ell =0}\) is set to the sum of (i) the total weight of the shortest path from \(\mathtt {\{input\}}_{\ell =0}\) to \(\mathtt {\{+\}}_{\ell =0}\) within the backbone digraph and (ii) the total weight of the shortest path from \(\mathtt {\{input\}}_{\ell =0}\) to \(\mathtt {\{+\}}_{\ell =0}\) within the residual digraph. Finally, this aggregate level digraph, which encapsulates the SESE region as a black box, is integrated back into the main network’s level digraph. This approach simplifies the problem, reducing it to a structure analogous to that depicted in Figure 13b.
Orion’s bootstrap placement policy is significantly faster than DaCapo’s. For ResNet-20 (AlexNet), Orion completes this placement in only 1.94 (0.82) seconds, representing an 8.14\(\times\) (1270\(\times\)) speed-up over DaCapo on the same networks. Even for ResNet-1202, Orion completes the placement in only 151 seconds. Furthermore, Orion’s strategy is more effective than Fhelipe’s. For instance, on ResNet-20, Orion reduces the number of inserted bootstraps by 36.2% compared to Fhelipe.
Summary
DaCapo, Fhelipe, HALO, and Orion have all proposed methods for bootstrap insertion management. DaCapo and Fhelipe offer general strategies applicable to a wide range of applications. In contrast, HALO and Orion are tailored for specific application domains: HALO targets bootstrap insertion within dynamic loops, while Orion focuses on its application in neural network inference. Among the general strategies, DaCapo typically incurs longer execution times but yields marginally better outcomes than Fhelipe. Bootstrap insertion management methods designed for specific application types tend to be more efficient than general-purpose approaches, as they can leverage stronger, domain-specific assumptions.
Data layout
Section Challenge 1: describing FHE programs with appropriate primitive operations (Challenge 1) demonstrates that selecting appropriate tensor data layouts can yield performance improvements ranging from several-fold to an order of magnitude. FHE compilers that support tensor programs as input (Table 7) face several key challenges: 1) determining which data layouts to support, 2) optimizing the data layout selection for each tensor while minimizing layout conversion overhead to achieve minimal latency, and 3) supporting a broad range of tensor operations with minimal computational overhead. We analyze three representative works: CHET(Dathathri et al. 2019) (Section CHET), Fhelipe(Krastev et al. 2024) (Section (Krastev et al. 2024)), and Orion(Ebel et al. 2025) (Section 4.4). While HeLayers(Aharoni et al. 2023) also emphasizes data layout optimization, its supported layouts constitute a subset of Fhelipe’s capabilities and demonstrate significantly lower performance. We discuss HeLayers further in Section Other compilers.
CHET
CHET is designed for moderate-depth neural networks and provides limited support for coarse-grained operations (e.g., convolutions and fully connected layers) with two primary layouts: HW and CHW. In CNNs, image tensors have a shape of \(N\times C \times H \times W\). The HW layout stores each channel separately in row-major format within a ciphertext, requiring \(N \times C\) ciphertexts in total. Conversely, the CHW layout stores \(C\) channels in a single ciphertext, enabling the storage of an entire image. For images with numerous channels, multiple ciphertexts can be utilized, with each ciphertext storing \(c\) channels where \(c<C\).
CHET optimizes tensor layout selection through a cost model that evaluates all plans within the search space and selects the configuration with minimal cost. To prevent exponential growth of the search space with respect to vector operands, CHET employs two key heuristics: (i) homomorphic convolutions typically achieve higher performance with HW layout for both input and output, while other homomorphic tensor operations generally perform better with CHW layout, and (ii) homomorphic matrix multiplications (fully connected layers) typically exhibit superior performance with CHW output layout, regardless of input layout, while other homomorphic tensor operations perform optimally when input and output share the same layout.
Based on these heuristics, CHET considers four data layout strategies:
-
1.
HW: uniformly applies HW layout across all homomorphic tensor operations
-
2.
CHW: uniformly applies CHW layout across all homomorphic tensor operations
-
3.
HW-conv, CHW-rest: employs HW layout for homomorphic convolutions and CHW for all other operations
-
4.
CHW-fc, HW-before: utilizes HW layout for all operations up to the first homomorphic fully connected layer, then switches to CHW layout
Strategies 1 and 2 eliminate transformation overhead but offer complementary performance characteristics: Strategy 1 optimizes convolution performance at the expense of other operations, while Strategy 2 demonstrates the inverse behavior. Although Strategy 3 theoretically optimizes each operation’s performance through ideal layout selection, the substantial overhead of layout transformations often results in suboptimal overall performance. Strategy 4 leverages the architectural characteristic of CNNs, where fully connected layers typically appear in the latter stages. While this approach requires only one transformation, it sacrifices performance for operations like average-pooling and activation functions preceding the first fully connected layer.
The optimal choice among these four layouts varies depending on the neural network architecture and backend implementation. For the HEAAN backend, Strategy 4 typically yields optimal results, while Strategy 2 generally performs best with the SEAL backend. This divergence stems from the different computational complexities of CMult and PMult operations in HW and CHW layouts, respectively. In SEAL’s RNS-CKKS scheme, PMult and CMult exhibit similar complexities with minimal performance variation. However, in HEAAN’s CKKS scheme, PMult and CMult have distinct complexities of \(O(N \cdot \log N \cdot M(Q))\) and \(O(N \cdot M(Q))\) respectively, resulting in significant performance differences that make Strategy 2 less suitable for HEAAN.
CHET supports applications such as LeNet and SqueezeNet. Due to the absence of Bootstrapping insertion management, CHET implements HE-friendly neural network models, utilizing square functions for activation and average-pooling instead of max-pooling. Consequently, its neural network models are less complex than those in DaCapo. CHET’s layout support is confined to row-major layouts, with limited tensor operations and kernels.
Fhelipe
Compared to CHET, Fhelipe supports hundreds of data layouts. While CHET only implements a limited set of kernels, such as fully connected and convolution layers, Fhelipe provides a comprehensive API similar to tensor languages like NumPy(Harris et al. 2020), PyTorch(Paszke et al. 2019), and TensorFlow(Abadi et al. 2016). This API supports a rich set of tensor operations, as shown in Table 9.
Layout definition: Consider a tensor with dimension indices \(i, j, k, \ldots\), each with a different number of bits \(I, J, K, \ldots\). Let the string \(S=\left( i_{I-1}, \ldots , i_{0}, j_{J-1}, \ldots , j_{0}, k_{K-1}, \ldots \right)\) be the concatenation of the individual bits of all indices. A layout of this tensor is defined as any permutation of the elements in \(S\), with gap bits (denoted as \(G\)) interleaved arbitrarily. The layout representation determines how tensor element indices map to ciphertext slot indices. For instance, in Figure 2, matrix A is stored in row-major order with layout \(i_{1}i_{0}j_{1}j_{0}\). For element \(A_{32}\) with index (3,2) (i.e., \((11_{2},10_{2})\)), where \(i_{1}=1, i_{0}=1, j_{1}=1, j_{0}=0\), the corresponding slot is \(1110_{2}=14\) in the underlying vector. Similarly, matrix B, stored in column-major order with layout \(j_{1}j_{0}i_{1}i_{0}\), maps \(B_{32}\) to slot \(1011_{2}=11\). Vector \(y\) with layout \(j_{1}j_{0}GG\) contains empty slots, where only slots with zero gap bits (0, 4, 8, 12) store valid values. Fhelipe ensures empty slots contain zeros by masking them out during operations that generate empty slots (shrink, stride, sum).
The layout system requires tensor dimension sizes to be powers of 2; for example, a \(3\times 3\) matrix must be padded to \(4\times 4\). When a tensor requires multiple ciphertexts for storage, the lowest-order \(\log _{2} n\) bits of the layout encode the slot of each element, while the remaining \(\left( |S|-\log _{2} n\right)\) bits encode its specific ciphertext. These are referred to as slot-selecting and ciphertext-selecting bits, respectively. For example, tensor t in Figure 14 has dimensions \(4\times 4\times 4\) with \(n=16\), requiring 4 ciphertexts. Its layout \(z_{1}z_{0}y_{1}y_{0}x_{1}x_{0}\) comprises ciphertext-selecting bits \(z_{1}z_{0}\) and slot-selecting bits \(y_{1}y_{0}x_{1}x_{0}\).
This flexible layout system offers several advantages. Reshape tensor operations (extend, shrink, stride, dropdim, insertdim, reorderdim) require only layout modifications without changing the underlying ciphertext, resulting in zero overhead in compiled FHE programs. For example, given a tensor t with initial layout \(i_{1}i_{0}j_{1}j_{0}\), t.shrink(dim=0, 2) produces layout \(G i_{0}j_{1}j_{0}\), while t.stride(dim=1, 2) yields \(i_1 i_0 j_0 G\). Furthermore, the flexible layout enables elegant ciphertext compaction through a two-step process: first, filling gap bits with ciphertext-selecting bits, then performing rotation and summation operations to align ciphertexts with the layout. As illustrated in Figure 14, after executing t.stride(dim=x,2).stride(dim=y,2), the layout becomes \(z_{1}z_{0}y_{1}Gx_{1}G\). During compaction, the layout is modified to \(y_{1}z_{1}x_{1}z_{0}\), followed by executing rotate(ct,0)+rotate(ct,-1)+rotate(ct,-4)+rotate(ct,-5), where rotation shifts are determined by the new layout as \((z_{1}\times 2^{2}+z_{0}\times 2^{0})\).
Fhelipe implements a layout assignment algorithm that automatically determines the layout configuration for all tensors. Rather than seeking an optimal solution, the algorithm aims for a best-effort assignment through a two-step process: 1) a forward pass for initial layout assignment, and 2) backtracking to ensure consistent layouts for binary operations while maintaining performance. During the forward pass, program inputs receive row-major layouts, unary operations determine their output layouts based on input layouts, and operations generating gaps (stride, shrink, sum) perform compaction when feasible.
However, this approach may result in mismatched data layouts between inputs of binary operations (addition and multiplication). To address this, Fhelipe employs backtracking for each input. Initially, layout conversion is performed immediately after the input using the other input’s layout as the target. The algorithm then proceeds with greedy backtracking, attempting to hoist layout conversion by modifying the layout of tensors generating this input. This process continues as long as performance does not degrade. After applying backtracking to both inputs independently, the algorithm selects the more efficient plan.
Fhelipe stands as the first tensor program FHE compiler with bootstrapping support, enabling fully automatic compilation of deep neural networks like ResNet-20. This distinguishes it from DaCapo, which only handles bootstrapping insertion for existing FHE operation-based programs, leaving data layout decisions to domain experts. In contrast, Fhelipe automates the entire process while achieving performance comparable to expert-written FHE programs(Lee et al. 2022; Podschwadt and Takabi 2020).
The comprehensive support for tensor operations in Fhelipe enables compilation of more complex tensor programs compared to CHET, with most tensor operations incurring no additional overhead. Fhelipe demonstrates an average \(18.5 \times\) speedup over CHET across various applications including RNN(Podschwadt and Takabi 2020), HELR(Han et al. 2019), and ResNet-20(Lee et al. 2022)Footnote 3. Despite supporting diverse data layouts, Fhelipe maintains efficient compilation time, completing all benchmark compilations within 30 seconds. This efficiency stems from its best-effort approach rather than exhaustive optimization.
Orion
Orion introduces a new packing technique, termed single-shot multiplexing, which employs a modified Toeplitz formulation of convolutions to convert them into matrix-vector multiplications. Homomorphic matrix-vector multiplication is typically computed using the diagonal method (Halevi and Shoup 2014). This method involves element-wise multiplication (PMult) of the \(n\) diagonals of the matrix with rotated versions of the vector, followed by summation of the results. The Baby-Step Giant-Step (BSGS) optimization (Cheon et al. 2018) can reduce the number of HRot operations required for an \(n\times n\) matrix-vector multiplication from \(O(n)\) to \(O(\sqrt{n})\). Building upon this, by combining the hoisting optimization (Halevi and Shoup 2018) and the double-hoisting optimization (Bossuat et al. 2021), the efficiency of matrix-vector multiplication can be further enhanced. In addition to reducing the number of HRot operations and leveraging performance gains from hoisting and double-hoisting techniques, single-shot multiplexing supports arbitrary parameters and ensures that even strided convolutions consume only a single multiplicative level. In contrast, the multiplexed packing approach proposed by Lee et al. (2022) consumes two levels for computing strided convolutions.
Figure 15a illustrates how Orion computes single-input, single-output (SISO) convolutions where \(c_{i}=c_{o}=s=1\). Orion constructs a weight matrix of size \(h_{o}w_{o}\times h_{i}w_{i}\) (where \(h_{o}, w_{o}\) and \(h_{i}, w_{i}\) are the height and width of the output and input images, respectively). This matrix is a Toeplitz matrix, where each row corresponds to one filter multiplication. For example, the first row of the matrix in Figure 15a performs a dot product between the filter weights \(\{5,6,8,9\}\) and the input pixels \(\{a,b,d,e\}\). This operation corresponds to positioning the filter at the top-left corner of the input, with padding=1 and stride=1. Subsequent rows of the Toeplitz matrix are generated as the kernel slides across the input image. Notably, the weight matrix contains only \(f\) non-zero diagonals, where \(f\) is the number of filter elements. The advantage of this Toeplitz formulation is that, when combined with the double-hoisting BSGS optimization, the number of HRot operations can be reduced from \(O(f)\) to \(O(\sqrt{f})\).
This approach can be readily extended to multiple-input, multiple-output (MIMO) convolutions. Figure 15b shows a MIMO convolution with \(c_{i}=c_{o}=2\), along with its analogous Toeplitz matrix. This matrix is constructed in much the same way as in the SISO case. Each row represents one filter multiplication, and the diagonal method can be applied to this matrix to produce a row-major output ciphertext in a single multiplicative level. Once again, this formulation enables the double-hoisting BSGS optimization to significantly reduce the number of required HRot operations.
For strided convolutions, the situation is more complex, as illustrated in Figure 15c. If the same method were applied, the weight matrix would contain numerous sparse non-zero diagonals. The number of non-zero diagonals would significantly exceed the number of filter elements, leading to a substantial increase in the required HRot operations. To ensure the diagonals are densely packed, thereby reducing the number of HRot operations, Orion reorganizes the rows of the weight matrix.
Summary
CHET implements only two data layouts and employs heuristics to avoid searching through an extensive solution space–a simple yet effective approach. In contrast, Fhelipe introduces a highly flexible data layout system that accommodates hundreds of layout variations and diverse tensor operations. As for Orion, its focus is exclusively on convolutions.
SIMD
The data layout (Section Data layout) and this section represent two aspects of Challenge 1. While data layout is a primary concern for FHE compilers that support tensor programs as input, this section focuses on compilers that process high-level (or imperative) programs containing loops and control-flow structures as inputFootnote 4. These programs operate on scalar values rather than tensors, as illustrated in Listing 1a. The key challenge lies in efficiently transforming scalar programs to utilize FHE’s batching paradigm, aiming to generate code similar to Listing 1b. We examine three approaches to address this challenge: Porcupine(Cowan et al. 2021) (Section Porcupine), Coyote(Malik et al. 2023) (Section Coyote), and HECO(Viand et al. 2023) (Section 4.5). Both Porcupine and Coyote employ synthesis-based methods, while HECO adopts a heuristic-based approach. We provide a comparative analysis and summary of these three compilers in Section 4.5.
Porcupine
Porcupine synthesizes optimal kernel compilations by minimizing computational cost. Users need to provide three components as input: a reference implementation in Racket, a Racket sketch serving as a HE kernel template, and a data layout specification. The reference implementation and kernel sketch are shown in Listing 1 and Listing 2, respectively. While the reference implementation must produce correct outputs, its implementation details do not influence Porcupine’s synthesis results. Porcupine is lifted by Rosette(Torlak and Bodik 2013) to a specification—a symbolic input-output expression defining the program’s behavior.
Porcupine employs syntax-guided synthesis (Alur et al. 2013) to complete user-provided sketches. These sketches must describe loop-free programs. Listing 2 consists of L arithmetic instructions, where sketches must be parameterized by the number of program components (L in this case). The data layout defines the packing arrangement of inputs and outputs into ciphertext and plaintext vectors. In the \(G_{x}\) example, both input and output images are stored in a single ciphertext using row-major ordering with zero-padding at the borders. While the data layout guides the synthesizer, the reference implementation remains independent of these packing details.
Porcupine’s synthesis engine implements a counter-example guided inductive synthesis (CEGIS) loop (Jha et al. 2010; Solar-Lezama et al. 2006) to complete the sketch while minimizing \(L\). The engine utilizes Rosette’s built-in capabilities to translate synthesis and verification queries into constraints, which are then solved using the SMT solver Boolector (Brummayer and Biere 2009). The synthesis process comprises three phases: initial solution synthesis, optimization for optimal solution, and code generation. The engine outputs an HE kernel described in Quill, Porcupine’s proposed HE DSL, which is subsequently translated into a SEAL program using the BFV scheme.
Synthesizing an initial solution. Porcupine’s CEGIS-based synthesis engine operates in three stages: synthesis, verification, and counter-example-based retry. The process begins by generating a concrete input-output example \(\left( x_{0}, y_{0}\right)\) through specification evaluation using a random input \(x_{0}\). The engine then attempts to synthesize a program that transforms \(x_{0}\) into \(y_{0}\) by completing the sketch, generating a synthesis query \(\operatorname {solve}\left( \operatorname {sketch}_{L}\left( x_{0}\right) =y_{0}\right)\). While the synthesized program guarantees correct output for \(x_{0}\), it may not generalize to other inputs. The engine generates additional input-output pairs, and upon encountering incorrect outputs, uses these counter-examples alongside the initial example as constraints for synthesis. If no solution is found, the engine attempts synthesis with an expanded sketch \(\operatorname {sketch}_{L+1}\) containing \(L+1\) components. This approach of exploring smaller sketches first ensures discovery of the most compact solution.
Optimization. Porcupine evaluates program cost using the function \(\text {cost}(p)=\text {latency}(p)\times (1+\text {multiplicative depth}(p))\), where multiplicative depth penalizes high-noise programs that might require larger HE parameters and reduce performance. The optimization process iteratively searches for lower-cost programs. Given the initial solution \(\operatorname {sol}_{0}\) with cost \(\text {cost}_{0}\), Porcupine augments the synthesis query with the constraint that any new solution \(\text {sol}_{1}\) must satisfy \(\text {cost}_{1}< \text {cost}_{0}\). This iteration continues until either no lower-cost solution exists or the compilation time exceeds the user-specified timeout. The initial solution serves solely to establish a cost upper bound and does not constrain the structure of subsequent solutions, allowing the engine to explore diverse instruction combinations and orderings.
Given the vast search space, Porcupine implements several optimizations to make synthesis more tractable:
- Rotate sketch and rotation restrictions:
-
Listing 2 implements a rotate sketch, which treats ciphertext rotation as an input to addition and multiplication instructions rather than as an independent operation. Two types of rotation restrictions further constrain the search space. First, tree reduction restricts rotations to powers of two for kernels implementing internal ciphertext reduction. Second, for sliding window kernels, holes ??rot are constrained to align with elements within the window. These restrictions effectively reduce the possible rotations from thousands to tens of options.
- Symmetry breaking:
-
The engine mandates static single assignment (SSA) to establish operation ordering. It further requires operands in binary operations to appear in increasing order, thereby eliminating functionally equivalent redundant candidates.
- Restricted bitwidth:
-
The synthesis formulation employs restricted bitwidth rather than full-precision bit vectors, reducing the number of variables the solver must consider.
Despite these optimizations, Porcupine’s scalability remains limited to approximately 10-12 instructions, consistent with known program synthesis limitations (Gulwani et al. 2017). To overcome this constraint, Porcupine adopts a divide-and-conquer approach, partitioning larger programs into independently synthesizable segments.
Porcupine exhibits significant compilation overhead. For instance, synthesizing the Roberts Cross program, which comprises 10 lines of code, requires 609.64 seconds, with 212.52 seconds dedicated solely to generating the initial plan. The system also faces considerable program size constraints—for example, the L2 Distance implementation is limited to vectors with only 4 elements. Programs exceeding 12 lines necessitate multi-step synthesis, where the program is partitioned into smaller, independently synthesizable kernels.
Despite these limitations, Porcupine demonstrates competitive performance across various benchmarks. In applications such as convolution and polynomial regression, Porcupine generates FHE programs that match or exceed expert implementations. Performance improvements reach up to 52% in specific benchmarks, with a geometric mean improvement of 25%. Moreover, the multi-step synthesis approach consistently outperforms expert implementations, validating its effectiveness for larger programs.
Coyote
The ideas in Coyote build upon Superword Level Parallelism (SLP)(Larsen and Amarasinghe 2000)Footnote 5. However, direct application of SLP to FHE programs yields suboptimal performance. While SLP assumes relatively low costs for vector lane shuffling and indexing operations, these operations in FHE are implemented through expensive rotations. The overhead of implementing SLP-induced shuffles through masks and rotations is substantial and often negates the benefits of vectorization.
Figure 16 illustrates how SLP compilation, due to its inadequate consideration of FHE shuffling costs, can produce code that performs worse than its non-vectorized counterpart. The SLP compilation shown in Figure 16c of the code in Figure 16a requires two rotation operations: one for the second operand in Line 2 and another for %5 in Line 3. Using an approximate cost model(Brakerski et al. 2013) where multiplication and rotation operations have a latency of 1 and addition operations have a latency of 0.1, the total execution cost of this schedule is 3.2, compared to 2.5 for the unvectorized version shown in Figure 16b. This comparison demonstrates how the overhead from SLP-induced shuffling operations can exceed the potential benefits of vectorization.
Coyote first transforms the input program into a circuit representation, as shown in Figure 16a. The algorithm then collapses some connected subcircuits into single vertices to form a quotient. Subsequently, it assigns lanes to each vertex in the quotient to generate a pre-schedule. All operations within a collapsed subcircuit share the same lane assignment.
For instance, in Figure 16d, all vertices in the root’s left subtree are assigned to lane 0, while those in the right subtree are assigned to lane 1. The resulting pre-schedule, illustrated in Figure 16e, requires only one rotation operation, yielding a total cost of 2.3. This performance surpasses both the unvectorized schedule and the aggressive schedule produced by SLP shown in Figure 16.
Figures 16b and 16c represent two boundary cases: a quotient with a single super-node encompassing all vertices, and a quotient identical to the input circuit where no collapse occurs, respectively. A pre-schedule can be structured into epochs and columns. Epochs constitute groups of independent vertices at the same height that are packed together into vector instructions requiring no data movement. Columns represent groups of vertices assigned to the same lane, corresponding to computation executed in a single thread without internal vectorization.
To identify the pre-schedule with minimal cost, Coyote must address three challenges:
-
1.
Cost computation methodology for pre-schedules
-
2.
Optimal lane placement determination for a given quotient
-
3.
Identification of the optimal quotient structure
Regarding Question 1, the cost of a pre-schedule comprises two components: the cost of alignment rotations and the cost of arithmetic operations. The number of rotations is calculated per epoch by counting distinct rotation amounts, determined by subtracting the tail lane from the head lane for all cross-lane arcs. The total rotation count is the sum across all epochs. For instance, if an epoch contains five cross-lane arcs–three with a rotation of -1 and two with a rotation of 6–its rotation count is 2. The number of arithmetic operations per epoch is determined by taking the maximum count of each operation type across all subcircuits associated with the epoch’s vertices.
For example, consider an epoch containing two vertices: one with 3 additions and 2 multiplications, and another with 2 additions and 4 multiplications. The estimated arithmetic operation count would be 3 additions and 4 multiplications. The final cost is computed as a linear combination of these operations, weighted by their respective operational costs. Using an approximation model(Brakerski et al. 2013), rotations and multiplications are weighted at 1.0, while additions and subtractions are weighted at 0.1.
For Question 2, Coyote employs a simulated annealing algorithm to determine optimal lane placement. The algorithm initializes by enumerating operations’ lanes for each epoch. New plans are generated by randomly selecting two columns and swapping a subset of their epochs. The algorithm terminates after 20000 rounds, returning the lowest-cost solution discovered.
For Question 3, Coyote utilizes best-first search to identify the optimal quotient. The initial plan treats each vertex in the input circuit as a separate subgraph, corresponding to the most aggressive SLP approach. Candidates are generated by examining the set of cross-lane arcs and selecting one for contraction, followed by determining the optimal lane placement and associated cost estimation. The search terminates either when a fixed number of rounds (150-200) have elapsed–due to the computational intensity of lane placement–or when the priority queue is exhausted.
Coyote exhibits significant limitations: its compilation time exceeds that of Porcupine, and it imposes substantial program size restrictions. Moreover, its performance improvements are modest, falling short of both Porcupine and expert implementations, achieving only a \(0.74\times\) geometric mean speedup compared to expert implementations.
HECO
A straightforward approach exists for converting scalar imperative programs to FHE’s batching paradigm, which HECO refers to as the "strawman approach." Listing 2 demonstrates how this approach transforms the operation x[i]=x[i]+y[j]. The approach converts vector element access (extract) into vector masking combined with rotation to slot 0, while element setting (insert) is transformed into masking operations with rotation and addition. However, the computational cost of the strawman approach renders it impractical. For instance, in the simple program shown in Listing 3, this approach requires O(n) rotations and masking operations, despite the program requiring only a single homomorphic addition.
Inspired by the strawman approach, HECO introduces several optimizations implemented through a series of stages: preprocessing steps, a batching pass with its associated simplification pass, and a rotate-and-sum pass. The preprocessing steps lay the foundation for subsequent optimizations, while the batching pass converts secret scalar operations into vector operations. The simplification pass eliminates redundant operations. The rotate-and-sum pass employs the technique described in (Han et al. 2018) to convert vector summations of the following form into vector operations:
The preprocessing stage consists of three primary steps:
- Unroll statically-sized loops:
-
As illustrated in Listing 1a, all loops are eliminated, resulting in the form shown in Listing 4.
- Merge sequential associative binary operations into n-ary group operations:
-
For example, x=a+b; y=x+c is transformed into y=a+b+c, eliminating inter-statement dependencies.
- Type conversion from vectors of secrets to BatchedSecrets:
-
This step converts multi-dimensional tensors into 1D fixed-length vectors using column-major layout.
The batching pass traverses operations with secret scalar result types, computing a target slot (ts) for each operation, which will be defined shortly. For each operation, it then processes its dependent operations, transforming fhe.extract(x, i) into fhe.rotate(x, i-ts). Subsequently, it processes operations dependent on the current operation, replacing their operands from the original operation with fhe.extract(v, ts).
The target slot of an operation indicates which slot in the secret vector should store the secret scalar produced by that operation. It is determined as follows:
-
If subsequent operations return the operation’s result, the target slot is 0
-
If subsequent operations modify slot i of another vector using the operation’s result, the target slot is i
-
Otherwise, if the operation depends on slot j of a vector, its target slot is j
This target slot mechanism resolves the inefficiencies of the strawman approach. Consider Listing 3, where in z[i]=x[i]+y[i], the expression x[i] (originally tensor.extract(x,i)) has a target slot of i and is transformed into fhe.rotate(x,0), eliminating the need for rotation. Similar transformations apply to y[i] and z[i]. After the simplification pass removes redundant operations, this results in z=fhe.add(x,y).
To illustrate the batching pass, consider how it transforms Listing 1a into Listing 1b. In Listing 4, for the computation of img_out[5], the addition’s target slot is 5 since its result is written to img_out. Consequently, img[5] becomes fhe.rotate(img,0) and img[4] becomes fhe.rotate(img,-1). Similarly, in computing img_out[6], the addition’s target slot is 6, transforming img[6] to fhe.rotate(img,0) and img[5] to fhe.rotate(img,-1)=–identical to the transformations for =img_out[5]. In fact, all \(n^{2}\) expanded statements undergo the same rotate operations transformations, which the simplification pass consolidates into Listing 1b.
Through these passes, HECO successfully transforms imperative programs into efficient FHE implementations, achieving performance improvements of three to four orders of magnitude compared to the naive strawman approach.
HECO utilizes the same benchmarks as Porcupine while demonstrating superior compilation efficiency. For the Roberts Cross benchmark, HECO completes compilation in just 0.06 seconds, compared to Porcupine’s 609.64 seconds. Even with 4096 elements, HECO maintains efficient compilation, requiring only 1.28 seconds. Although HECO may not discover optimal solutions like Porcupine (which can sometimes find non-intuitive optimizations), it achieves comparable latency across all benchmarks.
Summary
This section compares Porcupine, Coyote, and HECO across several dimensions:
- Compilation time and program scale:
-
As synthesis-based compilers, Porcupine and Coyote exhibit significantly longer compilation times compared to HECO. They only support small kernels (limited to approximately 12 instructions) and heavily restricted program sizes (vectors with few elements). Consequently, these compilers are unsuitable for larger programs such as neural networks. The intended usage pattern involves decomposing programs into kernels and then combining these kernels into FHE programs. In contrast, HECO can accommodate larger programs effectively.
- Extensibility:
-
Both HECO and Porcupine can be readily extended to support the CKKS scheme. Coyote, however, presents considerable challenges when adapted to CKKS, primarily due to its heavy reliance on blend operations. While these operations are almost free in BFV, their implementation in CKKS incurs non-trivial computational costs.
- Performance optimization:
-
Due to inherent limitations in SLP (Straight-Line Programs), Coyote’s acceleration capabilities are notably inferior to those of HECO and Porcupine, restricting it to relatively simple programs.
- Ease of use:
-
Among the three compilers, Porcupine demands more extensive FHE background knowledge from users, requiring them to provide both a sketch and data layout specification. However, sketch composition is relatively straightforward, and the effort invested in sketch development can be amortized by reusing or modifying sketches from kernels with similar computational patterns. Notably, Porcupine offers a distinct advantage: unlike HECO and Coyote, where compilation performance depends on input program implementation, Porcupine’s performance remains implementation-independent. Users need only focus on writing functionally correct programs.
Parameter selection
This section examines automated parameter selection in compilers. Several frameworks, including CHET, EVA, and Fhelipe, have proposed methods for automatic parameter selection within the RNS-CKKS scheme. EVA’s approach closely aligns with CHET’s methodology, and subsequent works have largely adopted similar strategies. The RNS-CKKS scheme requires users to select four key parameters: \(L\), \(N\), \(B\), and the bit width of \(\Delta\). Among these approaches, CHET and Fhelipe’s parameter selection methods are particularly noteworthy. CHET (Section CHET) exemplifies parameter selection in compilers without bootstrapping, while Fhelipe (Section Fhelipe) demonstrates the methodology for compilers with bootstrapping management.
CHET
CHET employs a fixed value of \(B=60\) and offers two approaches for determining the scaling factor \(\Delta\). The first approach relies on manual user selection, where users specify scaling factors for all inputs (allowing distinct \(\Delta\) values for each input) and the desired output scale. The second approach implements profile-guided automatic selection of scaling factors, where users provide a set of representative (training) images. CHET utilizes these images to automatically determine appropriate fixed-point scales for the images, weights, and output.
For parameter \(L\), CHET tracks the number of moduli consumed \(r\) throughout the program execution. It then identifies the minimal \(L\) that satisfies \(\prod _{i=r+1}^{L}q_{i}\) exceeding the desired output scale. With \(L\) and \(B\) determined, \(Q\) can be computed. As discussed in Section CKKS scheme and primitive operations, the lower bound of \(N\) can be derived from \(Q\) and the desired security level. CHET ensures 128-bit security in output programs and selects the minimum value of \(N\) based on the security parameters table provided in (Chase et al. 2017).
Fhelipe
Similar to CHET, Fhelipe requires users to specify the bit width of the input scale \(\Delta\), typically ranging between 35 and 45 bits. Fhelipe fixes \(N\) at \(2^{15}\), which represents the minimum value that supports bootstrapping while maintaining 128-bit security. Given the security level and \(N\), the upper bound of the bit width of \(Q\) can be determined, which is 1552 in Fhelipe. The parameter \(B\) is set equal to the bit width of \(\Delta\).
In the Lattigo implementation, bootstrapping operations consume 742 bits of modulus, while KeySwitch operations require 305 bits. This allocation leaves approximately \(L_{\text {eff}} \approx 10\) levels available for computation (the exact value varies based on the user-specified \(\Delta\)).
Other compilers
This section briefly introduces FHE compilers in Table 7 which are not covered in detail.
AHEC (Chen et al. 2020) is built on the PlaidML(Plaidml 2019) framework and supports multiple frontends and backends. Through Intel nGraph(Cyphers et al. 2018), programs written in PyTorch, TensorFlow, and other deep learning frameworks can be processed by PlaidML and converted into kernels in the Tile DSL, a component of PlaidML. AHEC leverages PlaidML to support various CPU and GPU backends. Rather than utilizing existing FHE libraries like SEAL, AHEC implements HE primitive operations directly in Tile DSL. Machine learning workloads are described using these HE primitive operations as building blocks in Tile programs, which are then optimized using the Tile optimizer before being converted to executable code by PlaidML. Regarding the challenges discussed in Section Main challenges of writing FHE programs, AHEC’s primary contribution lies not in addressing them directly, as most of this functionality is provided by PlaidML. Instead, its significant contribution is bridging the gap between frontend programming frameworks and hardware backends, maintaining neutrality toward both machine learning programming frameworks and hardware implementations.
Alchemy (Crockett et al. 2018) comprises a collection of DSLs designed for expressing both plaintext and ciphertext computations, along with associated interpreters and compilers. Alchemy’s interpreters provide various functionalities, with examples including an evaluator for interpreting plaintext or ciphertext DSL operations and a diagnostic compiler that monitors the noise rate of ciphertexts throughout program execution. The plaintext-to-ciphertext compiler (PT2CT), which converts programs from plaintext DSL to ciphertext DSL, represents Alchemy’s primary contribution and addresses Challenge 2 (ciphertext maintenance). However, Alchemy exhibits several limitations: 1) compilation time becomes prohibitively long for larger or more complex functions under the ghc Haskell compiler, 2) parameter selection requires manual intervention, with programmers needing to specify sufficiently large and arithmetically valid cyclotomic indices, and 3) the use of Haskell eDSLs as the frontend presents a significant barrier to entry.
nGraph-HE and nGraph-HE2. nGraph-HE(Boemer et al. 2019b) extends the Intel nGraph(Cyphers et al. 2018) deep learning compiler to enable FHE implementation with minimal code modifications. The compiler implements both runtime optimizations (such as special plaintext value detection) and compile-time optimizations (including ISA-level parallelism and graph-level optimizations). Its successor, nGraph-HE2(Boemer et al. 2019a), introduces a hybrid computational model where server-client interaction facilitates non-HE compatible operations, though this increases communication overhead. Both versions adopt a simplified data layout approach similar to Cryptonets(Gilad-Bachrach et al. 2016), utilizing single ciphertext slots per inference and relying on batching for multiple slots, resulting in substantial latency and memory requirements. While nGraph-HE2 introduces "lazy rescaling" to reduce operational complexity, neither version implements automatic encryption parameter selection.
FHE-Booster. FHE-Booster propose three new methods to insert Bootstrapping at appropriate positions: 1. Integer linear programming (ILP) model which guarantees the minimum number of bootstraps. 2. integer non-linear programming which optimizes the execution time of the FHE program. 3. polynomial-time score-based heuristics. Method 1 and 2 are not scalable to large FHE programs as integer programming are NP-hard problems. Method 3 does not guarantee an optimal solution but it is much faster than Method 1 and 2, providing a balanced trade-off between execution time and the number of bootstraps. However, Method 3 underperforms DaCapo and Fhelipe, achieving limited speedups. While better than LAZY-BOOTSTRAP overall, it is consistently worse than Fhelipe, with a gmean \(1.5 \times\) slowdown. In some benchmarks, it performance is even worse than LAZY-BOOTSTRAP as it places many more Bootstrapping. In addition, although complexity of Method 3 is lowest among the three options, it still have superlinear runtime, and take many minutes or fail to complete in some circuits(White 2023).
T2. Gouert et al. (2023) introduced the Terminator 2 Benchmark Suite for comparing various FHE backends and libraries, enabling programmers to select optimal schemes for specific tasks. The T2 compiler focuses on transpiling plaintext programs in its DSL to various FHE backends rather than optimization. Its primary distinguishing feature is comprehensive support for multiple FHE schemes—including the boolean scheme TFHE, integer schemes BFV and BGV, and the real number scheme CKKS—along with multiple libraries such as TFHE(TFHE 2017), PALISADE, HElib(Helib 2019), Lattigo, and SEAL. T2 functions essentially as a basic transpiler without introducing novel solutions to the three main challenges. It implements automatic bootstrapping using the straightforward LAZY-BOOTSTRAP approach but lacks data layout selection capabilities due to its low-level operational input and does not perform automatic parameter selection. While this results in lower performance compared to compilers like EVA, T2 serves as a practical solution for users primarily seeking to convert programs across different FHE schemes and libraries.
Discussion and future directions
Current FHE compilers address the challenges of writing FHE programs outlined in Section Main challenges of writing FHE programs to varying degrees. We argue that FHE compilers will become the primary approach for FHE programming, analogous to how CPU programming has evolved—where compilers now automatically handle optimizations like loop unrolling and bit-twiddling that programmers previously performed manually. Given FHE’s complexity and significantly lower computational efficiency compared to CPU instructions, FHE compilers are essential.
The following analysis examines how current FHE compilers address each challenge:
- Challenge 1:
-
Addressing Challenge 1 is crucial for improving FHE program performance. While significant progress has been made, there remains room for improvement. For neural network applications, Fhelipe achieves performance comparable to (Lee et al. 2022), yet neither represents the state-of-the-art for ResNet-20 latency. (Rovida and Leporati 2024) demonstrates nearly twice the single-threaded performance of (Lee et al. 2022) without operation-level parallelization, indicating potential for further optimization in FHE compilers for neural network applications.
- Challenge 2:
-
Numerous efforts have addressed scale management, with (Lee et al. 2024) currently offering the best balance of performance and compilation time. However, the improvements from scale management are less substantial than those from Challenge 1, with speedup from EVA to (Lee et al. 2024) being less than \(1.5 \times\).
- Challenge 3:
-
While most FHE compilers implement automatic parameter selection for \(B\), \(N\), and \(L\), they rely on consumed levels rather than precise cost models. Many compilers, including EVA and Hecate, use a fixed \(B=60\), which may not be optimal. Current parameter selection algorithms do not address optimization-related homomorphic parameters, such as the decomposition number (\(\texttt{dnum}\)) in KeySwitch.
Current CKKS FHE compilers face several significant limitations:
-
Restricted library support, with SEAL being the predominant backend. Few compilers support more advanced libraries like OpenFHE and Lattigo, which offer Bootstrapping capabilities and enhanced efficiency. Due to SEAL’s lack of Bootstrapping support, most compilers can only compile shallow applications and cannot handle deeper applications such as HELR and ResNet-20.
-
Inadequate documentation and user experience. The CKKS scheme lacks a compiler comparable to CONCRETE (for TFHE scheme) in terms of comprehensive documentation, ease of use, and performance optimization.
-
Hardware limitations due to library dependencies restrict most compilers to CPU execution, preventing utilization of more efficient GPU implementations. However, frameworks like MLIR(Lattner et al. 2021) enable support for diverse hardware backends, an approach adopted by HECO, Hecate, ELASM, and DaCapo.
We identify the following potential future research directions for FHE compilers:
- Applying state-of-the-art homomorphic encryption algorithms:
-
Current FHE compilers have not sufficiently focused on optimizing HE algorithms. Among the literature we reviewed, only Orion utilizes a relatively advanced HE algorithm, double-hoisting (Section 4.4), yet it is still approximately five years behind the cutting edge. In recent years, numerous HE algorithm optimizations have been proposed, such as the optimization for reducing approximation error by Kim et al. (2022) and the algorithm for accelerating KeySwitch by Kim et al. (2023). Integrating these algorithms into FHE compilers presents new opportunities (e.g., shorter execution times, smaller errors) and challenges.
- Compiling general-purpose programs into homomorphic encryption programs:
-
Currently, many FHE compilers focus on optimizing neural network applications. For more general programs, such as those with branches and loops, research on their compilation is still insufficient, leaving significant room for optimization. Although Porcupine, Coyote, and HECO target more general programs, Porcupine and Coyote suffer from extremely long compilation times, rendering them impractical, and HECO has significant limitations in its applicability. We anticipate more work on compiling general-purpose programs into HE programs.
- Multi-scheme FHE compilers:
-
Currently, FHE compilers that simultaneously support multiple schemes (most importantly, the CKKS and TFHE schemes) are scarce. The CKKS and TFHE schemes have distinct advantages and are suited for different scenarios. The CKKS scheme offers higher throughput but also higher latency, making it suitable for highly parallel programs with large input data. Conversely, the TFHE scheme has lower throughput and lower latency, ideal for scenarios with low parallelism and small input data sizes. Adaptive scheme selection based on tasks and scenarios is a promising future direction for FHE compilers. The T2 compiler supports multiple schemes, but its optimization level is low, primarily serving to compare the applicability of different FHE schemes.
- Cross-scheme FHE compilers:
-
Some studies have already shown that using multiple schemes within a single application can lead to performance improvements (Bian et al. 2023; Kim et al. 2024; Bae et al. 2024; Agrawal et al. 2024; Deng et al. 2024; Boura et al. 2018; Lu et al. 2021; Bae et al. 2023). However, research on cross-scheme FHE compilers is still lacking, with HEIR (Bian et al. 2023) being a notable exception. Cross-scheme compilation faces significant precision challenges, yet HEIR’s discussion on precision is insufficient. We anticipate the proposal of more cross-scheme FHE compilers in the future.
- Finer-grained homomorphic encryption parameter selection:
-
Homomorphic encryption involves numerous parameters. Current FHE compilers primarily focus on a few key parameters (Section Parameter selection). However, the selection of the important parameter \(\Delta\) is still left to the user in most FHE compilers, and the few compilers that do offer automatic selection often just use a default setting. Furthermore, bootstrapping involves numerous parameters, such as the message ratio (Han and Ki 2020) and the choice of scaling factors within bootstrapping. These parameters significantly impact the performance and precision of bootstrapping, yet there is a lack of work in FHE compilers analyzing the selection of these bootstrapping parameters.
Conclusion
FHE represents a promising technology, yet its programming complexity poses significant challenges. FHE compilers serve as crucial tools to bridge the gap between homomorphic encryption and end users. This survey first summarizes the fundamental challenges in FHE programming: selecting appropriate homomorphic primitives for encrypted operations, and implementing efficient ciphertext maintenance, particularly in scale management operations. Contemporary FHE compilers attempt to address one or more of these challenges. The survey then examines the methodologies adopted by influential compilers in recent years to overcome these obstacles. Finally, we evaluate the current state of solutions to these challenges and presents perspectives on future directions in FHE compiler research.
Data availability
Data available within the article.
Notes
The SISO implementation approach closely resembles Listing 1b
Note that compilation time encompasses more than just Bootstrapping management, as both compilers perform additional tasks
CHET was modified to support lazy bootstrapping as it originally lacked bootstrapping insertion capabilities
Due to FHE limitations, control-flow must be entirely static, preventing the use of secret values as branch or loop conditions
For the fundamental concepts of SLP, refer to Figure 1 in Ref (Larsen and Amarasinghe 2000)
References
Abadi M, Barham P, Chen J, Chen Z, Davis A, Dean J, Devin M, Ghemawat S, Irving G, Isard M et al (2016) \(\{\)TensorFlow\(\}\): a system for \(\{\)Large-Scale\(\}\) machine learning. In: 12th USENIX Symposium on Operating Systems Design and Implementation (OSDI 16). https://doi.org/10.47941/ijce.1812
Acar A, Aksu H, Uluagac AS, Conti M (2018) A survey on homomorphic encryption schemes: theory and implementation. ACM Comput Surv 51(4):79–17935. https://doi.org/10.1145/3214303
Agrawal R, Castro L, Yang G, Juvekar C, Yazicigil R, Chandrakasan A, Vaikuntanathan V, Joshi A (2023) Fab: an fpga-based accelerator for bootstrappable fully homomorphic encryption. 2023 IEEE International Symposium on High-Performance Computer Architecture (HPCA). HPCA. pp 882–895. https://doi.org/10.1109/HPCA56546.2023.10070953
Agrawal R, Chandrakasan A, Joshi A (2024) Heap: a fully homomorphic encryption accelerator with parallelized bootstrapping. https://doi.org/10.1109/isca59077.2024.00060
Aharoni E, Adir A, Baruch M, Drucker N, Ezov G, Farkash A, Greenberg L, Masalha R, Moshkowich G, Murik D, Shaul H, Soceanu O (2023) HeLayers: a tile tensors framework for large neural networks on encrypted data. Proc Priv Enhanc Tech 1:325–342. https://doi.org/10.56553/popets-2023-0020
Alharbi A, Zamzami H, Samkri E (2020) Survey on homomorphic encryption and address of new trend. Int J Adv Comput Sci Appl 11(7):618–626
Alur R, Bodik R, Juniwal G, Martin M, Raghothaman M, Seshia SA, Singh R, Solar-Lezama A, Torlak E, Udupa A (2013) Syntax-guided synthesis. Form Methods Comput-Aided Des FMCAD. https://doi.org/10.1109/FMCAD.2013.6679385
Archer DW, Calderón Trilla JM, Dagit J, Malozemoff A, Polyakov Y, Rohloff K, Ryan G (2019) Ramparts: a programmer-friendly system for building homomorphic encryption applications. In: Proceedings of the 7th ACM Workshop on Encrypted Computing & Applied Homomorphic Cryptography. WAHC’19, pp 57–68, New York, NY, USA. https://doi.org/10.1145/3338469.3358945
Al Badawi A, Bates J, Bergamaschi F, Cousins DB, Erabelli S, Genise N, Halevi S, Hunt H, Kim A, Lee Y, et al (2022) Openfhe: open-source fully homomorphic encryption library. In: Proceedings of the 10th Workshop on Encrypted Computing & Applied Homomorphic Cryptography, pp 53–63. https://doi.org/10.11591/ijeecs.v34.i3.pp1989-1998
Bae Y, Cheon JH, Kim J, Park JH, Stehlé D (2023) HERMES: efficient ring packing using MLWE ciphertexts and application to transciphering. Cryptology ePrint Archive (Paper 2023/1244)
Bae Y, Cheon JH, Kim J, Stehlé D (2024) Bootstrapping bits with ckks. In: Advances in Cryptology – EUROCRYPT 2024: 43rd Annual International Conference on the Theory and Applications of Cryptographic Techniques, Zurich, Switzerland, May 26–30, 2024, Proceedings, Part II. EUROCRYPT, pp 94–123, Berlin, Heidelberg. https://doi.org/10.1007/978-3-031-58723-8_4
Bai J, Lu F, Zhang K et al (2019) ONNX: open neural network exchange. https://github.com/onnx/onnx
Bansal V (2021) Survey on homomorphic encryption. 2021 5th International Conference on Information Systems and Computer Networks (ISCON). pp 1–4. https://doi.org/10.1109/iscon52037.2021.9702486
Bian S, Zhang Z, Pan H, Mao R, Zhao Z, Jin Y, Guan Z (2023) HE3DB: an efficient and elastic encrypted database via arithmetic-and-logic fully homomorphic encryption. Proceedings of the 2023 ACM SIGSAC Conference on Computer and Communications Security. CCS ’23. New York, NY, USA, pp 2930–2944. https://doi.org/10.1145/3576915.3616608
Bian S, Zhao Z, Zhang Z, Mao R, Suenaga K, Jin Y, Guan Z, Liu J (2023) HEIR: a unified representation for cross-scheme compilation of fully homomorphic computation
Boemer F, Costache A, Cammarota R, Wierzynski C (2019) nGraph-HE2: a high-throughput framework for neural network inference on encrypted data. In: Proceedings of the 7th ACM Workshop on Encrypted Computing & Applied Homomorphic Cryptography. WAHC’19, pp 45–56, New York, NY, USA. https://doi.org/10.1145/3338469.3358944
Boemer F, Lao Y, Cammarota R, Wierzynski C (2019) ngraph-he: a graph compiler for deep learning on homomorphically encrypted data. Proceedings of the 16th ACM International Conference on Computing Frontiers. CF ’19. New York, NY, USA, pp 3–13. https://doi.org/10.1145/3310273.3323047
Bossuat J-P, Mouchet C, Troncoso-Pastoriza J, Hubaux J-P (2021) Efficient bootstrapping for approximate homomorphic encryption with non-sparse keys. In: Canteaut A, Standaert F.-X. (eds.) Advances in Cryptology – EUROCRYPT 2021. EUROCRYPT ’21, pp 587–617, Cham. https://doi.org/10.1007/978-3-030-77870-5_21
Boura C, Gama N, Georgieva M, Jetchev D (2018) CHIMERA: combining ring-LWE-based fully homomorphic encryption schemes. J Math Cryptol 14(1):316–38
Brakerski Z, Gentry C, Halevi S (2013) Packed ciphertexts in lwe-based homomorphic encryption. In: Public-Key Cryptography–PKC 2013: 16th International Conference on Practice and Theory in Public-Key Cryptography, Nara, Japan, February 26–March 1, 2013. Proceedings 16, pp 1–13. https://doi.org/10.1007/978-3-642-36362-7_1
Brakerski Z, Gentry C, Vaikuntanathan V (2014) (Leveled) fully homomorphic encryption without bootstrapping. ACM Transact Comput Theory (TOCT) 6(3):1–36. https://doi.org/10.1145/2090236.2090262
Brummayer R, Biere A (2009) Boolector: an efficient smt solver for bit-vectors and arrays. In: Tools and Algorithms for the Construction and Analysis of Systems: 15th International Conference, TACAS 2009, Held as Part of the Joint European Conferences on Theory and Practice of Software, ETAPS 2009, York, UK, March 22-29, 2009. Proceedings 15, pp 174–177. https://doi.org/10.1007/978-3-642-00768-2_16
Brutzkus A, Gilad-Bachrach R, Elisha O (2019) Low latency privacy preserving inference. International Conference on Machine Learning. pp 812–821. https://doi.org/10.1109/jiot.2020.3003468
Carpov S, Dubrulle P, Sirdey R (2015) Armadillo: a compilation chain for privacy preserving applications. Proceedings of the 3rd International Workshop on Security in Cloud Computing. SCC ’15. New York, NY, USA, pp 13–19. https://doi.org/10.1145/2732516.2732520
Chase M, Chen H, Ding J, Goldwasser S, Gorbunov S, Hoffstein J, Lauter K, Lokam S, Moody D, Morrison T et al (2017) Security of homomorphic encryption. HomomorphicEncryption. org, Redmond WA, Tech. Rep https://doi.org/10.14419/ijet.v7i4.6.20439
Chen H, Laine K, Player R (2017) Simple encrypted arithmetic library-seal v2. 1. In: Financial Cryptography and Data Security: FC 2017 International Workshops, WAHC, BITCOIN, VOTING, WTSC, and TA, Sliema, Malta, April 7, 2017, Revised Selected Papers 21, pp 3–18. https://doi.org/10.1007/978-3-319-70278-0_1
Chen H, Cammarota R, Valencia F, Regazzoni F, Koushanfar F (2020) Ahec: end-to-end compiler framework for privacy-preserving machine learning acceleration. 2020 57th ACM/IEEE Design Automation Conference (DAC). DAC. pp 1–6. https://doi.org/10.1109/DAC18072.2020.9218508
Cheon JH, Kim A, Kim M, Song Y (2017) Homomorphic encryption for arithmetic of approximate numbers. In: Advances in Cryptology–ASIACRYPT 2017: 23rd International Conference on the Theory and Applications of Cryptology and Information Security, Hong Kong, China, December 3-7, 2017, Proceedings, Part I 23, pp 409–437. https://doi.org/10.1007/978-3-319-70694-8_15
Cheon JH, Han K, Kim A, Kim M, Song Y (2019) A full rns variant of approximate homomorphic encryption. In: Selected Areas in Cryptography–SAC 2018: 25th International Conference, Calgary, AB, Canada, August 15–17, 2018, Revised Selected Papers 25. SAC, pp 347–368. https://doi.org/10.1007/978-3-030-10970-7_16
Cheon JH, Han K, Kim A, Kim M, Song Y (2018) Bootstrapping for approximate homomorphic encryption. In: Nielsen JB, Rijmen V (eds) Advances in Cryptology – EUROCRYPT 2018. EUROCRYPT ’2018, pp 360–384, Cham. https://doi.org/10.1007/978-3-319-78381-9_14
Cheon S, Lee Y, Kim D, Lee JM, Jung S, Kim T, Lee D, Kim H (2024) DaCapo: automatic bootstrapping management for efficient fully homomorphic encryption. In: Proceedings of the 32nd USENIX Security Symposium (USENIX Security ’24). USENIX Security. https://doi.org/10.1007/978-3-642-30057-8_1
Cheon S, Lee Y, Youm H, Kim D, Yun S, Jeong K, Lee D, Kim H (2025) Halo: loop-aware bootstrapping management for fully homomorphic encryption. In: Proceedings of the 30th ACM International Conference on Architectural Support for Programming Languages and Operating Systems, Volume 1. ASPLOS ’25, pp 572–585, New York, NY, USA. https://doi.org/10.1145/3669940.3707275
Chielle E, Mazonka O, Gamil H, Tsoutsos NG, Maniatakos M (2018) E3: a framework for compiling C++ programs with encrypted operands. Cryptology ePrint Archive, Paper 2018/1013
Chillotti I, Gama N, Georgieva M, Izabachène M (2020) Tfhe: fast fully homomorphic encryption over the torus. J Cryptol 33(1):34–91. https://doi.org/10.1007/s00145-019-09319-x
Chillotti I, Ligier JM, Orfila D, Tap J-BS (2020) CONCRETE: concrete operates on ciphertexts rapidly by extending TfhE. https://doi.org/10.1680/epocs.28203
Clet P-E, Stan O, Zuber M (2021) Bfv, ckks, tfhe: Which one is the best for a secure neural network evaluation in the cloud? In: Applied Cryptography and Network Security Workshops: ACNS 2021 Satellite Workshops, AIBlock, AIHWS, AIoTS, CIMSS, Cloud S&P, SCI, SecMT, and SiMLA, Kamakura, Japan, June 21–24, 2021, Proceedings, Berlin, Heidelberg, pp 279–300. https://doi.org/10.1007/978-3-030-81645-2_16
Cowan M, Dangwal D, Alaghi A, Trippel C, Lee VT, Reagen B (2021) Porcupine: a synthesizing compiler for vectorized homomorphic encryption. Proceedings of the 42nd ACM SIGPLAN International Conference on Programming Language Design and Implementation. PLDI 2021. New York, NY, USA, pp 375–389. https://doi.org/10.1145/3453483.3454050
Crockett E, Peikert C (2016) \(\lambda \circ \lambda\): functional lattice cryptography. In: Proceedings of the 2016 ACM SIGSAC Conference on Computer and Communications Security. CCS ’16, pp 993–1005, New York, NY, USA. https://doi.org/10.1145/2976749.2978402
Crockett E, Peikert C, Sharp C (2018) ALCHEMY: a language and compiler for homomorphic encryption made easY. Proceedings of the 2018 ACM SIGSAC Conference on Computer and Communications Security. CCS ’18. New York, NY, USA, pp 1020–1037. https://doi.org/10.1145/3243734.3243828
CryptoLab (2022) HEaaN HE Library. https://heaan.it/
Cyphers S, Bansal AK, Bhiwandiwalla A, Bobba J, Brookhart M, Chakraborty A, Constable W, Convey C, Cook L, Kanawi O et al (2018) Intel ngraph: an intermediate representation, compiler, and executor for deep learning. arXiv preprint https://doi.org/10.3169/itej.65.1304arXiv:1801.08058
Dathathri R, Saarikivi O, Chen H, Laine K, Lauter K, Maleki S, Musuvathi M, Mytkowicz T (2019) CHET: an optimizing compiler for fully-homomorphic neural-network inferencing. Proceedings of the 40th ACM SIGPLAN Conference on Programming Language Design and Implementation. PLDI 2019. New York, NY, USA, pp 142–156. https://doi.org/10.1145/3314221.3314628
Dathathri R, Kostova B, Saarikivi O, Dai W, Laine K, Musuvathi M (2020) EVA: an encrypted vector arithmetic language and compiler for efficient homomorphic computation. In: Proceedings of the 41st ACM SIGPLAN Conference on Programming Language Design and Implementation. PLDI 2020, pp 546–561, New York, NY, USA. https://doi.org/10.1145/3385412.3386023
Deng X, Fan S, Hu Z, Tian Z, Yang Z, Yu J, Cao D, Meng D, Hou R, Li M, Lou Q, Zhang M (2024) Trinity: A general purpose fhe accelerator. 2024 57th IEEE/ACM International Symposium on Microarchitecture (MICRO). pp 338–351. https://doi.org/10.1109/MICRO61859.2024.00033
Doan TVT, Messai M-L, Gavin G, Darmont J (2023) A survey on implementations of homomorphic encryption schemes. J Supercomput 79(13):15098–15139. https://doi.org/10.1007/s11227-023-05233-z
Ebel A, Garimella K, Reagen B (2025) Orion: a fully homomorphic encryption framework for deep learning. In: Proceedings of the 30th ACM International Conference on Architectural Support for Programming Languages and Operating Systems, Volume 2. ASPLOS ’25, pp 734–749, New York, NY, USA. https://doi.org/10.1145/3676641.3716008
Elsloo T, Patrini G, Ivey-Law H (2019) SEALion: a framework for neural network inference on encrypted data
Fan S, Wang Z, Xu W, Hou R, Meng D, Zhang M (2023) TensorFHE: achieving practical computation on encrypted data using GPGPU. In: 2023 IEEE International Symposium on High-Performance Computer Architecture (HPCA), pp 922–934. https://doi.org/10.1109/HPCA56546.2023.10071017
Fontaine C, Galand F (2007) A survey of homomorphic encryption for nonspecialists. EURASIP J Inf Secur 2007(1):013801
Gentry C, Sahai A, Waters B (2013) Homomorphic encryption from learning with errors: Conceptually-simpler, asymptotically-faster, attribute-based. In: Advances in Cryptology–CRYPTO 2013: 33rd Annual Cryptology Conference, Santa Barbara, CA, USA, August 18-22, 2013. Proceedings, Part I, pp 75–92. https://doi.org/10.1007/978-3-642-40041-4_5
Gilad-Bachrach R, Dowlin N, Laine K, Lauter K, Naehrig M, Wernsing J (2016) CryptoNets: applying neural networks to encrypted data with high throughput and accuracy. Proceedings of The 33rd International Conference on Machine Learning. pp 201–210. https://doi.org/10.1155/2020/3910250
Gong Y, Chang X, Mišić J, Mišić VB, Wang J, Zhu H (2024) Practical solutions in fully homomorphic encryption: a survey analyzing existing acceleration methods. Cybersecurity 7(1):5. https://doi.org/10.1186/s42400-023-00187-4
Gorantala S, Springer R, Purser-Haskell S, Lam W, Wilson R, Ali A, Astor E.P, Zukerman I, Ruth S, Dibak C, Schoppmann P, Kulankhina S, Forget A, Marn D, Tew C, Misoczki R, Guillen B, Ye X, Kraft D, Desfontaines D, Krishnamurthy A, Guevara M, Perera I.M, Sushko Y, Gipson B (2021) A general purpose transpiler for fully homomorphic encryption
Gouert C, Mouris D, Tsoutsos N (2023) SoK: new insights into fully homomorphic encryption libraries via standardized benchmarks. Proceedings on Privacy Enhancing Technologies https://doi.org/10.56553/popets-2023-0075
Gulwani S, Polozov O, Singh R et al (2017) Program synthesis. Found Trends® Program Lang 4(1–2):1–119. https://doi.org/10.1109/nafips.2011.5752038
Halevi S, Shoup V (2014) Algorithms in HElib. In: Garay JA, Gennaro R (eds) Advances in cryptology – CRYPTO2014. Lecture notes in computer science. Lecture notes in computer scienceLecture notes in computer science. Springer, Berlin, pp 554–571
Halevi S, Shoup V (2018) Faster homomorphic linear transformations in HElib. In: Shacham H, Boldyreva A (eds) Advances in cryptology - CRYPTO 2018. Springer, Cham, pp 93–120
Halevi S, Shoup V (2021) Bootstrapping for HElib. J Cryptol 34(1):7. https://doi.org/10.1007/s00145-020-09368-7
Han K, Ki D (2020) Better bootstrapping for approximate homomorphic encryption. In: Cryptographers’ Track at the RSA Conference, pp 364–390. https://doi.org/10.1007/978-3-030-40186-3_16
Han K, Hong S, Cheon JH, Park D (2018) Efficient logistic regression on large encrypted data
Han K, Hong S, Cheon JH, Park D (2019) Logistic regression on homomorphic encrypted data at scale. Proc AAAI Conf Artif Intell 33(01):9466–9471. https://doi.org/10.1609/aaai.v33i01.33019466
Harris CR, Millman KJ, Van Der Walt SJ, Gommers R, Virtanen P, Cournapeau D, Wieser E, Taylor J, Berg S, Smith NJ et al (2020) Array programming with numpy. Nature 585(7825):357–362. https://doi.org/10.1038/s41586-020-2649-2
He K, Zhang X, Ren S, Sun J (2016) Deep Residual Learning for Image Recognition. 2016 IEEE Conference on Computer Vision and Pattern Recognition (CVPR). CVPR’16. pp 770–778. https://doi.org/10.1109/cvpr.2016.90
HElib (2019) https://github.com/homenc/HElib
Hong S, Kim S, Choi J, Lee Y, Cheon JH (2021) Efficient sorting of homomorphic encrypted data with k-way sorting network. IEEE Trans Inf Forensics Secur 16:4389–4404. https://doi.org/10.1109/TIFS.2021.3106167
Howard AG, Zhu M, Chen B, Kalenichenko D, Wang W, Weyand T, Andreetto M, Adam H (2017) MobileNets: efficient convolutional neural networks for mobile vision applications. https://doi.org/10.48550/arXiv.1704.04861
Iandola FN, Han S, Moskewicz MW, Ashraf K, Dally WJ, Keutzer K (2016) SqueezeNet: AlexNet-level accuracy with 50x fewer parameters and \(<\)0.5MB model size. https://doi.org/10.48550/arXiv.1602.07360
Jha S, Gulwani S, Seshia SA, Tiwari A (2010) Oracle-guided component-based program synthesis. In: Proceedings of the 32nd ACM/IEEE International Conference on Software Engineering - Volume 1. ICSE ’10, pp 215–224, New York, NY, USA. https://doi.org/10.1145/1806799.1806833
Johnson R, Pearson D, Pingali K (1994) The program structure tree: computing control regions in linear time. SIGPLAN Not 29(6):171–185. https://doi.org/10.1145/773473.178258
Jung W, Kim S, Ahn JH, Cheon JH, Lee Y (2021) Over 100x faster bootstrapping in fully homomorphic encryption through memory-centric optimization with GPUs. IACR Transact Cryptogr Hardw Embed Syst 4:114–148
Juvekar C, Vaikuntanathan V, Chandrakasan A (2018) GAZELLE: a low Latency framework for lSecure neural network inference. Proceedings of the 32nd USENIX Security Symposium (USENIX Security ’18). USENIX Security 18. pp 1651–1669. https://doi.org/10.1109/aicas48895.2020.9074001
Kim J, Lee G, Kim S, Sohn G, Rhu M, Kim J, Ahn JH (2022) Ark: fully homomorphic encryption accelerator with runtime data generation and inter-operation key reuse. In: 2022 55th IEEE/ACM International Symposium on Microarchitecture (MICRO), pp 1237–1254. https://doi.org/10.1109/micro56248.2022.00086
Kim S, Kim J, Kim MJ, Jung W, Kim J, Rhu M, Ahn JH (2022) BTS: an accelerator for bootstrappable fully homomorphic encryption. In: Proceedings of the 49th Annual International Symposium on Computer Architecture. ISCA ’22, pp 711–725, New York, NY, USA. https://doi.org/10.1145/3470496.3527415
Kim A, Papadimitriou A, Polyakov Y (2022) Approximate homomorphic encryption with reduced approximation error. In: Cryptographers’ Track at the RSA Conference. CT-RSA, pp 120–144. https://doi.org/10.1007/978-3-030-95312-6_6
Kim M, Lee D, Seo J, Song Y (2023) Accelerating HE operations from key decomposition technique
Kim J, Kim S, Choi J, Park J, Kim D, Ahn JH (2023) SHARP: A Short-Word Hierarchical Accelerator for Robust and Practical Fully Homomorphic Encryption. In: Proceedings of the 50th Annual International Symposium on Computer Architecture. ISCA ’23, pp 1–15, New York, NY, USA. https://doi.org/10.1145/3579371.3589053
Kim J, Seo J, Song Y (2024) Simpler and faster BFV bootstrapping for arbitrary plaintext modulus from CKKS. Cryptology ePrint Archive.(Paper 2024/109)
Krastev A, Samardzic N, Langowski S, Devadas S, Sanchez D (2024) A tensor compiler with automatic data packing for simple and efficient fully homomorphic encryption. Proc ACM Program Lang 8:152–126152150. https://doi.org/10.1145/3656382
Krizhevsky A, Sutskever I, Hinton GE (2012) Imagenet classification with deep convolutional neural networks. In: Proceedings of the 25th International Conference on Neural Information Processing Systems - Volume 1. NIPS’12, pp 1097–1105, Red Hook, NY, USA. https://doi.org/10.5555/2999134.2999257
Larsen S, Amarasinghe S (2000) Exploiting superword level parallelism with multimedia instruction sets. Proceedings of the ACM SIGPLAN 2000 Conference on Programming Language Design and Implementation. PLDI ’00. New York, NY, USA, pp 145–156. https://doi.org/10.1145/349299.349320
Latibari BS, Gubbi KI, Homayoun H, Sasan A (2023) A survey on fhe acceleration. 2023 IEEE 16th Dallas Circuits and Systems Conference (DCAS). pp 1–6. https://doi.org/10.1109/DCAS57389.2023.10130256
Lattner C, Amini M, Bondhugula U, Cohen A, Davis A, Pienaar J, Riddle R, Shpeisman T, Vasilache N, Zinenko O (2021) Mlir: Scaling compiler infrastructure for domain specific computation. 2021 IEEE/ACM International Symposium on Code Generation and Optimization (CGO). CGO. pp 2–14. https://doi.org/10.1109/CGO51591.2021.9370308
Lecun Y, Bottou L, Bengio Y, Haffner P (1998) Gradient-based learning applied to document recognition. Proc IEEE 86(11):2278–2324. https://doi.org/10.1109/5.726791
Lee D, Lee W, Oh H, Yi K (2020) Optimizing homomorphic evaluation circuits by program synthesis and term rewriting. In: Proceedings of the 41st ACM SIGPLAN Conference on Programming Language Design and Implementation. PLDI 2020, pp 503–518, New York, NY, USA. https://doi.org/10.1145/3385412.3385996
Lee J-W, Kang H, Lee Y, Choi W, Eom J, Deryabin M, Lee E, Lee J, Yoo D, Kim Y-S, No J-S (2022) Privacy-preserving machine learning with fully homomorphic encryption for deep neural network. IEEE Access 10:30039–30054. https://doi.org/10.1109/ACCESS.2022.3159694
Lee Y, Heo S, Cheon S, Jeong S, Kim C, Kim E, Lee D, Kim H (2022) HECATE: Performance-Aware Scale Optimization for Homomorphic Encryption Compiler. In: 2022 IEEE/ACM International Symposium on Code Generation and Optimization (CGO). CGO, pp 193–204. https://doi.org/10.1109/CGO53902.2022.9741265
Lee E, Lee J-W, Lee J, Kim Y-S, Kim Y, No J-S, Choi W (2022) Low-complexity deep convolutional neural networks on fully homomorphic encryption using multiplexed parallel convolutions. In: Proceedings of the 39th International Conference on Machine Learning. ICML’2022, pp 12403–12422. https://doi.org/10.1109/tdsc.2024.3448406
Lee Y, Cheon S, Kim D, Lee D, Kim H (2023) ELASM: Error-Latency-Aware Scale Management for Fully Homomorphic Encryption. In: Proceedings of the 32nd USENIX Security Symposium (USENIX Security ’23). USENIX Security ’23, pp 4697–4714. https://doi.org/10.1007/s41019-019-00100-5
Lee Y, Cheon S, Kim D, Lee D, Kim H (2024) Performance-aware Scale Analysis with Reserve for Homomorphic Encryption. In: Proceedings of the 29th ACM International Conference on Architectural Support for Programming Languages and Operating Systems, Volume 1. ASPLOS ’24, vol. 1, pp 302–317. New York, NY, USA. https://doi.org/10.1145/3617232.3624870
Lewington CP (2025) Programming privacy—a short observational study of homomorphic encryption compilers for bioinformatics applications. In: Jahankhani H, Issac B (eds) Cybersecurity and human capabilities through symbiotic artificial intelligence. Springer, Cham, pp 249–274
Liu W, You L, Shao Y, Shen X, Hu G, Shi J, Gao S (2025) From accuracy to approximation: a survey on approximate homomorphic encryption and its applications. Computer Sci Rev 55:100689. https://doi.org/10.1016/j.cosrev.2024.100689
Lu W-J, Huang Z, Hong C, Ma Y, Qu H (2021) PEGASUS: bridging polynomial and non-polynomial evaluations in homomorphic encryption. 2021 IEEE Symposium on Security and Privacy (SP). SP ’2021. pp 1057–1073. https://doi.org/10.1109/SP40001.2021.00043
Malik R, Sheth K, Kulkarni M (2023) Coyote: a compiler for vectorizing encrypted arithmetic circuits. In: Proceedings of the 28th ACM International Conference on Architectural Support for Programming Languages and Operating Systems, Volume 3. ASPLOS 2023, pp 118–133, New York, NY, USA. https://doi.org/10.1145/3582016.3582057
Marcolla C, Sucasas V, Manzano M, Bassoli R, Fitzek FHP, Aaraj N (2022) Survey on fully homomorphic encryption, theory, and applications. Proc IEEE 110(10):1572–1609. https://doi.org/10.1109/JPROC.2022.3205665
Martins P, Sousa L, Mariano A (2017) A survey on fully homomorphic encryption: an engineering perspective. ACM Comput Surv 50(6):83–18333. https://doi.org/10.1145/3124441
Mouchet CV, Bossuat J-P, Troncoso-Pastoriza JR, Hubaux J-P (2020) Lattigo: a multiparty homomorphic encryption library in go. In: Proceedings of the 8th Workshop on Encrypted Computing and Applied Homomorphic Cryptography, pp 64–70. https://doi.org/10.1109/icicis46948.2019.9014698
Pal S, Swaminathan K, Aharoni E, Kushnir E, Drucker N, Schaul H, Buyuktosunoglu A, Soceanu O, Bose P (2023) Fully homomorphic encryption for computer architects: a fundamental characterization study. In: Annual IEEE/ACM International Symposium on Microarchitecture. https://doi.org/10.1007/978-3-319-12229-8_3
PALISADE (2020) Lattice Cryptography Library https://palisade-crypto.org/
Paszke A, Gross S, Massa F, Lerer A, Bradbury J, Chanan G, Killeen T, Lin Z, Gimelshein N, Antiga L et al (2019) Pytorch: an imperative style, high-performance deep learning library. Adv Neural Inf Process Syst. https://doi.org/10.1063/5.0063300
PlaidML (2019) A platform for making deep learning work everywhere. https://github.com/plaidml/plaidml
Podschwadt R, Takabi D (2020) Classification of encrypted word embeddings using recurrent neural networks. In: Proceedings of the 13th International Conference on Web Search and Data Mining (WSDM ’20). WSDM ’20. https://doi.org/10.15368/theses.2018.89
Rovida L, Leporati A (2024) Encrypted image classification with low memory footprint using fully homomorphic encryption. Int J Neural Syst 34:2450025. https://doi.org/10.1142/S0129065724500254
Samardzic N, Feldmann A, Krastev A, Devadas S, Dreslinski R, Peikert C, Sanchez D (2021) F1: a fast and programmable accelerator for fully homomorphic encryption. MICRO-54: 54th Annual IEEE/ACM International Symposium on Microarchitecture. MICRO ’21. New York, NY, USA, pp 238–252. https://doi.org/10.1145/3466752.3480070
Samardzic N, Feldmann A, Krastev A, Manohar N, Genise N, Devadas S, Eldefrawy K, Peikert C, Sanchez D (2022) CraterLake: a hardware accelerator for efficient unbounded computation on encrypted data. Proceedings of the 49th Annual International Symposium on Computer Architecture. ISCA ’22. New York, NY, USA, pp 173–187. https://doi.org/10.1145/3470496.3527393
Shivdikar K, Bao Y, Agrawal R, Shen M, Jonatan G, Mora E, Ingare A, Livesay N, AbellÁN JL, Kim J, Joshi A, Kaeli D (2023) GME: GPU-based microarchitectural extensions to accelerate homomorphic encryption. In: Proceedings of the 56th Annual IEEE/ACM International Symposium on Microarchitecture. MICRO ’23, pp 670–684, New York, NY, USA. https://doi.org/10.1145/3613424.3614279
Simonyan K, Zisserman A (2015) Very deep convolutional networks for large-scale image recognition. In: Bengio Y, LeCun Y (eds) 3rd International Conference on Learning Representations, ICLR 2015, San Diego, CA, USA, May 7-9, 2015, Conference Track Proceedings. https://doi.org/10.1145/2986035.2986042
snucrypto (2023) HEAAN. https://github.com/snucrypto/HEAAN
Solar-Lezama A, Tancau L, Bodik R, Seshia S, Saraswat V (2006) Combinatorial sketching for finite programs. SIGARCH Comput Archit News 34(5):404–415. https://doi.org/10.1145/1168919.1168907
TFHE (2017) Fast fully homomorphic encryption library over the Torus. https://github.com/tfhe/tfhe
Torlak E, Bodik R (2013) Growing solver-aided languages with rosette. In: Proceedings of the 2013 ACM International Symposium on New Ideas, New Paradigms, and Reflections on Programming & Software. Onward! 2013, pp 135–152, New York, NY, USA. https://doi.org/10.1145/2509578.2509586
Tsuji A, Oguchi M (2024) Comparison of fhe schemes and libraries for efficient cryptographic processing. 2024 International Conference on Computing, Networking and Communications (ICNC). pp 584–590. https://doi.org/10.1109/ICNC59896.2024.10556382
Viand A, Shafagh H (2018) Marble: making fully homomorphic encryption accessible to all. In: Proceedings of the 6th Workshop on Encrypted Computing & Applied Homomorphic Cryptography. WAHC ’18, pp 49–60, New York. https://doi.org/10.1145/3267973.3267978
Viand A, Jattke P, Hithnawi A (2021) SoK: fully homomorphic encryption compilers. 2021 IEEE Symposium on Security and Privacy (SP). SP ’2021. pp 1092–1108. https://doi.org/10.1109/SP40001.2021.00068
Viand A, Jattke P, Haller M, Hithnawi A (2023) HECO: fully homomorphic encryption compiler. In: 32nd USENIX Security Symposium (USENIX Security 23). USENIX Security, pp 4715–4732, Anaheim, CA. https://doi.org/10.59350/91pv0-hca48
White T (2023) Scheduling general purpose encrypted computation on multicore platform. Master’s thesis, University of Delaware. https://doi.org/10.21236/ada471188
White T, Gouert C, Yang C, Tsoutsos NG (2023) Fhe-booster: accelerating fully homomorphic execution with fine-tuned bootstrapping scheduling. 2023 IEEE International Symposium on Hardware Oriented Security and Trust (HOST). HOST. pp 293–303. https://doi.org/10.1109/HOST55118.2023.10132930
Wood A, Najarian K, Kahrobaei D (2020) Homomorphic encryption for machine learning in medicine and bioinformatics. ACM Comput Surv (CSUR) 53(4):1–35
Yang Y, Zhang H, Fan S, Lu H, Zhang M, Li X (2023) Poseidon: practical homomorphic encryption accelerator. In: 2023 IEEE International Symposium on High-Performance Computer Architecture (HPCA), pp 870–881. https://doi.org/10.1109/HPCA56546.2023.10070984
Zhang J, Cheng X, Yang L, Hu J, Liu X, Chen K (2024) Sok: fully homomorphic encryption accelerators. ACM Comput Surv 56(12):1–32. https://doi.org/10.1145/3676955
Zhu Y, Wang X, Ju L, Guo S (2023) Fxhenn: Fpga-based acceleration framework for homomorphic encrypted cnn inference. 2023 IEEE International Symposium on High-Performance Computer Architecture (HPCA). pp 896–907. https://doi.org/10.1109/hpca56546.2023.10071133
Zhu H, Suzuki T, Yamana H (2023) Performance comparison of homomorphic encrypted convolutional neural network inference among HElib, Microsoft SEAL and OpenFHE. 2023 IEEE Asia-Pacific Conference on Computer Science and Data Engineering (CSDE). pp 1–7. https://doi.org/10.1109/CSDE59766.2023.10487709
Acknowledgements
Not applicable.
Funding
This research was supported by the National Key R&D Program of China (Grant No.2023YFB4503201)
and the Strategic Priority Research Program of the Chinese Academy of Sciences (Grant No.XDB44030200).
Author information
Authors and Affiliations
Contributions
Zhuoyu Tian drafted the manuscript. Shengyu Fan and Xianglong Deng contributed to manuscript revision. Mingzhe Zhang, Rui Hou, and Dan Meng supervised the work.
Corresponding author
Ethics declarations
Competing interests
None of the authors have any competing interests in the manuscript.
Additional information
Publisher's Note
Springer Nature remains neutral with regard to jurisdictional claims in published maps and institutional affiliations.
Rights and permissions
Open Access This article is licensed under a Creative Commons Attribution 4.0 International License, which permits use, sharing, adaptation, distribution and reproduction in any medium or format, as long as you give appropriate credit to the original author(s) and the source, provide a link to the Creative Commons licence, and indicate if changes were made. The images or other third party material in this article are included in the article's Creative Commons licence, unless indicated otherwise in a credit line to the material. If material is not included in the article's Creative Commons licence and your intended use is not permitted by statutory regulation or exceeds the permitted use, you will need to obtain permission directly from the copyright holder. To view a copy of this licence, visit http://creativecommons.org/licenses/by/4.0/
About this article
Cite this article
Tian, Z., Fan, S., Deng, X. et al. A survey on fully homomorphic encryption compilers. Cybersecurity 9, 218 (2026). https://doi.org/10.1186/s42400-026-00641-z
Received:
Accepted:
Published:
Version of record:
DOI: https://doi.org/10.1186/s42400-026-00641-z