全同态加密理论、生态现状与未来展望（下）

《全同态加密理论、生态现状与未来展望》系列由[email protected]和[email protected]整理原创发布，分为上中下三个系列：

• 全同态加密理论、生态现状与未来展望（上）：专注于介绍全同态加密理论知识。
• 全同态加密理论、生态现状与未来展望（中1）：专注于介绍全同态加密四代算法中第一代第二代FHE算法的衍化历程。
• 全同态加密理论、生态现状与未来展望（中2）：专注于介绍全同态加密四代算法中第三代第四代FHE算法的衍化历程。
• 全同态加密理论、生态现状与未来展望（下）：专注于介绍当前全同态加密生态现状及未来展望。

整个系列内容可能存在纰漏，希望能得到大家的反馈，有任何问题欢迎邮件联系[email protected]和[email protected]，或在本文下方评论留言。

4. FHE开源社区动态

最初的Gentry09 FHE方案比明文计算慢约1亿倍，因此被认为远未达到实际应用的标准。经过过去十多年的算法优化，FHE方案的性能已有大幅提升。从软件的角度来看，FHE算法库在帮助研究人员和从业者编写第一个基于FHE的应用程序方面发挥了关键作用，并且它们的演化和优化显著提高了这些应用程序的效率。然而，利用这些API需要对FHE方案有深入的了解。近年来，更高层次的工具开始发展，试图弥合开发隐私保护应用程序的工程师与现有技术FHE库之间的鸿沟。沿着这一思路，一些FHE编译器应运而生，旨在将高级程序转换为基于FHE的实现。这些编译器是使FHE能够为非专家提供服务的关键步骤，这对于设计隐私保护应用程序的基本构建块至关重要，从而促进了FHE的广泛采用。借助编译器，应用程序可采用Python、C++、Rust甚至DSL等高级语言来编写。从硬件角度来看，利用特定的硬件架构（如，基于FPGA、GPU、CPU、TPU和ASIC等架构），也做了大量努力。这类设计被称为FHE加速器，能够在软件中显著提高FHE方案的性能。

图 10: FHE ecosystem architecture

由上图开源生态展示可知，当前FHE编译器创新开发非常活跃，而近年来基础算法库中的理论算法创新仍显不足。

4.1 FHE开源算法库

FHE算法库的主要目标是通过API提供FHE方案的操作。除了由KeyGen、Enc、Dec和Eval提供的核心功能外，大多数广泛使用的库还包含额外的功能，允许对密文进行维护（即在计算过程中管理噪声增长）和操作，以及同态加法和乘法方法。然而，正确的使用仍然依赖于开发者，开发者必须深入了解每个API调用在给定隐私保护解决方案中的含义。

表 1: FHE 方案开源算法库

Library	Language	BGV	B/FV	FHEW	TFHE	CKKS	Date of last commit
HElib	C++	●	○	○	○	●	18/7/2023
SEAL	C++/C#	●	●	○	○	●	11/7/2024
PALISADE	C++	●	●	●	●	●	19/4/2024
Lattigo	Go	●	●	○	○	●	18/12/2024
FHEW	C++	○	○	●	○	○	30/5/2017
TFHE	C++/C	○	○	○	●	○	26/3/2023
TFHE-rs	Rust	○	○	○	●	○	1/3/2025
HEAAN	C++	○	○	○	○	●	14/8/2023
RNS-HEAAN	C++	○	○	○	○	●	26/10/2018
FV-NFLlib	C++	○	●	○	○	○	26/7/2016
OpenFHE	C++	●	●	●	●	●	30/10/2024

上表中提供了现有的开源FHE库、它们使用的编程语言、支持的FHE方案以及最后更新的日期：

• 第一个发布的FHE算法库是HElib，由Halevi和Shoup提出，采用C++基于NTL库实现。HELib是IBM开发的BGV和CKKS实现。详情见2014年论文《Algorithms in helib》。

• SEAL是由微软开发，采用C++和C#实现（以支持.NET）。它利用英特尔的HEXL------为启用AVX-512的处理器提供高效同态加密操作实现的库。Microsoft的SEAL，支持BGV/BFV和部分CKKS，并配有相关的EVA编译器（该项目已不再积极开发）。

• PALISADE是由DARPA联盟开发的。它是用C++编写的，可配置使用NTL/GMP或tcmalloc库。

• Lattigo是由2020年论文《Lattigo: A multiparty homomorphic encryption library in go》提出的，是第一个用Go编写的库。Lattigo是纯Go语言实现的CKKS，同时也包括BGV/BFV的实现，最初由Jean-Philippe Bossuat开发，目前由Tune Insight维护。

• FHEW由Ducas和Micciancio提出，用C++编写，但自2017年以来未更新。

• TFHE 库由2019年论文《TFHE: fast fully homomorphic encryption over the torus》作者提供，用C++和C编写，运行需要至少一个快速傅里叶变换（FFT）处理器。TFHE被认为是FHEW库的继任者。TFHE库在2021年9月之后不维护了。

• TFHE-rs是Zama实现的TFHE变体，采用Rust编写。TFHE-rs是领先的CGGI实现，采用Rust编写，由盈利公司Zama开发和维护。其基于原始的TFHE库实现。

• HEAAN库用C++编写，建立在NTL库之上。HEAAN库是经典的CKKS实现，当其作者成立了盈利性研究实验室CryptoLab时，该项目转为闭源。最后一个开源版本HEAAN（C++）仍然在GitHub上可用，2022年1月之后闭源了。

• RNS-HEAAN用C++编写，但自2018年以来未更新。

• FV-NFLlib用C++编写，基于NFLlib C++库。NFLlib是一个专门用于理想格基加密的库，基于数论变换（NTT）。值得注意的是，FV-NFLlib在过去五年没有更新。

• OpenFHE是一个新库（2022年7月发布），由PALISADE、HElib、HEAAN和FHEW库的作者设计。它用C++编写，包含所有相关的FHE方案：BGV、B/FV、FHEW、TFHE和CKKS，还实现了一些PALISADE中未覆盖的最近改进。OpenFHE实现了所有主要的FHE方案，包括方案切换，主要由Duality维护。OpenFHE取代了早期的PALISADE项目，PALISADE项目目前已不再维护。OpenFHE是唯一支持方案切换的库，并且是DPRIVE项目参与者作为硬件入口点的主要API。

以上这些FHE开源算法库：

• 具有不同的可用性和完成度。

• 适用于单线程CPU、多线程CPU、GPU或FPGA。

• 每个都有其自身的FHE方案实现。

• 每个都有特定的API接口。

4.2 FHE开源编译器

在过去十年中，已有数十种同态加密编译器问世，这些编译器的存在有充分的理由。因为同态加密技术涉及复杂的数学知识，并需要专家知识来将计算表达为同态加密操作。这些编译器为可能没有时间或专业知识手动优化计算的用户提供了支持。另一个原因是，同态加密的计算成本仍然很高，编译器可以帮助用户优化其安全计算任务。

FHE编译器是旨在抽象化FHE库所暴露的技术API的高层工具，使得更广泛的开发人员能够安全地实现隐私保护机制。FHE编译器解决了设计基于FHE的应用时常见的工程挑战：

• 参数选择：为FHE方案定义合适的参数值，从而产生安全且高效的实例，并非易事。一些FHE编译器允许根据一些预定义的需求自动生成参数。

• 明文编码：在FHE中，明文消息的语义与可以执行的同态计算类型密切相关。某些特定上下文的FHE编译器可以用来帮助处理这一问题（如，nGraph-HE）。

