作者：Jeffrey Hu、Arnav Pagidyala

核心观点

· 全同态加密（FHE）被誉为“密码学的圣杯”，但目前其应用受到性能、开发体验和安全性方面的限制。

· 如上图所示，为了构建一个真正保密且安全的共享状态系统，需要将FHE与零知识证明（ZKPs）和多方计算（MPC）结合使用。

· FHE正在迅速发展；新的编译器、库、硬件等的开发，以及Web2公司（如英特尔、谷歌、DARPA等）的研发大大促进了FHE的发展。

· 随着FHE及其周边生态系统的成熟，我们预计“可验证的FHE”将成为标准。去中心化应用程序（DApps）/rollups可能选择将计算和验证外包给FHE协处理器。

· 链上FHE的一个基本限制是“谁持有解密密钥”。阈值解密（Threshold decryption）和MPC提供了针对这种限制的解决方案，但它们通常有需要在性能与安全性之间权衡的问题。

引言

区块链的透明性是一把双刃剑。虽然其开放性和可观察性很有吸引力，但这也恰恰是企业采用区块链技术时的顾虑所在。

链上隐私一直是加密领域近十年来最具挑战性的问题之一。尽管有许多团队正在构建基于零知识证明（ZKP）的系统来实现链上隐私；但它们无法支持共享的加密状态。原因在于这些方案是一系列ZKP的函数，因此不可能对当前状态应用任意逻辑。这意味着我们不能仅仅使用ZKP来构建加密的共享状态应用程序（比如私有的Uniswap）。

然而，最近的技术突破表明，将ZKP与全同态加密（FHE）相结合，可以实现完全通用化、加密的去中心化金融（DeFi）。这是如何实现的呢？FHE是一个新兴的密码学领域，能够在加密数据上进行任意计算。如上图所示，ZKP可以证明用户输入和计算的完整性，而FHE可以处理计算本身。

虽然FHE被誉为“密码学的圣杯”，我们将试图提供对该领域及其各种挑战及可能解决方案的客观分析。该技术报告将涵盖以下链上FHE主题：

1. FHE方案、库和编译器（FHE Schemes, Libraries and Compilers）

2. 安全阈值解密（Secure Threshold Decryption）

3. 用户输入和计算方的ZKP（ZKPs for User Inputs + Computing Party）

4. 可编程、可扩展的数据可用性（DA）层（Programmable, Scalable DA Layer）

5. FHE硬件（FHE Hardware）

全同态加密（FHE）方案、库和编译器

挑战：新兴的FHE方案、库和编译器

链上FHE的基本瓶颈在于其开发工具和基础设施的滞后。与零知识证明（ZKP）或多方计算（MPC）不同，FHE自2009年以来发展时间较短，因此成熟度较低。

FHE开发体验的主要限制包括：

· 缺少易于使用的前端语言，让开发者在不需要深入了解后端密码学的情况下进行编码。

· 缺少功能齐全的FHE编译器，能够处理所有复杂的工作（如参数选择、BGV/BFV的SIMD优化和并行优化）。

· 现有的FHE方案（特别是TFHE）与普通计算相比大约慢1000倍。

为了真正理解整合FHE的复杂性，让我们来看一下开发者所要经历的流程：

将FHE整合到应用程序中的第一步是选择一个FHE方案。下表解释了主要的方案：

如上表所示，布尔电路（如FHEW和TFHE）具有最快的bootstrapping 速度，可以避免复杂的参数选择过程，并且可以用于任意/通用计算，但相对较慢；而BGV/BFV适合一般DeFi应用，因为它们在高精度算术计算方面更高效，但开发者必须提前知道电路的深度以设置scheme的所有参数。另一方面，CKKS支持同态乘法，允许精度误差，使其适用于非精确用例，如机器学习。

作为开发者，你需要非常谨慎地选择一个FHE方案，因为它将影响所有其他设计决策和未来的性能。此外，还有几个关键参数对于正确设置FHE方案至关重要，例如模数大小的选择和多项式次数的作用。

接下来我们讨论库，下表展示了目前使用较多的FHE库的功能和能力：

但是，这些库与不同的FHE方案和编译器的关系也各不相同，如下所示：

选择了FHE方案后，开发者需要设置参数。正确选择参数将对FHE方案的性能产生巨大影响。比较困难的是，这需要对抽象代数、FHE特定操作（如重新线性化和模数切换）以及算术或二进制电路有所了解。最后，为了有效选择参数，需要从概念上理解它们如何影响FHE方案。

