将 ZKP 与全同态加密（FHE）相结合，可以实现完全通用化、加密的去中心化金融（DeFi）。

撰文：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）的审阅。我们期待读者能去了解这些人在该领域所做的令人印象深刻的工作和努力！