石家庄外贸建站公司_武汉优化网站技术_域名seo站长工具_上海自动seo

1. 引言

Sunscreen团队重新构想了在同态加密（FHE）中应如何进行计算，采用一种全新的计算范式，并开发出一种新的 FHE 编译器设计，实现了一个愿景：

• 开发者可以“自带程序”。

Sunscreen的第二代编译器构成了这一新愿景的基础 ：

• 同态处理单元（HPU）。

全同态加密（Fully Homomorphic Encryption, FHE）使得在加密数据上运行任意计算程序成为可能，让用户既能保护数据隐私，又能将加密数据用于实际应用。有了 FHE，可以构建如：

• 完全可定制的 AI 代理（可基于任何数据进行训练，无论多敏感）
• 链上生态系统中的隐藏交易策略等应用。

现有的 FHE 工具并未以方便开发者构建隐私保护应用的方式构建，而且它们底层对同态计算（即对加密数据的计算）的方法无法很好地适应硬件的演进。

Sunscreen团队最新工作的灵感源自两个基本问题：

• 如何才能真正扩展一项技术？
• 如何让开发者更高效地上手一项新技术？

为回答这两个问题，Sunscreen团队：

• 1）重新设想了 FHE 中应如何进行计算，采用一种新的计算范式；
• 2）开发了一种新的 FHE 编译器架构，使开发者可以“自带程序”，而无需为使用 FHE 重写已有应用。

Sunscreen团队聚焦于 Torus FHE (TFHE) 加密方案——2018年论文TFHE: Fast Fully Homomorphic Encryption over the Torus，这是一种支持多种加密操作并能进行无限计算的 FHE 方案。这些特性使 TFHE 特别适用于区块链场景，在链上部署时，开发者无法预先知道将执行多少次或何种类型的计算（类似 Vitalik 或以太坊基金会在设计以太坊时也无法预料所有开发者将构建什么应用）。

与现有 TFHE 方法不同，Sunscreen的新范式：

• 将一种特殊的重加密技术“电路引导式重加密（circuit bootstrapping）”
• 与
• 多路选择器（multiplexer）结合，

构建出可扩展的任意计算架构。通过构建一个针对 FHE 操作定制的虚拟处理器，并将其作为 LLVM 工具链的后端，让开发者可以用主流语言直接编写程序。

2. 重构 (T)FHE

许多人（包括专家）在评估 FHE 方案时常常误入歧途，只关注单个操作的性能，而不是完整程序的性能。

一个简单的思想实验如下：

• 系统 A：每个操作耗时 1 秒，需要执行 3 个操作且只能顺序进行；
• 系统 B：每个操作耗时 2 秒，也需要执行 3 个操作但可以并行处理。

你更愿意使用哪个系统？

直观图示如下：

Sunscreen采用的是长远眼光：

• 要让 FHE 在未来数年中扩展，就必须从架构上充分利用硬件（无论是 CPU、GPU 还是未来的 ASIC），而不是指望硬件奇迹般地加速 FHE。

具体而言，这意味着应通过架构设计最大限度地实现并行计算、最小化电路中的关键路径（critical path）。一般来说，提高并行性有助于提升吞吐量，关键路径越短则延迟越低。

而目前基于 TFHE 的方案并未优先考虑这些目标。

2.1 TFHE 与重加密的简要历史

无论采用哪种 FHE 方案，核心挑战之一都是“噪声”。无需深入原理，只需知道噪声过大会导致密文无法解密。

为了抑制密文中的噪声，需要一种特殊操作 —— 重加密（bootstrapping）。这是实现无限计算的关键，因而已有大量研究致力于加快此操作。

目前常见的 FHE 方案包括 BFV（Sunscreen旧版编译器 所用）、CKKS 和 TFHE。TFHE 中的 “T” 代表 torus，该方案又称为 CGGI16——2016年论文Faster Fully Homomorphic Encryption: Bootstrapping in less than 0.1 Seconds。

前两种方案通常采用“分层（leveled）”模式，仅支持一定电路深度，极大限制了可构建的应用。

TFHE 的优点是：

• 相比其他方案，它的重加密与比较操作更加高效（即更快）。

当然TFHE也有一些缺点，比如：

• 算术计算性能不如 BFV 或 CKKS，且当提高精度（位宽）时性能下降显著。

TFHE 的重加密分为几种形式：