此时，开发者可能会问：

我的明文（plaintext）空间需要多大？可以接受多大的密文？我在哪里可以并行计算？等等问题……

此外，尽管FHE可以支持任意计算，但开发者在编写FHE程序时需要改变思维方式。例如，程序中不能根据变量写一个分支（if-else），因为程序不能将变量视为普通数据进行直接比较。相反，开发者需要将代码从分支改为可以包含所有分支条件的某种计算。同样，这也阻止了开发者在代码中编写循环。

简而言之，对于不熟悉FHE的开发者来说，将FHE整合到他们的应用程序中几乎是不可能的。这将需要显著的开发工具和基础设施来抽象化FHE所呈现的复杂性。

解决方案：

1. Web3特定的FHE编译器

虽然已经存在由谷歌和微软等公司构建的FHE编译器，但它们：

· 没有以性能为设计目标，与直接编写电路相比增加了1000倍的“开销”

· 为CKKS（即ML）优化，对于DeFi所需的BFV/BGV并不那么有益

· 不是为Web3构建的。不支持与ZKP方案、可编程区块链等的兼容性。

直到Sunscreen FHE编译器的出现。它是一个Web3原生编译器，为算术操作（例如DeFi）提供了一些最佳性能，而不需要硬件加速器。如上所述，参数选择可能是实施FHE方案最困难的部分。Sunscreen不仅自动化了参数选择，还实现了数据编码、密钥选择、实施重新线性化和模数切换、设置电路和实现SIMD操作。

随着技术的不断进步，我们期待看到不仅在Sunscreen编译器中，还有其他团队构建属于自己的，能够支持其他高级语言的进一步优化。

2. 新的FHE库

虽然研究人员不断探索新的有效方案，但FHE库也可以使更多开发者整合FHE。

以FHE智能合约为例。尽管从不同的FHE库中进行选择可能很困难，但当我们谈论链上FHE时，选择就变得更容易了，因为在Web3中只有少数几种主导编程语言。

例如，Zama的fhEVM将Zama的开源库TFHE-rs集成到典型的EVM中，将同态操作作为预编译合约公开。有效地使开发者能够在他们的合约中使用加密数据，而无需对编译工具进行任何更改。

而对于其他特定场景，可能还需要一些其他基础设施。例如，用C++编写的TFHE库维护得不如Rust版本好。尽管TFHE-rs可以支持C/C++的导出，但如果C++开发者想要更好的兼容性和性能，他们必须编写自己的TFHE库版本。

最后，市场缺乏FHE基础设施的一个核心原因是我们缺少有效的方式来构建FHE-RAM。一个可能的解决方向是针对一个没有某些操作码的FHE-EVM进行研究。

安全阈值解密（Secure Threshold Decryption）

挑战：不安全/中心化的阈值解密

每个保密的共享状态系统都基于加密和解密密钥。由于不能信任任何单一方，因此解密密钥在网络参与者之间通过多方计算（MPC）进行分片。

链上全同态加密（FHE）最具挑战性的方面之一是构建一个安全且高性能的阈值解密协议。主要有两个瓶颈：

（1）基于FHE的计算引入了显著的“开销”，因此需要高性能的节点，这本质上减少了验证者集合的潜在规模；

（2）随着参与解密协议的节点数量增加，延迟也会增加。

至少目前为止，FHE协议依赖于验证者中的大多数是诚实的（honesty majority），然而如上所述，链上FHE意味着较小的验证者集合，因此存在更高的串谋和恶意行为的可能性。

如果阈值节点串谋作恶怎么办？它们将能够绕过协议，基本上解密任何东西，包括用户输入到任何链上数据。此外，更要注意的是在当前系统中解密协议可以不被察觉地发生（即“无声攻击”）。

解决方案：改进的阈值解密或动态MPC

有几种可能的方法来解决阈值解密的缺点。

（1）启用n/2阈值，这将使串谋更加困难；

（2）在硬件安全模块（HSM）内运行阈值解密协议；

（3）使用基于受信任执行环境（TEE）的阈值解密网络，由去中心化链控制认证，允许动态密钥管理。

与其利用阈值解密，更可能的情况是使用MPC。一个在链上FHE中可以使用的MPC协议的现象级的例子：Odsy的新的2PC-MPC，这是第一个非串谋且大规模去中心化的MPC算法。

另一种方法可能是仅使用用户的公钥来加密数据。然后验证者处理同态操作，必要时用户自己可以解密结果。虽然这只适用于特定的使用案例，但我们完全可以避免阈值假设。

