核心要点：
- 被誉为“密码学圣杯”的全同态加密（FHE），尽管面临性能、开发体验（DevEx）以及安全性的诸多挑战，限制了其当前的广泛应用。
- 正如所示，FHE需与零知识证明（ZKP）和多方计算（MPC）相结合，以打造一个真正保密且安全的共享状态系统。
- FHE的快速发展离不开新编译器、库和硬件的贡献，特别是受益于Web2公司（如英特尔、谷歌、DARPA等）的研究与开发。
- 随着FHE及其相关生态的成熟，我们预见“可验证FHE”将成为标准。分布式应用/rollups可能会选择将计算和验证任务外包给FHE协处理器。
- 链上FHE面临的一个根本限制是“谁持有解密密钥”，而阈值解密和MPC虽提供了解决方案，但通常存在性能与安全性的权衡。
引言：
区块链的透明性既是优点也是缺陷；其开放性和可观察性虽然美好，但却是企业采纳的一大障碍。
链上隐私问题已成为加密领域近十年来最大的挑战之一。许多团队致力于构建基于ZKP的系统以实现链上隐私，但它们无法支持共享、加密状态。为何如此？简单来说，因为这些程序基于一系列ZKP，使得无法对当前状态应用任意逻辑。这意味着我们无法仅凭ZKP来构建保密的共享状态应用（如私有版Uniswap）。
然而，最近的突破表明，将ZKP与FHE相结合能够实现全面通用的、保密的去中心化金融（DeFi）。FHE作为密码学的新兴领域，能够对加密数据进行任意计算。如图所示，ZKP能证明用户输入和计算的完整性，而FHE则负责处理计算本身。
尽管FHE被誉为“密码学圣杯”，我们仍旨在对该领域及其挑战和潜在解决方案进行客观分析。我们将讨论以下链上FHE主题：
- FHE方案
- 库和编译器
- 安全阈值解密
- 用户输入和计算方的ZKP
- 可编程
- 可扩展的DA层
- FHE硬件
FHE方案、库和编译器的挑战：
链上FHE的一大瓶颈在于其开发工具/基础设施的滞后。与ZKP或MPC不同，FHE自2009年问世以来发展时间较短，成熟度有限。
FHE DevEx面临的主要限制包括：
- 缺乏一种简单的前端语言，使得开发者无需深入了解后端密码学即可编码。
- 需要一个功能齐全的FHE编译器，能够处理所有复杂工作，如参数选择、BGV/BFV的SIMD优化和并行优化。
- 目前的FHE方案（特别是TFHE）与常规计算相比速度慢约1000倍。
为了深入理解FHE的整合复杂性，让我们深入探讨开发者的实际操作流程：
首先，整合FHE到应用中需要选择合适的FHE方案。以下表格阐述了主要方案的差异：
如表所示，布尔电路（例如FHEW & TFHE）具备最快的自举速度，能够规避复杂的参数选择过程，适用于任意/通用计算，但相对较慢；而BGV/BFV则更适合通用DeFi应用，因为它们在高精度算术运算中表现更高效，但开发者需要提前了解电路深度以设定所有参数。另一方面，CKKS支持同态乘法，允许一定的精度误差，使其成为如机器学习等非精确用例的理想选择。
作为开发者，在选择FHE方案时需要极度谨慎，因为这将影响所有后续设计决策和性能。此外，设置FHE方案的几个关键参数，如模数大小和多项式度数的选择，都至关重要。
接着，让我们来看看流行的FHE库及其特性和能力：
但这些库与不同方案和编译器之间的关系如下：
在选定FHE方案后，开发者需要设定参数。正确选择参数对FHE方案的性能产生重大影响。遗憾的是，这需要对抽象代数、特有于FHE的操作（如重线性化和模数切换）以及处理算术或二进制电路有深入的了解。为了有效选择参数，还需要从概念上理解这些参数如何影响整个方案。
此时，开发者可能会考虑：
我的明文空间需要多大？能接受哪种程度的密文？在哪些环节可以实现并行计算？等等。
此外，尽管FHE支持任意计算，但开发者在编写FHE程序时需要改变思维方式。比如，程序中不能根据变量写出分支（if-else），因为程序不能像处理明文数据那样直接比较变量。相反，开发者需要将代码从分支逻辑转变为能够整合所有分支条件的计算形式。同样，这也限制了在代码中使用循环的可能性。
总的来说，对于初涉FHE领域的开发者而言，将FHE整合到他们的应用中是一项几乎不可能的任务。这需要大量的开发工具和基础设施来抽象化FHE所带来的复杂性。
解决方案：
1.针对Web3的特定FHE编译器
虽然谷歌和微软等公司已经开发出FHE编译器，但这些编译器：
- 并非以性能为主导设计，相较于直接编写电路，增加了1000倍的开销。
- 针对CKKS（即机器学习）进行了优化，不适合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。
通过以上分析，我们看到全同态加密（FHE）作为密码学领域的激动人心的新领域，尽管在实际应用和开发方面面临诸多挑战，但随着技术的发展和生态系统的成熟，这些挑战预计将逐渐被克服，FHE在未来的加密和Web3领域将发挥越来越重要的作用。
安全阈值解密
挑战：不安全/中心化的阈值解密
每个保密共享状态系统的基础都是一个加密/解密密钥。由于无法完全信任任何单一方，解密密钥在网络参与者间通过多方计算（MPC）分割。
链上FHE最棘手的问题之一是构建一个既安全又高效的阈值解密协议。存在两个主要瓶颈：（1）基于FHE的计算引入的重大开销要求高性能节点，从而在本质上缩减了可能的验证者集合规模；（2）参与解密协议的节点数增加时，相应的延迟也会增加。
至少在目前，FHE协议依赖于验证者中的诚实多数，但如前所述，链上FHE意味着较小的验证者集合，从而增加了串谋和恶意行为的可能性。
如果阈值节点串谋将如何？它们将有能力绕过协议，实际上可以解密从用户输入到任何链上数据的一切。此外，值得注意的是，当前系统中的解密协议可能会悄无声息地进行（即“沉默攻击”）。
解决方案：改进的阈值解密或动态MPC
解决阈值解密的不足之处有几种可能的方法。首先，实现n/2阈值将使串谋变得更加困难；其次，可以在硬件安全模块（HSM）内运行阈值解密协议；最后，使用基于受信任执行环境（TEE）的阈值解密网络，由去中心化链控制认证，实现动态密钥管理，也是一个可行的方案。
相较于使用阈值解密，采用多方计算（MPC）可能是更好的选择。如Odsy的新型2PC-MPC协议，这是首个非串谋且大规模去中心化的MPC算法，是解决此问题的一个优秀例子。
另一种方法是仅使用用户的公钥来加密数据，之后由验证者处理同态操作，并由用户自行解密结果（如果需要）。虽然这种方法仅适用于特定的利基用例，但它能够完全避开阈值假设的问题。
总体而言，链上FHE需要一个高效的MPC实现，该实现即使在恶意行为者存在的情况下也能工作，引入的延迟最小，且能够允许节点无需特殊权限或灵活地加入。
ZKP在用户输入及计算方面的应用
挑战：用户输入及计算的可验证性
在Web2环境中，当我们请求计算任务时，我们完全信任特定公司会按其承诺在幕后执行任务。然而在Web3环境中，情况完全相反；与其依赖公司的声誉和诚实行事的承诺，我们现在处于一个无需信任的环境中，意味着用户不必信任任何人。
尽管FHE能够处理加密数据，但它无法验证用户输入或计算的正确性。没有验证能力，FHE在区块链背景下几乎毫无用处。
解决方案：ZKP在用户输入及计算方面的应用
虽然FHE允许任何人对加密数据执行任意计算，但ZKP可以在不透露底层信息的情况下证明某些事情的真实性。那么，它们如何相互关联？
FHE和ZKP的结合体现在三个关键方面：
- 用户需提交证明，证明其输入密文格式正确，即密文符合加密方案的要求，而非随机数据串。
- 用户需提交证明，证明其明文输入满足特定应用的条件，如账户余额大于转账金额。
- 验证者节点（计算方）需证明其正确执行了FHE计算，这称为“可验证FHE”，类似于rollup所需的ZKP。
进一步探讨ZKP的各种应用：
1.全同态加密（FHE）的密文在ZKP中的应用
FHE基于格密码学，意味着其构建涉及格，而这些格是具备抗量子（PQ）安全性的。相较而言，流行的ZKP技术如SNARKS、STARKS和Bulletproofs并不依赖格密码学。
为了证明用户的FHE密文格式正确，我们需展示它符合特定的矩阵-向量方程，这些方程的元素来自环，且大小较小。本质上，我们需要一个能够高效处理格关系并在链上验证成本效率的证明系统，这是一个开放的研究领域。
2.明文输入在ZKP中的应用
除了格式正确的密文证明外，用户还需证明其明文输入满足应用的要求。幸运的是，不同于之前的步骤，我们可以利用通用的SNARKs来验证用户输入的有效性，使开发者能利用现有的ZKP方案、库和基础设施。
然而，挑战在于如何将这两个证明系统“串联”起来。我们需要确保用户对两个证明系统使用了相同的输入，否则恶意用户可能会操纵协议。这是一个极其复杂的密码学任务，同时也是一个初步探索的研究领域。
Sunscreen已为此铺平了道路，他们的ZKP编译器支持Bulletproofs，因为它与SDLP连接最为紧密。未来的发展正在努力将FHE和ZKP编译器“链接”起来。
Mind Network在利用FHE进行安全计算的同时，也在集成ZKP方面走在前列，以确保零信任输入和输出。
3.正确计算的ZKP
在现有硬件上运行的FHE极其低效和成本高昂。我们见证了可扩展性三难题的展现，即高节点资源要求的网络难以达到足够的去中心化水平。一种可能的解决方案是所谓的“可验证的FHE”，即计算方（验证者）提交一个ZKP来证明交易的诚实执行。
“可验证的FHE”的早期原型由名为SherLOCKED的项目展示。在这里，FHE计算被转移到Risc ZERO的Bonsai zkVM上，在链下处理加密数据的计算，然后返回结果和一个ZKP，并在链上更新状态。
Aztec的链上拍卖演示是最近的一个实例。如前所述，现有的FHE链通过一个阈值密钥加密整个状态，因而系统的强度受限于其阈值委员会。相反，在Aztec中，用户自己拥有数据，不受阈值安全假设的约束。
重要的是要明确在哪里可以首先构建FHE应用程序。开发者可以在FHE驱动的L1、FHE rollup上构建他们的应用，或者在任何EVM链上构建并利用FHE协处理器。每种设计都有其自身的权衡，但我们更倾向于设计良好的FHE rollups（由Fhenix领先）或FHE协处理器，因为它们继承了以太坊等其他优势的安全性。
直至最近，对FHE加密数据进行欺诈证明还是一项复杂任务，但Fhenix.io的团队最近展示了如何利用Arbitrum Nitro堆栈结合FHE逻辑编译到WebAssembly来实现欺诈证明。
FHE的数据可用性（DA）层
挑战：缺乏定制化和吞吐量
虽然Web2中存储已实现商品化，但在Web3中却不尽相同。由于FHE的数据膨胀超过了10,000倍，我们需确定如何存储庞大的FHE密文。若每个DA层中的节点都需下载并存储每个FHE链的数据，那么只有机构级的操作者才能跟上这一需求，这增加了系统向中心化倾斜的风险。
关于吞吐量，Celestia的极限为每秒6.7MB，而若要运行任何形式的FHEML，所需的带宽可能达到每秒数GB。根据1k(x)最近的数据显示，由于设计上的选择，现有的DA层无法支持FHE，因为其吞吐量被有意限制。
解决方案：水平扩展 + 定制化
我们需要一个可以实现水平可扩展性的DA层。现有DA架构将所有数据传播到网络的每个节点，这成为扩展性的主要障碍。与此相反，随着越来越多的DA节点加入系统，每个节点存储的数据量减少到1/n，随着更多区块空间的释放，性能和成本都将得到改善。
此外，考虑到FHE与大数据量相关联，为开发者提供围绕擦除编码阈值的更高定制化水平将十分有益。即，你愿意接受DA系统在多大程度上的保证？无论是基于权益加权还是去中心化加权。
EigenDA的架构为FHE DA层可能的形态提供了基础。其水平扩展、结构性成本降低、DA与共识的解耦等特性，为支持FHE提供了一定水平的可扩展性。
最后，一个值得考虑的高层次想法是为FHE密文存储构建优化的存储槽。由于密文遵循特定的编码方案，因此拥有专为其优化的存储槽可能有助于存储的高效使用和快速检索。
FHE硬件
FHE硬件挑战：性能不足
采用链上全同态加密（FHE）时，由于计算开销导致的显著延迟，使得在任何标准处理硬件上运行FHE变得不切实际。这种限制源于与内存的大量交互，处理器需处理庞大的数据量。除了内存交互外，复杂的多项式计算和耗时的密文维护操作也造成了相当的开销。
为了深入了解FHE加速器的发展状况，我们需探究其设计空间：特定应用的FHE加速器与通用FHE加速器。
FHE的计算复杂性及硬件设计的核心始终围绕着给定应用程序所需的乘法次数，即“同态操作的深度”。在特定应用场景中，由于深度是已知的，因此系统参数和相关计算是固定的。这种情况下的硬件设计将更简单，并通常能针对性能进行优化，相比之下通用加速器设计则更为复杂。在通用场景中，FHE需支持任意数量的乘法操作，需要引导（bootstrapping）来减少同态操作中积累的噪声。引导过程代价高昂，需要大量的硬件资源，包括片上内存、内存带宽和计算能力，这意味着硬件设计将与特定应用的设计有很大的不同。因此，尽管像英特尔、Duality、SRI、DARPA等主要参与者在推进GPU和ASIC设计方面取得了突破，但这些设计可能并不完全适用于区块链用例。
关于开发成本，通用硬件的设计和制造成本高于特定应用硬件，但其灵活性使得硬件能够在更广泛的应用领域中使用。另一方面，对于特定应用设计，如果应用需求变化，需要支持更深层次的同态计算，那么特定应用的硬件需要结合软件技术（如MPC）来实现通用硬件同样的目标。
值得注意的是，与特定应用用例（如FHEML）相比，为链上FHE提供加速服务更具挑战性，因为它要求处理更广泛的通用计算。例如，目前的fhEVM devnet吞吐量仅限于单位TPS。
考虑到我们需要专门针对区块链的FHE加速器，另一个考虑点是ZKP硬件向FHE硬件的转换程度。
ZKP和FHE之间存在一些共同的模块，如数论变换（NTT）和底层的多项式操作。然而，这两种情况中使用的NTT的位宽不同。在ZKP中，硬件需要支持不同位宽范围的NTT，例如64位和256位，而在FHE中，由于NTT操作数是在剩余数系统中表示，因此更短。此外，ZKP中处理的NTT度数通常高于FHE情况。因此，设计一个同时适用于ZKP和FHE并提供满意性能的NTT模块并非易事。除了NTT外，FHE中还存在如自同构等在ZKP中不存在的其他计算瓶颈。将ZKP硬件简单地应用于FHE的一种方法是将NTT计算任务卸载到ZKP硬件上，并使用CPU或其他硬件处理FHE中的其他计算。
总结这些挑战，使用FHE对加密数据进行计算曾比处理明文数据慢100,000倍。然而，得益于新的加密方案和FHE硬件的最新发展，当前性能已大幅提升，与处理明文数据相比只慢约100倍。
解决方案：
1.FHE硬件的改进
许多团队正积极研发FHE加速器，但他们并未专注于特定于通用区块链计算（如TFHE）的FHE加速器。例如，FPT，一种针对区块链特定的固定点FPGA加速器，是首个充分利用FHE计算中固有噪声的硬件加速器，完全通过近似固定点算术实现TFHE引导。另一个可能对FHE有用的项目是BASALISC，这是一系列旨在大幅加速云中FHE计算的硬件加速器。
正如前文所述，FHE硬件设计的一个主要瓶颈是与内存的大量交互。为了解决这个问题，一个潜在的方案是尽量减少与内存的交互。内存中处理（PIM）或近内存计算在这种情况下可能非常有帮助。PIM是一种解决未来计算系统中“内存墙”挑战的有前景的方案，它允许内存同时承担计算和存储功能，有望彻底改变计算与内存的关系。在过去十年中，为此目的设计的非易失性存储器技术，如阻变RAM、自旋转移扭矩磁性RAM和相变内存取得了巨大进步。使用这些特殊的存储器，已有研究表明在机器学习和基于格的公钥加密领域实现了显著的计算性能提升。
2.软件/硬件优化
近期的发展中，软件被认为是硬件加速过程中的关键组成部分。例如，著名的FHE加速器如F1和CraterLake就采用了编译器进行混合软件/硬件共同设计的方法。
随着该领域的发展，我们可以预期完全功能的编译器将与针对区块链特定的FHE编译器共同设计。FHE编译器可基于各自FHE方案的成本模型来优化FHE程序。这些FHE编译器可以与FHE加速器编译器集成，通过纳入硬件级别的成本模型来提高端到端性能。
3.联网的FHE加速器：从单点提升到多点扩展
当前的FHE硬件加速努力主要集中在“单点提升”，即专注于单个加速器的垂直改进上。而“多点扩展”则侧重于通过横向联网将多个FHE加速器连接起来，这可以类似于ZKP的并行证明生成那样大幅提高性能。
FHE加速面临的一个主要问题是数据膨胀：指在加密和计算过程中数据大小的显著增加，这给片上和片外内存之间的有效数据移动带来了挑战。
数据膨胀对于通过横向联网连接多个FHE加速器构成了显著的挑战。因此，FHE硬件和网络共同设计将成为未来研究的一个有希望的方向。一个可能的例子是为FHE加速器实施自适应网络路由：实现一种根据实时计算负载和网络流量动态调整FHE加速器间数据路径的路由机制。这将确保最佳的数据传输速率和高效的资源利用。
结语
FHE将从根本上重塑我们在不同平台上保护数据的方式，为前所未有的隐私新时代铺平道路。构建这样一个系统将需要在FHE、ZKP和MPC方面的重大进步。
在探索这一新领域时，密码学家、软件工程师和硬件专家之间的合作努力至关重要。此外，立法者和政治家等的参与也不可或缺，因为符合监管的合规性是实现主流采用的唯一途径。
最终，FHE将站在数字主权变革的前沿，预示着一个数据隐私和安全不再是相互排斥而是紧密结合的未来。
微信扫一扫 
