FHE是ZK的下一步，加密技术的终局？

转载

164 天前

9141

佐爷歪脖山

文章转载来源：佐爷歪脖山

加密货币的发展主线异常清晰，比特币创造了加密货币，以太坊创造了公链，泰达公司创造了稳定币，BitMEX 创造了永续合约，四种创造如同加密原语搭建出万亿的市场，数不清的暴富神话，或者被人时刻铭记的去中心化的迷梦。

加密技术的发展轨迹却不甚明了，各类共识算法，种种精巧的设计都敌不过质押和多签系统，而后者才是维持加密系统运转的真正支柱，比如抽去中心化质押的 WBTC 后，大部分 BTC L2 都无法存在，而 Babylon 的原生质押是这个方向的探索，价值 7 千万美元的探索。

我尝试在本文中勾勒一种加密技术的发展史，这区别于加密行业的各类技术变迁过程，比如 FHE 和 ZK 以及 MPC 的关系，从一个粗略应用的过程而言，MPC 用于开始，FHE 可以用于中间的计算过程，而 ZK 可以最终证明，而从应用时间顺序，则是 ZK 最早落地，之后 AA 钱包概念大火，MPC 作为一种技术方案得到重视，发展提速，唯独 FHE 在 2020 年已经被神施以喻言，但在 2024 年才略微起火。

MPC/FHE/ZKP

与 ZK 和 MPC 不同，FHE 甚至和当前所有的加密算法都不同，除了 FHE 之外，任何的对称或非对称加密技术，都在试图创造一个“不容易或无法破解的密码系统”来达到绝对的安全，但是 FHE 的目标是让加密后的密文发挥作用，即加密和解密是重要的，但是加密后，解密前的内容也不该浪费。

理论齐备，Web2 先于 Web3 落地

FHE 是一种基础技术，并且在学术上已经完成理论探索，Web2 巨头出力颇多，比如微软、英特尔、IBM 和 DARPA 支持的 Duality 已经进行软硬件适配和开发工具的准备。

有个好消息是，Web2 的巨头们也并不知道该拿 FHE 来做什么，Web3 从现在起步不算晚，还有一个坏消息是 Web3 的适配约等于 0，主流的比特币、以太坊都无法原生兼容 FHE 算法，尽管以太坊是世界计算机，但是硬算 FHE 恐怕要算到世界末日。

我们主要关注 Web3 的探索，只需要记住 Web2 巨头们对 FHE 非常热衷，并且已经做了大量基础工作即可。

这是因为 Vitalik 从 2020 年到 2024 年，重心都在 ZK 上。

这里要简单阐释下我对 ZK 的爆火归因，在以太坊确立以 Rollup 的扩容路线之后，ZK 的状态压缩功能可以极大减少 L2 向 L1 传输数据的大小，这在经济上具有巨大价值，当然，这只是理论上的，L2 的碎片化以及排序器等问题，甚至部分 L2/Rollup 收割用户手续费问题，这都属于发展中的新问题，只能用继续发展来解决。

简单归纳下，即以太坊需要扩容，确立了 Layer 2 发展路线，ZK/OP 系 Rollup 争奇斗艳，形成短期 OP，长期 ZK 的行业共识，塑造出 ARB/OP/zkSync/SatrkNet 四大巨头。

经济性是 ZK 能被加密世界，尤其是以太坊体系接纳的重要原因，甚至是唯一原因，因而接下来的 FHE 技术特点不会赘述，重点是考察 FHE 能在哪些方向提高 Web3 的运转效率，或者降低 Web3 的运作成本，降本和增效，总要占一个。

FHE 发展小史和成果

首先是区别同态加密和全同态加密，严格意义上而言，全同态加密是前者的一种特例，同态加密意味着“对密文的加法或乘法计算等同于对明文的加法或乘法计算”，即：

此时，c 和 E(c)，d 和 E(d) 可以视为等价值，但是要注意，这里的有两个难点：

明文和密文的相等，其实是明文在加入一些噪音后，对其进行进行运算得到密文，如果密文导致的偏离值过大，则会导致计算失败，因此控制噪音的各类算法的关键；
加法和乘法的开销巨大，密文计算可能是明文计算的 1 万到 100 万倍以上，而只有同时实现无限次的加法和乘法密文计算才能被称为全同态加密，当然，各类同态加密在各自领域也有其独特价值，按照实现程度的不同，可做如下划分：