总结来说，链上FHE需要一个高效的MPC实现，这种实现具备如下特点：

（1）即使在存在恶意行为者的情况下也能工作；

（2）引入最小的延迟；

（3）允许无需许可/灵活的节点加入。

用户输入和计算方的零知识证明（ZKP）

挑战：用户输入和计算的可验证性：

在Web2世界中，当我们请求执行一个计算任务时，我们完全信任某个公司会按照他们承诺的方式在幕后运行这个任务。在Web3中，这个模型完全颠倒了。我们不再依赖公司的声誉并简单地相信他们会诚信做事，而是在一个无需信任的环境中运作，这意味着用户不应该需要信任任何人。

虽然全同态加密（FHE）允许处理加密数据，但它无法验证用户输入或计算的正确性。如果没有验证的能力，FHE在区块链的背景下几乎没有用处。

解决方案：用户输入和计算方的ZKP：

虽然FHE允许任何人对加密数据进行任意计算，但ZKP允许人们在不透露底层信息本身的情况下证明某事是真实的。那么它们是如何相关的呢？

FHE和ZKP结合在一起有三个关键方式：

1. 用户需要提交一个证明，表明他们的输入密文是正确的格式。这意味着密文符合加密方案的要求，而不仅仅是任意的数据字符串。

2. 用户需要提交一个证明，表明他们的输入明文满足给定应用程序的条件。例如，账户余额大于转账金额。

3. 验证节点（即计算方）需要证明他们已正确执行FHE计算。这被称为“可验证的FHE”，可以看作是rollups所需ZKP的类比。

为了进一步探索ZKP的应用：

1. 密文的ZKP

FHE建立在基于格（lattice-based）的密码学上，这意味着加密原语的构造涉及格（lattice），这些格是后量子（post-quantum）安全的。相比之下，流行的ZKP，如SNARKs、STARKs和Bulletproofs，并不依赖于基于格的密码学。

为了证明用户的FHE密文格式正确，我们需要展示它满足某个带有环中元素（entries from rings）的矩阵-向量方程，并且这些元素的数值是小的。本质上，我们需要一个为处理基于格关系（lattice-based relations）而设计的、在链上验证成本效率高的证明系统，这是一个开放的研究领域。

2. 明文输入的ZKP

除了证明格式正确的密文外，用户还需要证明他们的输入明文满足应用程序的要求。幸运的是，与之前的步骤不同，我们可以利用通用的SNARKs来证明用户输入的有效性，从而使开发者能够利用现有的ZKP方案、库和基础设施。

然而，挑战在于我们需要“连接”这两个证明系统。连接意味着我们需要确保用户对两个证明系统使用了相同的输入。否则，恶意用户可能会欺骗协议。这里需要再次强调，这是一个极其困难的密码学壮举，也是一个早期研究的开放领域。

Sunscreen已经为此奠定了基础，他们的ZKP编译器支持Bulletproofs，因为它最容易与SDLP连接。针对“连接”FHE和ZKP编译器的研究也在不断推进。

Mind Network一直在引领ZKP的整合，以确保零信任输入和输出，同时利用FHE进行安全计算。

3. 正确计算的ZKP

在现有硬件上运行的FHE极其低效和昂贵。正如我们之前所见的可扩展性三难问题的动态表现，那些对节点资源要求较高的网络无法扩展到足够的去中心化水平。一个可能的解决方案是一个被称为“可验证的FHE”的过程，其中计算方（验证者）提交一个ZKP来证明交易的诚实执行。

一个可验证的FHE的早期原型可以通过一个名为SherLOCKED的项目展示。本质上，FHE计算被加载到Risc ZERO的Bonsai zkVM上，该VM在链下处理加密数据上的计算，并返回带有ZKP的结果，并在链上更新状态。

举一个利用FHE协处理器的最近的例子：Aztec的链上拍卖演示。正如我们之前所讨论的，现有的FHE链使用阈值密钥加密整个状态，这意味着系统的强度仅取决于其阈值委员会（threshold committee）。相反，在Aztec中，用户拥有自己的数据，因此不受阈值安全假设的约束。

最后，重要的是要了解开发者可以在哪里首先构建FHE应用程序。开发者可以在FHE支持的L1、FHE rollup上构建他们的应用程序，或者在任何EVM链上构建并利用FHE协处理器。每种设计都有其自身的权衡，但我们更倾向于设计良好的FHE rollups（由Fhenix开创）或FHE协处理器，因为它们从以太坊中继承了安全性等其他好处。

