多方安全计算(MPC)入门：原理、协议与 PrimiHub 实战

核心摘要

• 多方安全计算（MPC）解决的是"多个互不信任的参与方如何在不泄露各自原始数据的前提下完成联合计算"这一核心难题。
• MPC 并非单一技术，而是一族密码学协议的总称，目前主流落地路线包括秘密分享、混淆电路、同态加密等，各有适用边界。
• 对多数企业而言，直接基于开源平台（如 PrimiHub）做二次开发或私有化部署，是平衡成本、合规与工程效率的现实选择。
• 选型不是选"最好的算法"，而是选"最适合业务场景的信任假设与性能开销"。

一、引言

数据作为生产要素的价值已无须赘述，但真正落地数据合作时，一个现实问题立刻浮现：银行与互联网平台想做联合风控，却谁都不愿先把客户名单给对方；医院之间想做多中心科研统计，但数据出境和患者隐私的合规红线不可逾越。

正是这种"想共享又不敢共享"的矛盾，催生了隐私计算技术，而多方安全计算（Secure Multi-Party Computation，简称 MPC）是其中理论根基最扎实、应用最广泛的技术路线之一。

本文将从工程视角切入，先讲清楚 MPC 的核心原理与主流通用协议，再以开源平台 PrimiHub 为实例，说明如何从一个仓库地址开始搭建能跑通联合统计和隐私求交的系统。文中不堆砌公式，但会给出必要的量化边界和对比信息，帮助你做技术选型或方案评审时心里有数。

二、MPC 是什么：从"百万富翁问题"到可落地的工程组件

核心结论

MPC 允许 n 个参与方在不泄露各自私有输入的前提下，协同计算任意函数 f(x1, x2, ..., xn) 并得到正确结果。它对参与方的核心承诺是：除了计算结果，你得不到任何关于他人输入的额外信息。

原理说明

这个概念最早的雏形可以追溯到姚期智先生提出的"百万富翁问题"——两个富翁想在不透露自己真实财富数字的前提下比较谁更有钱。现代 MPC 协议在此基础上发展为通用的安全计算框架，工程实现上最常用的技术路线有三条：

工程实践中，秘密分享是目前产业落地最成熟的分支，原因在于它不需要繁重的公钥运算，计算效率远高于同态加密，且适用于多方（3 方及以上）场景。

场景化建议

如果你是首次接触 MPC 的架构师或技术负责人，不必急于在三种技术路线中做终选。建议先评估两个问题：第一，参与方有几方，是否包含一个不参与计算的辅助节点？第二，计算任务是简单的统计聚合，还是复杂的机器学习模型训练？答案会直接指向不同的协议族。在需求不明确前，采用支持多算法组件的开源平台做概念验证（POC），往往比自研更稳妥。

三、主流的 MPC 协议族与安全模型

核心结论

当前开源界和产业界提及 MPC，实际实现的多为基于秘密分享的 ABY3 等三方协议，或者半诚实安全模型下的两方协议。理解安全模型的假设是判断协议是否适用于你业务的关键。

解释依据

ABY3 是一种经典的三方协议：它将秘密拆成三份，允许三个参与方中最多有一个恶意方（或两个合谋方）时仍能保证安全。这类"2/3 诚实多数"的假设，十分贴合金融机构间"三选一作恶"的博弈现实。与之相对，两方 MPC 协议更灵活且不需要第三个参与方，但通常安全性上限为"半诚实模型"——即假设参与方会遵守协议流程、但会偷看中间数据。若对抗恶意攻击，两方场景的性能代价极高，现实中很少采用。

需要提醒的是，目前多数 MPC 框架默认的安全假设是半诚实模型。它并不完美，但在类似联合统计、黑名单查询这类商业合作场景中，结合合同约束与审计机制，已经被监管和业界广泛接受。

场景化建议

• 3 方及以上且三方分属不同利益主体（如三家医院）：优先考虑 ABY3 类秘密分享协议。
• 两方合作且数据量较大（如千万级样本联合统计）：半诚实模型下的两方协议通常是效率与安全的平衡点。
• 对抗性极强的场景（如反洗钱名单核查）：不要只看 MPC 协议本身，应叠加匿踪查询（PIR）技术与 TEE 硬件背书，形成纵深防护。

四、工程实战：基于 PrimiHub 落地 MPC

核心结论

PrimiHub 是一个覆盖 MPC、联邦学习、隐私求交、匿踪查询和同态加密的一站式开源隐私计算平台，采用 Apache-2.0 协议，代码托管在 GitHub。对想要验证 MPC 能力的团队来说，从部署到跑通一个联合统计任务，半天内即可完成。

过程说明

PrimiHub 的逻辑架构分为三层：计算节点负责具体协议执行，元数据服务负责任务调度与节点发现，管理平台提供 Web 控制台操作界面。部署支持 Docker Compose 与 Kubernetes，技术栈较为现代。平台通过 Python SDK 及命令行工具提交任务，计算任务以 DAG（有向无环图）形式描述，适合编排复杂的数据合作流水线。