• 门级重加密（Gate Bootstrapping）：最早提出的经典方法；
• 函数式/可编程重加密（Functional/Programmable Bootstrapping）：功能更强；
• 电路级重加密（Circuit Bootstrapping）：可扩展但使用较少。

函数式重加密在表面上看似“买一赠一”：

• 既减少噪声又同时进行计算。

但在前述思想实验中，它的行为却更像系统 A —— 不利于并行。

电路级重加密与门级类似，仅仅降低噪声，但有个好处：

• 输出直接兼容“同态多路选择器（homomorphic multiplexer）”。

2.2 拆解Sunscreen的方案：CBS-CMUX

在不涉及 FHE 的情况下，也可以仅用多路选择器实现任意计算。你可以将多路选择器（mux）理解为实现 “if” 语句的硬件：给定两个输入 $d_0$, $d_1$ 和选择位 $b$，当 $b=0$ 输出 $d_0$，否则输出 $d_1$。

FHE 中的多路选择器称为 cmux，可对加密数据进行此类选择，生成加密结果。

Sunscreen的目标是：

• 使用多路选择器树进行通用计算，随后通过电路级重加密降低噪声，以便继续执行后续加密计算。

称之为 CBS-CMUX 方法，因它依赖两种关键操作的组合实现任意程序。

在此过程中需要在几种不同的密文类型（如 GGSW、GLWE）之间切换，这部分将在后续论文中详解。虽然这些细节对工程师看似噩梦，Sunscreen的编译器已实现全自动处理。

Sunscreen的方法优势：

• 减少关键路径上的重加密次数：如，16 位同态比较中，关键路径只需一次重加密，而使用函数式方法则需 3 次。即使使用硬件加速，仍需串行执行所有操作。
• 提升电路内部并行性：当可用核心数或资源足够时，可实现显著加速（类似系统 B）。

3. “自带程序”（BYO（bring your own） program）

开发者应能 自带程序，而不是被迫使用特定的领域语言（eDSL）或重写已有代码。

因此，开发者现在可直接用 C 编写程序，或导入已有 C 代码（有限约束）。要构建 FHE 程序，仅需在代码中加上指令，标明哪些函数是 FHE 程序，以及哪些输入输出需要加密。

3.1 Parasol 编译器现状

Sunscreen的Parasol编译器屏蔽了使用 FHE 时的常见困难，包括参数选择、程序到电路的转换、插入特定 FHE 操作等。

Parasol 编译器支持构建两种 TFHE 变体：

• 单密钥 TFHE（适用于单用户或单实体数据）
• 阈值 TFHE（适用于多方数据）

目前Parasol 编译器支持常见的算术、逻辑、比较操作，也支持导入函数和函数内联，方便构建模块化、可复用的程序。

Sunscreen团队从 C 入手作为概念验证，未来可根据需求加入如 Rust 等 LLVM 兼容语言前端支持。

接下来计划增加的特性包括：

• 有符号整数
• 更高精度整数（目前仅支持到 64 位）
• 明文除法
• 明文分支判断
• 数组等。

4. 架构概览

为提供良好开发体验，Sunscreen团队构建了基于 LLVM 的编译器：

• 开发者可使用 C、C++、Rust 等主流语言，仅需添加少量 FHE 指令；
• 可重用 LLVM 内建的各种优化和转换。

但如何高效运行这些程序呢？普通计算机无法胜任。

因此，还需构建一个可真正运行 FHE 程序的 虚拟处理器。

Sunscreen团队希望程序表示尽可能紧凑，因此该处理器以高级操作（如加法、乘法）表示程序，运行时动态扩展为 FHE 电路。

Sunscreen的处理器和编译器都基于内部构建的 TFHE 方案变体。

5. 技术预览

对于那些希望更深入了解Sunscreen技术栈的朋友，以下是一些详细信息。相应的研究论文即将发布，敬请关注！