部分同态加密（Partially homomorphic encryption）：只允许对加密数据执行有限的操作集，如加法或乘法。某种同态加密（Somewhat homomorphic encryption）：允许有限数量的加法和乘法运算。
全同态加密（Fully homomorphic encryption）：允许无限数量的加法和乘法运算，从而实现对加密数据的任意计算。

全同态加密（FHE）的发展历程可以追溯到 2009 年，Craig Gentry 首次提出了基于理想格的全同态算法，理想格是一种数学结构，它允许用户定义一个多维空间中的点集，其中这些点满足特定的线性关系。

在 Gentry 的方案中，使用理想格来表示密钥和加密数据，从而使得加密数据可以在保持隐私的同时，并且使用自举来降低噪音，自举可以理解为“自己使劲揪自己的鞋带，把自己翻过来”，实际操作上是通过对 FHE 加密后的密文再加一次密，达到降低噪音并维持保密性，以此支持复杂的计算操作。

这个算法是 FHE 的里程碑，首次在工程上证明了 FHE 的可行性，但是开销巨大，甚至要三十分钟才能运算一步，基本上没有实用化的可能性。

从 0 到 1 解决后，剩下的只是大规模实用化，也可以理解为基于不同的数学假设，开展对应的算法设计，除理想格外，被用于安全性假设的还有 LWE（Learning with Error）及其变种，也是目前最为常见的方案。

在 2012 年，Zvika Brakerski, Craig Gentry 和 Vinod Vaikuntanathan 提出了 BGV 方案，这是第二代 FHE 方案之一，其最重要的贡献是模数转换技术，这一技术有效地控制了同态运算带来的密文噪声增加，从而构造了 Leveled FHE，即这样的 FHE 可以实现给定计算深度的同态计算任务。

与之类似的还有 BFV 和 CKKS 等方案，尤其是 CKKS 方案可以支持浮点运算，但是会进一步增强对算力资源的消耗，仍然需要更好的方案。

最后是 TFHE 和 FHEW 方案，尤其是 TFHE 方案，这是 Zama 的首选算法，我们对其进行简要介绍，简单来说，FHE 的噪音问题可以通过 Gentry 首次应用的自举来降低，而 TFHE 可以做到高效自举，并且在精度上有保障，因此和区块链领域有较好的结合点。

我们对各方案的介绍点到为止，实际上他们之间的差异并不是优劣之分，更多是场景不同，但是基本都需要强大的软硬件资源支持，即使是 TFHE 方案，也需要解决硬件问题才能大规模应用，基本上不可能沿袭 ZK 领域“算法和软件先行，硬件和模块化跟进”的路径，也就是从一开始 FHE 就要和硬件同步发展，至少在加密领域必然如此。

Web 2 OpenFHE vs Web3 Zama

前文提到 Web2 巨头都在探索，也形成了一些实践成果，这里对其进行总结，并引入 Web3 的应用场景。

删繁就简，IBM 贡献了 Helib 库，主要支持 BGV 和 CKKS，微软的 SEAL 库主要支持 CKKS 和 BFV 方案，值得一提的是， CKKS 作者之一的 Song Yongsoo 参与了 SEAL 的设计和开发，而 OpenFHE 是最为集大成者，由 DARPA 支持的 Duality 研发，目前支持 BGV、BFV、CKKS、TFHE 和 FHEW 等主流算法，估计是市场上现存的 FHE 库中最为齐备的。

并且，OpenFHE 也探索过和因特尔的 CPU 加速库合作，以及调用英伟达的 CUDA 接口，以支持 GPU 加速，但是 CUDA 对 FHE 最近的支持停留在 2018 年，暂时未找到更新的支持，如有错讹，还请指正。

OpenFHE 支持 C++ 和 Python 两种语言，Rust API 正在开发中，并且致力于提供简单全面的模块化和跨平台能力，如果是 Web2 开发者，那么这是最简单的开箱即用方案。

如果是 Web3 开发者，就要上上难度了。

受限于孱弱的运算能力，大部分公链无法支持 FHE 算法的执行，其次是比特币和以太坊生态目前缺乏对 FHE 的“经济需求”，再次强调，是先有了对 L2-->L1 高效传输数据的需求，才激发了 ZK 算法的落地，而不能为了 FHE 而 FHE ，这是拿着锤子敲钉子，强行的匹配，只会增加落地成本。

FHE+EVM 工作原理

后文会详述目前遇到的困难和可能的落地场景，这里主要给 Web3 开发者一些信心。

2024 年 Zama 拿到了加密领域最大的一笔涉 FHE 概念融资，由 Multicoin 领投的 7300 万美元，Zama 目前主要有基于 TFHE 算法库，其次是 fhEVM 支持在其上开发具备 FHE 功能的 EVM 兼容链。

