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