Nemesis框架：基于缓存思想加速多槽全同态加密的隐私保护机器学习

1. 项目概述：当隐私保护遇上性能瓶颈

在数据驱动的时代，机器学习模型正以前所未有的深度渗透到医疗、金融乃至我们的日常生活。随之而来的，是公众对数据隐私日益增长的担忧。想象一下，你的医疗影像数据被用于训练一个AI诊断模型，或者你的消费记录被用于信贷评估，你当然希望这些敏感信息在计算过程中不被任何第三方窥探。这就是隐私保护机器学习（PPML）要解决的核心问题。

全同态加密（FHE）技术，被誉为隐私计算领域的“圣杯”。它允许数据在全程加密的状态下进行计算，服务提供商只能看到一堆如同天书般的密文，却能在其上执行复杂的运算，最终得到加密的结果，只有拥有密钥的数据所有者才能解密看到正确答案。这完美契合了“数据可用不可见”的理想。然而，这个“圣杯”有个众所周知的致命缺点：慢。FHE的计算开销比处理明文数据要高出几个数量级，一次简单的乘法可能需要数秒，这使得它在处理像图像识别、自然语言处理这类需要海量矩阵运算的现代机器学习任务时，几乎寸步难行。

传统的优化思路，比如算法层面的改进或硬件加速，虽然有效，但往往触及天花板。这时，缓存思想进入了研究者的视野。去年SIGMOD上发表的Rache工作，首次将缓存机制引入FHE，针对加密单个整数或标量的场景取得了显著加速。但现实世界的机器学习数据远不止单个数字，它们通常是高维向量或张量。Rache的局限在于，它无法有效处理FHE中更强大的“多槽”加密——即一次性能将多个明文打包进一个密文多项式里进行并行计算。这就像你有一个能装很多货物的集装箱（多槽密文），但优化工具（Rache）却只擅长处理散装的小包裹（标量），效率瓶颈依然存在。

正是在这个背景下，Nemesis框架应运而生。它的目标很明确：将缓存优化的威力，从“散装运输”扩展到“集装箱运输”，攻克多槽FHE的效率难关。我花了相当长时间研究相关开源实现和论文，发现Nemesis的设计非常巧妙。它没有颠覆FHE的基础密码学原理，而是在其之上构建了一个智能的“预计算-重构-随机化”工作流，核心思想是将昂贵的加密操作转化为相对廉价的同态运算。接下来，我将深入拆解这个框架的每一个环节，分享从原理到实操的完整细节，以及我在复现和思考过程中总结的一些关键心得。

2. 核心思路拆解：预计算、重构与随机化的三位一体

Nemesis的性能提升并非来自魔法，而是基于一个清晰的、三层级的优化策略。理解这个策略，是掌握其精髓的关键。

2.1 从“现做现卖”到“预制菜”：预计算的核心价值

传统FHE加密流程是“来一个数据，加密一次”。对于需要反复加密相似或相关数据集的ML任务（例如，联邦学习中多个客户端上传的模型更新），这种模式产生了巨大的重复计算开销。Nemesis的预计算阶段，可以理解为提前准备一批高质量的“加密预制菜”。

这个“预制菜”就是Ciphertext_base。算法1描述了它的制作过程：系统会预先选择一批常用的或高频率出现的明文值（例如，在图像数据中常见的像素值范围，或模型权重中常见的数值），将它们通过范德蒙矩阵编码成一个多项式P_base(x)，然后对这个多项式进行一次完整的、昂贵的FHE加密。这次加密的成本是固定的，并且只发生一次。

注意：这里“选择明文”并非指选择用户的真实数据，而是在算法设计阶段，根据数据分布特征或应用场景，选择的一组基底值。例如，在图像处理中，可以选择0到255的灰度值作为候选集。这完全在本地进行，不涉及任何用户隐私数据。

这个预计算密文Ciphertext_base本身不包含任何用户隐私信息，它只是一个“模板”或“工具”。它的妙处在于其数学结构：由于编码时使用了单位根构建的范德蒙矩阵，使得这个加密后的多项式具有非常好的代数性质，能够通过后续的同态运算，高效地“变换”成对目标数据的加密结果。

2.2 化“加密”为“运算”：重构阶段的巧思

当需要加密用户真实的、目标数据批次{m0, m1, ..., m_{d-1}}时，Nemesis不再调用昂贵的原生加密函数，而是进入重构阶段。这是整个框架性能提升的关键。