• 数据独立执行：由于 FHE 操作本质上是数据独立的，因此使用FHE执行数据依赖的分支步骤并非易事，因为这可能会破坏隐私属性。在这种情况下，可以通过评估两个分支并在最后选择结果的方式来进行分支操作。

• 打包或批处理：支持将消息打包或批处理到一个单一密文中的FHE方案可以直接利用 SIMD 指令集。一些 FHE编译器已经积极优化了向量化操作。

• 密文维护：在FHE操作过程中，如何优化噪声增长的管理并不简单，FHE编译器开始使用先进的策略来协助这一传统上复杂的部分。

表 2: 公开可用的 FHE 编译器

Compiler	Language	HElib	SEAL	PALISADE	FHEW	TFHE/-rs	OpenFHE	Date of last commit
ALCHEMY	Haskell	○	○	○	○	○	○	15/3/2020
Cingulata	C++	○	●	○	○	●	○	15/1/2024
E3	Pascal/NASL	●	●	●	●	●	○	3/3/2023
SHEEP	C++	●	●	○	○	●	○	7/4/2023
EVA	C++	○	●	○	○	○	○	1/5/2021
Marble	C++	○	●	○	○	○	○	23/12/2020
Transpiler	C++/Starlark	○	●	○	○	○	○	19/3/2024
Concrete	C++/MLIR	○	○	○	○	●	○	19/12/2024
nGraph-HE	C++	○	●	○	○	○	○	3/1/2023
HEIR	C++/MLIR	○	○	○	○	●	●	7/1/2025
ANT-ACE	C++	○	●	○	○	○	●	10/12/2024
Oraqle	Python	●	○	○	○	○	●	27/11/2024
HECO	MLIR	○	●	○	○	○	○	23/7/2024
T2	Java	●	●	●	○	●	○	30/12/2023
Sunscreen	Rust	○	●	○	○	○	○	6/12/2024

表2列出了FHE编译器，展示了它们使用的编程语言、它们利用的FHE 算法库，以及它们最后更新的日期：

• ALCHEMY 是由2018年论文《Alchemy: A language and compiler for homomorphic encryption made easy》作者用Haskell编写的编译器。它实现了BGV，使用了Λ ⚬ λ（发音为"L O L"）——支持FHE的基于环的格加密库。

• Cingulata（以前称为Armadillo），由2015年论文《Armadillo: a compilation chain for privacy preserving applications》作者用C++编写的编译器，建立在FLINT和Sage库之上。

• E3（Encrypt-Everything-Everywhere） 是由2018年论文《E3: A Framework for Compiling C++ Programs with Encrypted Operands》提出的一个框架，主要用C++编写，并支持多种FHE库。

• SHEEP（为Homomorphic Encryption Evaluation Platform的递归缩写） 是由Turing Institute开发的框架，用C++编写，并附带多个现成的 Jupyter notebooks，包含关于如何使用SHEEP的示例。

• EVA（Vector Arithmetic Language and Compiler） 是由2020年论文《EVA: An encrypted vector arithmetic language and compiler for efficient homomorphic computation》中提出的，用C++编写，并结合了2019年论文《CHET: an optimizing compiler for fully-homomorphic neural-network inferencing》来支持tensor电路。

• Marble 是由2018年论文《Marble: Making fully homomorphic encryption accessible to all》作者编写的C++编译器。

• Transpiler是Google主导的FHE C++转译器。该转译器将Google的XLS库连接到多个FHE后端（目前为TFHE库和OpenFHE的BinFHE库）。详情见2021年论文A General Purpose Transpiler for Fully Homomorphic Encryption。已近10个月无更新。HEIR为Google的下一代编译器框架。

• Concrete是由Zama团队开发的，基于LLVM的TFHE编译器，可将python程序转换为FHE等效程序。对应2020年论文《CONCRETE: Concrete operates on ciphertexts rapidly by extending TfhE》。

• nGraph-HE由Intel AI研究团队2019年论文《nGraph-HE: a graph compiler for deep learning on homomorphically encrypted data》中提出，基于该团队2019年论文《nGraphHE2: A high-throughput framework for neural network inference on encrypted data》中所提出的nGraph ML编译器，后续加入了对非多项式激活函数的支持。nGraph-HE是特别为ML应用设计的领域特定FHE编译器。

• HEIR由Google团队于2022年提出，是基于多级中间表示（MLIR）的编译工具链，其他编译器可以重用和扩展它。HEIR旨在支持所有主要的FHE方案和硬件后端。截至目前，它支持将CGGI导出到TFHE-rs（用于CPU）和FPT（用于FPGA），并且正在准备支持将BGV导出到OpenFHE（同时也为DPRIVE加速器做准备）。

• ANT-ACE由蚂蚁技术研究院于2024年11月开源，是专为自动化神经网络（NN）推断而设计的FHE编译器框架。ANT-ACE接受经过预先培训的ONNX模型作为输入,并直接生成C/C++程序以对加密数据执行NN推理。ANT-ACE专为隐私保护机器学习（PPML）推理应用而设计。在此设置中,ML推理在云中运行,使客户端可以上传其数据并接收推理结果。

• Oraqle由2024年论文《Oraqle: A Depth-Aware Secure Computation Compiler》提出，通过实现深度感知的算术化方法，同时解决了高级操作的算术化和乘法深度减少的问题。Oraqle编译器并不专注于单独减少乘法次数或乘法深度，而是同时减少这两者。这样，它生成了多个电路，这些电路在这两个指标之间进行权衡。支持公共子表达式消除（CSE），使用HElib库布置同态加密操作，但布置方式相对简单（如，可能会在缩小模数后又重新放大模数）。没有使用DSL，而是允许用户用纯Python表达电路，并通过重载操作符支持Python函数的一个子集。

• HECO由2023年论文《HECO: Fully Homomorphic Encryption Compiler》提出，类似于HEIR编译器，依赖MLIR工具链。它支持Python前端和SEAL后端。它未实现高级原语的算术化，目前这部分任务留给用户完成。HECO执行简单的参数选择，并采用简单的重线性化操作布置。由于基于MLIR，它能够执行CSE，并支持减少乘法深度的矢量化处理。

• T2由2022年论文SoK: New Insights into Fully Homomorphic Encryption Libraries via Standardized Benchmarks提出。T2编译器提供了一种描述算术电路的领域特定语言（DSL），支持为多个库生成代码。如果$p$是素数，该编译器实现了针对等式检查和比较的算术化，但未考虑深度-成本权衡。该编译器从预定义列表中选择参数，并自动布置同态加密操作。支持三种不同的计算模型：整数、二进制和浮点域。

• Sunscreen编译器由Suncreen团队采用Rust语言开发，其选择依赖于微软SEAL库中的BFVf方案，因为BFV方案在32位和64位计算方面提供了一些最佳的开箱即用算术运算性能同时专注于自动化参数和密钥选择，并支持序列化和WASM，使开发人员的设置变得轻松。

此外，HELayers是IBM为算术FHE设计的编译器，专门用于寻找良好的打包方案。核心代码未开源。目前已用于IBM的FHE云服务中，使数据科学家和开发人员可以部署隐私在云中保留机器学习驱动的软件即服务（SaaS）应用程序。

HEaaN.mlir是CryptoLab为HEaaN设计的编译器，目前未开源。详情见2023年论文《HEaaN.MLIR: An Optimizing Compiler for Fast Ring-Based Homomorphic Encryption》。

4.3 FHE开源加速器

表 3: 公开可用的 FHE 加速器

