The appeal of fully homomorphic encryption in genomics is straightforward to state but difficult to achieve in practice. Differential expression analysis, one of the most common first steps in cancer transcriptomics, compares gene expression levels between groups of samples, such as tumor tissue versus healthy tissue, to identify genes whose activity changes with disease. Because expression profiles are inherently identifying, uploading raw count matrices to a third-party cloud service exposes patients to real risk. FHE promises to dissolve that risk: the cloud server performs the statistical computation on ciphertexts, and only the data owner, holding the secret key, can decrypt the results. The catch is cost. Homomorphic operations are orders of magnitude slower than their plaintext equivalents, and the exact penalty depends heavily on which encryption scheme is chosen and how its parameters are configured.

The study focuses on the two most widely deployed FHE schemes, BFV and CKKS, which take philosophically different approaches to arithmetic on encrypted data. BFV operates on exact integers, making it well suited to the raw integer counts that RNA-seq pipelines produce, but it requires careful quantization when computations produce fractional values. CKKS, by contrast, works natively with approximate real numbers, embedding a scaling factor into each plaintext and accepting a small, controlled amount of noise with every operation. That approximation is usually negligible for statistical work, but it accumulates through a process called rescaling, and the new research shows that this accumulation can become measurable under certain parameter settings. Until now, the field has had little empirical guidance on when each scheme’s weaknesses matter more than its strengths.

To settle the question, the author designed a benchmark of unusual thoroughness for the FHE-genomics intersection. Two cancer RNA-seq datasets served as testbeds: the UCI Gene Expression RNA-Seq dataset, comprising 801 samples spanning five cancer types and yielding ten pairwise class comparisons, and the TCGA lung cancer dataset combining lung squamous cell carcinoma and lung adenocarcinoma, with 1,129 samples and a single pairwise comparison. Experiments swept across polynomial modulus degrees of 4,096, 8,192 and 16,384, the parameter that largely determines both security headroom and computational cost, and across three cohort sizes. Every configuration was run ten independent times under parameters compliant with the 128-bit security standard, the widely accepted benchmark for practical cryptographic deployments, for a total of 300 runs. That repetition matters, because FHE timings can be noisy and single-run benchmarks have historically overstated the reliability of performance claims.

The headline result is a decisive speed advantage for BFV. Across every configuration tested, BFV completed the full encrypt-compute-decrypt cycle in 3.5 to 7.5 times less total latency than CKKS. For teams weighing the practicality of encrypted differential expression analysis, that gap is not a rounding error; it can be the difference between a pipeline that finishes overnight and one that stalls for days. Yet the story does not end there. CKKS fought back on a different axis: at the largest polynomial modulus degree of 16,384, its ciphertexts were approximately 2.66 times smaller per sample than BFV’s. In cloud environments where storage and bandwidth are billed by the gigabyte, and where genomic cohorts can involve tens of thousands of samples, that storage advantage translates directly into cost savings and faster data transfer. The study’s central conclusion is that neither scheme is universally dominant; the right choice depends on whether a deployment is latency-bound or storage-bound.

Perhaps the most surprising finding concerns what actually drives computational cost. Intuition suggests that processing more samples should take proportionally longer, but the benchmark showed that execution time scaled primarily with the number of pairwise class comparisons rather than with sample count. In the UCI dataset, with its ten pairwise comparisons, the encrypted computation was far heavier than in the TCGA comparison, despite the latter containing more samples. This is a genuinely counterintuitive result that had received little attention in prior FHE benchmarking studies, and it carries immediate practical implications: analysts designing privacy-preserving pipelines for multi-class cancer studies should budget their computation around the number of group contrasts, not the size of the cohort, and should consider consolidating comparisons wherever the science allows.

Accuracy, the other half of the tradeoff equation, behaved in scheme-specific ways that the author traced to the underlying mathematics. CKKS’s approximation error grew worse at higher polynomial modulus degrees, a consequence of scale-induced rescaling noise accumulating through the computation. BFV, working with exact integers, showed the opposite and rather elegant behavior: its quantization noise decreased as cohort size increased, because averaging over more samples smooths out the rounding error introduced when fractional statistics are mapped onto the integer plaintext space. These opposing error dynamics mean that the accuracy picture changes with both the scheme and the scale of the study, and pipeline designers cannot simply assume that bigger parameters yield better results.

