1. MPC工程全景
隐私计算并不是单一技术，而是一组在“数据可用”与“数据不可见”之间寻找平衡的工程方法。联邦学习、可信执行环境、差分隐私与多方安全计算（MPC）常被并列讨论，但它们的信任假设和工程代价差异很大。联邦学习依赖协调方与参与方之间的协议约束，TEE依赖硬件厂商与侧信道防护，差分隐私通过噪声换取统计不可区分性，而MPC则试图在密码学层面保证：参与方除了约定的输出之外，不泄露任何额外信息。理解这一区别，是进入MPC工程的第一道门槛。
MPC的核心承诺可以概括为：多个持有私有输入的参与方，在不暴露各自输入的前提下，共同计算一个约定函数，并只得到函数输出。形式化地说，参与方 P₁,…,Pₙ 分别持有 x₁,…,xₙ，希望计算 y=f(x₁,…,xₙ)，同时满足正确性、隐私性与（在恶意模型下）可验证性。工程上，这三个性质分别对应“结果对不对”“中间看不看得见”“有人作恶能不能发现”。
工程视角下的MPC三要素：秘密分享负责把明文拆成不可读的份额；交互协议负责在份额上完成加法、乘法等运算；密码学原语（OT、同态、承诺等）负责在恶意参与方存在时仍能保证安全。三者缺一，系统要么不安全，要么不可用。
从需求到落地，MPC工程通常要跨越五类挑战。第一是安全模型选择：半诚实模型假设参与方遵守协议但会偷看中间数据，恶意模型则假设参与方可能篡改消息、伪造份额。半诚实方案性能好，恶意方案安全性高但开销常高出一个数量级。第二是参与方数量与拓扑：两方计算常用OT与混淆电路，三方及以上常用秘密分享，参与方越多，通信轮次和带宽压力越大。第三是计算任务表达：MPC原生支持加法和乘法，比较、除法、开方、查表等操作需要拆解为电路或协议组合，任务表达方式直接决定性能。第四是性能与资源：通信量、轮次、CPU、内存、网络延迟共同决定端到端时延，跨机房场景下网络往往是瓶颈。第五是工程集成：密钥管理、身份认证、任务调度、结果审计、异常恢复，这些“非密码学”问题往往决定系统能否上线。
下面这张图把MPC工程从需求到落地的关键链路、参与角色与核心挑战放在同一张关系图中，便于建立整体认知。
这张图左侧是需求与角色，中间是协议与工程引擎，右侧是落地与输出，底部是课程地图。它想传达一个关键判断：MPC工程不是“选一个协议就结束”，而是从安全目标出发，经过协议层、原语层、引擎层，最终落到服务、审计与性能指标上。任何一层缺失，系统都难以真正可用。
为了把“从需求到落地”讲清楚，本课程后续会沿着一条主线展开：先建立密码学与安全模型基础，再进入秘密分享、OT、混淆电路等核心协议；随后讨论两方与多方协议的具体实现，包括半诚实与恶意模型下的差异；接着进入工程框架，覆盖任务表达、通信调度、密钥管理、异常恢复；再讨论性能优化，包括通信压缩、批处理、并行化与硬件加速；最后通过行业案例，把金融、医疗、广告等场景中的真实约束与工程取舍讲透。
在进入具体协议之前，先建立一个可操作的判断框架。面对一个MPC需求，工程上至少要回答五个问题：参与方是谁、各自持有什么数据、要计算什么函数、能接受什么安全模型、网络与算力边界在哪里。这五个问题决定了后续协议选型、参数配置和性能预期。例如，三方半诚实场景下，基于Shamir秘密分享的协议通常比两方OT方案通信更少；而如果参与方之间互不信任且存在作恶可能，就必须引入恶意安全机制，代价是轮次和计算量显著上升。
学习建议：本课程不要求你先成为密码学专家，但要求你始终带着“安全假设—协议选择—性能代价”这条线索阅读。每学一个协议，都问自己：它假设参与方会作恶吗？它需要几轮通信？它的瓶颈在计算还是带宽？它适合什么规模的数据和什么拓扑？
最后需要明确：MPC不是万能药。它适合“多方数据不能出域、但需要联合计算”的场景，例如联合风控、隐私求交、联合统计、模型训练中的梯度聚合等。对于单方数据可以集中处理的场景，MPC带来的额外开销可能并不划算。工程判断的核心，是在隐私收益与性能成本之间找到可接受的平衡点。本课程的目标，就是帮助你建立这种判断力，并具备把MPC从论文原型推进到生产系统的工程能力。