FHE被誉为“密码学圣杯”，但受性能、开发体验和安全性挑战限制，需要结合ZKP和MPC才能实现真正保密且安全的共享状态系统。Sunscreen的出现，为算术运算提供了最佳性能，支持多高级语言，但FHE应用和开发仍面临挑战，如安全阈值解密挑战和用户输入及计算的可验证性挑战。Network正在利用FHE进行安全计算，许多团队正研发FHE加速器，以提高性能，为数据隐私和安全提供更多保护。
核心要点：
被誉为“密码学圣杯”的全同态加密(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程序时需要改变思维方式。比如，程序中不能根据变量写出分支(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的各种应用：
虚拟币交易所
类型：金融理财 大小：214.05MB
系统：安卓、苹果 语言：中文
欧易交易所app有最低的手续费，最快捷的交易，强劲的API以及更多，实时为你更新区块链动态资讯，还有专业的服务团队为大家提供分析和参考，喜欢就来下载吧！
温馨提示：本文内容由互联网用户自发贡献，该文观点仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。
