2. MPC协议基础

在多方安全计算（MPC）工程落地中，最常被拿来比较的四类底层协议是：秘密分享（Secret Sharing）、混淆电路（Garbled Circuit, GC）、不经意传输（Oblivious Transfer, OT）与同态加密（Homomorphic Encryption, HE）。它们并非同一层级的并列技术：OT 常作为 GC 的构造组件，秘密分享与 GC 是两种不同的计算范式，HE 则依赖密码学假设提供可计算密文。工程选型的关键，不是问“哪个最好”，而是先明确计算任务形态、参与方数量、信任模型、性能瓶颈与合规约束，再判断哪类协议能以可接受的代价完成任务。

四类协议的本质差异

秘密分享把明文拆成多份“份额”，单份不泄露信息，多方各自持有份额并协同计算。加法分享下，加法可本地完成，乘法需要交互（如 Beaver 三元组）。其优势是计算开销低、适合算术电路与统计聚合；缺点是参与方数量增加时通信轮次和带宽可能上升，且通常要求一定比例的诚实参与方。

混淆电路把函数编译成布尔电路，由一方生成混淆表，另一方（或双方）通过 OT 获取输入标签并逐门求值。GC 适合布尔逻辑、比较、集合求交等任务，且通常只需常数轮交互；但电路规模大时混淆表体积和计算量显著增长，生成方负担较重。

不经意传输是“发送方有多个消息，接收方只取其中一个，发送方不知道接收方取了哪个”的协议。它既是独立原语，也是 GC 输入阶段的必备组件。工程中常用 IKNP 类 OT 扩展，把少量基础 OT 扩展成大量 OT，以降低公钥操作成本。

同态加密允许在密文上直接做加法或乘法（视方案而定），计算方无需解密。它适合外包计算、单方加密多方计算或密文聚合场景；但密文膨胀、噪声增长、参数选择复杂，且多方协同解密需要门限化设计，工程门槛较高。

工程选型的四个判断维度

第一，任务形态。如果计算以加法、乘法、比较、聚合为主，秘密分享通常更自然；如果以布尔逻辑、位运算、集合操作为主，混淆电路更合适；如果计算方不能接触明文且需要长期密文存储，同态加密更匹配。

第二，参与方数量与信任模型。秘密分享在 3~10 方、存在诚实多数假设时表现良好；GC 与 OT 更常见于两方场景；HE 则适合“一方加密、另一方计算、多方门限解密”的架构。若参与方互不信任且数量多，秘密分享的份额分发与合谋风险需要重点评估。

第三，性能瓶颈。秘密分享的瓶颈常在通信轮次与带宽；GC 的瓶颈在混淆表体积与生成方算力；HE 的瓶颈在密文膨胀、噪声管理与自举开销；OT 的瓶颈在基础公钥操作数量。工程上应先用小规模基准测试测出单次乘法、单次比较、单次密文乘的耗时与流量，再外推到目标规模。

第四，合规与可审计性。金融、医疗场景常要求可解释的协议假设、密钥管理与审计日志。秘密分享与 GC 的协议假设相对直观；HE 的参数选择与安全性证明更复杂，需要专业密码团队参与。

一个可执行的选型对照示例

假设某联合风控场景：3 家机构各持有一批用户特征，需要计算交集用户的评分均值，参与方 3 方，允许 1 方被腐化，要求秒级返回。此时可优先考虑秘密分享：各方将特征向量做加法分享，交集判断可用秘密分享下的比较协议或结合 PSI，均值计算通过 Beaver 三元组完成乘法与求和。若交集判断的布尔逻辑非常复杂，也可采用GC + OT 做两两 PSI，再把交集结果转成秘密分享份额做后续统计。

若场景改为“银行把加密数据外包给云，云上做逻辑回归推理”，则同态加密更合适：银行用 CKKS 加密特征，云端在密文上做加法和乘法，返回密文结果，银行解密。此时需要关注乘法深度、缩放因子与噪声预算，必要时引入自举。

常见误区与排障提示

• 把 OT 当成完整计算协议：OT 只解决“选择获取”问题，不能单独完成任意函数计算，通常要与 GC 或秘密分享组合。
• 忽略输入阶段成本：GC 的输入标签获取依赖 OT，若 OT 扩展实现不当，输入阶段可能成为瓶颈。
• 低估 HE 的密文膨胀：CKKS 密文通常是明文的上百倍，网络传输和存储需要提前规划。
• 秘密分享乘法未预生成三元组：在线阶段若临时生成 Beaver 三元组，会引入额外交互，建议离线预生成并缓存。

综上，四类协议各有明确的适用边界：秘密分享适合多方算术统计，混淆电路适合两方布尔逻辑，不经意传输是输入与 PSI 的关键组件，同态加密适合外包密文计算。工程选型的正确姿势，是先锁定任务形态与信任模型，再用带宽、轮次、算力、合规四项指标做量化对比，最后通过最小可行原型验证，而不是凭直觉选择“最安全”或“最快”的单一协议。