重构的核心是一个缩放+同态乘法的过程。具体来说：

1. 缩放：根据预计算多项式P_base(x)的系数{b_i}，对每个目标明文m_i进行缩放，得到m'_i = m_i / b_i。这一步是在明文域进行的，计算代价极低。
2. 编码：将缩放后的明文向量{m'_i}编码成一个新的明文多项式P'(x)。
3. 同态乘法：执行一次同态乘法：Ciphertext_target = Ciphertext_base ⊛ P'(x)。

这里的“魔法”发生了。在同态加密中，密文与明文多项式相乘，其效果等价于对密文所对应的明文多项式进行系数层面的缩放。由于Ciphertext_base加密的是P_base(x)，而P'(x)的系数是m_i / b_i，经过同态乘法和解密后，结果恰好就是目标明文m_i。这样，我们仅用一次相对廉价（相比于加密）的同态乘法，就“合成”了对目标数据的加密结果，完全绕过了昂贵的标准加密流程。

实操心得：缩放因子b_i来源于预计算阶段对基底明文的编码。确保这些b_i不为零至关重要。在实现时，通常需要精心选择基底明文集合，或引入微小的扰动，以避免除零错误。一种常见的做法是在编码时加入一个小的正则化项。

2.3 安全性的守护神：随机化的重要性

如果只有预计算和重构，会引入一个严重的安全问题：确定性。对于相同的目标明文输入，重构阶段产生的密文Ciphertext_target将是完全确定的。攻击者通过观察大量密文，可能分析出预计算基底甚至目标明文的信息。

因此，随机化阶段是Nemesis不可或缺的安全组件。它的作用是在重构后的密文上，叠加一个由离散高斯分布采样生成的随机噪声多项式R(x)。即：Ciphertext_randomized = Ciphertext_target ⊕ R(x)。

这个噪声的加入，确保了最终输出的密文是概率性的，即使对相同的明文多次加密，也会得到不同的密文输出，从而满足现代密码学所要求的“不可区分性选择明文攻击（IND-CPA）”安全。关键在于，这个添加的噪声是受控的，其幅度经过精心设计，既足以破坏任何确定性模式，又不会超出FHE方案的“噪声预算”，从而保证后续同态计算的正确性和最终解密的准确性。

三者关系总结：预计算是“备料”，创建可重用的安全模板；重构是“烹饪”，利用模板快速合成目标密文；随机化是“调味”，确保每一道“菜”（密文）看起来都独一无二，无迹可寻。三者协同，在保证FHE原有安全级别的前提下，实现了加密效率的质的飞跃。

3. 技术细节深度解析：从数学原理到工程实现

理解了高层思路，我们深入到数学和实现层面，看看Nemesis是如何具体运作的。

3.1 范德蒙编码：多槽并发的数学基石

Nemesis支持多槽FHE（如CKKS、BFV方案）的关键，在于其预计算阶段采用的范德蒙编码。这允许我们将一个包含d个明文槽的向量，编码成一个d-1次多项式。

假设我们有一个明文向量m = [m0, m1, ..., m_{d-1}]���我们选择一个d次本原单位根ω（在特定的数域中）。构造范德蒙矩阵V，其中V_{ij} = (ω^j)^i。我们的目标是找到一个系数向量c = [c0, c1, ..., c_{d-1}]，使得V * c = m。

换句话说，我们希望找到一个多项式P(x) = c0 + c1*x + ... + c_{d-1}*x^{d-1}，当我们在x = ω^0, ω^1, ..., ω^{d-1}这d个点上求值时，恰好得到m0, m1, ..., m_{d-1}。即：

P(ω^0) = m0 P(ω^1) = m1 ... P(ω^{d-1}) = m_{d-1}

通过求解这个线性系统（c = V^{-1} * m），我们就得到了编码多项式P(x)的系数。对这个多项式进行加密，就得到了一个密文，其解密后在d个槽位上的值正是原始明文向量m。

为什么选择范德蒙结构？因为单位根ω的性质（ω^d = 1）使得范德蒙矩阵V具有非常好的数学特性，其逆矩阵有快速算法（类似于逆FFT），编码和解码效率极高。这正是CKKS等方案能实现SIMD（单指令多数据）风格并行计算的基础。

3.2 同态乘法的正确性证明

重构阶段的核心操作Ciphertext_target = Ciphertext_base ⊛ P'(x)为什么能奏效？我们来做一个简单的推导。

令：

• Ciphertext_base加密了多项式P_base(x) = Σ b_i * x^i。
• P'(x)是明文多项式，其系数为m'_i = m_i / b_i（假设b_i非零）。

在同态加密中，密文与明文多项式相乘遵循以下规则（以BFV/BGV的乘明文操作为例）：

Dec( Enc(P_base) ⊛ P' ) ≈ P_base * P' (mod 模数)

这里的≈是因为FHE运算会引入噪声，但在噪声可控的情况下，解密结果是近似的。

那么，乘积多项式P_base(x) * P'(x)的系数是什么呢？实际上，在点值表示下（即在ω^i这些点上）思考更为直观。因为我们的编码确保了：

P_base(ω^i) = b_i P'(ω^i) = m'_i = m_i / b_i

因此，在每一个槽位i上：

[P_base * P'](ω^i) = P_base(ω^i) * P'(ω^i) = b_i * (m_i / b_i) = m_i

这意味着，乘积多项式在单位根处的取值正好是目标明文m_i。因此，Ciphertext_target解密后，在各个槽位上得到的就是m_i。这个过程完美地将一次加密转换为了编码和一次同态乘法。

注意事项：上述推导是理想情况。在实际的CKKS方案中，由于支持的是近似算术，并且涉及模数转换和重缩放等操作，实现细节更为复杂。Nemesis在OpenFHE上的实现需要精细地处理这些细节，确保噪声增长在可控范围内，并且缩放操作不会损失过多精度。在复现时，必须严格遵循所选FHE库的API规范来执行乘明文操作。

3.3 随机噪声的生成与控制

随机化阶段生成的噪声多项式R(x)，其系数r_i从离散高斯分布N(0, σ^2)中采样。标准差σ的选择是一个权衡：

• 安全性：σ需要足够大，使得生成的噪声具有足够的熵，能有效掩盖明文信息。通常，σ与FHE方案的基础噪声参数在同一量级。
• 效率与正确性：σ不能过大。过大的噪声会快速消耗密文的“噪声预算”，可能导致后续同态运算层数减少，或在解密前噪声就溢出，导致解密失败。此外，生成大方差的高斯随机数本身也更耗时。

在Nemesis的实现中，σ被设定为一个与安全参数λ相关的固定值。采样后的浮点数r_i会被取整并模q（密文系数模数），以适配FHE的有限域运算。

一个关键的实现技巧：为了最大化性能，R(x)的生成可以提前预计算多个样本，或者使用伪随机数生成器（PRNG）配合一个种子在运行时快速生成。由于R(x)是独立于明文和密钥的，这部分预计算可以完全离线进行，进一步减少在线延迟。

4. 实战：基于OpenFHE与PFLlib的Nemesis集成

理论再优美，也需要落地验证。Nemesis的原型系统基于OpenFHE和PFLlib构建。下面我将结合对代码的分析，阐述关键的实现步骤和集成要点。

4.1 环境搭建与依赖

首先需要搭建一个包含OpenFHE和PFLlib的开发环境。OpenFHE是C++库，而PFLlib是Python的联邦学习框架，因此通常采用混合编程的方式。

# 1. 安装OpenFHE (以Ubuntu为例) git clone https://github.com/openfheorg/openfhe-development.git cd openfhe-development mkdir build && cd build cmake .. -DBUILD_SHARED=ON -DNATIVE_SIZE=64 -DCMAKE_BUILD_TYPE=Release make -j$(nproc) sudo make install # 2. 安装PFLlib及其依赖 git clone https://github.com/hpdic/PFLlib.git cd PFLlib pip install -e . --user # 注意：可能需要根据OpenFHE的安装路径设置C++编译器的包含路径和链接库路径

4.2 Nemesis核心模块C++实现

Nemesis对OpenFHE的扩展主要在于实现了预计算、重构和随机化的新算法。以下是一个高度简化的核心类结构示意：

// nemesis_engine.h #include “openfhe.h” using namespace lbcrypto; class NemesisEngine { public: // 初始化，指定参数和预计算的基底明文 NemesisEngine(const CCParams<CryptoContextCKKSRNS>& parameters, const std::vector<double>& base_plaintexts); // 预计算阶段：生成Ciphertext_base void Precompute(); // 重构阶段：输入目标明文向量，输出随机化后的密文 Ciphertext<DCRTPoly> ReconstructAndRandomize(const std::vector<double>& target_plaintexts); // 仅重构（用于调试或特定场景） Ciphertext<DCRTPoly> Reconstruct(const std::vector<double>& target_plaintexts); private: CryptoContext<DCRTPoly> cc_; // OpenFHE加密上下文 KeyPair<DCRTPoly> kp_; // 密钥对 Ciphertext<DCRTPoly> cipher_base_; // 预计算密文 std::vector<double> base_coeffs_; // 预计算多项式P_base(x)的系数（编码后） double randomization_std_; // 随机化噪声的标准差 // 内部方法：编码、解码、生成噪声多项式等 Plaintext EncodePlaintext(const std::vector<double>& vec); std::vector<double> DecodePlaintext(const Plaintext& pt); Plaintext GenerateRandomNoisePolynomial(); };

实现要点：

1. 参数选择：在构造函数中，需要精心选择CKKS的参数，包括环维度（ringDim，如4096）、缩放因子（scaleModSize）、乘法深度等。这些参数决定了安全级别、精度和能支持的计算复杂度。预计算基底的选择需要与这些参数兼容。
2. 预计算实现：在Precompute()函数中，需要将base_plaintexts通过FFT或直接线性求解（对于小维度）编码成多项式，然后调用cc_->Encrypt(kp_.publicKey, plaintext)进行加密。这里编码的效率和精度至关重要。
3. 重构实现：Reconstruct函数是性能核心。它需要：
   • 将target_plaintexts除以对应的base_coeffs_（需处理除零和数值稳定性）。
   • 将缩放后的向量编码为明文多项式P_prime。
   • 调用cc_->EvalMult(cipher_base_, P_prime)执行同态乘明文操作。OpenFHE的EvalMult操作会自动处理模切换和重缩放。
4. 随机化集成：在ReconstructAndRandomize中，先调用Reconstruct得到cipher_target，然后生成noise_plaintext，最后调用cc_->EvalAdd(cipher_target, noise_plaintext)。为了性能，GenerateRandomNoisePolynomial可以使用预生成的噪声池或快速PRNG。

4.3 与PFLlib的Python层集成

PFLlib负责联邦学习的训练流程。我们需要在客户端本地模型���密上传的环节，用Nemesis替换掉标准的CKKS加密。

# 在PFLlib的客户端更新函数中集成Nemesis import pflib.tensor as tensor # 假设我们有一个通过Cython或pybind11封装的Nemesis C++引擎 from nemesis_bridge import NemesisEngineWrapper class NemesisClient: def __init__(self, client_id, model): self.client_id = client_id self.model = model # 初始化Nemesis引擎，加载预计算好的参数和密文基 self.nemesis_engine = NemesisEngineWrapper(param_path=‘ckks_params.json’, base_cipher_path=‘cipher_base.bin’) def local_train_and_encrypt_update(self, data_loader): # 1. 本地训练，获取模型更新（明文张量） local_update = self._local_training(data_loader) # 返回一个字典，键为参数名，值为numpy数组 # 2. 将模型更新扁平化并序列化为一个大的浮点数向量 update_vector = self._flatten_update(local_update) # 3. 使用Nemesis进行高效加密（替代标准的 cc.Encrypt） # 注意：需要将长向量分割成多个批次，每个批次长度等于密文槽数d encrypted_update_parts = [] batch_size = self.nemesis_engine.get_slot_count() for i in range(0, len(update_vector), batch_size): batch = update_vector[i:i+batch_size] # 如果最后一个批次不足，需要填充（padding） if len(batch) < batch_size: batch = np.pad(batch, (0, batch_size - len(batch)), ‘constant’) # 核心调用：重构并随机化 encrypted_batch = self.nemesis_engine.reconstruct_and_randomize(batch.tolist()) encrypted_update_parts.append(encrypted_batch) # 4. 将加密后的部分返回给服务器 return {‘client_id’: self.client_id, ‘encrypted_update’: encrypted_update_parts}

集成关键点：

• 数据序列化与分块：模型更新通常是一个巨大的向量。需要将其分割成多个长度为d（密文槽数）的块，分别用Nemesis加密。这引入了额外的序列化/反序列化开销，但相对于加密开销来说微乎其微。
• 填充（Padding）：最后一个数据块可能不足d个元素，需要进行填充。常用的填充策略有零填充或重复填充，需要在解密后去除。
• 通信：加密后的密文对象需要被序列化（例如，使用OpenFHE的Serializable接口）才能通过网络发送。密文尺寸较大，是联邦学习通信的主要开销之一，但这与是否使用Nemesis无关。

4.4 性能调优与参数选择

根据论文中的实验数据，Nemesis的重构阶段占据了超过90%的时间。因此，优化重构是提升整体性能的关键。

1. 批量处理最大化：尽量确保每次调用Reconstruct时，目标明文向量的长度等于或接近密文的最大槽数d。避免频繁处理小批量数据，以摊销函数调用的固定开销。
2. 基底选择优化：预计算的基底明文向量base_plaintexts的选择会影响缩放因子b_i。理想情况下，b_i的绝对值应远离零，且数值大小相对均匀，以避免缩放时出现数值不稳定（过大或过小的数）。可以考虑对训练数据分布进行统计分析，选择更有代表性的基底。
3. 噪声参数调优：随机化的标准差σ需要在安全性和计算效率间取得平衡。可以通过实验，测试不同σ下模型训练的最终精度和密文噪声增长情况，选择一个在安全参数下可接受的最小值。
4. 利用多线程：在客户端，对不同参数层的更新向量进行加密可以并行处理。此外，OpenFHE内部的某些运算也可能支持并行化，需要根据其文档进行配置。

5. 效果评估与对比分析

纸上得来终觉浅，我们直接看Nemesis在真实场景下的表现。论文在MNIST、FashionMNIST和CIFAR-10数据集上，使用一个简单的CNN模型进行了联邦学习实验。

5.1 性能对比：Nemesis的压倒性优势

实验对比了四种加密方案：

• CKKS Naive：最基础的用法，每个数据点单独加密。这是性能基线，也是最慢的。
• CKKS Batch：使用CKKS原生的批处理（多槽）能力，将多个数据点打包进一个密文。这是当前实践中常用的优化方法。
• Rache+：扩展版Rache，支持浮点数，但仍是针对标量/单槽的优化。
• Nemesis：本文提出的框架。

结果如图1所示（数据来源于论文）：在CIFAR-10数据集上，加密整个模型更新（约87.8万个参数），Nemesis仅需约4.8秒，而CKKS Batch需要8.0秒，速度提升了约1.67倍。相比于需要超过4000秒的Rache+和超过15000秒的CKKS Naive，Nemesis的优势是数量级的。

为什么Nemesis比CKKS Batch快？CKKS Batch虽然利用了SIMD并行，但其加密过程仍然是对整个明文多项式进行标准的、昂贵的加密运算。Nemesis的预计算-重构流程，将大部分加密成本转移到了离线阶段，在线阶段主要成本是一次同态乘明文操作，这比完整的加密要轻量得多。

5.2 各阶段耗时分解与瓶颈定位

图5展示了Nemesis内部三个阶段的耗时占比，这是一个非常关键的分析：

• 预计算（Precomputation）：耗时占比小于0.1%，几乎可以忽略不计。这证实了其“一次性投入，长期受益”的设计是成功的。
• 随机化（Randomization）：耗时占比约7.4%-9.0%。这是一个相对固定且可接受的开销，是换取安全性必须付出的代价。
• 重构（Reconstruction）：耗时占比超过90%！这是绝对的性能瓶颈。

这个分析指明了未来的优化方向：重构阶段是同态乘明文和编码操作，其效率直接取决于底层FHE库（如OpenFHE）中乘明文运算的实现效率。任何对EvalMult（或CKKS中的EvalMult）操作的底层优化，都将直接、显著地提升Nemesis的整体性能。

5.3 不同批次大小的影响

图2、3、4分别考察了批次大小（Batch Size）对三个阶段的影响。

• 预计算时间（图2）：基本恒定，与批次大小无关。因为预计算只做一次，与后续加密的数据量无关。
• 重构时间（图3）：随着批次减小而增加。这是因为总数据量固定时，批次越小，需要调用Reconstruct的次数越多，而每次调用都有固定的开销（如函数调用、数据准备）。因此，在实际应用中，应尽可能用满密文的槽位，采用最大批次。
• 随机化时间（图4）：趋势与重构时间类似，也是批次越小，总时间越长，原因同上。

实操心得：在系统设计时，应将客户端本地更新的大小与密文槽数d进行对齐。例如，如果模型参数总数是100万，d=2048，那么最好将参数向量组织成ceil(1,000,000 / 2048) ≈ 489个密文。这样可以最大化每个密文的利用率，最小化重构和随机化的调用次数。

6. 常见问题、挑战与未来展望

在实际研究和尝试复现Nemesis思想的过程中，会遇到一些典型问题和挑战。

6.1 常见问题排查

1. 解密失败或结果不正确

   • 检查缩放因子：首先确认预计算基底编码后得到的系数b_i没有零值或极端接近零的值。这会导致重构阶段的除法产生极大数值或NaN。
   • 检查噪声预算：随机化添加的噪声以及重构阶段同态乘法引入的噪声，可能消耗了过多的噪声预算。使用OpenFHE的cc->Decrypt()调试接口或GetNoise()方法检查关键步骤后的噪声水平。确保剩余噪声预算足以支持后续的同态运算（如服务器端的聚合）。
   • 验证编码/解码过程：单独测试编码一个已知向量，然后立即解码，看是否能无损恢复。确保在复数域和实数域转换（CKKS特性）时，缩放因子（scale）设置正确。

2. 性能未达预期

   • 批次大小未对齐：确保你传入Reconstruct的每个向量长度都等于密文槽数d。零填充的部分虽然浪费了一些空间，但比分成多个小批次处理要高效得多��
   • FFT/NTT参数：CKKS的性能极度依赖于数论变换（NTT）和FFT的参数。确保环维度是2的幂，并且选择的模数链支持所需的乘法深度。不恰当的参数会导致性能急剧下降。
   • 内存与缓存：大规模向量和密文操作对内存带宽敏感。确保你的数据布局是连续的，并尝试利用多线程进行并行编码/解码操作。

3. 安全性疑虑

   • 随机数质量：确保用于生成噪声多项式的随机数生成器（RNG）是密码学安全的（CSPRNG）。在OpenFHE中，通常使用PseudoRandomNumberGenerator类。
   • 基底公开问题：预计算的基底密文Ciphertext_base是公开的。需要确保攻击者无法从Ciphertext_base反推出用于生成它的基底明文base_plaintexts。这依赖于底层FHE方案（CKKS）的IND-CPA安全性。只要底层FHE是安全的，Ciphertext_base就不会泄露信息。

6.2 当前局限性与挑战

尽管Nemesis表现优异，但它并非银弹，仍有其适用范围和挑战：

• 适用范围：Nemesis优化的是加密阶段。在联邦学习等场景中，如果通信带宽是瓶颈，或者服务器端的同态聚合计算非常复杂，那么加密加速带来的整体收益可能被其他环节抵消。它最适合加密开销占主导的场景。
• 存储开销：需要存储预计算的基底密文Ciphertext_base。虽然只是一个密文，但对于超大规模模型，可能需要多个不同的基底密文来覆盖不同的参数分布，会带来一定的存储成本。
• 动态数据分布：预计算基底是基于对数据分布的先验知识选择的。如果客户端数据分布与预设基底差异巨大（例如，缩放因子b_i普遍很小），可能导致数值不稳定。对于非平稳数据流，可能需要设计自适应机制来更新基底。

6.3 未来可能的演进方向

基于对这项工作的理解，我认为有几个值得探索的方向：

1. 与模型压缩结合：将Nemesis与模型剪枝、量化技术结合。量化后的模型权重往往取值空间更小、更集中，这使得预计算基底的选择更高效，甚至可能用一个基底密文就能很好地覆盖所有权重。
2. 分层预计算：针对大型模型，可以设计分层级的预计算策略。例如，为不同层的权重分布学习不同的基底密文，而不是使用全局统一的基底。
3. 硬件加速：重构阶段的核心是乘明文操作和编码/解码。这些操作有固定的计算模式，非常适合用GPU或专用AI芯片（如Google的TPU）进行加速。探索Nemesis在硬件加速器上的实现是一大看点。
4. 扩展到其他同态方案：目前工作基于CKKS。理论上，该框架也可适配BGV/BFV等方案。探索在不同方案下的实现细节和性能表现，将增加其通用性。

Nemesis框架为我们提供了一个极具启发性的思路：通过巧妙的预计算和代数变换，将密码学原语中的昂贵操作转化为廉价操作。这种“以计算换计算”的思想，或许能为更多隐私计算性能瓶颈的突破打开一扇新的大门。在实际尝试将其思想应用到自己的项目中时，深刻体会到，在隐私、安全与效率的三角博弈中，精妙的算法设计往往能带来意想不到的突破。