面向 Dev Multiverse 的下一代 FHE 工具链：TFHE 如何带领我们实现这一目标

介绍

FHE 正在改变游戏，欢迎大家参与。

如果你不知道我在说什么，那说明你最近过得有点与世隔绝。去浏览一下FHE.org 上的一些综合资源，然后再回来。

为了向科技界兑现FHE的承诺，它必须配备新一代工业强度的开发、编译和运行时执行工具，任何人都可以使用它来轻松构建同态应用程序。

不过，目前，FHE 领域的许多专家和公司仍将大部分时间和精力投入到改进 FHE 背后的加密技术上，而不是专注于为非专家构建出色的开发工具。听我说：增强核心 FHE 功能和性能永远是好消息。但从大局来看，这些渐进式改进最多只能在一定程度上促进全球采用。它们会在某个时候对采用产生影响，但不是现在。

从我的角度来看，很明显，当今科技界需要功能强大、开发人员友好的 FHE 工具链，以便开始解锁由 FHE 驱动的成功案例，并将 FHE 从技术趋势转变为数字安全业务的实际范式转变。我相信，目前关于 FHE 的知识水平（无论是科学上还是技术上）已经足以在当下构建此类工具，并让精通技术的大众毫不拖延地使用它们。新功能的持续集成将随着时间的推移自然展开，它总是如此。

但问题是：FHE 有多种形式。根据您使用的加密方案 - 或者您将其用于何种特定用途，会出现表示计算和运行同态程序的不同方式。这就像 FHE 方案完全是不同的动物，一个给你图灵机，另一个给你 lambda 演算。生物多样性在技术或其他方面总是好的，但这也意味着您在实践中使用 FHE 时需要确定一个可行的策略。

我的公司Zama专注于一种特定的 FHE 方案，即TFHE。TFHE凭借非常特殊的资产实现了同态数据处理：超快速引导和以表查找网络表示的计算。我们已经深入了解了这些特性（这些特性曾经使 TFHE 在 FHE 领域处于劣势）如何转化为同态库、编译、虚拟机或硬件加速。

其他著名的 FHE 竞争者，如CKKS 、 BGV或BFV，在实际应用中涉及的概念截然不同：引导速度太慢，因此处理深度有限，但数据可以通过大规模批处理进行矢量化，计算表示为多项式电路，并且 - 对于 CKKS - 结果是近似的。因此，将 BGV/BFV 和 CKKS 转换为编译器和运行时需要工具构建者具有完全不同的思维方式。

不过，开发人员不太可能太关心哪种特定方案为他们的 FHE 工具链和运行时环境提供支持，只要它们易于操作且在部署的同态应用程序中满足性能要求即可。他们本身就是富有创造力的建设者，他们的重点应该放在他们可以为用户提供的新体验上。

因此，FHE 技术推动者的最终目标是构思和交付不仅能在开发多元宇宙中大放异彩，而且足够强大以树立新的行业标准的工具。为了实现这一目标，他们必须冒险选择更可能让他们实现这一目标的 FHE 方案。

来玩个游戏。

假设有一位开发人员对 FHE 的复杂性一无所知，但想要构建一个同态应用程序。您是这里的工具构建者，您面对的是这位开发人员，您可以期望他熟悉一些常见的开发实践和计算机科学的基础知识，但其他一切 - 高级数学等，都是禁忌。您如何才能成功地让他们自己制作 FHE 应用程序？

本文探讨了通过投注 TFHE 来赢得该比赛的各种策略。

根据应用程序的性质（自定义数据处理、神经网络、智能合约或通用编程），我们将探索由 TFHE 支持的制胜之路。这一探索将带我们走上一条简单的道路、一条艰难的道路，以及介于两者之间的其他道路，并在实际实现中具有不同的技术准备水平。

什么是 TFHE 计划？

TFHE 代表 Torus FHE。TFHE 也以其发现者的名字命名为 CGGI，它在 FHE 领域占有独特的地位：它是最著名的实现可编程引导 (PBS) 的机制。