名称	平台	语言	BFV	CKKS	TFHE/-rs	可编程	可自举	最新提交日期
cuHE	GPU	Cuda/C++	○	○	●	○	●	8/6/2017
CuFHE	GPU	Cuda/C++	○	○	●	○	●	9/2/2019
NuFHE	GPU	Python/Mako	○	○	●	○	●	18/3/2020
HEAT	FPGA	C	●	○	○	○	○	25/8/2020
HEXL	CPU	C++	●	●	○	●	○	19/7/2024
HEXL-FPGA	FPGA	C++	●	●	○	●	○	28/10/2022
HERACLES	CPU	Python	○	●	○	●	○	14/11/2024
FPT	CPU	Rust	○	○	●	●	●	21/8/2024
Jaxite	TPU/GPU	Python	○	○	●	●	●	20/12/2024

表3概述各个开源FHE加速器所使用的硬件、开发语言、支持的FHE算法方案等信息。其中"可编程"指的是加速器能够支持多种加密参数，而无需重新配置硬件架构。支持"自举"意味着可以执行自举操作，从而实现加速器上无限次的FHE操作。"BFV"代表BFV/BGV，"TFHE"代表TFHE/GSW。对于所有FHE加速器，FFT/NTT模块是其共同的核心组件，因为这是多项式计算的瓶颈，并直接决定了性能。需要指出的是，大多数现有的加速器（除了基于GPU的NuFHE）并未同时实现FFT和NTT计算，因为FFT包含浮点运算，而NTT仅包括整数运算。它们需要完全不同的硬件电路进行加速。因此，为简化设计复杂性并减少硬件资源开销，加速器设计者通常选择加速FFT或NTT中的一种运算，因此只能支持相应运算的FHE算法，正如上表所列。通过将FFT/NTT模块与其他计算单元以优化的数据路径相连接，加速器可以完成其目标FHE工作。不同的工作在FFT/NTT模块和数据路径的设计上存在差异，以实现其加速目标。早期的工作由于计算场景有限，通常为NTT/FFT计算单元设计了固定的硬件架构和计算流程，以降低设计复杂性。随着应用场景的不断增加，后期工作倾向于设计可编程的NTT/FFT单元和数据路径，以支持不同的参数设置和多种应用。此外，后期的研究发现，引入更多带有定制设备的片上存储空间至关重要，因为通用硬件（如GPU和FPGA）的内存已无法满足日益复杂的FHE应用所需的大量计算。因此，对于能够负担得起的设计者来说，专用集成电路（ASIC）成为了首选。

• cuHE由2015年论文《cuHE: A Homomorphic Encryption Accelerator Library》提出，使用GPU进行加速，并提供了NTT和CRT（Chinese Remainder Theorem）的CUDA实现。CuFHE于2018年提出，cuFHE利用cuHE的实现来提升TFHE的性能。cuHE和cuFHE都是开源的独立加速库不提供与FHE库的官方集成。它们仅支持使用NTT的多项式运算加速，而基于FFT的实现可能在TFHE中获得更高的性能。此外，除了功能有限外，cuFHE采用固定的加密参数，无法配置以实现高通用性。

• NuFHE由NuCypher在2018年推出，为基于GPU的环同态加密实现。nuFHE提供FFT或NTT以提高性能，并提供Python API。通过FFT，nuFHE相较于cuFHE实现了更高的性能。但它也存在与cuFHE类似的通用性限制问题。

• HEAT由2019年论文FPGA-Based High-Performance Parallel Architecture for Homomorphic Computing on Encrypted Data提出，与cuHE、cuFHE和nuFHE不同，HEAT针对word-wise FHE方案BFV加速，并进一步利用FPGA实现更灵活的硬件设计。因此，HEAT使用异构的ARM-FPGA协同设计架构，并在Xilinx ZCU102开发套件和Amazon AWS的f1实例上做了实现。HEAT支持的多项式阶数为4096，无法满足大多数实际需求，极大地限制了其通用性。

• HEXL由Intel 2021年论文《Intel HEXL: Accelerating Homomorphic Encryption with Intel AVX512-IFMA52》中提出，与之前依赖于GPU和FPGA等特定硬件设备的工作不同，利用了Intel CPU提供的SIMD特性，为FHE提供了即插即用的加速能力。HEXL已通过替换底层算术实现，集成到PALISADE、Microsoft SEAL和HElib中。由于HEXL是线程安全的，用户可以通过多线程并行化不同操作以获得更好的性能。然而，由于架构的不足，当线程数较多时整体性能会显著下降。此外，与其他领域基于CPU的加速库类似，HEXL还面临着内存访问缓慢的问题，这进一步降低了其整体性能。

• HEXL-FPGA由Intel于2021年提出，为了弥补HEXL的缺陷，提供了基于HLS的NTT/iNTT、乘法和密钥切换的实现。用户可以将每个功能编译成单独的比特流并将其加载到FPGA设备上。HEXL-FPGA可以与HEXL集成，以加速相应的FHE库。然而，基于HLS的解决方案存在固有问题。HLS设计用高级语言编写，并依赖编译器将代码转换为硬件设计。由于硬件和软件的本质差异，编译过程可能导致资源消耗冗余和复杂的工作流同步，从而导致性能次优。因此，HEXL-FPGA很难充分利用FPGA的优势。此外，HEXL-FPGA仅支持有限范围的加密参数。

• Jaxite是Google团队2023年推出的通过TPU（Tensor Processing Unit）加速CGGI的硬件方法。尽管目前性能提升还不显著，但目标是实现$10\times$ 至 $100\times$ 的CPU性能提升，利用Google已大规模部署的TPU，提前推出FHE产品，在更强大的硬件加速器问世前占得先机。

在全同态加密（Fully Homomorphic Encryption，FHE）研究中，一个重要方向是设计定制硬件以加速FHE操作。最突出的项目群隶属于DARPA的一个计划，称为DPRIVE。简而言之，DARPA为FHE硬件设计者提供资助，挑战他们在FHE环境下尽可能快速地完成逻辑回归、卷积神经网络（CNN）推理和CNN训练任务。
当前参与DPRIVE的团队有四个：

• Intel，其加速器名为HERACLES。具体见2022年论文《Intel HERACLES: Homomorphic Encryption Revolutionary Accelerator with Correctness for Learning-oriented End-to-End Solutions》。

• Duality，其加速器名为TREBUCHET。具体见2023年论文《TREBUCHET: Fully Homomorphic Encryption Accelerator for Deep Computation》。该项目目前未开源。

• SRI International，其加速器名为CraterLake。具体见2022年论文《CraterLake: a hardware accelerator for efficient unbounded computation on encrypted data》。该项目目前未开源。

• Niobium Microsystems，其加速器名为BASALISC。具体见2022年论文《BASALISC: Programmable Hardware Accelerator for BGV Fully Homomorphic Encryption》。该项目目前未开源。

所有DPRIVE的参与者都在开发加速算术FHE方案（如BFV/BGV和CKKS）的专用集成电路（ASIC）。这些项目正处于不同的制造阶段，初步性能数据基于仿真结果。如，Niobium的初始论文声称，其加速器在处理一个包含$1,024$个样本和$10$个特征的数据集上的逻辑回归任务时，能达到约$5,000\times$的性能提升：硬件耗时约$40$秒，而CPU需要$60$小时。而这只是硬件加速潜力的下限，未来性能将更高。

这些加速器的核心是对数论变换（Number-Theoretic Transform，NTT）及相关多项式环运算的加速。其主要难点在于：集成足够的RAM来存储所有密文及辅助密钥材料；优化内存局部性以提高性能。

