Zama TFHE 密文的Bootstrapping：小于1ms!

1. 引言

Zama 团队近期宣布，其突破了 TFHE Bootstrapping 的 1 毫秒大关 ------ 现在在 GPU 上的延迟以微秒计，同时保持相同的安全等级与错误概率（针对 4 位消息）。

全同态加密（Fully Homomorphic Encryption, FHE）使得在加密数据上执行任意数量的操作成为可能。这得益于一种特殊的操作------Bootstrapping。然而，Bootstrapping也是 FHE 的主要性能瓶颈：

若要让 FHE 得以广泛应用，必须极大地降低其延迟并提升吞吐量。
- 只有当加密计算在速度上接近明文计算时，FHE 才能真正进入实用阶段。

Zama团队长期致力于 TFHE 可编程 Bootstrapping 的加速研究。可编程 Bootstrapping 机制是 TFHE-rs 中所有操作的核心：

它不仅能重置密文中的噪声，还能在同态域中对其应用任意函数。
- 这为在加密数据上实现通用算术运算提供了极大的灵活性与能力。

Zama 最初的 TFHE Bootstrapping 实现，在 CPU 上的执行时间为 53 毫秒，安全等级为 128 位，且在 4 位消息下的错误概率为 2 − 128 2^{-128} 2−128。

而如今：

Zama TFHE Bootstrapping 的延迟已正式突破 1 毫秒大关，并在 GPU 上以微秒级速度运行 ------ 同时保持相同的安全性与错误概率。

2. Bootstrapping 的加速历程

全同态加密（FHE）之所以能在加密数据上进行无限次操作，正是因为 Bootstrapping 操作的存在。

该概念由 Craig Gentry 于 2009 年提出，基于格密码学（lattice-based cryptography）：

其核心思想是在同态域中计算解密电路本身。
- 当时的估算表明，这一过程的计算时间可能长达 30 分钟。

到了 2018 年，TFHE Bootstrapping 被正式提出 [Chillotti2020]（2020年论文 TFHE: Fast Fully Homomorphic Encryption Over the Torus），延续了其前身 FHEW 的设计思路。

在大多数 FHE 方案中，一次 Bootstrapping 通常要处理数千条消息，即使你只想处理一条或几条消息，也必须为整个batch（批处理）付出代价。

而 TFHE 则不同：

它的 Bootstrapping 延迟极低。正如前文所述，Zama 的首个实现仅需 53 毫秒。

若要让 FHE 计算真正无缝进行，Bootstrapping 的延迟与吞吐量都必须尽可能接近明文计算。TFHE 的出现，让单次或少量 Bootstrapping 的低延迟计算成为现实。

自项目初期起，Zama 就着手研究在 GPU 上加速 TFHE Bootstrapping 的可能性------尽管该算法本质上是高度顺序化的，不太适合 GPU 并行执行。

然而，经过不断优化，Zama逐步将 Bootstrapping 时间一再压缩。

到了 2024 年，在 NVIDIA H100 GPU 上执行一次 TFHE Bootstrapping 的时间仅需 2 毫秒，比最初的 CPU 实现快了 26 倍。

这项成果得益于在 TFHE 引导（bootstrap）中采用了一种替代算法------多比特（multi-bit）算法 [Zhou2018][Joye2022]（2018年论文 Faster bootstrapping with multiple addends 以及 2022年论文 Blind Rotation in Fully Homomorphic Encryption with Extended Keys），该算法具有更高的并行度。

这种算法同样可以在 CPU 上实现，以获得更低的延迟，但代价是吞吐量显著下降。
而在 GPU 上，该算法则非常契合：它在保持吞吐量的同时，大幅降低了延迟。

在首次实现之后，团队进行了大量底层优化，以充分利用 GPU 资源并最大化并行性。性能就这样一步步提升。

在 2021 到 2024 年之间，TFHE 的安全级别发生了变化：

如今的 TFHE-rs 已达到 IND-CPA D \text{IND-CPA}^D IND-CPAD 安全性，但在 2021 年的 Concrete 库中，它还仅具备 IND-CPA 安全性（因为当时尚未发现相关攻击）。
为了在 IND-CPA D \text{IND-CPA}^D IND-CPAD 攻击下仍保持 128 位安全性，研究团队不得不调整密码学参数，并引入新的技术来缓解攻击 [Bernard2025, Ruijter2025]（2025年论文Drifting towards better error probabilities in fully homomorphic encryption schemes 以及 2025年论文 Don't be mean: Reducing Approximation Noise in TFHE through Mean Compensation）。
- 这些变化对性能带来了显著影响，但随后通过一系列优化和新的密码学技术（尤其是用于降低引导后噪声水平的改进），最终得到了补偿。

尽管如此，2 毫秒的延迟仍然不够快。

过去几个月中，Zama 的 GPU 团队专注于进一步优化引导性能。

引入了一种针对区块链加密参数的编译期专用实现。
- 这种方法利用了在编译时已知的更多变量，从而降低了 GPU 的寄存器压力；结合细致调优的优化手段，成功实现了显著的性能提升。
- 目前，单个 GPU 上的引导延迟约为 800 微秒（µs），并维持 128 位 IND-CPA D \text{IND-CPA}^D IND-CPAD 安全性。

