1.1 百万富翁问题：不肯亮底牌的比较

1.1 百万富翁问题：不肯亮底牌的比较

本节摘要：百万富翁问题是 MPC 的出生证明——爱丽丝和鲍伯想比较谁更有钱，却都不肯透露具体身价。本节用这道题把 MPC 的定义、输入输出约束与"安全"的直观含义一次讲清，并给出三种思路的失败原因分析。

从一道题开始

姚期智在 1982 年的论文里提出了一个看似社交礼仪问题的场景：两位百万富翁在酒会上相遇，都想知道谁更富有，但谁也不愿意报出自己的具体资产。富有程度关乎谈判地位——报了数，接下来的一切博弈都劣势尽显。奇怪的是，这道题在数学上毫无难度（比较两个数的大小是小学生都会的事），难的只有一件事：比较必须在双方都不暴露输入的前提下完成。

把这道题抽象一下，就得到了 MPC 的标准形式化定义。设 n 个参与方各自持有私有输入 x1 到 xn，他们想共同计算函数 y = f(x1, ..., xn)，并要求：每方最终得到输出 y（或约定的输出子集），而除此之外，任何一方关于其他方输入所能知道的，不多于从 y 本身能推算出来的东西。最后半句是全部精髓——"能从结果推出来的信息不算泄露"，这一点在 1.2 节还会反复用到。

为什么这道题值得一个领域为它而生？因为它把"数据合作"中最普遍的矛盾压缩到了最小的规模：参与方只要两方、函数只要一次比较。任何能解这道题的方法，稍加扩展就能处理"联合求和""联合建模""联合筛选"这些真实业务。反过来，解不了这道题，谈什么隐私 AI 都是空中楼阁。

图：百万富翁问题的三种解法对比

三种朴素思路为什么不行

直接亮底牌的问题一目了然：输出是"谁大谁小"，输入是两个具体数，亮底牌把信息量从 1 比特膨胀到了整个数值区间。有个常见的反驳是"只报个大概行不行"——报"八百万左右"同样泄露了数量级和精度范围内的信息，而且模糊输入算出来的比较结果还可能是错的。安全性和正确性在这里直接冲突。

委托可信第三方是工程上最常见的折中，也是很多"隐私计算平台"早期的实际形态。它的要害在信任模型：第三方能看到所有输入，谁来监督第三方？数据库被拖库怎么办？内部的运营人员有权限怎么办？MPC 的野心恰恰是去掉这个信任锚点——不需要任何一方被信任，安全性由数学保证。

**各种聪明的"手工技巧"**值得多说两句，因为它们直观且常被误解。一个流传很广的例子：爱丽丝准备 n 个上锁的盒子对应资产区间，鲍伯把自己的数对应的盒子戳个洞、其余销毁，爱丽丝打开后看哪个盒子漏了标记。这套方案在物理世界里尚有斟酌余地，搬到数字世界立刻破产——鲍伯总要"选中一个盒子"，服务端记录了查询行为就等于知道了答案区间。这类技巧的共同缺陷是：它们保护的是"声明"，而不是"信息流"。MPC 的严格性正在于它分析并约束每一条消息的信息含量。

定位与延伸

有了这道题，整个领域的版图可以看成对它的回答史：混淆电路（第 3 章）把比较电路整个加密后交给对方算；GMW（第 4 章）用异或门和不经意传输逐门算；SPDZ 系（第 5 章）把数字拆成随机份额在环上做算术。三条路线的安全假设、通信模式、适用场景不同，但回答的是同一道题。

常见误读：MPC 并不阻止你从"结果"里推断信息。如果两家银行算出联合风控分后，其中一家从分数反推出对方客群的大致构成，这不是协议失效——是函数选得不好。选函数（比如加噪声、只输出区间）是业务设计的一部分。

本节要点：百万富翁问题把"想算又不肯交数据"的矛盾形式化；MPC 的安全承诺永远相对于输出而言；去掉可信第三方是它区别于委托计算的本质特征。下一节把"安全"这个笼统词拆成三件可以分别工程化的事。

三个高频误问的正面回答

误问一：既然结果允许泄露，那 MPC 是不是没用？ 恰恰相反，这是它务实的地方。协议把泄露压缩到理论上限——你最多知道结果，一条多余的消息都没有。剩下的问题"结果本身该不该这么细"属于函数设计：把精确比较改成区间比较、把均值改成分档统计，泄露面立刻收紧。技术给保证，业务定边界，两件事别混着谈。

误问二：小规模数据直接人工核对不就行了？ 人工核对在小样本上可行，但"人工"不是可审计、可复现、可规模化的机制。监管问"数据谁碰过"时，MPC 给出的是密码学层面的保证，人工流程给出的是制度层面的承诺，两者在合规强度上不在一个层级。

误问三：能不能把 MPC 理解成某种加密算法？ 不能。加密是一段数学，MPC 是一套多方交互流程：它规定消息怎么发、发几轮、每方如何更新本地状态。同一个功能可以由不同协议实现，不同协议的安全档位与开销差异巨大——这正是后续章节"协议选型"问题的根源。

用一段演算收尾，体会"输出选择"的分量。两方各持一个数，约定输出均值：甲方输入 100，乙方输入分别是 90 与 110 时，甲方看到的输出是 95 与 105——从输出的变化量可以直接反推乙方的输入，因为均值、甲方输入、乙方输入三个量知道其二就能解出其三。换成输出"谁更大"，无论乙方是 90 还是 110，甲方都只看到同一句话"乙大"，乙方的输入被隐藏在结果的分辨率之下。协议一字不改，函数改一行，泄露程度天差地别。

把问题放回谈判桌

技术书籍常忽略百万富翁问题的博弈论底色，但它恰恰是理解应用的关键。两人比较财富，输的一方不仅知道了排名，还可能因此在随后的合作谈判里被压价——MPC 能藏住数字，藏不住"结果会改变行为"这个事实。这也是为什么真实业务设计协议时，要先问"结果会不会影响对方的下一步动作"：会，就要考虑结果的最小化披露（只给一方、只给区间、分批给）；不会，才谈得上放心的全量计算。

反过来看，这个底色也解释了 MPC 商业化的路径。最早付费的场景——联合风控、联合营销——都是"结果价值对称"或"结果可以单向交付"的场景，博弈上的别扭最少。理解这一点，比多记十个协议名更能帮你判断一个"隐私计算需求"是真需求还是凑热闹。

本节的思想遗产可以压成一句话：姚期智的贡献不是解了一道题，而是证明了"隐藏输入的联合计算"存在数学解。此后四十多年，整个行业做的事情不过是把这个解做得更快、更便宜、更好用。

收尾前的最后一次定位

把 1.1 的内容放进全书坐标：它是问题的"出生地"，也是全书的"回程票"——后面每一章遇到设计抉择时，都会回到"这道题到底要保护什么"来校准方向。第 3 章的电路是它的工程化身，第 5 章的 MAC 是给它加的防伪封条，第 7 章的联合风控是它的商业化身。记住题目本身，比记住任何一个解法都重要——解法会更替，题目永恒。