鲁汶大学COSIC研究实验室开发的基于FPGA的方法，名为FPT（详情见2022年论文《FPT: a Fixed-Point Accelerator for Torus Fully Homomorphic Encryption》）。该项目使用Alveo U280 FPGA，以流水线方式处理$16$个密文的批量，自举函数的吞吐量达到$1$次自举/$35$微秒。其曾现场演示过，在CGGI下运行Conway’s Game of Life，动画几乎是实时的。

与DPRIVE中以NTT优化为主的硬件不同，FPT是一种专注于快速傅里叶变换（FFT）的硬件实现。该项目以TFHE-rs的API为基础，专门针对CGGI设计。此外Optalysys公司正在开发一种光学计算芯片，利用光通过透镜（或纳米级等效物）时的干涉模式，实现"光速"计算傅里叶变换，从而加速自举过程。

2024年10月，全同态加密硬件技术联盟（FHE Technical Consortium for Hardware，FHETCH）成立，旨在提高全同态加密 (FHE) 硬件和软件之间的互操作性，以实现实际应用。该联盟由Optalysys、Chain Reaction和Niobium创立，将汇集FHE软件开发商、硬件制造商和云提供商，以加速开发具有商业可行性的FHE解决方案。FHETCH致力于缩小当前FHE解决方案与实际商业部署需求之间的性能差距。该联盟将专注于开发FHE硬件加速技术，创建开放的技术标准，确保FHE系统符合全球监管框架并与现有数据中心格式和FHE软件库无缝集成。这些努力将推动FHE的商业可行性，降低采用门槛，并扩大其在各个行业的应用。

5. FHE+区块链前沿项目情况

区块链的一个主要问题是所有交易和数据都是公开可见的，这对需要使用敏感信息（如个人或财务数据）的应用程序开发人员来说是一个挑战。

FHE可解决区块链的计算机密性、数据安全、用户报名、法规遵从性以及智能合约隐私问题，用于构建链上机密支付、机密投票、保密投票、机密智能合约、盲拍、trustless游戏、trustless桥、机密机器学习、去中心化身份、机构金融等。

目前以太坊社区PSE Acceleration Program，致力于赋能ZKP、FHE、MPC及相关技术领域的个人，目前有多个FHE相关提案。

也涌现了很多公司和团体，致力于提供与区块链兼容的FHE解决方案，如：Zama和Sunscreen等公司致力于提供用于构建机密智能合约的工具和库等；OpenFHE这样的库开始提供面向区块链生态系统的功能（如OpenFHE的新Rust wrapper）；以及大量基于FHE开发的链或应用程序项目。

目前来看，除Octra使用了HFHE算法，其它项目多使用现有的FHE算法，且大多数项目是基于Zama提供的工具和库来构建应用。但现实情况是，IBM、微软、Google等巨头布局FHE生态多年，若其切入到区块链领域，实力不容小觑。

5.1 Zama：FHE解决方案提供商

Zama是一家开源加密公司，致力于为区块链和AI构建最先进的FHE解决方案。由Rand Hindi和著名密码学家Pascal Paillier于2020年初共同创立，Zama提供用于Web2和Web3项目的FHE解决方案，如TFHE-rs库、TFHE编译器Concrete、隐私保护机器学习Concrete ML和机密智能合约fhEVM。其源代码更新非常活跃。需注意Zama技术用于商用目的时，需获得Zama专利授权后才能使用。

2024年3月7日，Zama获得了7300万美元的A轮融资。

Zama创建的fhEVM，是一种机密的智能合约解决方案，使开发人员能够使用Solidity创建机密的链上应用程序。fhEVM可以集成到任何与EVM兼容的链中，确保从提交交易到智能合约处理交易的那一刻，状态始终保持端到端加密。

2024年12月6日，Zama团队发布fhEVM协处理器，使得可在以太坊、Base和其他EVM链上运行FHE智能合约，允许开发人员在任何EVM链上构建机密智能合约，包括那些原生不支持FHE的链，而无需对底层协议进行任何更改。其tps速度由一年前的每秒2笔，提高到了每秒近20笔，速度提升了10倍，且现有新架构具有很高的可扩展性，只需添加更多硬件，就有希望能实现每秒数百甚至数千笔FHE交易。

5.2 Sunscreen：FHE隐私计算引擎

Sunscreen专注于Web3隐私解决方案，将ZKP与FHE结合。所构建的FHE编译器，支持将普通Rust函数转换为具有隐私性的FHE等效函数，当前支持BFV以及TFHE等同态加密方案，并提供了FHE编译器playground。所构建的ZKP编译器，致力于面向希望同时使用FHE和ZKP的开发人员，当前支持将Bulletproofs作为ZKP后端。其源代码近期更新较活跃。

2022.7，Sunscreen获得由Polychain Capital领投的465万美元种子融资。2023.9发布了私有测试网。

5.3 Fhenix：以太坊L2 FHE + Optimistic Rollup

Fhenix定位为以太坊的FHE + Optimistc Rollup，其完全兼容EVM和Solidity，使用FHE实现链上机密智能合约。Fhenix底层采用Arbitrum Nitro和Zama的FHE方案。2024年6月，获得由Hack VC牵头的1500万美元的A轮融资，共筹集了2200万美金。开源代码库见：https://github.com/fhenixprotocol，代码更新活跃。

2024年11月20日升级至Fhenix Nitrogen测试网，最大特点是引入了Threshold Network来实现去中心化、信任最小化的解密操作；同时为解决因FHE密文很大导致以太坊链上存储成本高的问题，引入了Celestia作为数据可用层，来降低交易成本。

目前Fhenix测试网平均产块间隔为约4分钟，日均交易约1千笔左右。

5.4 Inco：模块化隐私L1链

Inco定位为模块化机密计算L1区块链，用作现有EVM和Cosmos L1链的通用隐私层。底层为Cosmos和Zama的fhEVM。其源代码近期代码更新不太活跃。

2024年2月上线Inco Gentry测试网，近期该测试网没有交易。2024年初获得了由1kx领投的450万美元种子融资。

5.5 SherLOCKED：ZK+FHE+MPC隐私基础设施

SherLOCKED定位为EVM链的基于FHE的隐私基础设施，为EthOnline’23 黑客马拉松决赛入围者。其源代码近两年代码无更新。

开发人员可使用SherLOCKED编写自定义智能合约，通过sherLOCKED SDK构建加密交易以及解密加密数据，节点网络执行MPC管理解密私钥，利用RISC0 zkVM来证明token余额的加法和减法同态运算。

5.6 FRAMED!：链上隐藏游戏

FRAMED!为使用 fhEVM 构建的完全链上且无需信任的隐藏信息游戏（黑手党），为ETHGlobal NYC 2023决赛入围者。FRAMED!能够直接在链上存储加密状态。支持 FHE 的智能合约允许对加密数据进行计算，而无需解密，其核心游戏逻辑在Inco测试网上作为全同态智能合约实现。其源代码（TypeScript），2024年4月4日之后代码无更新。

5.7 Privasea：FHEML推理网络

Privasea 定位为 FHEML 推理网络，基于 Zama concrete 技术。

2025年1月10日， Privasea宣布以1.8亿估值获得了1500万美金的A轮融资。