简而言之，PBS 是一种同态表查找。它返回T[x]的加密，其中T是您选择的列表函数，给定索引x的加密。它的运行速度不取决于T的条目，而只取决于条目的数量，并且以毫秒为单位。此外，PBS 会重置其输出密文中嵌入的加密噪声，因此您可以无限地按顺序编写 PBS，同时知道您的同态应用程序将始终处理干净的密文。

TFHE 网络

TFHE 所倡导的计算模型是典型的。

TFHE 程序中的基本处理单元看起来与神经元完全一样，并由两个基本同态运算组成：

1. 输入的线性组合返回E(x) ，其中x = w_1 x_1 + … + w_n x_n modulo m ，给定加密输入E(x_1), …, E(x_n)和一组明文权重w_1, …, w_n 。

   
   

2. 一个 PBS，根据E(x) E(T[x])其中T是某个大小为m的明文表。

在“TFHE 神经元”中， m 、 x_i 、 w_i以及条目T[0], …, T[m-1]都是整数，并且可以自由选择“参数” m 、 w_1, …, w_n和T鉴于线性组合的成本几乎为零，效率瓶颈是 PBS，其运行时间仅取决于模数m ：速度随着m增加而降低。这促使在 TFHE 神经元中使用较小的值（奇数或偶数，但至少为 2）作为模数，尽管必须找到一种权衡，以避免计算表达能力的大幅降低。

现在，就像神经网络中的神经元被组装成层以利用并行性和 HPC 技巧一样，TFHE 网络将 TFHE 神经元层堆叠起来。每层都有一个权重矩阵，模数为一个公共模数m和一个大小为m的查找表向量。但是，模数在前一层或后一层中可以自由变化，就像层的形状一样。

这就是 TFHE 的全部内容！好了，我们只需要系统地将函数表达为查找网络。现在我们有了同态计算模型。

实际上，TFHE 支持该模型的多种扩展（任意低级运算符图、各种类型的密文、多输出表查找、多种变量打包方式等）。但我们暂时可以忽略这些增强，因为查找网络视觉已经足够强大，足以让我们将普通程序转换为同态等价程序并运行它。因此，我们可以专注于如何做到这一点，至少对于该技术的第一次迭代来说是这样。

使 TFHE 网络可执行

因此，TFHE 网络只是一个蓝图，尚未准备好在同态应用中正确执行。尽管其所有层的模数、权重矩阵和查找表都已完全指定，但它仍然缺少一个关键要素，即加密参数化。

加密参数决定了运行时网络内将发生的所有可能指标：具体密文大小、PBS 内部密钥切换和引导密钥的实际张量维度、低级同态运算符中的各种算法选项、明文精度和噪声级别如何在整个网络中演变，以及最终加密和解密的具体方法。它们还可以预测内存使用情况和性能。

找出哪组参数可以优化 TFHE 网络的执行可能很麻烦，而且无论如何，即使是专家也很难像 FHE 早期那样用纸笔方式进行计算，因为一切都取决于一切。此外，几个最佳集合可能同时共存，因此需要在公钥大小、关键路径延迟或最大吞吐量之间进行套利。幸运的是，自动执行此任务的问题在过去几年中已经得到解决，现在有强大的优化工具可以快速确定给定 TFHE 网络的最佳加密实例。

一旦使用加密参数实例化，TFHE 网络就真正变得可执行，或者更确切地说，通过适当的编译即可成为真正的可执行文件。

TFHE 计划

TFHE 程序是通过“简单逻辑”粘合在一起的参数化 TFHE 网络的集合。

简单的逻辑是由

• 对明文变量（即普通的、非加密的变量）进行操作的指令，

• 分支，无论是无条件的还是有条件的，以明文谓词为条件，

• 在明文地址进行内存读写、指针运算，

• 调用子程序/函数。

  
  

