MPC托管详解：谷歌如何守护加密密钥

区块链文库报道：

MPC 托管详解：为何 Google 正式加入这场竞赛

当单个秘密数字能够保护十亿美元加密资产时，对银行而言，这便是一个噩梦般的场景。用一句话解释 MPC 托管：它是一种守护加密货币的方式，确保完整的私钥从不集中存储在单一位置。2026 年 10 月 28 日，Google 在其于纽约举办的首届数字资产研讨会上预览了一项基于此理念的服务。

该产品名为“Google Multi-Party Compute”（多方计算）。目前已有几家金融机构在私下进行测试，但 Google 并未披露具体名称。Google 计划于 2027 年初进行商业发布，且尚未公布定价策略。

本指南涵盖了该技术的工作原理及其与旧有方案的对比，并在最后列出了向任何服务提供商提问的关键问题。

MPC 托管为银行和基金解决了什么问题？

每个加密钱包都依赖于私钥。这是一串长秘密数字，用于证明所有权并允许转移代币。持有者即控制资金。

这导致了单点故障风险。如果密钥泄露，窃贼可在几分钟内清空账户；如果密钥丢失，资金将永久无法找回。区块链交易不可逆转。

早期的解决方案虽有所帮助，但存在局限。硬件钱包将密钥保存在一个离线设备中，比笔记本电脑更安全。然而，单一设备意味着存在丢失、被盗或被强迫解锁的风险。

银行需要更多保障。它们需要多人批准大额转账，就像传统电汇一样。它们需要支出限额以及清晰的审批记录。单一的密钥无法执行这些控制措施。

多方计算（MPC）正是为填补这一空白而设计的。它是密码学的一个分支，多个参与方共同完成一项结果，而无需向彼此透露各自的私有部分。

这就是每个 MPC 钱包背后的理念，也是正确理解 MPC 托管的起点。这也是银行首先关注该技术的原因。

MPC 托管是如何工作的？简化版阈值签名

最容易理解 MPC 托管的方式是类比厨房场景。想象三位厨师守护着一份秘密食谱。每位厨师只知道其中一种原料。他们在帘子后面烹饪，最终菜肴完美呈现，但没有一位厨师知道完整的食谱。

MPC 托管的工作方式与此类似。“食谱”即私钥，“原料”即密钥分片（key shares），是存储在不同位置的少量秘密数据片段。“成品”则是有效的签名，即批准交易的证明。

MPC 托管的基本流程如下：

• 设置阶段：各方运行联合仪式以创建密钥分片。完整的密钥从未被构建出来。
• 请求阶段：有人提议进行转账。
• 签名阶段：足够的密钥分片协同工作以生成一个签名。
• 广播阶段：区块链看到一个普通签名，无法分辨这是由群体生成的。

阈值签名规定了必须有多少分片达成一致。它表示为“k-of-n”。在 2-of-3 设置中，三个分片中的任意两个即可签名。丢失一个分片不会导致锁定，而单独窃取一个分片无法转移资金。

5-of-7 设置要求从七个分片中获得五个批准，适合拥有严格控制的大型团队。Google 表示其预览版支持这两种模式。

这是最简化的 MPC 托管解释：多只手协作，没有单一的主密钥。

接下来是“门禁守卫”，这部分感觉最像正常的银行控制机制。在签名开始之前，策略引擎会根据书面规则检查转账。Google 表示，这运行在“Confidential Space”内部，这是一个硬件隔离的计算环境，可在数据使用时提供保护。

示例规则包括支出限额、批准的目的地列表以及多个部门的签批。Google 的文档还描述了针对比特币的金额、地址类型和找零输出的检查。找零输出是指发送回发送者的剩余硬币。

同一文档指出，该设计基于 DKLS23 阈值签名协议。它还指出，突破少于阈值的参与方无法伪造签名。目前可将其视为供应商声明，因为我们尚未找到该服务的公开独立审计报告。

MPC 与多重签名及冷存储对比：哪种托管模型更合适？

MPC 托管与其竞争对手的比较始于三种主导机构托管技术的模型，它们以不同的方式解决相同的问题。

模型	密钥存放位置	批准方	主要弱点
冷存储	离线设备上的完整密钥	通常为单一持有者	丢失、被盗或操作员受骗
多重签名 (Multisig)	链上规则设置的多个完整密钥	固定数量的签名者	设置僵化，变更需在链上进行
MPC 托管	单一密钥的分片，无完整密钥	分片持有者的阈值	取决于代码质量和分片安全性

