Not all FHE is created equal.
"Fully Homomorphic Encryption" is an umbrella term for a family of cryptographic schemes that share one key property: they allow computation on encrypted data. But underneath that umbrella are fundamentally different constructions, each with distinct strengths, weaknesses, and noise models.
If you're building an FHE application, or evaluating whether Aura made the right choices, you need to understand the difference between TFHE, BGV, BFV, and CKKS. This is that article.
The Four Major FHE Schemes
BGV (Brakerski-Gentry-Vaikuntanathan)
Developed in 2011. Operates on integer arithmetic modulo a prime. Supports batching — packing many values into a single ciphertext for SIMD-style operations. Efficient for large-scale integer computation.
Noise model: noise grows multiplicatively with multiplications. The modulus ladder technique (modulus switching) is used to manage noise without full bootstrapping — each multiplication consumes one level of the modulus. Once levels are exhausted, you need bootstrapping to continue.
Best for: applications requiring many exact integer multiplications, where you can plan the circuit depth in advance.
BFV (Brakerski/Fan-Vercauteren)
Closely related to BGV. Also operates on integers, also supports batching. The main practical difference is a slightly different noise management approach that performs better in some software implementations.
In practice, BGV and BFV are often used interchangeably for similar workloads. Most FHE libraries (Microsoft SEAL, OpenFHE) support both.
Best for: same as BGV — exact integer arithmetic, batched operations, known-depth circuits.
CKKS (Cheon-Kim-Kim-Song)
Designed specifically for approximate arithmetic on real numbers. Instead of exact integers, CKKS operates on approximate floating-point values with bounded error. The error is small enough to be irrelevant for most practical computations (e.g., 0.001% error on financial amounts).
CKKS supports batching on complex or real number vectors — making it extremely fast for neural network inference, statistical computation, and financial math where exact integers aren't required.
The critical limitation: CKKS results are approximate. For applications requiring exact binary comparisons — "is this value strictly greater than this threshold?" — CKKS introduces ambiguity at the boundary.
Best for: approximate arithmetic (financial calculations, ML inference), SIMD-heavy computation on real-valued data.
TFHE (Torus FHE)
Developed by Chillotti et al. at KU Leuven. Operates on single bits (or small integers) rather than large polynomials. Each bit is a separate LWE (Learning With Errors) ciphertext.
TFHE's key innovation is programmable bootstrapping: it fuses the noise-removal bootstrapping operation with a lookup table evaluation. In one bootstrapping step, TFHE can simultaneously reset noise AND apply any function of a small domain. This is extremely efficient for boolean circuits and comparisons.
TFHE is fast for gate-by-gate operations but slower for large integer arithmetic than BGV/BFV (because each bit is a separate ciphertext).
Best for: exact boolean logic, comparisons, lookup tables, circuits with many conditional branches.
The Noise Question: Why It Shapes Everything
All FHE schemes share the same fundamental challenge: noise accumulation. Every operation adds noise; too much noise corrupts decryption.
But different schemes handle noise differently:
BGV/BFV: Use a "modulus ladder" — each ciphertext has a modulus budget. Multiplications consume levels. When levels run out, bootstrapping is needed to refresh. The benefit: you can execute many multiplications without bootstrapping if your circuit depth is planned. The downside: circuit depth is limited without bootstrapping, and bootstrapping in BGV/BFV is expensive.
CKKS: Similar modulus ladder approach, but the approximate arithmetic means you get more "slack" — small noise doesn't matter until it exceeds the precision requirement. Bootstrapping in CKKS is also expensive, but CKKS's batching often means fewer total bootstraps needed per unit of computation.
TFHE: Each bootstrapping is fast (because it operates on single bits, not large polynomials), but you bootstrap after every gate (by design — each gate includes a bootstrapping as part of programmable bootstrapping). The cost per bootstrap is low; the frequency is high.
Why Aura Uses a Hybrid Approach (and What That Means)
Here's the insight that took us months of production development to validate:
No single FHE scheme is optimal for all parts of a DeFi computation.
A swap computation has two structurally different components:
Arithmetic: Price calculation, fee computation, output amount determination. These are additions and multiplications on approximate values. CKKS handles this 10-50x more efficiently than gate-level FHE, because CKKS batches multiple values and uses approximate arithmetic natively.
Boolean: Slippage check (is output ≥ minimum?), sufficient balance verification (does balance ≥ trade amount?). These require exact binary comparisons. Gate-level FHE handles this precisely; CKKS introduces ambiguity at the threshold boundary.
Our hybrid architecture — Aura FHE's implementation:
CKKS for the arithmetic-heavy price calculation and fee math
Scheme switch to Aura FHE's gate-level evaluation at the boolean boundary (~2ms overhead)
Aura FHE gate-level layer for all binary comparisons and safety checks
The scheme switch costs 2ms. The savings from using CKKS for arithmetic: 30-60ms. Net: a significant win.
This hybrid architecture is not documented in FHE literature for DeFi applications. We figured it out empirically during production development of Shield Swap.
The Deep Dive
For those who want the full mathematical treatment: our litepaper at docs.afhe.io/whitepaper includes the noise propagation models for each scheme, the formal specification of our scheme-switching protocol, and the benchmark comparison between single-scheme and hybrid approaches.
The practical summary: FHE scheme selection is a design decision, not an implementation detail. Choosing wrong costs you 10-50x in performance.
→ afhe.io/sdk — SDK launching April 7