直到最近，在FHE加密数据上实现欺诈证明还是复杂的，但最近Fhenix.io的团队展示了如何使用Arbitrum Nitro堆栈与FHE逻辑编译到WebAssembly来实现欺诈证明。

FHE的数据可用性（DA）层

挑战：缺乏可定制性和吞吐量

虽然在Web2中“存储”已经商品化，但在Web3中情况并非如此。考虑到全同态加密（FHE）维持着超过10000倍的数据膨胀，我们需要确定在哪里存储大量的FHE密文。如果给定的DA层中的每个节点操作者都要下载并存储每个FHE链的数据，那么只有机构操作者才能跟上需求，从而增加了中心化的风险。

关于吞吐量，Celestia的最高速度为6.7 MB/s，如果我们想运行任何形式的FHEML，我们将需要每秒数GB的带宽。根据1k(x)最近分享的数据，由于设计决策限制了吞吐量（有意为之），现有的DA层无法支持FHE。

解决方案：水平扩展+可定制性

我们需要一个能够支持水平可扩展性的DA层。现有的DA架构将所有数据传播到网络中的每个节点，这是可扩展性的一个主要限制。相反，随着更多DA节点进入系统，水平可扩展性意味着每个节点存储的数据量减少，随着更多区块空间的可用，性能和成本得到改善。

另外，考虑到与FHE相关的大量数据的大小，为开发者提供更高级别的纠删码阈值（erasure coding thresholds）定制化是有意义的。换句话说，开发者对DA系统的保证感到什么程度的舒适？是基于权益的加权还是基于去中心化的加权。

EigenDA的架构可以作为FHE的DA层某种可能性的一个基础。它的水平扩展性、结构成本降低、DA和共识的解耦等属性，都为能够支持FHE的可扩展性水平铺平了道路。

最后，一个更高维度的想法可能是为存储FHE密文构建优化的存储槽，因为密文遵循特定的编码方案，所以拥有优化的存储槽可能有助于高效使用存储空间和更快的检索。

全同态加密（FHE）硬件

挑战：低性能的全同态加密（FHE）硬件

在链上全同态加密（FHE）应用的推广中，一个主要问题是由于计算开销导致的显著延迟，这使得在任何标准处理硬件上运行FHE变得不切实际。这种限制源自于与内存的大量交互，这是由于处理器需要处理巨大的数据量。除了内存交互外，复杂的多项式计算和耗时的密文维护操作也带来了大量的开销。

为了深入理解FHE加速器的状态，我们需要揭开其中具体设计的面纱：针对特定应用的FHE加速器与可泛化的FHE加速器。

FHE的计算复杂性和硬件设计的核心始终与给定应用所需的乘法数量有关，称为“同态操作的深度”。在特定应用的情况下，深度是已知的，因此系统参数和相关计算是固定的。因此，针对特定应用的硬件设计将更容易，并且通常可以优化以获得比可泛化加速器设计更好的性能。在一般情况下，如果需要FHE支持任意数量的乘法，需要引入bootstrapping技术来移除同态操作中积累的部分噪声。bootstrapping技术代价比较高，需要大量硬件资源，包括芯片内存、内存带宽和计算，这意味着硬件设计将与特定应用的设计大不相同。因此，尽管英特尔、Duality、SRI、DARPA等行业重要参与者在GPU和ASIC设计方面的工作无疑在提高上限，但它们可能无法一对一地应用于支持区块链场景。

在开发成本方面，可泛化硬件需要比特定应用的硬件更多的资本进行设计和制造，但其灵活性允许硬件在更广泛的应用范围内使用。另一方面，对于特定应用的设计，如果应用的需求变化并需要支持更深层次的同态计算，则需要将特定应用的硬件与一些软件技术（如MPC）结合使用，以实现与可泛化硬件相同的目的。

值得注意的是，与特定应用用例（例如FHEML）相比，链上FHE的加速要困难得多，因为它需要能够处理更一般的计算，而不是更具特定性的集合。例如，fhEVM开发网络目前的交易处理速度仅限于个位数TPS。

鉴于我们需要针对区块链定制的FHE加速器，另一个考虑因素是：从ZKP硬件到FHE硬件的可转移性到底如何？

