Focused Hierarchical Encoder for Unified FHE

• Focused Hierarchical Encoder (FHE) is a unified acceleration architecture that integrates arithmetic FHE, logic FHE, and scheme conversion into one design.
• It employs a finite-kernel decomposition approach that reuses hardware units like NTT and MAC to efficiently handle multipurpose encrypted workloads.
• Dynamic scheduling and configurable units balance resources across diverse FHE tasks, delivering significant performance and area improvements over specialized accelerators.

Searching arXiv for the Trinity paper and closely related accelerator papers to ground the article with citations. Trinity is a unified ASIC accelerator for fully homomorphic encryption that supports arithmetic FHE, logic FHE, and CKKS↔TFHE scheme conversion within a single architecture. In "Trinity: A General Purpose FHE Accelerator" (Deng et al., 2024), the design is presented as the first multi-modal FHE accelerator based on a unified architecture, with support for CKKS, TFHE, and their conversion scheme derived from a shared decomposition into a finite set of arithmetic kernels. The central premise is that real FHE applications often require both arithmetic and logic computation, and that prior ASIC accelerators were siloed across schemes, making hybrid workflows dependent on heterogeneous accelerators, additional data movement, and fragmented resource utilization.

1. Unified support for arithmetic, logic, and conversion

The motivating problem is the coexistence of arithmetic and logic computation in practical encrypted workloads. CKKS is an arithmetic FHE scheme that supports SIMD-style packed arithmetic over vectors of values, whereas TFHE is a logic FHE scheme optimized for bit-level operations and programmable bootstrapping. Modern hybrid applications, such as encrypted databases, often need both: arithmetic for aggregation and logic for filtering or comparison. This is why scheme conversion between CKKS and TFHE is treated as a first-class requirement rather than an auxiliary feature (Deng et al., 2024).

The paper positions Trinity against prior specialized accelerators. CKKS accelerators such as SHARP support arithmetic FHE efficiently but do not accelerate TFHE. TFHE accelerators such as Morphling support logic FHE efficiently but do not support CKKS. The supplied account states that there was no prior accelerator that supports scheme conversion as a first-class operation. Trinity is proposed to remove that fragmentation by providing one accelerator that can serve CKKS, TFHE, and conversion workflows.

A common misconception is that conversion must be handled as a separate exotic primitive outside the main acceleration path. The paper argues the opposite: conversion is expressed through kernels already needed by CKKS and TFHE. This suggests that unification is not merely a packaging decision, but a consequence of a deeper arithmetic commonality among the supported schemes.

2. Finite-kernel decomposition of CKKS, TFHE, and conversion

A key theoretical claim is that CKKS, TFHE, and their conversion procedures can each be decomposed into a finite set of reusable arithmetic kernels (Deng et al., 2024). For CKKS, the identified kernels are NTT, BConv, IP, ModMul, ModAdd, and Auto. The automorphism transform is defined by

$\sigma_r(i) = i \cdot 5^r \bmod N.$

Within the paper’s hierarchical reconstruction model, higher-level CKKS operations are reduced to these kernels. HMult is mapped to NTT, BConv, IP, ModMul, and ModAdd; HRotate adds Auto; Rescale is reduced to NTT and ModAdd.

TFHE is presented through the kernels ModSwitch, Blind Rotation, External Product, SampleExtract, and TFHE KeySwitch. Its central procedure is programmable bootstrapping, described as a sequence of arithmetic subroutines. The simplified view given in the paper begins with ModSwitch on an input ciphertext $c=(a,b)$:

$$\tilde{c} = (\tilde{a}, \tilde{b}) = \text{ModSwitch}(c),$$

with

$$\tilde{c} = \left(\left\lfloor \frac{2N}{q} \cdot \mathbf{a} \right\rceil, \left\lfloor \frac{2N}{q} \cdot b \right\rceil \right).$$

