我用Stoffel MPC构建了一个隐私保护的基因组研究

# 我用 Stoffel MPC 构建了一项私有基因组学研究 来源：https://vishakh.blog/2026/07/21/i-built-a-private-genomics-study-with-stoffel-mpc/ 大多数基因组研究（https://en.wikipedia.org/wiki/Genome-wide_association_study）一开始都要求参与者上传他们拥有的最具识别性且不可撤销的数据之一——他们的 DNA。我一直在探索多方计算能否提供另一种模式：一种即使没有人在最初收集参与者的基因组，也能让研究产出有用结果的模式。 这个问题现在促使我使用 Stoffel MPC 构建了一个概念验证。一百名模拟参与者成功计算了等位基因聚合计数，而没有任何一方看到完整数据集。这篇文章解释了我构建了什么、它的表现如何以及我学到了什么。 ## Stoffel MPC 已发布 Stoffel（https://stoffelmpc.com/）最近发布了其多方计算（MPC）平台的 0.1.0 版本，目标宏大：让隐私保护应用不仅限于密码学专家团队，也能被普通开发者所使用。 MPC 允许多台计算机对私有数据进行计算，而无需任何一台计算机接收完整的输入。尽管传统上 MPC 系统很难构建，但 Stoffel 将这项技术呈现为一个易于上手的开发者平台。应用使用其类似 Python 的 StoffelLang 编写，编译为字节码，并由 Stoffel VM 在一组 MPC 参与方之间执行。 我们不再需要依赖更强大的隐私政策或更安全的中心化数据库。我们只需避免在单一地点收集原始数据。 ## 自然，我想用 Monadic DNA 来试试 鉴于我一直在进行 Monadic DNA（https://monadicdna.com/）的相关工作，基因组学自然成了一个测试案例。在早期的一次实验（https://vishakh.blog/2025/07/08/using-mpc-for-anonymous-and-private-dna-analysis）中，我和同事们使用了 Nillion 以及来自三十名参与者的真实基因型数据，探索了私有 DNA 分析。 遗传数据是隐私系统的一个异常良好的测试。它具有高度识别性，能揭示亲属信息，并且一旦泄露就无法更改。同时，许多有用的基因组研究并不需要检查单个记录。研究人员可能只需要群体层面的变异计数或跨群体计算的评分。 我想探索的具体用例是一个重新设计的 Monadic DNA（https://monadicdna.com/）移动应用。Monadic DNA 用户将他们的基因型数据保存在手机上，并可能选择参与一项需要跨多个用户聚合统计的研究（可能以获取报酬为回报）。问题在于，该应用能否在无需先将用户的完整基因型上传到 Monadic DNA、研究人员或其他受信任的中心化服务的情况下，安全地贡献这些数据。 与传统设计中每个人的基因型数据都上传到一个必须保护它的中心化服务不同，我想看看 Stoffel 是否能让每个 Monadic DNA 应用直接贡献数据给一个联合计算。在这种设计中，没有协调者、应用服务器或单个 MPC 参与方会接收到完整数据集。 实验的源代码位于 github.com/vishakh/stoffel-test（https://github.com/vishakh/stoffel-test）。 ## 概念验证的目标 该概念验证模拟了一百个 Monadic DNA 移动应用用户加入一项基因组聚合研究。每个用户贡献六个合成的 SNP 值，这些值他们本可以通过 Monadic DNA、23andMe 或其他服务获得。该研究计算每个目标等位基因的总计数以及一个跨群体的简单加权评分。 重要的部分是信任边界。每个模拟用户拥有独立的客户端身份和一个仅包含该用户六个值的过程。客户端在本地创建秘密共享，并将不同的份额直接发送给每个 MPC 参与方。只有聚合计数和评分被揭示。 这与将所有一百条记录放入一个服务器端客户端是刻意不同的。后者会在 MPC 网络内部展示私有算术，但该客户端仍将成为一个受信任的数据收集者，能够看到或泄露每条基因型。 在预期的 Monadic DNA 流程中，用户会在移动应用中审查并同意一项研究。应用会仅选择该批准计算所需的 DNA 值，在手机上创建秘密共享，然后直接发送给 MPC 参与方。完整的 DNA 数据绝不应经过 Monadic DNA 的服务器或其他中心化摄入服务；只有经批准的聚合结果才能离开 MPC 计算。 ## 比较 MPC 与全同态加密 多方计算（MPC）和全同态加密（FHE）都使得在不暴露底层输入的情况下对数据进行计算成为可能，但它们使用了不同的模型。使用 FHE 时，每个用户通常使用公钥加密其基因型，然后服务器直接对密文进行计算。使用 MPC 时，每个用户将其输入分割成秘密共享，并将不同的份额发送给多个计算参与方。 这两种方法将信任和操作复杂性置于不同的位置。FHE 系统需要一个谁来解密结果的策略。这可能涉及一个密钥持有者，或者一个跨多个参与方共享的阈值密钥。MPC 不依赖单个解密密钥持有者，但它需要多个足够独立的参与方在计算过程中进行通信并保持可用。 性能特征也因工作负载和实现而异。FHE 支持非交互式加密输入和由单个服务进行的计算，尽管密文操作在计算上可能很昂贵。MPC 引入了参与方之间的通信，而简单的聚合算术（如本实验中的求和）是 MPC 的自然工作负载。这两种方法在基因组学中都没有普遍优势。适当的选择取决于计算、信任假设、部署约束和期望的交互模型。本概念验证通过 Stoffel 探索了 MPC 选项，而不是试图建立相对于 FHE 的普遍优势。 要了解更多关于使用 FHE 构建消费类应用的信息，请参见 https://vishakh.blog/2025/08/06/lessons-from-using-fhe-to-build-a-secure-consumer-app/。 2026 年 8 月，我还将在 HOPE 26 会议上就 FHE 发表演讲：https://schedule.hope.net/hope26/talks#Using-Fully-Homomorphic-Encryption-to-Build-Real-World-Software ## 技术细节 本地设置包含三种类型的组件： - 一百个本地客户端进程，代表独立的用户或移动设备。每个进程接收一个唯一、短期的身份，并仅拥有自己的六个合成 SNP 值。 - 四个 Stoffel MPC 参与方，从每个客户端接收秘密共享，并共同执行私有计算。 - 一个协调者，用于授权参与者并处理发现。它不接收基因型值，也不执行基因组计算。 协调者和四个 MPC 参与方运行在 Docker 中。客户端作为独立的本地进程在 Docker 网络外部运行，并通过暴露的本地地址连接。这证明了用户端客户端本质上不需要与 MPC 基础设施一同运行。 私有计算使用 StoffelLang 编写。标记为 `secret` 的值在程序操作过程中保持共享状态。核心聚合函数从每个用户的输入槽中读取一个私有值，并将这些值相加： 程序对所有六个 SNP 重复此操作。它只揭示群体总数，然后计算加权群体评分。它从不故意揭示单个贡献。 四个参与方使用 Stoffel 的 HoneyBadger 后端，基于 BLS12-381 标量域。用开发者的话说，HoneyBadger 是 Stoffel 用于私有算术的通用引擎。配置使用四个参与方和阈值为一，满足 HoneyBadger 的 `n >= 3t + 1` 要求，并在协议假设下容忍一个故障参与方，因此一个坏苹果不会破坏整个 MPC 节点篮子。 运行器会配置身份、编译程序、启动基础设施，并以 50 毫秒的间隔启动客户端。它会独立计算确定性合成测试数据的预期结果，检查 MPC 参与方发出的聚合结果，并记录时间和内存使用。运行结束后一切都会被拆除。 ## 发现 一百用户运行成功完成，并产生了预期值： SNP 目标等位基因 聚合计数 rs429358 C 100 rs7412 T 101 rs6265 A 99 rs1801133 T 100 rs4988235 T 101 rs12913832 G 99 加权群体评分为 `498`，与从测试数据独立计算的结果一致。 在我的开发 PC 上，基准测试测量到： - 启动和准备基础设施耗时 28.26 秒； - 启动客户端并完成 MPC 工作负载耗时 6.17 秒； - 完整运行（包括设置、验证和清理）耗时 45.29 秒； - 一百个客户端进程的峰值内存约为 1.29 GiB； - 协调者和四个 MPC 容器的峰值内存约为 62 MiB。 大部分耗时是基础设施启动，而非私有计算本身。这是一个本地概念验证，而非生产环境基准测试，但端到端运行在一分钟以内还是令人鼓舞的。 从十个客户端扩展到一百个客户端也带来了一个有用的基础设施教训。每个客户端都与协调者和所有四个参与方建立连接，创建了大约五百个客户端到服务器的连接。如果同时启动所有客户端，会导致间歇性 TLS 故障，因为客户端在等待 MPC 输入掩码。密码学计算并非瓶颈；问题在于初始的连接突发。 将客户端启动间隔仅设为 50 毫秒，将握手突发分散到大