其次是效率问题，只能通过软硬件合作解决，一个是 EVM 无法直接运行 FHE 合约，这和 Zama 的 fhEVM 方案并不冲突，Zama 的是自己搭建了一条链，可以直接把 FHE 功能原生加入进去，比如 Shiba Inu 也要搭建基于 Zama 方案的 Layer 3，新造的链支持 FHE 并不困难，难的是以太坊 EVM 自身如何具备 FHE 合约部署能力，这需要以太坊的 Opcode（操作码）支持，好消息是 Fair Math 和 OpenFHE 联合举办了 FHERMA 竞赛，鼓励开发者改写 EVM 的 Opcode，算是在积极探索结合可能性。

另一个是硬件加速，可以这样说，即使 Solana 等高性能公链原生支持 FHE 合约部署，也会把其节点拖死，原生 FHE 硬件主要有 Chain Reaction 的 3PU™（隐私保护处理单元），属于 ASIC 方案，其次是 Zama 或者 Inco 也在探索硬件加速的可能性，比如 Zama 现在的 TPS 是 5 左右，Inco 能做到 10 TPS，而 Inco 认为使用 FPGA 硬件加速，可以将 TPS 提速到 100-1000 左右。

但是也无需过于担忧速度问题，现有的 ZK 硬件加速方案，理论上都可以进行改造以适配 FHE 方案，因此下文的讨论中均不会过度设计速度问题，而主要是寻找场景和解决 EVM 兼容适配。

暗池玉殒，FHE X Crypto 未来可期

Multicoin 在领投 Zama 时曾豪言，ZKP 已是过去，未来属于 FHE，未来是否成真，现实总是艰难，在 Zama 之后，Inco Network 和 Fhenix 组成了 fhEVM 生态隐形联盟，方向各有侧重，道路基本一致，即致力于 FHE 和 EVM 生态的融合。

做的早不如来得巧，我们先从一盆冷水开始。

2024 年也许是 FHE 的大年，而 2022 年起步的 Elusiv 已经停止运行，Elusiv 最早是 Solana 上的“暗池”协议，现在代码库和文档都被删除。

说到底，FHE 作为技术组件的一部分，仍旧需要和 MPC/ZKP 等技术一起使用，而我们需要考察的是 FHE 究竟在哪些方面能改变区块链的现行范式。

首先要承认，单纯认为 FHE 会加强隐私所以具备经济价值并不准确，从过往的实践来看，Web3 或链上用户没有那么在乎隐私，只有在隐私可以提供经济价值时才会使用相关工具，比如，黑客为了隐藏盗取资金才会使用 Tornado Cash，而普通用户只会使用 Uniswap，因为使用 Tornado Cash 会付出额外的时间或经济成本。

FHE 的加密成本，本身就是对链上本就孱弱的运行效率的进一步折磨，只有当这种拉高成本会带来更显著的收益，保护隐私才具备大规模推广的可能性，比如 RWA 方向的债券发行和交易，比如 2023 年 6 月，中银国际通过瑞银，在香港向亚太客户发行了“区块链数字化结构票据”，并在瑞银新闻稿中指出是通过以太坊进行，但是神奇的是找不到该交易的合约地址和分发地址，如果有谁能找到，欢迎补充相关信息。

这个例子可以显性说明 FHE 的重要性，对于机构级客户，他们有使用区块链等公链的需求，但是并不适合或想要公开全部信息，那么 FHE 这种密文显示，并可直接进行买卖等操作的特性就会比 ZKP 更适合。

而对于个人散户而言，FHE 目前仍旧是比较遥远的底层基础设施，我可以列几个方向，比如抗 MEV ，隐私交易，更安全的网络，防止第三方窥探等等，但显然这都不是第一性需求，并且现在使用 FHE 确实会让网络变慢，不如坦率说 FHE 的主角时刻还未到来。

说到底，隐私是不痛不痒的需求，作为公共服务，很少人愿意为隐私溢价付费，我们需要找到利用 FHE 加密后的数据可计算特性能节约成本或提升交易效率的场景，从而产生市场自发的助推力。比如抗 MEV 的解决方案有很多种，比如中心化节点其实就可以解决，FHE 并不能直击场景痛点。

