MATCHA: TFHE ASIC Accelerator
- MATCHA is an ASIC accelerator designed for TFHE, a fully homomorphic encryption scheme that relies on FFT/IFFT-based polynomial transforms for bootstrapping.
- It reduces the dominant bootstrapping cost by employing approximate multiplication-less FFT/IFFT and pipelined execution, achieving around 0.16 ms NAND gate latency.
- MATCHA delivers 2.3× higher NAND-gate throughput and 6.3× better energy efficiency than previous accelerators while preserving standard 110-bit TFHE security.
MATCHA is an ASIC-style accelerator for fully homomorphic encryption over the torus (TFHE), designed to reduce the latency and energy cost of Boolean-gate evaluation by attacking the dominant cost center in TFHE bootstrapping: FFT/IFFT-based polynomial operations (Jiang et al., 2022). In the formulation reported for this system, TFHE is attractive because it supports arbitrary-depth Boolean computation with comparatively fast bootstrapping, yet a single gate remains expensive on conventional platforms: about 13.1 ms per NAND gate on CPU, roughly 0.37 ms on a GPU baseline, about 0.18 ms on a GPU with aggressive bootstrapping-key unrolling, and ms for FPGA/ASIC TVE-style baselines without BKU. MATCHA combines aggressive bootstrapping-key unrolling, approximate multiplication-less integer FFT/IFFT, and a pipelined datapath, yielding about 0.16 ms-class gate latency, higher NAND-gate throughput than prior accelerators, and higher throughput per Watt while preserving standard 110-bit TFHE security (Jiang et al., 2022).
1. Position within TFHE acceleration
TFHE evaluates Boolean gates and performs bootstrapping after essentially every nontrivial gate. In the reported cost breakdown, bootstrapping accounts for about 99% of CPU TFHE gate latency, and FFT/IFFT kernels account for about 80% of bootstrapping latency (Jiang et al., 2022). MATCHA is therefore organized around a narrow thesis: the critical path for practical TFHE acceleration is not generic integer arithmetic, but repeated polynomial transforms inside blind rotation and external-product computation.
The paper contrasts three prior hardware regimes. GPU implementations accelerate FFTs effectively, but still rely on expensive floating-point FFT/IFFT kernels and consume high power, so throughput-per-Watt remains poor. Prior FPGA approaches, especially TVE-style designs, are slower because they do not effectively support aggressive bootstrapping-key unrolling, do not pipeline bootstrapping-key-bundle construction with external-product phases, and repeatedly invoke costly double-precision floating-point FFT/IFFT kernels. CPUs are especially poor under aggressive unrolling because they have too few cores, suffer cache conflicts from enlarged bootstrapping keys, and cannot overlap bundle construction with external products in hardware (Jiang et al., 2022).
In this context, MATCHA is not presented as a universal FHE engine. It is a specialized accelerator for Boolean TFHE at a fixed security target and parameter set, optimized for the actual bottleneck structure of torus-based gate bootstrapping (Jiang et al., 2022).
2. TFHE formulation and the bootstrapping bottleneck
The mathematical setting follows standard TFHE. The torus is
with polynomial rings
For a plaintext bit , encryption samples (\mathbf{a}\xleftarrow{\$}\mathbb{T}^n\) and error \(e\), and formsDecryption returns%%%%202020$}\mathbb{T}^n\) and error \(e\), and forms$20%%%%32.3\times$4, so rounding recovers $2.3\times$5 (Jiang et al., 2022).
This correctness margin is central to MATCHA’s design. The accelerator introduces bounded approximation error inside FFT/IFFT kernels, but relies on TFHE’s noise tolerance and the refreshing effect of bootstrapping so that those errors do not cause decryption failures (Jiang et al., 2022). That design choice is not a change in hardness assumptions; it is a numerical exploitation of the existing TFHE correctness slack.
For bootstrapping, torus values are rounded to integers:
$2.3\times$6
The expensive blind-rotation term is
$2.3\times$7
which requires many polynomial multiplications. Naive multiplication is $2.3\times$8, while FFT/IFFT reduces it to $2.3\times$9. MATCHA targets precisely this transform-heavy inner loop (Jiang et al., 2022).
3. Approximate multiplication-less integer FFT/IFFT
The first major contribution is approximate multiplication-less integer FFT/IFFT. Prior TFHE software mapped torus values to 32-bit integers by scaling with $6.3\times$0, but still used 64-bit double-precision floating-point FFT/IFFT to preserve numerical accuracy. MATCHA argues that exact floating-point FFT hardware is both area- and power-intensive, and that TFHE does not require that level of transform fidelity as long as aggregate noise remains below the decryption threshold (Jiang et al., 2022).
Instead of floating-point complex multipliers, MATCHA uses a depth-first iterative conjugate-pair FFT and implements twiddle multiplication approximately using lifting steps. A basic lifting step is written as
$6.3\times$1
$6.3\times$2
Its matrix and inverse are
$6.3\times$3
By quantizing each floating-point lifting coefficient to a dyadic value $6.3\times$4, multiplication becomes a small number of additions and binary shifts; the paper gives $6.3\times$5 as an example (Jiang et al., 2022).
The resulting transform is integer-to-integer with perfect reconstruction in the lifting framework, while replacing expensive multipliers with shifters and adders. MATCHA standardizes on 64-bit dyadic-value-quantized twiddle factors. The reported approximation noise is about $6.3\times$6 dB, compared with about $6.3\times$7 dB for standard floating-point FFT/IFFT. Empirically, 38-bit DVQTFs caused no decryption failures for $6.3\times$8 TFHE gates when $6.3\times$9 was small, but larger unrolling such as $\mathbb{T} = \mathbb{R}/\mathbb{Z},$0 required 64-bit DVQTFs to avoid failures in the same test (Jiang et al., 2022).
This implies that the FFT/IFFT design is not merely an arithmetic simplification. It is a precision-engineering decision coupled tightly to TFHE’s bootstrap noise budget.
4. Aggressive bootstrapping-key unrolling and pipelined execution
The second major idea is aggressive bootstrapping-key unrolling. Standard blind rotation processes $\mathbb{T} = \mathbb{R}/\mathbb{Z},$1 secret-key terms sequentially. MATCHA groups multiple secret-key terms together to reduce the frequency of external products:
$\mathbb{T} = \mathbb{R}/\mathbb{Z},$2
for $\mathbb{T} = \mathbb{R}/\mathbb{Z},$3 (Jiang et al., 2022). For $\mathbb{T} = \mathbb{R}/\mathbb{Z},$4, the construction expands grouped selector terms using
$\mathbb{T} = \mathbb{R}/\mathbb{Z},$5
This permits pre-encryption of grouped key terms as TGSW ciphertext bundles.
BKU with $\mathbb{T} = \mathbb{R}/\mathbb{Z},$6 cuts bootstrapping additions roughly in half, and larger $\mathbb{T} = \mathbb{R}/\mathbb{Z},$7 reduces external-product frequency further, but at an exponential cost in bootstrapping-key size. The key observation of the paper is that aggressive unrolling is not automatically beneficial: on CPU, unrolling beyond $\mathbb{T} = \mathbb{R}/\mathbb{Z},$8 becomes slower, while on MATCHA the best point is $\mathbb{T} = \mathbb{R}/\mathbb{Z},$9. The paper attributes the poorer $\mathbb{R}_N[X] := \mathbb{R}[X]/(X^N+1), \qquad \mathbb{Z}_N[X] := \mathbb{Z}[X]/(X^N+1), \qquad \mathbb{T}_N[X] := \mathbb{R}_N[X]/\mathbb{Z}_N[X].$0 result to the fact that the design has only eight TGSW clusters, so available hardware parallelism cannot sustain the larger bundle-building workload (Jiang et al., 2022).
MATCHA makes larger $\mathbb{R}_N[X] := \mathbb{R}[X]/(X^N+1), \qquad \mathbb{Z}_N[X] := \mathbb{Z}[X]/(X^N+1), \qquad \mathbb{T}_N[X] := \mathbb{R}_N[X]/\mathbb{Z}_N[X].$1 practical through a specialized two-stage pipeline. Bootstrapping is split into overlapped phases: bootstrapping-key-bundle construction and external product. A TGSW cluster computes bundle terms, while an EP core consumes the previous bundle and updates the accumulator:
$\mathbb{R}_N[X] := \mathbb{R}[X]/(X^N+1), \qquad \mathbb{Z}_N[X] := \mathbb{Z}[X]/(X^N+1), \qquad \mathbb{T}_N[X] := \mathbb{R}_N[X]/\mathbb{Z}_N[X].$2
By overlapping these phases across iterations, bundle-construction cost is hidden, and aggressive BKU becomes beneficial on hardware rather than pathological (Jiang et al., 2022).
A concise statement of the reported noise trade-off is useful because it explains why unrolling cannot increase indefinitely.
| Noise term | BKU unrolled by 2 | MATCHA unrolled by $\mathbb{R}_N[X] := \mathbb{R}[X]/(X^N+1), \qquad \mathbb{Z}_N[X] := \mathbb{Z}[X]/(X^N+1), \qquad \mathbb{T}_N[X] := \mathbb{R}_N[X]/\mathbb{Z}_N[X].$3 |
|---|---|---|
| External-product noise | $\mathbb{R}_N[X] := \mathbb{R}[X]/(X^N+1), \qquad \mathbb{Z}_N[X] := \mathbb{Z}[X]/(X^N+1), \qquad \mathbb{T}_N[X] := \mathbb{R}_N[X]/\mathbb{Z}_N[X].$4 | $\mathbb{R}_N[X] := \mathbb{R}[X]/(X^N+1), \qquad \mathbb{Z}_N[X] := \mathbb{Z}[X]/(X^N+1), \qquad \mathbb{T}_N[X] := \mathbb{R}_N[X]/\mathbb{Z}_N[X].$5 |
| Rounding noise | $\mathbb{R}_N[X] := \mathbb{R}[X]/(X^N+1), \qquad \mathbb{Z}_N[X] := \mathbb{Z}[X]/(X^N+1), \qquad \mathbb{T}_N[X] := \mathbb{R}_N[X]/\mathbb{Z}_N[X].$6 | $\mathbb{R}_N[X] := \mathbb{R}[X]/(X^N+1), \qquad \mathbb{Z}_N[X] := \mathbb{Z}[X]/(X^N+1), \qquad \mathbb{T}_N[X] := \mathbb{R}_N[X]/\mathbb{Z}_N[X].$7 |
| Bootstrapping-key noise | $\mathbb{R}_N[X] := \mathbb{R}[X]/(X^N+1), \qquad \mathbb{Z}_N[X] := \mathbb{Z}[X]/(X^N+1), \qquad \mathbb{T}_N[X] := \mathbb{R}_N[X]/\mathbb{Z}_N[X].$8 | $\mathbb{R}_N[X] := \mathbb{R}[X]/(X^N+1), \qquad \mathbb{Z}_N[X] := \mathbb{Z}[X]/(X^N+1), \qquad \mathbb{T}_N[X] := \mathbb{R}_N[X]/\mathbb{Z}_N[X].$9 |
| FFT/IFFT approximation noise | about $m \in \mathbb{B}=\{0,1\}$0 dB | about $m \in \mathbb{B}=\{0,1\}$1 dB |
As $m \in \mathbb{B}=\{0,1\}$2 increases, external-product and rounding noise decrease linearly, but bootstrapping-key noise grows exponentially. This is the central precision trade-off that fixes $m \in \mathbb{B}=\{0,1\}$3 as the architectural optimum for this implementation (Jiang et al., 2022).
5. Microarchitecture and memory system
Architecturally, MATCHA contains a polynomial unit, eight TGSW clusters, eight EP cores, 32 scratchpad-memory banks, crossbars connecting memories and compute units, and an HBM2 memory controller/PHY (Jiang et al., 2022). One TGSW cluster plus one EP core forms one bootstrapping pipeline.
The polynomial unit handles polynomial additions/subtractions, bootstrapping initialization, sample extraction, and key switching using adders, comparators, and logic units. Each TGSW cluster contains 16 32-bit integer multipliers, 16 32-bit integer adders, and a 16 KB two-bank register file. Each EP core contains one FFT core, four IFFT cores, four 32-bit integer multipliers, four 32-bit integer adders, and a 256 KB eight-bank register file (Jiang et al., 2022).
The FFT/IFFT core includes address generation, a twiddle-factor buffer, input/output FIFOs, and 128 butterfly cores; each butterfly contains two 64-bit integer adders and two 64-bit shifters. The depth-first conjugate-pair organization reduces twiddle reads and improves locality. The paper also notes that CPFFT needs only one complex root-of-unity read per radix-4 butterfly, and two butterflies in the same block can share a twiddle, halving twiddle-buffer traffic (Jiang et al., 2022).
The memory system is tuned to the access asymmetry between TGSW scaling and FFT/IFFT. TGSW scaling has strong spatial locality, so a two-bank ping-ponged register file is sufficient. FFT/IFFT accesses are irregular, so EP cores use eight-bank storage. All compute blocks connect to 32 scratchpad banks through bit-sliced crossbars, with separate paths for SPM-to-cores, cores-to-SPM, and cores-to-cores. HBM2 provides 640 GB/s (Jiang et al., 2022). The paper explicitly states that separate register banks for TGSW clusters and EP cores are used to avoid on-chip memory conflicts between sequential-access TGSW stages and irregular FFT/IFFT stages.
The reported implementation summary is as follows.
| Component | Power | Area |
|---|---|---|
| Each TGSW cluster | 0.98 W | 0.368 mm4 |
| Each EP core | 2.87 W | 1.89 mm5 |
| Eight pipelines total | 30.8 W | 18.06 mm6 |
| Polynomial unit | 2.33 W | 0.32 mm7 |
| Crossbars | 2.11 W | 0.44 mm8 |
| 4 MB 32-bank SPM | 3.52 W | 3.25 mm9 |
| Memory controller/HBM2 PHY | 1.225 W | 14.9 mm$}\mathbb{T}^n\) and error \(e\), and forms$0 |
| Total | 39.98 W | 36.96 mm$}\mathbb{T}^n\) and error \(e\), and forms$1 |
The design is synthesized in 16 nm and runs at 2 GHz (Jiang et al., 2022).
6. Security, performance, and quantitative significance
MATCHA does not claim a change in cryptographic security level. It retains standard TFHE parameters for 110-bit security:
$}\mathbb{T}^n\) and error \(e\), and forms$2
The approximation affects numerical correctness margins, not the underlying hardness assumptions (Jiang et al., 2022).
Performance claims are reported relative to multiple baselines. NAND-gate latencies are listed as 13.1 ms for the CPU baseline, 6.67 ms for CPU with BKU $}\mathbb{T}^n\) and error \(e\), and forms$3, 0.37 ms for the GPU baseline, 0.18 ms for GPU with aggressive BKU $}\mathbb{T}^n\) and error \(e\), and forms$4, and $}\mathbb{T}^n\) and error \(e\), and forms$5 ms for FPGA/ASIC TVE-style baselines without BKU. MATCHA is best at $}\mathbb{T}^n\) and error \(e\), and forms$6, improving latency by 13% over the GPU baseline, with about 0.16 ms-class gate latency (Jiang et al., 2022).
The more explicit throughput claims are $}\mathbb{T}^n\) and error \(e\), and forms$7 higher NAND-gate throughput than the best prior accelerator and $}\mathbb{T}^n\) and error \(e\), and forms$8 higher throughput per Watt (Jiang et al., 2022). The energy-efficiency result is tied not only to faster gate execution, but also to the power gap between platforms: the paper notes GPU power above 200 W, whereas MATCHA consumes 39.98 W.
These quantitative results matter because TFHE gate acceleration is frequently constrained by two coupled costs: frequent bootstrapping and expensive floating-point transforms. MATCHA’s contribution is to remove floating-point FFT hardware from the critical path, reduce external-product frequency by aggressive BKU, and keep the enlarged key-bundle workflow sustainable through pipeline overlap. The throughput and throughput-per-Watt gains should be read as the consequence of those three design decisions acting together, rather than as an isolated circuit-level optimization (Jiang et al., 2022).
7. Scope, limitations, and nomenclature
The main limitations are architectural rather than cryptographic. Aggressive BKU is not arbitrarily scalable because bootstrapping-key size grows exponentially with $}\mathbb{T}^n\) and error \(e\), and forms$9, key noise increases as 0, and the fixed number of TGSW clusters limits practical unrolling; in this design, 1 is optimal and 2 is no longer efficient (Jiang et al., 2022). The approximate FFT/IFFT strategy is safe here because TFHE refreshes ciphertexts frequently and retains sufficient twiddle precision, but the paper explicitly notes that the same approach is less transferable to leveled HE schemes where approximation error may accumulate without immediate bootstrapping. The accelerator is also specialized for Boolean TFHE at the chosen parameter set, not a general-purpose FHE processor (Jiang et al., 2022).
The name “MATCHA” is not unique across arXiv. It has also been used for an Android Studio plugin for privacy nutrition labels (Li et al., 2024), a Mathematica package for matching UV models onto HEFT (Gómez-Ambrosio et al., 9 Jun 2026), a correspondence model for “matching anything” in computer vision (Xue et al., 24 Jan 2025), and several other systems in robotics, evaluation, recommendation, and text generation. In the hardware-security literature, however, MATCHA specifically denotes the TFHE accelerator introduced in “MATCHA: A Fast and Energy-Efficient Accelerator for Fully Homomorphic Encryption over the Torus” (Jiang et al., 2022).