该引导方案对两位消息（2-bit message）进行加密，用于布尔运算，并采用高斯噪声（Gaussian noise） ------ 这是文献中的参考标准。

而在实际应用中，TFHE-rs 在区块链场景中使用的是对 4 位消息（4-bit message）加密、并采用 TUniform 噪声分布的版本：

在这种参数下，引导耗时为 945 微秒（µs）。

3. 性能基准（Benchmarks）

下表展示了当前 GPU 版本与 2021 年原始 CPU 版本的性能对比。

参数均基于 IND-CPA D \text{IND-CPA}^D IND-CPAD 安全性，即 128 位安全性与失败概率 ≤ 2 − 128 \leq 2^{-128} ≤2−128，并使用 TUniform 噪声分布。

延迟	布尔型（Booleans）	4 位整数（当前使用）
2021	19 ms	53 ms
2025	796 µs	945 µs
加速比	24×	56×

CPU 与 GPU 的引导延迟对比说明：

CPU 延迟数据来自 2021 年的 Concrete-core 0.1.10，用于对比当前 GPU 延迟。

密文采用高斯噪声分布，安全性为 128 位，失败概率为 2 − 128 2^{-128} 2−128。

GPU 测试在 Nebius 平台上使用 1×H100 显卡进行，CPU 测试在 AWS hpc7a.96xlarge 实例上完成。

由此可见：

对于原始 TFHE 的布尔引导，实现了 24 倍性能提升；
对于 4 位整数（目前产品中使用的类型），提升达到了 56 倍。

TFHE 另一个极具吸引力的特性在于：

在多 GPU 上执行大批量引导（bootstrap batch）非常简单。
只需将输入分块（chunk）并分配给不同 GPU，独立执行引导即可。
- 执行过程中无需 GPU 间同步或协作。

因此，吞吐量可达到：

单节点（8×H100 GPU）上，每秒执行 189,000 次 4-bit 引导。

吞吐量	布尔型（Booleans）	4 位整数（当前使用）
2021	135 PBS/s	74 PBS/s
2025	223,440 PBS/s	189,000 PBS/s
提升幅度	1,655×	2,554×

CPU 与 GPU 吞吐量说明：

CPU 吞吐量同样来自 2021 年的 Concrete-core 0.1.10。

密文使用高斯噪声分布，128 位安全性，失败概率为 2 − 128 2^{-128} 2−128 。

GPU 结果在 Nebius 平台（8×H100）上测得，CPU 结果在 AWS hpc7a.96xlarge 上测得。

4. 对大整数（FheUint）运算的影响

单次引导（bootstrap）的延迟是评估 FHE 性能的良好指标，但在真实应用中，很少只涉及一次引导操作。

因此，当前 TFHE-rs 的 GPU 实现并非单纯针对最低延迟（latency-oriented）或最高吞吐量（throughput-oriented）进行优化，而是选择了两者之间的折中方案（tradeoff）。

这对于加速更高层次的运算（如对加密 32 位或 64 位消息的密文进行加法或乘法）至关重要。

若要进一步提升性能，可以针对延迟或吞吐量分别进行专门优化实现。

但当前方法的优势在于：

它为未来的性能优化奠定了坚实的基础。

在当前实现下，对于加密 64 位整数的加法与乘法运算，其延迟表现非常出色。

在单个配备 8×H100 GPU 的节点上：

两个 64 位加密消息的加法耗时 8.7 毫秒（ms），
乘法耗时 32 毫秒（ms），

具体如下表所示：

延迟（Latency）	64 位加密加法	64 位加密乘法
2022	2 秒	13 秒
2025	8.7 毫秒	32 毫秒
提升幅度	230×	406×

CPU 与 GPU 上的 64 位加密加法与乘法延迟对比说明：

CPU 延迟基于 2022 年 12 月的 Concrete 版本测得。

密文采用 TUniform 噪声分布，安全性为 128 位，失败概率为 2 − 128 2^{-128} 2−128。

GPU 结果测得于 Nebius 平台（8×H100），CPU 结果测得于 AWS hpc7a.96xlarge 实例。

完整的性能基准表（benchmarks）将在下一个 TFHE-rs 版本发布时公开。

Zama团队预计，这一最新成果将极大推动 FHE 在工业界的应用落地，尤其是在区块链领域。

但需要注意，在这些场景中，FHE 并非唯一的性能瓶颈：

网络通信、MPC 协议、数据交换以及零知识证明（ZKP）等环节同样会影响整体性能。

尽管如此，如今的 FHE 性能已前所未有地接近明文计算的速度。

而这仅仅是个开始------随着专用加速器（dedicated accelerators）的出现，其性能有望超越 GPU。

参考资料

1\] Zama团队2025年9月17日博客 [Bootstrapping TFHE ciphertexts in less than one millisecond](https://www.zama.ai/post/bootstrapping-tfhe-ciphertexts-in-less-than-one-millisecond)