另外一个问题是计算效率的问题，表面上看这是需要硬件加速或者算法优化的技术问题，但本质上这是市场没太大需求，项目方没有卷的动力，计算效率说到底都是卷出来的，还是以 ZK 为例，在蓬勃的市场需求下，SNARK 和 STARK 路线互相比拼，各类 ZK Rollup 从编程语言到兼容性玩命开卷，ZK 的发展在热钱催熟下一日千里。

应用场景和落地是 FHE 成为区块链基础设施的突破口，如果迈不出这一步，FHE 将永远无法在加密行业成势，各大项目方也就只能敲敲边鼓，在自己的一亩三分地自娱自乐了。

从Zama 和他的朋友们的实践来看，一个共识是以太坊外做新链，并将 ERC-20 等技术组件和标准复用其上，形成 FHE L1/L2 链接以太坊的加密方案，这种方案的好处是可以先行先试，打造 FHE 的基础组件，劣势在于如果以太坊自身不支持 FHE 算法，那么链外方案始终会处于比较尴尬的境地。

Zama 自身也认识到这个问题，在前述提及的 FHE 相关类库外，也发起了 FHE.org 组织，并赞助了相关会议，希望能将更多学术成果转化为工程应用。

Inco Network 的发展方向是“通用隐私计算层”，本质上是一种计算外包服务商模式，基于 Zama 搭建了 FHE EVM L1 网络，一个有趣的探索是和跨链消息协议 Hyperlane 合作，可以将另外一条 EVM 兼容链上的游戏机制部署在 Inco 之上，在游戏运行时需要用到 FHE 计算时，通过 Hyperlane 调用 Inco 的计算能力，随后只将结果回传原链。

实现 Inco 设想中的此类场景，需要满足 EVM 兼容链愿意相信 Inco 的信誉，并且 Inco 自身的计算能力要足够强，在链游这种高并发、低延时的需求中，能否真的良好运作是具有相当挑战性的。

由此引申下，某些 zkVM 其实也可以承当 FHE 计算外包商的角色，比如 RISC Zero 便已经具备该能力，ZK 系产品和 FHE 的下一步碰撞也许有更多火花可以迸发。

更进一步，某些项目希望能更靠近以太坊一点点，至少朝着成为以太坊的一部分方向前进，Inco 能用 Zama 方案实现 L1，Fhenix 就能用 Zama 方案实现 EVM L2，其目前还在发展中，看起来想做的方向有很多，不知道最终落地会是什么产品，也许是一条主打 FHE 能力的 L2 吧。

此外还有上文提及的 FHERMA 竞赛，读者中有精通以太坊开发的程序员可以去试试，帮助 FHE 落地的同时还有奖金拿。

此外，还有 Sunscreen 和 Mind Network 这两个比较神奇的项目，Sunscreen 主要由 Ravital 一个人运营，方向是用 BFV 算法打造适合 FHE 的编译器方案，但是长期处于测试和实验状态，距离产品实用化尚需时日。

最后，Mind Network 的思路主要集中在 FHE 和各现有场景，如再质押的结合上，但具体如何实现还需要时间来验证。

最后的最后，回收下本节开头，Elusiv 现在更名为 Arcium，还拿到了新的融资，转型成为“并行 FHE ”方案，这是要从执行效率上对 FHE 进行改进。

结语

本文看似是在讲 FHE 的理论和实践，但暗线是厘清加密技术自身的发展史，这不完全等同于加密货币用到的技术，ZKP 和 FHE 有很多相似点，其中之一是都在致力于让区块链保持公开特性之外保有隐私设计，而 ZKP 隐私方案指向的是降低 L2 <> L1之间交互的经济成本，而 FHE 仍在寻找自己的最佳场景。

各方案分型

路漫漫其修远兮，FHE 仍在上下求索。可以按照和以太坊的关联度远近，分为三型：

Type 1：独立王国，沟通以太。以 Zama/Fhenix/Inco network 为代表，主要是在提供开发基础件，鼓励自建 FHE L1/L2，适用于某些细分领域；
Type 2：外挂其上，融入以太。以 Fair Math/Mind Network 为代表，虽然保留一定的独立性，但是整体思路是和以太坊进行更深度的融合。
Type 3：相约通行，改造以太。如果以太坊无法原生支持 FHE 功能，那么需要在合约层进行探索，将 FHE 的功能散发到各 EVM 兼容链上，目前还没有太符合该标准的方案。

和 ZK 发展到后期才出现一键发链和硬件加速实用化不同，FHE 站在了 ZK 巨人的肩上，现在发一条 FHE 链可能是最简单的事，但是如何沟通自身和以太坊是最难的。

每日三省吾身，在区块链世界中寻找 FHE 的未来坐标：