基本上，纯逻辑包含语言支持的任何编程逻辑，但有一种情况除外：修改加密的程序变量，这是程序的 TFHE 部分的特权。纯逻辑对密文（以及 TFHE 公钥）唯一允许做的事情是将它们不加改变地移动并将它们提供给 TFHE 部分，就好像它们在自己独立的协处理器或容器内运行一样。

无论出于何种目的，符合此定义的程序都是完整的，可以成为成熟的同态应用程序，无论编程语言是什么。自定义编译将提供此最终映射，然后生成的对象可以在启用 TFHE 的运行时上运行，也可以作为独立的、自包含的可执行文件运行。

可以使用专用语言来统一 TFHE 程序的表示——比如某些 DSL，或者更好的MLIR 方言——以便可以使用相同的后端编译器执行编译。

运行时的确切性质（共享/动态库、VM 或其他）只是一种形式。任何一种选择都将产生一个可操作的 TFHE 驱动的同态应用程序，可以部署并向用户展示。

现在让我们回顾一下正在进行的游戏。

我们面对的是一位对 TFHE 或上述内容一无所知但想要构建同态应用程序的开发人员。假设我们已经发布了上面讨论的编译器和支持 TFHE 的运行时（如果有）。

我们的目标已经确定了，我们只需要一个 TFHE 程序就可以得到可执行文件。但是……我们到底要如何让开发人员自己制作像 TFHE 程序这样具体的东西呢？

简单的方法：发布一个 FHE lib，让开发人员做他们的事情

简单的制胜之路就在这里：将所有复杂性封装到黑盒 FHE API 中。

普通程序

在任何编程语言中，一个（简单的）程序本质上都可以看作是以下三个成分的组合：

• 程序逻辑由语言原生指令和作用域结构组成，

• 变量和程序分配给它们的数据类型选择，在所有可能的数据类型中选择，

• 调用在所有可用的外部函数中选择的外部函数，程序使用这些函数对其变量进行操作。

  
  

数据类型有自己的子语言，即原生类型和类型构造的混合，用于扩展这些原生类型并将它们组合成更高级别的结构化类型。类型系统旨在提供足够的表达能力，以涵盖程序可能需要的几乎所有数据结构。外部函数是由库（标准或其他）提供的函数，但它们也可以由语言原生指令隐式调用（想想模块化算术或除法的运算符）。

因此，普通程序实际上很“简单”：

听我说完。我并不是说，所有高级编程概念（例如多态性、对象及其成员和属性、类和层次继承、模板、宏、特征、线程、递归、语法糖、注释以及语言提供的所有其他可以想象到的零成本抽象）对于开发人员来说都是必要的，尽管它们是为了简化他们的工作而发明的。

我只是说，就我们的目的而言，它们只是无害的装饰，在编译时会消失，因为从源代码推断出程序的简化但等效的规范形式版本。该版本的程序，以任何中间表示 (IR) 表示，由直线基本块组成 - IR 中的基本指令序列 - 通过一些控制流图连接。

现在，这个程序的常规形式才是“简单的”。我的意思是，简单到可以增强同态能力。

将 FHE 放入图片中

通过发布语言原生的 FHE 库并让开发人员处理如何最好地使用它，您就赢得了游戏。

该库将公开新的数据类型（加密数据类型，以补充普通数据类型）以及一组同态函数，这些函数（或多或少）模仿开发人员熟悉的普通函数，只是它们适用于加密数据类型。简而言之，您正在扩展类型系统和库生态系统，并让开发人员的智慧弄清楚如何使用这些扩展来制作他们的同态应用程序。

这与 TFHE 没有特别的联系，任何 FHE 方案都可以。这就是各种 FHE 库的提供者所关注的：通过公开看起来和感觉尽可能接近普通编码体验的高级同态函数来提高 FHE 的可用性和用户友好性。所有加密复杂性都被抽象到程序将进行 oracle 调用的黑盒中。

当然，这对开发者来说可能很好。好吧...如果你作为库提供者履行了自己的承诺。

他们将找出一个同态程序，现在看起来像这样。