Crucially, however, the study delivers a reassuring bottom line for biomedical validity. Across all 300 runs and every configuration tested, both BFV and CKKS preserved the ranking of differentially expressed genes with a Spearman rank correlation above 0.999 relative to the plaintext baseline. In other words, even where numerical errors crept in, the biological conclusions, which genes rise to the top of the differential expression list, remained essentially identical to what an unencrypted analysis would produce. For clinical and research applications, that ranking fidelity is arguably the metric that matters most, and the result suggests that FHE-based privacy protection need not come at the price of scientific correctness.

Beyond the specific numbers, the study establishes a reproducible benchmarking framework that other researchers can extend to additional schemes, datasets, and statistical tasks. The author acknowledges Dr. Sudhakar Theerthagiri of Anna University’s MIT Campus for guidance on cryptography and methodological decisions, and the work received no external funding. Published open access on 15 September 2026, the paper arrives at a moment when privacy regulation and cloud genomics are colliding with growing force. As sequencing costs continue to fall and multi-institutional cancer studies become the norm, the demand for computation on encrypted genomes will only intensify. This benchmark gives the field its clearest map yet of the terrain: BFV for speed, CKKS for storage, class comparisons as the true computational driver, and gene rankings that survive encryption essentially intact. For a discipline wrestling with how to share its most sensitive data without giving it away, that map is a valuable piece of infrastructure in its own right.

Subject of Research: Privacy-preserving differential expression analysis of cancer RNA-seq data using fully homomorphic encryption

Article Title: Privacy-preserving differential expression analysis via fully homomorphic encryption: a systematic tradeoff evaluation of BFV and CKKS on cancer RNA-seq datasets

Article References: Shankar, D. (2026). Privacy-preserving differential expression analysis via fully homomorphic encryption: a systematic tradeoff evaluation of BFV and CKKS on cancer RNA-seq datasets. BMC Bioinformatics. https://doi.org/10.1186/s12859-026-06609-7

Image Credits: AI Generated

DOI: 10.1186/s12859-026-06609-7

Keywords: fully homomorphic encryption, BFV, CKKS, differential expression analysis, RNA-seq, cancer genomics, data privacy, transcriptomics, cloud computing, TCGA, genomic pipelines, cryptography

The stakes are enormous. Fully homomorphic encryption enables end-to-end encrypted data processing in untrusted environments, meaning a hospital could outsource genome analysis or a bank could delegate fraud detection to a cloud provider without exposing any sensitive records. Schemes such as BGV, BFV, GSW, CKKS, and TFHE have matured steadily over the past decade, and libraries like HElib, SEAL, HEAAN, Lattigo, OpenFHE, and PALISADE now implement their underlying arithmetic. But even with these libraries, the survey reports, encrypted computations on CPUs run four to five orders of magnitude slower than their plaintext equivalents. Well-optimized programs can be hundreds of times faster than naive ones, which makes efficient programming not a nicety but a necessity.

The difficulty begins with the extremely restricted set of primitive operations. Homomorphic programs can only perform vector element-wise addition, element-wise multiplication, and rotation shifts over long ciphertext vectors containing thousands to tens of thousands of slots. Operations that are trivial on a CPU, such as accessing a single array element or shuffling a vector, can require dozens or even hundreds of rotations and consume precious computational budget. Sophisticated tricks, like the single-input single-output convolution scheme that needs only kernel-squared rotations instead of a naive avalanche of masks and shifts, can improve efficiency by orders of magnitude, but designing such non-intuitive implementations demands years of cryptographic and numerical expertise.

A second layer of complexity comes from ciphertext maintenance. In the CKKS scheme, which the survey focuses on because of its dominance in machine learning workloads, every multiplication roughly squares a ciphertext’s scaling factor, and Rescale operations must be strategically inserted to keep scales and noise from growing exponentially. Binary operations also impose strict constraints: their operands must sit at the same level and, for additions, share the same scaling factor. Even seemingly obvious strategies backfire. The survey’s authors walk through a simple computation of x squared plus x to show that the always-rescale approach wastes a level, and a ResNet-style example demonstrates that naively bootstrapping ciphertexts the moment they run out of levels can nullify most of bootstrapping’s benefit, an operation that alone can consume over 80 percent of total runtime in deep inference workloads.

Parameter selection forms a third minefield. The polynomial degree N, the initial level budget L, and the small-prime bit width B interact in complicated ways that determine correctness, security, and speed simultaneously. The approximate nature of CKKS makes this worse: unlike exact schemes such as BFV and BGV, CKKS decryption always carries error, and bootstrapping merely restores multiplication capacity without cleaning the noise. The survey cites a striking case where a ResNet-20 inference program achieves 89.53 percent accuracy with a prime width of 33 bits but collapses to 10.87 percent, essentially random guessing, when that width drops to 31 bits.