多重签名将批准规则直接置于区块链本身。每个签名者持有完整的密钥，任何人都可以验证规则。这种公开的审计轨迹是其最大的优势。

代价是僵化性。更改签名者通常需要在链上进行变更。每条链也有自己的多重签名格式。

MPC 将规则保留在链下。网络看到的只是一个普通签名。提供商称，他们可以在不更改钱包地址的情况下添加签名者或刷新分片。代价是信任，因为你依赖的是无法在链上检查的密码学。

冷存储和 MPC 并非严格的竞争对手。冷存储意味着将密钥保持离线。一些提供商称，气隙隔离设备可以持有一个 MPC 分片。因此，你可以结合这两种思路。

那么，MPC 钱包与硬件钱包相比如何？硬件钱包保护一个完整的密钥，而 MPC 钱包完全避免了完整密钥的存在。因此，MPC 托管与硬件钱包的区别在于“一个完整密钥”与“无完整密钥”的选择。正确的选择取决于团队规模、转账量和风险偏好。

为何 Google 选择 MPC 用于机构托管技术

Google 已经提供 Cloud KMS 和 Cloud HSM 服务，用于存储和保护密钥。HSM（硬件安全模块）是为密钥存储设计的防篡改硬件盒子。新服务在一个包中添加了 MPC 签名、交易策略和密钥恢复功能。

这不是 Google 在此领域的第一步。2023 年，Google 发布了在 Confidential Space 上构建 MPC 签名的指南。当时银行必须自行组装各个组件。此次预览将该蓝图转变为托管产品。简而言之，这是作为服务的 MPC 托管，而非 DIY 套件。

其卖点在于控制权。银行可以将一个分片保留在自己的硬件上，第二个分片放在 Google Cloud，第三个分片放在另一个云提供商处。Google 表示，它无法以任何明文形式读取任何分片。没有任何单一云服务商或员工能持有足以签名的份额。

那么，为何机构使用 MPC？主要有三个原因：

• 审批流程：多个团队必须达成一致，正如传统金融领域一样。
• 速度：签名在链下协调进行，因此没有额外的链上批准步骤。
• 灵活性：根据提供商的说法，签名者可以更改，而无需将资金转移到新地址。

专业托管公司已经销售 MPC 多年。从市场角度看，MPC 托管意味着 Google 是后来者，而非先行者。其优势在于云规模效应，而银行是否更青睐它而非专业机构尚未经证实。

Google 还表示，其母公司已为其自身的数字资产使用该服务，但未说明具体涉及哪些资产。

MPC 托管详解：无人 advertised 的权衡取舍

MPC 托管安全吗？它是单一密钥的显著升级，但并非魔法。任何诚实的 MPC 托管指南都必须涵盖以下风险：

• 证据薄弱：Google 声称快速签名和密钥恢复，但伴随声明的并无独立基准测试。
• 实现至关重要：安全性取决于协议代码以及每个分片的存放位置。构建不良的系统可能比管理良好的单一密钥更弱。
• 阈值攻击：如果攻击者或内部人员获取足够多的分片，他们即可签名。2-of-3 设置的门槛低于 5-of-7。
• 恢复的双刃剑：丢失过多分片会导致资金被困。同时，备份也创造了新的目标。
• 云服务信任：跨云分散分片有帮助，但云账户和管理权限仍需严格控制。
• 量子风险：Google 计划支持的签名类型（ECDSA 和 Ed25519）预计在未来量子计算机面前会减弱。Google 提到了升级路径，但未设定公开发布日期。
• 预览状态：该服务仅在 2027 年初前仅限邀请制，且定价未知。

这些因素并未扼杀该理念。这是 MPC 托管诚实的一面：它们仅表明，精美的公告并不等于证明。托管设置的安全性仅取决于其最薄弱的分片。

结论：向任何托管提供商提出的五个问题

Google 的预览显示，MPC 托管正从利基工具转变为银行级基础设施。设计思路清晰：拆分密钥、设定阈值，并根据规则检查每笔转账。审计结果、实际速度和定价仍未知。

这足以让我们评判任何推销方案。在信任提供商之前，请提出以下五个问题：

1. 每个密钥分片存放在哪里，谁控制该环境？
2. 签名阈值是多少，如果分片丢失会发生什么？
3. 是否有独立公司对协议进行了审计，你能阅读报告吗？
4. 谁能更改策略规则，变更是否有日志记录？
5. 后量子升级的计划是什么？