现在有纯变量和加密变量共存，程序必须在这两种对象类型之间保持严格的区分。这是因为有一条 FHE 黄金法则，它告诉我们，当你将函数应用于纯变量和加密参数的混合时，结果必然是加密的，例如fhe_add(E(x), y)返回E(x+y)等等。因此，纯变量可以进入某些 FHE 函数，但永远不能从中出来。同态加密通过计算“污染”了它接触到的一切。

那么，看看......那么如何有条件地分支到加密变量？

嗯，不能。不过这根本不是什么大问题。

一个小问题：条件分支

在 FHE 应用程序中，条件分支只能作用于普通布尔值，而不能作用于加密布尔值。您如何知道根据加密位跳转到哪里？您没有用户的私钥来解密该位。

幸运的是，FHE 还为您提供了一些简单的技巧来解决这个问题。

如何正则化 if

假设开发人员最初想做类似的事情

if (x == 0) then y = 3 else z = 7

但意识到到那时，变量x实际上将被加密。如何修改这段代码？

首先要做的是重新编写普通的if语句以获得使用多路复用的等效直线代码：

 bit = (x == 0) // bit = 1 if x == 0 otherwise 0 y = 3 * bit + y * (1 - bit) // y = 3 if bit == 1 otherwise no change z = z * bit + 7 * (1 - bit) // z = 7 if bit == 0 otherwise no change

在第二遍中，开发人员必须在后续行中传播x是加密类型的事实：

 bit = fhe_is_equal(x, 0) // bit, y_new and z_new are encrypted y_new = fhe_add(fhe_mul(3, bit), fhe_mul(y, fhe_sub(1, bit))) z_new = fhe_add(fhe_mul(z, bit), fhe_mul(7, fhe_sub(1, bit)))

我们可以检查这在功能上是否等同于开发人员的初衷，就是这样。

如果编程语言允许本机运算符重载，FHE API 甚至可以使第二个代码片段的显式 FHE 函数变得多余，以便第一次重写是开发人员唯一需要做的事情。

为了给开发人员提供额外的语法糖，您甚至可以公开重载三元运算符a? b : c ，其中任何参数都可以加密或不加密。这段代码变得更加简单：

 bit = (x == 0) // bit = 1 if x == 0 otherwise 0 y_new = bit? 3: y // y = 3 if bit == 1 otherwise no change z_new = bit? z: 7 // z = 7 if bit == 0 otherwise no change

这很容易推广到任意的if/switch语句：每次有一个加密条件需要检查时，开发人员只需使用多路复用将语句的多个主体融合成一个等效的直线代码块。

如何规范 for/while 循环

现在，涉及加密条件的循环结构可以以同样的精神进行正则化。例如

for (i = 0; i < x; i++) do <body> // i is plain, x is encrypted

其中x是加密类型。首先，将其分解为一个简单的for语句和一个不规则的if语句：

 for (i = 0; i < known_max_value_of_x; i++) do if (i < x) then <body> // i is plain, x is encrypted

然后像前面一样对if语句进行正则化：

 for (i = 0; i < known_max_value_of_x; i++) do bit = (i < x) // i is plain, x and bit are encrypted <new_body> // new body regularized using bit? _ : _

注意到这需要一个立即数known_max_value_of_x 。默认情况下可以使用x的加密类型支持的最大值，但在许多情况下，开发人员知道x的更好的上限，这允许将总循环数减少到严格的最小值。

最终，上述转换很容易推广为一种系统的方法来规范不规则的控制流，程序员很容易吸收并融入到他们的编码习惯中。

示例：EVM 上的机密智能合约

Zama 的fhEVM是一个成熟的开源框架，用于在以太坊虚拟机 (EVM) 上开发和部署机密智能合约。fhEVM 合约是使用传统 Solidity 工具链构建的简单 Solidity 合约。熟悉的开发体验由库TFHE.sol增强，该库提供加密数据类型和标准函数的 FHE 替代品。