ZKP和FHE之间存在一些共同的模块，例如数论变换（NTT）和底层的多项式操作。然而，这两种情况中使用的NTT的位宽（bit width）不同。在ZKP中，硬件需要支持NTT的多种位宽，例如64位和256位，而在FHE中，由于使用了剩余数系统，NTT的操作数较短。其次，ZKP中处理的NTT degree通常高于FHE。由于这两个原因，设计一个同时对ZKP和FHE都有令开发者满意的性能的NTT模块并非易事。除了NTT之外，FHE中还存在一些其他的计算瓶颈，如自同构（automorphism），这些在ZKPs中并不存在。将ZKP硬件简单转移到FHE设置的一种方法是将NTT计算任务加载到ZKP硬件上，并使用CPU或其他硬件处理FHE中的其余计算。

总结这些挑战，使用FHE在加密数据上进行计算曾经比在明文数据上慢100,000倍。然而，由于较新的加密方案和FHE硬件的最新发展，目前的性能已经显著提高到比明文数据慢大约100倍。

解决方案：

1. FHE硬件的改进

许多团队正在积极构建FHE加速器，但他们并未专注于特定于可泛化区块链计算（例如TFHE）的FHE加速器。一个针对区块链的特定硬件加速器示例是FPT，一种固定点FPGA加速器。FPT是第一个重度利用FHE计算中固有噪声的硬件加速器，它完全使用近似的固定点算术实现TFHE引导。另一个对FHE可能有用的项目是BASALISC，这是一个旨在云端大幅加速FHE计算的硬件加速器架构的系列。

正如前面提到的，FHE硬件设计中的一个主要瓶颈是与内存的大量交互。为了绕过这个障碍，一个潜在的解决方案是尽可能减少与内存的交互。处理器内存（PIM）或近内存计算（near memory computation）可能在这种情况下有所帮助。PIM是应对未来计算机系统的“内存墙（memory wall）”挑战的有希望的解决方案，它允许内存同时承担计算和存储功能，承诺对计算与内存关系进行根本性改革。在过去十年中，设计解决此问题的非易失性内存方面取得了巨大进展，例如电阻式RAM、自旋转移扭矩磁性RAM和相变存储器。使用这种特殊内存，已有研究显示在机器学习和基于格的公钥加密中显著改善了计算性能。

2. 优化的软件和硬件

在最近的发展中，软件被公认为硬件加速过程中的一个关键组成部分。例如著名的FHE加速器，如F1和CraterLake，使用编译器进行混合软硬件共同设计。

随着这一领域的发展，我们可以期待与针对区块链的FHE编译器共同设计的功能齐全的编译器。FHE编译器可以根据相应FHE方案的成本模型优化FHE程序。这些FHE编译器可以与FHE加速器编译器集成，通过结合硬件级别的成本模型，改善端到端性能。

3. 网络FHE加速器：从垂直扩展到水平扩展

现有的针对FHE硬件加速的努力主要集中在“垂直扩展”，即专注于单个加速器的垂直改进。另一方面，“水平扩展”则关注于通过网络横向连接多个FHE加速器，这可能会大大提高性能，类似于与零知识证明（ZKPs）的并行证明生成。

FHE加速的一个主要困难是数据膨胀问题：指的是在加密和计算过程中发生的数据大小显著增加，为芯片内和芯片外存储器之间的高效数据传输带来挑战。

数据膨胀对通过网络横向连接多个FHE加速器构成了显著的挑战。因此，FHE硬件与网络的共同设计将是未来研究的一个有前景的方向。例如针对FHE加速器的自适应网络路由：实现一种基于实时计算负载和网络流量，来动态调整FHE加速器之间数据路径的路由机制。这将确保最佳的数据传输速率和高效的资源利用。

结束语

FHE将从根本上重新构建我们在各个平台上保护数据的方式，为一个前所未有的隐私新时代铺平道路。构建这样一个系统将需要在FHE、零知识证明（ZKPs）和多方计算（MPC）上取得重大进展。

当我们进入这个新领域时，密码学家、软件工程师和硬件专家之间的协作努力将是必不可少的。更不用说立法者、监管机构等，因为合规性是实现主流采用的唯一途径。

归根结底，FHE将站在数字主权变革浪潮的前沿，预示着一个数据隐私和安全不再是相互排斥而是密不可分的未来。

特别鸣谢

非常感谢Mason Song（Mind Network）、Guy Itzhaki（Fhenix）、Leo Fan（Cysic）、Kurt Pan、Xiang Xie（PADO）、Nitanshu Lokhande（BananaHQ）的审阅。我们期待读者能去了解这些人在该领域所做的令人印象深刻的工作和努力！