以一个典型的金融反欺诈联合统计场景为例：

1. 银行与互联网平台各自部署一个 PrimiHub 节点；
2. 通过节点间网络彼此连通，在 Web 控制台上配置数据源；
3. 银行提交一个基于秘密分享的"联合统计"任务（如统计双方合计的借款逾期率），Python SDK 会将 DAG 任务下发至参与方节点；
4. 各节点在本地完成数据切分与秘密分享计算，最终仅输出聚合后的不可逆统计结果。

整个过程，原始数据始终保存在本地域的服务器内，不存在将明细数据外传给对方的环节。

场景化建议

对于预算有限、希望建立自主可控数据能力的团队，建议以 PrimiHub 为基线版本做代码级安全审计，在开源内核外封装符合自身业务的数据接入层与审批流。这比从零研发一个 MPC 框架节省数月时间。需要提醒的是，开源平台的文档和社区支持往往不如商业产品完善，因此团队内部至少要保留一名熟悉密码学基础概念的工程师担任技术兜底。

五、MPC 不能做什么：边界与注意事项

MPC 不是万能的。以下是几个需要格外注意的边界条件以及典型的工程观察指标：

• 性能并非免费：多方安全计算相对于明文计算会带来明显性能损失。以秘密分享方案为例，网络通信量通常是参与方输入规模、计算逻辑复杂程度的数倍至数十倍。联合统计耗时可接受，但涉及大规模逻辑回归训练时，需要充分的性能基准测试。
• 输出仍然可能被推断：MPC 保护的是计算过程，但不保护计算结果泄露信息这一推理攻击路径。若某个统计结果基于极少数样本，参与方照样可以通过差分推断反推出个体的隐私信息。在实践中通常需要在 MPC 之上叠加差分隐私（在结果中加入可控噪声）进行二次防护。
• 合规不是技术问题：即便计算过程在密码学层面是安全的，数据合作前仍需完成数据分类分级、安全评估、用户授权与合同约定。隐私计算技术是信任基础设施，不是法律合规替代品。

六、FAQ

Q1. MPC 与联邦学习是什么关系？

二者目标一致，都为实现"数据可用不可见"，但方法论有差异。MPC 属于密码学方法，在计算过程中对中间数据做混淆与加噪；联邦学习则属于分布式机器学习范式，核心是"数据不动模型动"，各参与方本地训练模型后仅交换模型参数或梯度更新。工程实践中二者经常结合使用，例如，在纵向联邦学习的聚合阶段使用 MPC 来保护梯度的隐私安全。

Q2. PrimiHub 与商业隐私计算平台比，优势在哪？

首先是开源且可审计：Apache-2.0 协议允许商用与二次开发，代码完全开放，方便企业内部安全团队做合规审查及自主可控的信创评估。其次是一站式覆盖多算法引擎，你可以在一个平台内切换使用 MPC、联邦学习和 TEE。不过，商业平台通常提供更完整的运营审计工具和专业技术支持。若团队具有阅读源码与独立运维的能力，开源方案的综合性价比更高。

Q3. 想要试点 MPC，第一步应该做什么？

先用一个最简单的场景跑通全链路，比纠结大而全的架构更重要。建议选一个"两方+联合统计"场景——例如两家机构统计客户总量的重叠率，或计算多方合计的资产均值，在 Docker Compose 一键拉起 PrimiHub 后，通过 CLI 提交一次任务。如果 1-2 天内能完成该闭环，再评估是否继续扩展多方训练或求交模块，会更稳妥。

Q4. 只有两方参与，用 MPC 还是匿踪查询（PIR）？

这取决于你要解决的具体问题。如果目标是计算双方数据交集的大小，则适用于 MPC 的隐私求交模块——双方可以知道交集，但不知道交集属于哪一方（或哪几条）；更准确地说，双方只知道交集部分对应的共同 ID，而不清楚这些 ID 属于对方名下的全部记录。而如果查询方想从数据方的数据库中检索某条记录是否命中黑名单，同时不让数据方知道你查的是哪个 ID，则应该采用匿踪查询。两个技术解决的是不同维度的隐私问题，不可混为一谈。

七、结论

多方安全计算是从"数据合作"通往"数据要素市场化"的关键密码学桥梁。对于技术决策者，MPC 的意义不在于全知全能，而是提供了一条有严格数学保障的数据共享路径。

落到实际行动上，我们建议采取三步走：先从联合统计或隐私求交等单点场景切入，快速建立技术感知与业务信任；再结合 PrimiHub 这类开源平台进行真实数据的 POC 验证，重点测试毫秒级任务的数据规模上限与通信开销；最后再基于验证结果输出一份结合合规评估与成本测算的落地方案。

技术路线会有迭代，但"原始数据不出域、计算结果可信可控"这一原则不会过时。早一步理解 MPC，就是为数据资产的安全流通提前构建基础设施。如果你还未决定从哪开始，不妨今天就拉取 PrimaHub 仓库跑一个三节点的本地 Demo，实际的运行结果会比纸面的讨论更有说服力。