目前支持的加密数据类型有

ebool, euint4, euint8, euint16, euint32, euint64, eaddress

加密的带符号整数也即将被纳入。加密变量是使用专用构造函数从原始输入密文创建的：

 function mint(bytes calldata encryptedAmount) public onlyContractOwner { euint64 amount = TFHE.asEuint64(encryptedAmount); balances[contractOwner] = balances[contractOwner] + amount; totalSupply = totalSupply + amount; }

为了方便开发人员，Solidity 的原生运算符+, -, *, &, |, ^, etc进行了重载，并且提供的比较运算符eq, ne, gt, lt, ge, le返回加密的布尔值ebool 。同态三元运算符_? _ : _称为select ：

 function bid(bytes calldata encryptedBid) internal { euint32 bid = TFHE.asEuint32(encryptedBid); ebool isAbove = TFHE.le(bid, highestBid); // Replace highest bid highestBid = TFHE.select(isAbove, bid, highestBid); }

在运行时方面，fhEVM 提供了一个支持 TFHE 的 EVM，其中同态函数被公开为预编译合约，这是开源TFHE-rs Rust 库集成的结果。

有关详细信息，请参阅fhEVM 白皮书。

使用 TFHE 构建 FHE API 需要什么？

还记得可执行的 TFHE 程序是什么样子的吗？参数化的 TFHE 网络由简单的逻辑组装而成。好吧，你只需要一种方法将开发人员的软件逻辑映射到它。

第一个要求是确保程序逻辑“简单”。这正是我们通过规范控制流语句来教开发人员自己编写的。所以现在我们在这方面做得很好。

第二个要求是程序调用的所有同态函数必须映射到预先建立的参数化 TFHE 网络。由于多种原因，这比看起来更复杂。

1. 你需要为你的 API 函数创建 TFHE 网络

预先建立实现给定功能的参数化 TFHE 网络并不一定是一件简单的事情。

仅构建 2 个加密的 64 位无符号整数的同态加法就会让你面临许多技术选择：如何将 64 位输入表示为模整数向量？具体用什么模数（或多个模数）？然后如何实现具有多层表查找功能的 64 位加法电路？

选择很多。但通过良好的工程设计和大量的实验，你最终会做出决定。

2. 需要规范化加密数据类型

假设您为 API 的所有功能实现了 TFHE 网络，您希望确保它们可以像乐高积木一样随意组合。

这不一定能得到保证，因为表示相同加密数据类型的最佳方式可能因函数而异。因此，您需要采用通用的算术格式来表示每种加密数据类型，而不会对 TFHE 网络的效率造成太大的影响。

同样，有很多选择，您需要在它们之间进行套利。

3. 你需要确保实际的可组合性

假设所有 TFHE 网络现在在输入/输出格式上完全兼容，但可组合性可能仍然无法得到保证。

这是因为实例化一个 TFHE 网络的加密参数可能与实例化另一个 TFHE 网络的加密参数不兼容。尤其是，必须调整输入和输出密文中的加密噪声级别，以确定实际的可组合性。

这类似于电子电路中的阻抗，如果阻抗不匹配，就无法将一个电路连接到另一个电路。您需要先对齐它们的阻抗水平，这里也是一样。最简单的方法是使用固定的参数集 - 甚至可能只有一个唯一的参数集 - 经过调整以确保所有 API 函数的对齐。随后，无论开发人员编写什么代码，用户公钥的格式以及用户加密和解密中使用的参数都将固定。

那么为什么 FHE 库不够好呢？

它们足以用于通用编程，再次假设 FHE API 足够全面，能够为开发人员期望的所有标准功能提供同态替换，并具有完全的可组合性。

但对于专门研究

• 机器学习中的大型计算密集型函数，

• 定制的、非标准功能。

  
  

这时候同态编译就派上用场了。

艰难之路：发布同态编译器

艰难的道路从这里开始：要想在通用编程之外赢得比赛，您现在需要提供一个 TFHE 编译器。

编译器将处理开发人员自己不知道如何做的事情。它将接受开发人员的输入（无论输入是什么，您都可以调用），并且必须完成缺失的部分才能生成 TFHE 程序。

让我们看一下非标准应用的典型示例。

利用深度神经网络进行机密推理

通过将普通神经网络转变为同态等效网络，开发人员将构建和部署同态推理服务，其中用户输入和输出是端到端加密的。

开发人员提供的输入内容

开发人员应该足够了解机器学习，能够生成经过训练的量化模型，或者已经拥有一个量化模型。

量化的具体细节在这里确实很重要，因为您的编译器将要求模型基本上是一个 TFHE 网络 - 或者通过简单的重写即可轻松适应。已知可用的开源技术支持这种形式的量化，要么通过对预先训练的模型进行后量化，要么最好通过执行量化感知训练 (QAT)，与在同一数据集上训练的非量化模型相比，它可以实现最先进的准确度。

本质上，TFHE 网络层中使用的模数是 2 的可变幂，因此激活信号的精度以位为单位。权重是有符号整数，激活函数本身被量化并实例化为表查找。当激活将移位的硬符号函数与学习到的偏移量制成表格时，此定义涵盖了BNN 、 TNN等模型类型及其多位泛化。但原则上，人们可以自由地在激活函数中使用任意查找表，因此甚至可以在训练期间学习这些查找表以达到更好的准确性。

然而，开发人员不知道如何将他们的 TFHE 网络转换为同态可执行文件。因此，这里唯一缺少的要素只是该网络的加密参数化，而这正是您的编译器在进入后端编译阶段之前必须做的全部工作。

参数化 TFHE 网络需要什么？

请记住，TFHE 网络的参数化提供了可执行的加密实例。它还控制与该执行相关的所有指标，例如用户公钥的总大小和总运行时间。因此，参数化在这里至关重要，因为开发人员正在寻求将推理延迟降至最低。

TFHE 网络的加密参数有太多自由度，无法全部强制执行。此外，要优化的指标取决于网络完全外部的两个组件，并且取决于运行时用于执行低级 TFHE 操作的算法：

• 噪声公式集合。噪声公式将算子端点处的加密噪声的输入和输出分布关联起来，使用算子的参数作为未知变量。建立它们需要人类的科学分析和实验验证。

• 成本指标集合。成本指标根据操作符的参数预测其多维效率（内存使用、运行时间等）。它们通常是通过最佳拟合分析从基准测量中推断出来的。

  
  

运行时的噪声公式和成本模型与给定的 TFHE 网络一起构成了一整类优化问题的特定实例，并将该实例移交给专用优化器。我们在这里讨论的是具有多个目标的混合整数非线性规划，因此找出最优参数集的帕累托前沿需要解决该类非平凡的优化问题。

技术准备

良好的科学和工程技术使得此类优化问题在几秒钟内得到解决，并且Concrete等 TFHE 编译器已经将高效的 TFHE 参数优化器作为内部模块。

各种改进可以使 TFHE 优化器在未来变得更快，但即使没有这些改进，人们也可以认为 TFHE 网络的参数化几乎已经完成。

高速自定义数据处理

开发人员提供的输入内容

这些应用程序完全是另一种类型。开发人员掌握要实现的自定义函数的数学规范以及精度约束。例如

其中x是 0 到 1 之间的实数，使用F的近似值G是可以接受的，只要

开发人员知道，通过编写标准 API 函数在信封背面实现G可能不是最理想的。

你的编译器将会动态地制造一个专门设计用于满足G规范的全新 TFHE 网络。然后它将对其进行参数化，并继续进行后端编译以生成同态应用程序。

合成 TFHE 网络需要什么？

目前，科学界缺乏关于如何自动合成具有我之前所述确切定义的 TFHE 网络的知识。甚至对同样依赖于整数值模数算法的相邻类型电路的合成研究也非常稀少。更不用说任何现有的能够从头到尾执行这项任务的合成器了。

利用布尔合成

解决这个问题的一种方法是通过将 TFHE 网络降级为布尔电路来利用其一小部分计算能力。例如，可以强制 TFHE 神经元充当三元布尔门

经过

• 将其输入数量设置为 3，并将x_1, x_2, x_3设置为 0/1 值，
• 将其模数设置为m = 4 ，将其权重设置为(w_1, w_2, w_3) = (2, -1, 1) ，
• 将其查找表设置为[0, 1, 1, 0] 。

通过强制所有可能的权重和具有相同模量的表，可以构成一个 TFHE 神经元字典，用于计算三元门。下一步包括

• 使用布尔综合工具根据开发人员的规范生成布尔电路（许多开源工具可用于执行此操作），
• 将电路切割（又称为 3 路 LUT 分区）为属于字典的三元门，
• 用等效神经元替代这些三元门，
• 将电路重塑为最小深度的分层网络。

这只是众多策略中的一种说明性策略，因为依赖布尔电路的方法有很多。您也可以只考虑通常的二进制门，并用受约束的 TFHE 神经元来实现它们。CEA 的Cingulata和后来的 Google 的FHE 转译器正是通过 TFHE 开辟了这条道路。

技术准备

布尔综合利用了积极的电路优化技术，总体来说是一个已解决的技术问题 - 或者说基本如此，这使得该方法对于构建编译器的人来说是合理且实用的。

然而，一旦以这种方式生成 TFHE 网络，其宽度和深度可能会异常高，导致整体性能不佳。因此，人们普遍怀疑，通过放松 TFHE 神经元的完全人工布尔条件，可以充分利用它们的表现力并获得更小、更浅的网络。

但同样，需要进行更多研究才能明确如何做到这一点。完全不同的方法（例如借用机器学习中的一些适当训练方法来学习 TFHE 网络）最终可能会提供更好的结果。时间会证明一切。

寻求一个包罗万象的 TFHE 编译器

假设我们的综合问题得到解决并产生高效的自定义 TFHE 网络，你就会发现自己已经准备好将所有移动的部分组合在一起并设计一个完成整个工作的编译器：

1. 它将一个简单的程序作为输入，其中敏感变量被简单地注释为加密。

2. 它将接受预先训练的神经网络或其他机器学习模型，并将其重新解释为 TFHE 网络。

3. 它将接受仅由数学规范制成的函数模型，并执行即时合成以生成自定义 TFHE 网络。

4. 它会在需要时使用优化器模块将编译单元中悬而未决的所有未参数化的 TFHE 网络转换为可执行实例。

5. 它将执行各种目标 TFHE 运行时或/和硬件架构的编译后端阶段。

6. 它将利用特定的硬件加速器（通过其成本模型）来实现更快的 TFHE 网络的合成和参数化。

   
   

好吧，你还不如加入一些对控制流自动规范化的支持，这样开发人员就不必再关心它了。

这将为 FHE 应用程序构建者提供终极开发体验。

概括

在通用 FHE 编程环境中，TFHE 库可以利用预先存在的工具链提供模块化和完全自主的开发体验。

TFHE 率先采用了特定的编译技术，可以满足开发人员更进一步的需求，特别是对于加密机器学习推理，以及未来几年的高速加密数据处理和其他定制的 FHE 应用程序。

总体而言，TFHE 提供了一条清晰的技术路径来创建更加集成和自适应的 FHE 工具链，这些工具链可以在软件开发领域大展身手，并催生出新一波隐私优先解决方案，任何人都可以以前所未有的轻松方式构建和运行。

通过专注于 TFHE 查找网络，我仅使用了 TFHE 可以支持的多个计算模型中的一个。随着研究逐渐发现其更多功能，毫无疑问，新的 TFHE 测量方法将浮出水面。

哪些以及何时是另一个故事。但在这个故事的背后隐藏着一系列其他令人兴奋且可能具有启发性的问题，这些问题与机密计算的未来有关。