• 基于 LLVM 的编译器：开发者目前使用 C 语言编写 FHE（全同态加密）程序，并使用Sunscreen的支持虚拟处理器的 Clang 版本进行编译。没有这个虚拟处理器，生成的 FHE 程序将无法运行！如果想了解如何创建一个 LLVM 后端，可参看 Writing an LLVM Backend。
• 虚拟处理器：为了实际运行 Clang 输出的程序，Sunscreen团队开发了自己的虚拟处理器。它采用out-of-order 乱序处理器设计，并在指令内部进行动态调度，以最大化并行性。Sunscreen设计了一套自定义指令集架构，支持在明文和加密数据混合的环境下运行程序。为此，Sunscreen还在处理器层面对内存进行了重新设计，新增了支持加密数据分支的指令，并构建了自己的电路处理器，以支持 CBS-CMUX 计算方法。
• TFHE 库：在整个技术栈的最底层，是Sunscreen优化过的 TFHE 加密库，它实现了 TFHE 方案所需的加密操作。从理论上讲，其他 TFHE 库也可以接入Sunscreen的处理器使用。然而，考虑到Sunscreen是唯一实现 CBS-CMUX 方法的团队，开发自己的库是最合理的选择。

下面展示了整个流程的高级工作流：

6. 代码示例

那么，使用 Parasol 写的程序是什么样的呢？以下是一个简单示例，展示如何进行私密转账：

#include <stdint.h>[[clang::fhe_circuit]] void transfer([[clang::encrypted]] uint32_t *amount,[[clang::encrypted]] uint32_t *balance
) {uint32_t transfer_amount = *amount < *balance ? *amount : 0;*balance = *balance - transfer_amount;
}

可注意到，除了 [[clang::fhe_circuit]] 和 [[clang::encrypted]] 这两个标记外，它就是一个普通的 C 程序。

虽然该方法的优势在构建大型复杂程序时更为明显，但希望这个例子能让你感受到使用体验！

7. 基准测试

将 Parasol 与目前支持加密数据比较功能的 FHE 编译器进行了对比。

参考 2021年SoK: Fully Homomorphic Encryption Compilers 论文 中的标准，Sunscreen团队测试了编译器在两个应用上的表现：

• 一个是chi-squared test 卡方检验程序（偏重加法和乘法操作），
• 另一个是类似 美国心脏病协会提供的风险评估器的心脏病risk estimator 风险评估程序（偏重比较操作）。

在所评估的五款编译器中：

• 只有 Parasol 以电路重加密作为主要加密计算方式。
• Concrete 使用的是可编程（函数式）重加密，
• 而 Google、E3 和 Cingulata 使用的是较旧的门级重加密方法。

实验在 AWS c7a.16xlarge 实例上进行（64 个 vCPU，128GB 内存），所有编译器均设置为提供 128 位安全性。

坦率地说，当提供足够多的核心以进行任务并行化时，本方案优势最为明显。如果只在 16 或 32 核的机器上运行 FHE 计算，可能感受到的性能优势会小一些。需要强调的是，这只影响计算方；对于提供加密数据的终端用户来说，用笔记本或手机都完全没问题！

7.1 卡方检验基准

首先来看卡方检验任务中，编译器在运行时间、输出程序体积、内存使用方面的表现。

运行时间指的是电路评估过程（不包括密钥生成、输入加密等）。程序体积的定义因架构不同略有区别：在此列出了 Parasol 输出的 ELF 程序大小、Concrete 的 MLIR 表示、Google 转译器的二进制中间电路表示；E3 和 Cingulata 则是本地可执行文件大小。

编译器	运行时间	程序大小	内存使用
Parasol	610ms	256B	1.0GB
Concrete	1.84s	1.41kB	1.82GB
Google Transpiler	13.8s	323kB	299MB
E3-TFHE	440s	2.87MB	182MB
Cingulata-TFHE	85.6s	579kB	254MB

可以看到，Parasol 相比基于门级重加密的编译器（如 Google、E3、Cingulata）内存占用更高，这部分是由于更大的电路重加密密钥所致。

7.2 心脏病风险评估基准

接下来是心脏病风险评估程序的性能比较：

编译器	运行时间	程序大小	内存使用
Parasol	920ms	528B	1.0GB
Concrete	2.13s	10.4kB	4.0GB
Google Transpiler	3.26s	11.4kB	274MB
E3-TFHE	119s	1.87MB	181MB
Cingulata-TFHE	2.98s	613kB	254MB

8. 未来展望

Parasol 编译器是Sunscreen新愿景的基础：

• 同态处理单元（HPU）。
  • HPU 将允许一个 FHE 程序在任何链上运行，无需依赖特定虚拟机。

将在未来几周开源 Parasol，并提供全面文档助你快速上手。不就的将来也会公布关于 HPU 和配套测试网的更多细节。

参考资料

[1] Sunscreen团队Ravital Solomon 2025年4月17日博客 A new vision for TFHE and compilers