尽管其 公开源代码 自2023年7月份之后无更新，但其发布了多款基于 FHE 的应用，如 Privasea DeepSea AI 网络致力于推进人机协作和智能代理生态系统， 相应测试网 Beta 版 将于 2025 年 1 月 27 日上线，并计划于 2025 年一季度上线主网； ImHuman 为基于 FHEML 的 Dapp，已上线 Google Play 和 App Store； BotOr_NotABot telegram 插件，通过 OTP 验证将 Telegram 帐户链接到 ImHuman 应用程序，提供无缝的人工验证，同时确保用户的敏感生物特征数据安全。

5.8 Octra：基于超图的FHE L1

Octra是一个支持隔离执行环境的FHE区块链网络，提出了一种称为HFHE（FHE on Hypergraphs）的新型FHE，并声称HFHE可以与任何项目兼容并独立运行。2024年9月获得400万美元的pree-seed融资。2024年9月发布公开WASM sandbox，展示了FHE中hypergraphs的高效性。目前可在HFHE-WASM沙盒中测试加法和减法，未来将持续添加更多功能。其源代码主要采用OCaml语言编写。其核心为基于超图的FHE库：https://github.com/octra-labs/HFHE，未能找到相应论文，只有一个简单的算法说明。HFHE算法相对较新，学术讨论有限。解决方案的安全性尚未验证，需要进一步验证。

2025年1月7日发布了Octra测试网phase 1，有超过300个独立validator，需要1T内存，1T硬盘。

5.9 Mind Network：FHE重质押层

Mind Network定位为PoS和AI网络的FHE重质押层，由Zama支持。其源代码近半年无代码更新。

2024年9月，获得1000万美金Pre-A轮融资。2024年4月发布激励测试网活动，2024年5月活动结束。其FHE Bridge是首个面向受监管金融机构的量子抗性FHE桥，用于确保跨链交易的安全。已与SWIFT和几家全球银行进行了试点。与Chainlink签署了一级渠道合作协议。该产品基于以太坊基金会2023年研究成果FHE-DKSAP: Fully Homomorphic Encryption based Dual Key Stealth Address Protocol。

5.10 Co-FHE：基于Wasm的FHE

Co-FHE背后团队信息不详，其源代码，近半年无代码更新，其核心开发者维护了以下4个库：

• https://github.com/Co-FHE/fhe-wasm（WebAssembly）：基于FHE的Wasm模拟器。

• https://github.com/Co-FHE/wasmi（Rust）：fork自Wasmi Labs的wasmi库，定位为Wasm解析器。

• https://github.com/Co-FHE/tfhe-rs（Rust）：fork自Zama TFHE-rs库，为FHE算法库。

• https://github.com/Co-FHE/zkrpc：基于Zcash Halo2实现RPC ZK证明。

5.11 Verisense Network：FHE VaaS网络

Verisense Network定位为由FHE赋能的VaaS（Validation-as-a-Service）网络，可与任意重质押层配合使用，解锁AVS（Actively Validated Service）需求。
其源代码，代码更新活跃。

其核心论文主要有2个：

• 2024年8月Monadring：为借助VRF和FHE实现的轻量级共识协议。

• 2024年8月Verisense白皮书。

计划于2025年Q1上线测试网。

5.12 Airchains：zkFHE L2

Airchains：借助Zama fhEVM，正在重新定义机密性和透明度如何在链上共存，其强大的框架将zk和FHE结合在一起的L2。技术白皮书为Leveraging Zero-Knowledge and Fully Homomorphic Encryption Technologies。目前处于测试网阶段。其源代码，近期代码有更新。

5.13 Fair Math

Fair Math定位为去中心化FHE计算机，致力于成为下一代安全和去中心化应用程序的基础平台。其目标是构建一个可扩展的开源生态系统，使隐私保护计算能够广泛应用。通过克服与隐私和机密性相关的障碍，解锁新的用例并推动创新。其源代码，近期更新不太活跃。

2023年底，Fair Math和OpenFHE社区一起上线了FHERMA平台，详细信息见2024年初论文《FHERMA: Building the Open-Source FHE Components Library for Practical Use》，其引入了黑盒和白盒挑战，并对提交的FHE解决方案进行了全自动评估。FHERMA平台上的最初挑战是由机器学习和区块链中的实际问题引起的。获胜的解决方案被集成到FHE组件的开源库中，该库在Apache 2.0许可证下可供PET（Privacy-Enhancing Technology）社区的所有成员使用。目前FHERMA平台上已发布了多个挑战。2024年2月获得140万美金Pre-seed轮融资。2024年11月发布了技术白皮书《Decentralized FHE Computer》。

5.14 FHE方案评估

目前公开维护活跃的FHE算法库只有：

• SEAL（C++/C#）：主要由微软维护
• Lattigo（Go）：主要由Tune Insight维护。Tune Insight 是一家诞生于瑞士洛桑 EPFL 数据安全实验室的初创公司。
• TFHE-rs（Rust）：主要由Zama维护。
• OpenFHE（C++）：Duality。Duality 由世界知名的密码学家和数据科学家专家创立，旨在帮助组织与其业务生态系统（客户、供应商和合作伙伴）安全地协作处理敏感数据。

这些库代码实现上没啥明显缺陷，都是实现的多年前的FHE理论算法。不过Zama背后采用的TFHE算法，其本质不支持浮点运算，若用于机器学习等场景，其Concrete框架是做了一些额外处理的，若考虑AI场景应用，Zama的框架不一定是最优的，不过目前其整个套件支持应该是对应用项目方最友好的。

FHE+区块链项目除Zama、Sunscreen团队有很好的FHE理论背景，Octra（其HFHE无详细论文，实力不详），其它项目都是偏应用，且几乎都是用的Zama提供的框架。

性能目前比较权威的评测有：

• 2022年论文《SoK: New Insights into Fully Homomorphic Encryption Libraries via Standardized Benchmarks》。距今已过去2年多的时间了，各个库可能有迭代优化，各个指标应该是不准确了。
• HE Benchmarking Framework - HEBench：2023年8月之后再无更新。
• 2024年论文《Benchmarking Fully Homomorphic Encryption Libraries in IoT Devices》。针对的是资源受限的IoT设备上的评测。

性能评测其实很难有统一标准，各个库可能支持不同的加速器（CPU、GPU、FPGA、TPU、ASIC），以及项目方实际项目运行环境也会有不同限制，建议针对自身实际情况来针对性的评测。