Fully homomorphic encryption compilers attack these problems by translating ordinary programs, whether tensor code resembling PyTorch or plain scalar programs with loops, into optimized ciphertext programs. The survey describes a typical workflow: parse the input into an internal graph representation, optionally rewrite primitive operations, insert scale management and bootstrapping operations, choose evaluation keys and cryptographic parameters, and finally emit source code targeting a backend library or a standalone executable. Crucially, these compilers are device-agnostic, introducing minimal overhead compared with dedicated hardware accelerators, and they often generate code that outperforms expert hand-tuned implementations.

The heart of the survey is a systematic dissection of scale-management techniques. EVA, the first compiler to prioritize this problem, introduced watermark-based rescaling and eager level matching, delivering a 2.3-times average speedup over earlier approaches. Hecate extended that framework with a new Downscale operation and a search procedure driven by a cost model, gaining a further 27.85 percent on average but at the price of compilation times that can stretch to hundreds of seconds. ELASM added a scale-to-noise-ratio concept with noise-aware waterlines, letting users trade accuracy against latency, cutting output error by tens to hundreds of times at equal latency. The newest entrant, Reserve, replaces search with a backward static analysis that nearly matches Hecate’s performance while compiling in seconds rather than minutes.

Bootstrapping insertion has undergone a parallel revolution. DaCapo uses liveness analysis, bypass edge detection, and dynamic programming to find cost-minimizing insertion points, achieving a 1.21-times speedup over manual implementations on networks up to ResNet-40 and MobileNet. Fhelipe streamlines the same idea with depth boundaries and shortcut edges, and additionally supports hundreds of tensor data layouts, producing an 18.5-times speedup over the earlier layout compiler CHET. HALO specializes in dynamic loops whose trip counts depend on encrypted values, packing loop-carried variables into a single bootstrapped ciphertext and reducing code size by up to 11 times compared with DaCapo. Orion, tailored to private neural inference, models bootstrapping placement as a shortest-path problem on a level digraph, reducing ResNet-20 compilation to under two seconds, an 8.14-times speedup over DaCapo, and trimming inserted bootstraps by 36.2 percent relative to Fhelipe.

For general scalar programs, the survey contrasts synthesis-based and heuristic-based vectorization. Porcupine uses counter-example-guided program synthesis to discover optimal homomorphic kernels, matching or beating expert code with up to 52 percent improvements, but it can only handle roughly a dozen instructions and needed over 609 seconds for a small image filter. Coyote, building on superword-level parallelism, shows why naive vectorization fails when rotations are expensive, yet its own gains remain modest at 0.74 times expert performance. HECO, by contrast, applies a heuristic batching pipeline that transforms imperative code into efficient vectorized form in under a second, delivering three to four orders of magnitude improvement over naive element-by-element translation while scaling to large programs.

The survey closes with a candid assessment of what remains broken. Most compilers still target only the SEAL library, which lacks bootstrapping support and therefore caps program depth; documentation and user experience lag far behind mainstream compiler infrastructure; and parameter selection often relies on crude fixed defaults rather than precise cost models. The authors call for compilers that integrate state-of-the-art homomorphic algorithms, support general-purpose control flow, span multiple schemes from CKKS to TFHE, and even compile across schemes within a single application, an area where only the HEIR project has made an early start. Their conclusion is unambiguous: just as compilers absorbed the manual optimizations of early CPU programming, fully homomorphic encryption compilers are poised to become the primary gateway through which ordinary programmers, not cryptographers, will unlock computation on encrypted data.

Subject of Research: Compilers for fully homomorphic encryption, the tools that automatically convert ordinary programs into optimized code for computing on encrypted data.

Article Title: A survey on fully homomorphic encryption compilers

Article References: Tian, Z., Fan, S., Deng, X., Hou, R., Meng, D., & Zhang, M. (2026). A survey on fully homomorphic encryption compilers. Cybersecurity, 9(1), Article 218. https://doi.org/10.1186/s42400-026-00641-z

Image Credits: AI Generated

DOI: 10.1186/s42400-026-00641-z

Keywords: fully homomorphic encryption, compilers, CKKS scheme, cryptography, cloud computing privacy, bootstrapping, scale management, SIMD vectorization, machine learning, program synthesis, parameter selection, data privacy