Blind Rotation then proceeds over $n_{\text{lwe}}$ iterations, each using an External Product, with the recurrence

$$\text{ACC}_i = \text{ACC}_{i-1} + \text{INTT}(\text{tmp\_acc}).$$

SampleExtract converts GLWE to LWE, and TFHE KeySwitch is written as

$$c'' = (0,\ldots,0,b') - \sum_{i=0}^{kN} \sum_{j=0}^{l_k} a''_i[j] \cdot \text{ksk}[i][j].$$

Scheme conversion is reduced to the same style of kernel composition. For CKKS→TFHE, conversion is essentially repeated SampleExtract operations, one per slot:

$ct'_i = \text{SampleExtract}(ct,i).$

For TFHE→CKKS, the procedure consists of ring embedding, ciphertext packing, and field trace. The packing recursion is

$$ct = (ct_{even} + \text{Rotate}(ct_{even}, N/n_{slot})) + \text{HRotate}(ct_{even} - \text{Rotate}(ct_{odd}, N/n_{slot}), n_{slot}+1),$$

followed by field trace:

$ct = ct + \text{HRotate}(ct, 2^{\log N - k + 1}).$

The paper explicitly interprets these formulas as evidence that conversion is a composition of rotation, extraction, and homomorphic linear transforms rather than an isolated primitive.

3. Mathematical structures and transform choices

The mathematical setting differs across the supported schemes but is cast into a shared arithmetic substrate. CKKS works over the polynomial ring

$c=(a,b)$0

where $c=(a,b)$1, and a CKKS ciphertext is typically an RLWE pair

$c=(a,b)$2

TFHE uses LWE and GLWE ciphertexts. The forms listed in the paper are

$c=(a,b)$3

for LWE and

$c=(a,b)$4

for GLWE. GGSW ciphertexts are matrices of polynomials of size

$c=(a,b)$5

The transform layer is central to Trinity’s unification strategy. NTT is used to accelerate polynomial multiplication by moving from coefficient to evaluation representation. The supplied material gives the standard form

$c=(a,b)$6

for an $c=(a,b)$7-th root of unity $c=(a,b)$8 modulo $c=(a,b)$9, with $$\tilde{c} = (\tilde{a}, \tilde{b}) = \text{ModSwitch}(c),$$0 typically a power of two. The paper emphasizes radix-2, constant-geometry, and four-step NTT.

A major design choice is the replacement of FFT with NTT in TFHE. The paper states that this is possible if one chooses a prime modulus $$\tilde{c} = (\tilde{a}, \tilde{b}) = \text{ModSwitch}(c),$$1 such that

$$\tilde{c} = (\tilde{a}, \tilde{b}) = \text{ModSwitch}(c),$$2

with $$\tilde{c} = (\tilde{a}, \tilde{b}) = \text{ModSwitch}(c),$$3 chosen close to the TFHE modulus $$\tilde{c} = (\tilde{a}, \tilde{b}) = \text{ModSwitch}(c),$$4 (Deng et al., 2024). This enables TFHE to use NTT instead of FFT, thereby reusing CKKS-style NTT hardware and avoiding floating-point complexity and approximation error. The significance is architectural as much as algorithmic: exact finite-field transforms allow the same transform-centric hardware substrate to serve both arithmetic and logic FHE.

4. Architectural organization and configurable reuse

Trinity is organized around clusters, each containing heterogeneous functional blocks. Each cluster includes an NTTU, a TP, CU-x configurable units with $$\tilde{c} = (\tilde{a}, \tilde{b}) = \text{ModSwitch}(c),$$5 PE columns, an AutoU, a Rotator, an EWE, a VPU, and scratchpad and local buffers. The overall system contains 4 clusters, 2 HBM2 interfaces, and a fully connected inter-cluster NoC (Deng et al., 2024).

The central hardware mechanism is the Configurable Unit, or CU. A CU can act either as an NTT engine or as a MAC or systolic-array-like engine depending on the kernel being executed. Internally, the CU’s NoC can be configured as a butterfly topology for NTT or as a 2D mesh for systolic-array behavior. The PE datapath is designed so that the same physical PEs support NTT, iNTT, and MAC. This is the principal means by which Trinity shares hardware between transform-heavy and multiply-accumulate-heavy portions of FHE workloads.

The paper identifies three architectural challenges that motivate this design. The first is concurrent support for NTT and FFT; the chosen answer is to replace FFT with NTT in TFHE. The second is high utilization across varying polynomial lengths. TFHE typically uses $$\tilde{c} = (\tilde{a}, \tilde{b}) = \text{ModSwitch}(c),$$6 to $$\tilde{c} = (\tilde{a}, \tilde{b}) = \text{ModSwitch}(c),$$7, whereas CKKS, especially with bootstrapping, often uses $$\tilde{c} = (\tilde{a}, \tilde{b}) = \text{ModSwitch}(c),$$8. The utilization study summarized in the supplied material states that a deep, multi-stage NTT design is best for large $$\tilde{c} = (\tilde{a}, \tilde{b}) = \text{ModSwitch}(c),$$9, while a shallow, wide NTT design is best for smaller $$\tilde{c} = \left(\left\lfloor \frac{2N}{q} \cdot \mathbf{a} \right\rceil, \left\lfloor \frac{2N}{q} \cdot b \right\rceil \right).$$0. The third challenge is stable performance across different kernels. The reported arithmetic breakdowns are 59.2% NTT and 40.8% MAC for CKKS KeySwitch, and 75.5% NTT and 24.5% MAC for TFHE PBS. These imbalanced mixes motivate dynamic reassignment of shared resources.

5. Scheduling policy and algorithmic optimizations

Trinity’s execution model begins by decomposing a workload into a kernel flow, scheduling that flow to avoid contention, and allocating units dynamically based on the current kernel mix (Deng et al., 2024). The stated design philosophy is to prioritize NTT needs first, then assign unused CUs to BConv, IP, or External Product. The paper is explicit that CKKS and TFHE kernels are not run arbitrarily at the same time inside the same CU; the objective is controlled scheduling with dynamic resource reallocation rather than unconstrained overlap.

Several algorithmic optimizations are identified as central. The most consequential is replacing FFT with NTT in TFHE through appropriate modulus selection. Another is configurable support for multiple NTT lengths. Trinity’s NTTU is built around a constant-geometry NTT and a four-step NTT approach. The NTTU handles base cases efficiently; for larger transforms, the four-step method splits the work into phase-1 and phase-2 NTTs. When the polynomial is larger, part of the transform may be computed in the NTTU and part in the CU, which the paper presents as a way to improve utilization across sizes.

The NTTU also minimizes memory bandwidth by using OF-Twist, described as on-the-fly generation of twiddle or twisting factors, similar to ARK. In addition, the CU is reused for both NTT and MAC so that the same silicon can track shifts in arithmetic mix. This rebalancing is emphasized for CKKS KeySwitch, TFHE external products, and TFHE PBS. A further design choice is to use the CU for Inner Product instead of the EWE in some CKKS paths, which the paper associates with reduced bottlenecks and improved utilization.

A plausible implication is that Trinity’s optimization strategy is less about accelerating one dominant primitive in isolation and more about managing transitions among kernels whose relative weight changes across schemes and across phases within a scheme.

6. Measured performance, utilization, area, and workload coverage

The reported evaluation spans pure CKKS workloads, pure TFHE workloads, deep neural network TFHE workloads, scheme conversion, and hybrid applications (Deng et al., 2024). Against SHARP, Trinity achieves 1.49× average speedup for CKKS and up to 1.85× on HELR. Reported absolute latencies include 1.92 ms for bootstrapping and 1.37 s for HELR. Against Morphling, Trinity achieves 4.23× average speedup for TFHE PBS and up to 4.32× on Set-III. The paper also compares against a 1 GHz Morphling variant and CU variants, and states that the CU reuse strategy materially improves throughput.

For NN-20, NN-50, and NN-100 TFHE workloads, the supplied material states 919.3× average speedup over a CPU TFHE baseline and up to 950.9× for NN-100. For TFHE→CKKS conversion, the abstract reports 919.3× speedup over the CPU-based implementation, while the detailed discussion highlights an average 7814× speedup over baseline-SC. Example reported latencies are 0.049 ms for $$\tilde{c} = \left(\left\lfloor \frac{2N}{q} \cdot \mathbf{a} \right\rceil, \left\lfloor \frac{2N}{q} \cdot b \right\rceil \right).$$1, 0.063 ms for $$\tilde{c} = \left(\left\lfloor \frac{2N}{q} \cdot \mathbf{a} \right\rceil, \left\lfloor \frac{2N}{q} \cdot b \right\rceil \right).$$2, and 0.142 ms for $$\tilde{c} = \left(\left\lfloor \frac{2N}{q} \cdot \mathbf{a} \right\rceil, \left\lfloor \frac{2N}{q} \cdot b \right\rceil \right).$$3.

For HE3DB-style hybrid workloads, Trinity is reported at 0.42 s and 1.68 s, compared with 5.64 s and 22.55 s for a SHARP+Morphling system, with the baseline hybrid CPU setup described as far slower. The paper reports an average 13.42× speedup over SHARP+Morphling and 7107× over the baseline hybrid CPU setup. These numbers are significant because the motivating use case for Trinity is precisely the hybrid setting in which arithmetic computation, logic computation, and conversion coexist.

Utilization measurements are also part of the paper’s argument for configurability. The reported gains are an NTT utilization improvement of 1.2×, CKKS utilization improvement of 1.08× when using the CU for inner product, and TFHE PBS utilization improvement of 1.45× with CU reuse. Average utilization is reported as over 48% for CKKS workloads and over 64% for TFHE PBS workloads. Trinity’s total area is reported as

$$\tilde{c} = \left(\left\lfloor \frac{2N}{q} \cdot \mathbf{a} \right\rceil, \left\lfloor \frac{2N}{q} \cdot b \right\rceil \right).$$4

with total power

$$\tilde{c} = \left(\left\lfloor \frac{2N}{q} \cdot \mathbf{a} \right\rceil, \left\lfloor \frac{2N}{q} \cdot b \right\rceil \right).$$5

A central area claim is that Trinity’s hardware overhead is only 85% of the summed area of SHARP and Morphling, corresponding to a 15% area reduction relative to the combined area.

7. Interpretation and research significance

The main contribution of Trinity is the claim that CKKS, TFHE, and CKKS↔TFHE conversion can be accelerated by one unified FHE architecture rather than by separate specialized accelerators (Deng et al., 2024). The core technical insight is that these schemes reduce to a shared set of arithmetic kernels, particularly NTT, MAC, rotations, modular arithmetic, and extraction. On that basis, the architecture combines configurable CUs, NTT hardware reuse, dynamic workload allocation, and load balancing across kernels.

The paper also frames scheme conversion as architecturally native rather than externally attached. That positioning matters for hybrid FHE systems, because the absence of conversion support as a first-class operation was one of the defining limitations of prior siloed accelerators. By integrating conversion into the same kernelized hardware substrate, Trinity treats multi-scheme execution as a scheduling and mapping problem rather than as a boundary between incompatible devices.

An objective qualification is that the paper’s claims are organized around the specific trio of CKKS, TFHE, and their conversion scheme. It does not present unification as a scheme-agnostic result for all homomorphic encryption variants. Even so, the supplied evidence suggests a broader design principle: when apparently distinct FHE workflows collapse into a finite number of arithmetic kernels, unified acceleration becomes possible through configurable reuse rather than strict specialization.