另外，建议：实际项目选型时除考虑框架友好度之外，可以结合TFHE-rs](https://github.com/zama-ai/tfhe-rs)（Rust）、SEAL（C++/C#）、Lattigo（Go）、OpenFHE（C++）来综合评估，选择最适合的基础库。

5.15 FHE方案潜力股

目前来看，整个FHE生态正在成熟，社区和标准化也正在形成。目前由政府和工业联盟组织的Homomorphic Encryption Standardization专注于FHE的ISO标准化工作，同时还举办FHE研讨会。由Zama领导的FHE.org小组每周会举办一次关于FHE研究的研讨会，有一个活跃的Discord，且每年会举办FHE年度会议。OpenFHE项目有一个活跃的FHE Discourse论坛，里面有关于OpenFHE和FHE的讨论。TFHE-rs、Sunscreen和OpenFHE等开源生态更新活跃。DARPA的DPRIVE项目专注于FHE硬件加速，过去4年来为FHE硬件设计者提供了超过7千万美金的资助。IDASH每年会组织隐私和安全研讨会，并发布相关竞赛任务，为生物领域的同态加密做基准测试和加速。

对于区块链领域，目前Zama的先发优势明显，其开发的用于机密智能合约的fhEVM库，已被很多项目采用。Sunscreen团队正在迎头赶上。从整个FHE+区块链生态繁荣发展的角度来看，需要有更多的团队参与FHE理论算法创新、FHE算法库多语言开源实现、FHE加速、FHE编译器、FHE各种应用配套SDK工具等。

FHE应用在实际做方案选型时，应考虑所需计算次数、明文空间、密钥大小、密文大小、性能、是否对不同明文或密文做相同操作、开发者友好程度等因素综合考虑，来选择适合该应用的最佳FHE方案。目前来看，对比ZKP发展轨迹，目前仍处于FHE的早期阶段，后续应该会有类似的FHE算法寒纪武大爆发，从而能更好的满足实际应用落地场景的性能、安全等要求。

6. FHE与ZKP融合

隐私问题一直是一个需要解决的关键领域，不同的密码原语提供不同的隐私效用：

• ZKP：用户能够证明自己知道某个值，而无需透露该值。可保证计算完整性，但需要知悉数据的明文信息，来证明基于这些数据的计算是正确的，对于某些特定隐私保护应用场景，是明令禁止提供数据明文信息的。

• FHE：允许任何人直接对加密数据进行计算；结果与在纯文本上运行相同。密文的可塑性是FHE的一个定义性特性，因为它是允许在加密数据上执行同态计算的必要条件。这意味着FHE自身无法保证该计算的正确性，因此也无法提供任何计算完整性保证，使得在真实世界的FHE部署时，存在可疑的隐私攻击问题。

FHE与ZKP融合存在2个维度：

• 从区块链应用领域角度来看，将ZKP与FHE、智能合约结合，可解决新的不可能三角，其中智能合约提供可编程性、ZK提供可扩展性，而FHE提供隐私性。
  
  图 11: ZKP、FHE 以及智能合约结合

• 从FHE算法自身的角度来看，由于FHE密文固有的可塑性，其天生缺乏完整性，即当存在可能以任意方式恶意偏离协议的主动攻击者时，其不仅会影响正确性，还可能完全破坏FHE的机密性安全保证。现有的大多数FHE工作都依赖于半诚实服务器假设，服务器不会偏离预期计算。而借助ZKP技术，服务器正常计算 FHE 电路并存储所有（加密的）中间结果，然后计算ZKP proof证明其知道中间值的赋值，使得对于给定输入，电路输出为目标密文。从而可降低对服务器信任假设，提供更强大的完整性保证。同时也可借助ZKP来验证密文或密钥的有效性，确保其未被篡改或损坏，防止攻击并保证数据完整性。

在无信任环境中构建支持 FHE 的应用程序时，ZKP非常有用且通常是必需的。
在此所说的无信任是指以下两种情况之一：

• 情况一；无法完全信任 提供 FHE 加密数据的用户 或

• 情况二：无法完全信任 负责对加密数据执行计算的第三方。

具体场景为：

• 对于情况一，假设用户想要从她的加密账户余额’enc(bal)‘中提取一些加密金额’enc(amt)’。用户可能会（无意或恶意地）尝试发送比她实际拥有的更多的钱（使得’amt > bal’）。如何实现’amt <= bal’在将这两个值保密的同时保证其他方无法看到？使用 ZKP，用户可以证明’amt <= bal’而无需向任何人透露这些值实际上是什么。用户提供的密文也必须"格式正确"——这意味着它们符合底层加密方案的要求，而不仅仅是随机的数据字符串。
  • 如果不信任用户，如何确保确实如此？答案是使用ZKP！用户可随密文提供ZKP，证明密文的有效性，而无需透露任何底层值。
• 对于情况二，考虑web3中的工作原理，其中的格言是"don’t trust, verify不要信任，要验证"。如何知道第三方运行了所要求的FHE计算？答案是使用ZKP！计算方必须证明他们忠实地执行了FHE计算。可将这种设置称为"vFHE（可验证的FHE）“。与 rollup 所需的有效性证明类似，计算方必须证明他们忠实地执行了 FHE 计算。将这种设置称为"可验证的 FHE”（通常通过 ZKP，可以在其中验证 FHE 计算是否正确执行）。

6.1 用ZKP证明"FHE执行"

目前已对用ZKP证明"FHE执行"做了多种尝试：

• zkFHE团队2023年所做的Arithmetizing FHE in Circom尝试表明，使用Circom算术化TFHE中的单个自举NAND门，需要约15亿个约束；使用Circom算术化FHEW中的单个自举NAND门，需要约25亿个约束。尽管获得的约束总数对于任何实际应用而言都不切实际——证明"即使是简单的FHE计算的正确执行"（如验证单个同态加法和同态乘法运算）也需要几分钟的时间，但按操作划分的约束数量有助于识别出FHEW和TFHE方案中在零知识证明中需要更多努力的操作。为此zkFHE团队认为，应该由专门定制的FHE-friendly ZKP系统来证明FHE。 尽管 Circom 支持多种证明后端，circomlib-FHE 的设计目的并不是直接用于证明和验证加密计算。相反，它是一个原型工具，可快速、高效地测试和优化FHE方案在证明系统中的算术化表达。

• 2023年，L2IV Research团队和https://github.com/emilianobonassi/zkFHE均尝试了用RISC0 zkVM来验证FHE，性能并不理想。

• zkFHE团队正在构建https://github.com/zkFHE/zkOpenFHE，尝试用libsnark来证明OpenFHE库中FHE电路的正确评估，实现了约束的自动生成优化以及扩展witness的计算。

当前最先进的ZKP证明系统效率极高，但主要针对与FHE共享特征较少的应用进行优化。表达现代最先进的FHE方案面临一系列挑战，不仅因为同态操作，尤其是密文维护操作计算复杂，还因为FHE和证明系统在本质上操作于不同类型的代数结构上。

将FHE方案做ZK算术化证明时，需要克服的一些挑战：

• FHE方案使用的环（ $Z_q$ 和 $Z_Q[X]/(X^N+1)$ ）与R1CS的有限域 $F_p$ 之间的匹配问题。

• 模数切换中的舍入。

• 不同基数的多位分解和符号分解。

• 数组索引访问动态未知，如在密钥交换或FHEW的累加器更新中。

• 大量使用数论变换（NTT）。

• 大规模的RLWE-RGSW乘法和多个模约减操作。

FHE依赖于基于格的密码学，而web3空间中使用的最有效的ZKP则不然。为了证明FHE密文是格式正确的，需要证明它满足某个矩阵向量方程，其中的条目来自特定的数学"空间"（称为环），并且这些条目是"小的"。证明这些条目是"小的"是零知识领域中最昂贵的部分（通常有数千个range proofs）。2023年论文《Verifiable Fully Homomorphic Encryption》中，对Bulletproofs、Aurora、Groth16、Rinocchio等证明系统的vFHE实现性能进行了对比，事实证明，即使使用Groth16等高效证明系统，证明"简单的FHE计算的正确执行"（如验证单个同态加法和同态乘法运算）也需要几分钟的时间。

其中Bulletproofs、Aurora、Groth16是现有通用ZKP证明系统，而Rinocchio是支持FHE的证明系统，由2021年论文《Rinocchio: SNARKs for Ring Arithmetic》中提出，但其仅支持算术环操作，使用了一种高度低效的编码系统，表达能力有限，只能够表达现代FHE方案中的部分内容。zkFHE采用了新的编码方式对Rinocchio进行了优化，相应代码实现见：https://github.com/zkFHE/ringSNARK（C++），但性能仍不够理想。

未来可能需要FHE-friendly ZKP证明系统：如2024年7月Dan Boneh 和 Binyi Chen论文《LatticeFold: A Lattice-based Folding Scheme and its Applications to Succinct Proof
Systems》中所提出的LatticeFold证明系统，其在全同态加密（FHE）和格签名方案使用的相同模结构上运行，且可使用这种基于格的证明系统来更好地证明关于基于格的关系的陈述，不久的未来应该能看到将用于证明FHE具体性能数据。

6.2 用ZKP证明"FHE参与方的RLWE密文格式正确"

在无需信任的环境中使用FHE时，用户通常必须：加密她的输入并证明这些输入密文是"格式良好的"。

以太坊基金会2024年论文Greco: Fast Zero-Knowledge Proofs for Valid FHE RLWE Ciphertexts Formation》，使用ZKP来证明FHE参与方的RLWE密文格式正确，开源代码见：

• https://github.com/privacy-scaling-explorations/greco（Rust & Python）【基于Halo2证明系统】：证明BFV全同态加密方案中加密密文的正确性。

• https://github.com/enricobottazzi/zk-fhe（Rust）【基于Halo2证明系统】：使用ZK来证明，BFV全同态加密方案中，加密运算的正确执行。

在Multi-party FHE应用中，各方对自己的秘密数据加密，并将加密后的密文提交给server，根据应用逻辑，server会对各方所提交的密文做同态运算。

如，在不记名投票中，会将编码了选票的密文求和来计数。有效的加密选票形式为$E(0)$和$E(1)$。恶意投票人可能会发送无效的加密选票，如$E(145127835)$，从而搞乱整个选举。因此，选民必须证明其提交的密文是：一个有效RLWE密文，且，其所加密的明文信息对应有效选票（如要么为0，要么为1）。

Greco用zero-knowledge proof让用户证明其RLWE密文是well-formed（符合规则的），即相应的加密操作是正确的。Greco生成的proof，可与其他额外的特定应用逻辑组合，并在非交互配置中可被公开验证。

6.3 用ZKP证明"FHE Bootstrapping的正确执行"

bootstrapping操作通常为FHE方案中最昂贵的操作，尽管TFHE的bootstrapping，比其它FHE方案中的bootstrapping，计算开销更低，但其也足够复杂，使得若直观对其做SNARKifying操作，将导致Prover需要巨大的内存，对大多数应用来说是不切实际的。直接对TFHE的bootstrapping做SNARK-ifying操作，不是高效的方案。Zama团队曾实践过，使用FHE
toy参数（不是真实参数），在具有128GB RAM的AWS实例上运行，直接内存溢出。

Zama团队2024年论文Towards Verifiable FHE in Practice: Proving Correct Execution of TFHE’s Bootstrapping using plonky2中，首次阐述了，在实践中，将整个FHE bootstrapping操作，使用SNARK来证明。该论文方案充分利用了TFHE bootstrapping操作中的结构化特性：TFHE的PBS中，包含一个具有多次（约600到700次）迭代的循环；SNARKs技术可使用Incrementally Verifiable Computation（IVC）来高效证明该循环，而不是将该循环展开为一个大的电路。所谓IVC，是指一次证明一个迭代，而不是一次证明所有迭代。同时对其TFHE进行了少量调整，使其更适合于基于有限域的算术电路模型，如：

在其开源代码https://github.com/zama-ai/verifiable-fhe-paper（Rust，Plonky2）中，使用Plonky2实现了基于递归的IVC方案，并将该IVC方案用于了TFHE PBS。

Zama团队对其TFHE进行了少量调整，使其更适合于基于有限域的算术电路。如：将密文的modulus，修改为Plonky2原生使用的素数；修改了key switch，使得可通过external product来执行。借助基于IVC的实现，所需内存量降了一个量级，使得消费级笔记本也可运行该Prover。在经典AWS示例中，计算proof需约20分钟，仍相对较长，但已接近实用水平了。proof size约为200kB，验证proof时长仅需要数毫秒。

因此，Zama团队认为：vFHE处于实用化的边缘。证明FHE方案中最困难部分（bootstrapping），可使用具有非常合理计算资源的SNARK来证明。这是一个重要的里程碑，也是一个开始。仍有许多途径待探索，如：如何将Prover，由PBS电路，扩展到，完整的FHE电路？是否有改进基于通用zkVM的实现的技术？是否有更适合FHE的zkVM？使用基于folding的IVC（如见2024年论文《Mangrove: A Scalable Framework for Folding-based SNARKs》），而不是基于递归的IVC，能否获得更好的效果？Zama团队坚信vFHE方案将对隐私技术产生巨大影响，并将解锁众多惠及所有人的应用程序。

7. FHE未来方向

尽管同态加密（FHE）在支持加密数据的安全计算方面潜力巨大，但其广泛采用仍面临诸多障碍。FHE面临的一些主要挑战有：

• 计算复杂性：与ZK相比，FHE计算量明显更大，速度更慢，使得它在某些实际应用中不太实用。

• 密文尺寸庞大：同态加密通常导致密文扩展，即加密数据的尺寸远大于原始明文。这增加了存储需求和通信开销，特别是在处理大规模数据集时。

• 噪声累积：同态加密方案在执行同态运算时容易出现噪声累积，可能降低加密数据的质量并影响计算的准确性。在保护数据隐私的同时管理和减少噪声是一项重大挑战。

• 功能受限：尽管FHE支持对加密数据进行任意计算，但在高效执行某些操作和计算类型上存在实际限制，如RAM（随机访问模型）计算等。

• 密钥管理与分发：FHE需要生成和管理加密密钥，包括公钥和私钥，这使密钥管理和分发过程更加复杂。在确保高效访问控制的同时，安全分发和保护密钥是一项非平凡的任务。

• 密钥管理的复杂性以及对有效噪声管理的需求进一步增加了它的局限性。

• 标准化与互操作性：缺乏标准化的FHE方案和可互操作的实现，阻碍了不同平台和环境间的协作和采用。推动标准化对于促进互操作性并确保不同FHE实现间的兼容性至关重要。

为此需要：

• 改进算法：需要持续开发更高效的算法和技术，以降低FHE方案的计算复杂性并提升其性能。这包括优化同态运算、最小化噪声累积以及改进加密和解密算法。

• 参数选择优化：选择合适的加密参数并优化方案参数，对于在FHE实现中实现更好的性能和安全性至关重要。参数选择技术和优化策略旨在平衡性能、安全性和功能性。

• 硬件加速：专用硬件加速技术（如FPGA、ASIC等加密处理器）正在探索中，以加速同态计算并减少延迟。基于硬件的解决方案可显著提升FHE在特定应用和使用场景中的效率。目前已有一些在研的FHE加速器，详情参加本文"FHE开源加速器"章节内容。

• 混合加密方法：结合FHE与其他加密技术（如对称密钥加密AES），旨在利用两种方案的优点，同时减轻各自的局限性。通过仅使用FHE加密部分数据，混合方法能够减少计算开销和存储需求。

• 标准化工作：行业联盟和标准化机构正致力于开发FHE的通用标准和协议，促进跨平台和应用的互操作性与采用。标准化工作推动了FHE实现间的协作、互操作性和兼容性。

从FHE工程落地角度来看，期待有：

• 1）Threshold FHE（门限FHE）：目前FHE区块链项目大多使用一个通用公钥进行加密，使用分布式私钥进行解密。主流的门限解密方案不支持去中心化的validator集。@dWalletLabs在其2024年《2PC-MPC: Emulating Two Party ECDSA in Large-Scale MPC》白皮书中将FHE与MPC结合，致力于实现信任最小化隐私的飞跃。

• 2）Multi-key FHE（多密钥FHE）：门限FHE方案中经常未解决的一个问题是通用解密密钥只能解密使用通用加密密钥加密的密文。拥有通用密钥会在隐私保证方面带来一些严重的权衡。多密钥FHE通过对使用多个密钥加密的数据进行直接计算来规避这个问题，产生的结果只有在所有相关方（即用户和validators验证者）的同意和合作下才能解密。该方案未被利用的主要原因是它在本已繁琐的方案上产生了巨大的计算开销。

• 3）Verifiable FHE（vFHE）：FHE的另一个发展领域是可验证计算以及FHE完整性验证。可能需要有FHE-friendly ZKP方案。

• 4）新方案和实现：如今，格统治着FHE密文的世界。希望能有实现FHE方案的全新方法。正如Craig Gentry在其2022年论文《Homomorphic encryption: a mathematical survey》中所指出，在FHE算法理论创新方面，未来有可能：能构建"无噪声"的FHE；能实现针对量子电路的FHE等。

• 5）加速：让FHE性能能满足实际应用需求。

• 6）FHE编译器：更好的FHE编译器，能助力开发者体验，提升FHE应用落地进度。

8. FHE领域前景展望

在过去几年中，FHE的性能取得了多次飞跃，使其成为多种安全计算应用的有力解决方案。研究重点已从展示概念验证应用转向解决实际问题，目前已经看到第一波基于FHE的实际应用部署，如苹果公司最近在iOS上引入了基于FHE的实时来电显示功能，详情可参看苹果2024年7月博客Announcing Swift Homomorphic Encryption以及2024年10月博客苹果生态的机器学习和同态加密。

Data Bridge Market Research分析了全球全同态加密市场，该市场在2023年为2.9762亿美元，预计到2031年将达到5.5087亿美元，在2024-2031年预测期内的复合年增长率为8.00%。随着FHE理论算法和工程实现的快速发展，实际表现应能远超该预测值。

将ZK推向今天的水平总共花费了大约10亿美元——这是一个很大的兴奋和潜力，但还有更多的生产用例有待观察。Sergey预计FHE将需要大约相同的资金才能达到目前的水平需要大约9亿美金VC。这是因为FHE软件栈的类似部分需要重写，而且可以说需要重写更多。Sergey认为工程师应该关注更多的垂直用例，并考虑端到端的开发人员体验。当然，考虑通用VM环境是有利可图的，但其应针对特定的工作负载进行优化。谁将为保护隐私的固有管理费用支付美元（工程、维护和执行成本）还有待观察。FHE领域需要更多的资金、更多的工程师、实用的用例和简单的开发环境。

Niobium团队认为随着2025年的到来，FHE是一项即将成为主流的隐私增强技术。FHE在计算过程中对数据进行加密，这样即使被拦截也无法读取。硬件加速、风险投资和FHETCH等新的跨行业联盟为FHE带来了强劲的风向，未来两年将迎来首批商业应用。在2025年，随着FHE的正式采用，预计会观察到三个趋势：人工智能和区块链的采用将从最前沿开始；执法部门将积极推动加密技术的广泛应用；行业协作开发，而不是秘密作战。

参考文献

• GGH公钥密码系统 Public-key cryptosystems from lattice reduction problems

• Regev05论文On Lattices, Learning with Errors, Random Linear Codes, and Cryptography

• Brakerski12论文Fully Homomorphic Encryption without Modulus Switching from Classical GapSVP

• Micciancio-Regev书 Lattice-based cryptography

• KTX07论文Multi-bit Cryptosystems Based on Lattice Problems

• DGHV10论文Fully homomorphic encryption over the integers

• LV10论文On Ideal Lattices and Learning with Errors over Rings

• Gentry09论文Fully homomorphic encryption using ideal lattices

• CR16论文Recovering Short Generators of Principal Ideals in Cyclotomic Rings

• BV11论文Efficient Fully Homomorphic Encryption from (Standard)LWE

• LTV13论文On-the-fly multiparty computation on the cloud via multikey fully homomorphic encryption

• GSW13论文Homomorphic Encryption from Learning with Errors:Conceptually-Simpler, Asymptotically-Faster, Attribute-Based

• TRLWE18论文TFHE: Fast Fully Homomorphic Encryption over the Torus

• 陈智罡 全同态加密：从理论到实践

• 周福才、徐剑 格理论与密码学

• Google Jeremy Kun 2024.5博客 A High-Level Technical Overview of Fully Homomorphic Encryption

• Optalysys团队2024年10月博客 Fully Homomorphic Encryption industry leaders join forces to form global FHE Hardware Consortium

• Fhenix团队2023年10月17日博客 The Holy Grail of Encryption: The Rise of FHE Technology

• NGC Ventures团队2024年1月12日博客 Introduction to FHE and Blockchain: Implications for Scalability and Privacy

• Awesome Fully Homomorphic Encryption (FHE) x Blockchain resources, libraries, projects, and more

• Awesome Homomorphic Encryption

• PANews 2024年9月17日文章 全同态加密（FHE）的进展与应用

• 2022年论文《Survey on Fully Homomorphic Encryption, Theory, and Applications》

• Craig Gentry 2022年论文《Homomorphic encryption: a mathematical survey》

• 2024年12月20日Jorge Myszne，Niobium Microsystems 首席产品官 博客 3 Homomorphic Encryption Trends for 2025

• HCLTech团队2024年6月研报 Homomorphic encryption: Exploring technology trends and future approach

• 2024年论文《vFHE: Verifiable Fully Homomorphic Encryption》

• PPS Lab团队2023年10月博客 Arithmetizing FHE in Circom

• PPS Lab团队2023年10月博客 A primer on the FHEW & TFHE schemes

• 2024年论文《Oraqle: A Depth-Aware Secure Computation Compiler》

• 2023年10月论文《A Survey on Implementations of Homomorphic Encryption Schemes》

• Sunscreen团队2021年8月博客 An Intro to Fully Homomorphic Encryption for Engineers

• TFHE：2016年论文《Faster Fully Homomorphic Encryption: Bootstrapping in less than 0.1 Seconds》

• BGV：2011年论文 《Fully Homomorphic Encryption without Bootstrapping》

• BFV：2012年论文《Somewhat Practical Fully Homomorphic Encryption》

• CKKS：2016年论文《Homomorphic Encryption for Arithmetic of Approximate Numbers》

• HomomorphicEncryption.org 2018年slide Building Applications with Homomorphic Encryption

• Greenfield Capital 2024年7月博客 The muted Seven – 7 things you should consider re confidential compute

• Sunscreen 2023年8月博客 How SNARKs fall short for FHE

• 2024年4月18日BigBrainVC团队博客 Flawed Homomorphic Encryption

• 2024年Verisense Network slide An Introduction To FHE and Its Application in Rust

• Vitalik 2020年7月20日博客 Exploring Fully Homomorphic Encryption

• 2023年论文《Verifiable Fully Homomorphic Encryption》

• 2018年《Homomorphic Encryption Standard v1.1》

• 2021年论文《SoK: Fully Homomorphic Encryption Compilers》

• 2024年论文《SoK: Fully Homomorphic Encryption Accelerators》

• Sunscreen团队2023年5月博客 Building an FHE compiler for the real world

• Zama团队2023年5月23日博客 Private Smart Contracts Using Homomorphic Encryption

• Craig Gentry 2024年6月分享视频 FHE: Past, Present and Future