Safeheron合伙人回应Vitalik评MPC：MPC与智能约钱包并非竞争关系

原文作者：Kane Wang, Safeheron 合伙人 & 技术 VP

近期，以太坊创始人 Vitalik 表达对 MPC 钱包和智能合约钱包优缺点的观点，如下图：

Vitalik 认为基于 MPC 的 EOA 钱包存在根本的缺陷，因为无法撤销密钥，即使重新分片（re-sharing）也无法解决这个问题，重新分片之后老的分片持有者依然可以恢复私钥，因此智能合约钱包是唯一的选择。

这也引得社区对 MPC 钱包和智能合约钱包再次激烈讨论。截止发文前，一些朋友也已询问我对于 Vitalik 的 MPC 负面评价的看法。个人而言，这个问题的讨论最终演变成了立场讨论，不统一应用场景和业务场景前提的讨论都没有对错之分。

与其走向剑拔弩张，不如先理清此次争论点：Vitalik 指出的 revoke keys 究竟是什么，适用于什么场景？ MPC 钱包 的私钥分片管理机制与 智能合约钱包 的私钥管理机制又有何不同呢？

（1）何为撤销私钥（revoke keys）操作

举个例子，在使用智能合约钱包时，假设钱包地址为 Address 1 ，用户 A 使用私钥 SK_A，用户 B 使用 SK_B 管理该智能合约钱包，使用钱包转账时需要用户 A 和用户 B 同时授权。

如果用户想要更换钱包的管理权限，比如原本是用户 A、B 管理该钱包，现在想要保持钱包地址不变的前提下，更换为用户 C、 D 管理该钱包，并且撤销用户 A 和 B 的管理权限。通过智能合约可以实现撤销用户 A 和 B 对应私钥 SK_A、SK_B 对钱包的管理权限，修改对应的管理权限为用户 C 和 D 使用的私钥 SK_C 和 SK_D 。

私钥 SK_A 和 SK_B 本身作为私钥依然可以签名，不可以被撤销， 而是通过智能合约的可编程特性，把验证转账权限的方式从验证私钥 SK_A 和 SK_B 更改为了验证 SK_C 和 SK_D。 从使用钱包的角度看，我们可以认为私钥 SK_A 和 SK_B 管理合约钱包的权限被撤销了。

（2）何为 MPC 的私钥分片重新分片和私钥分片刷新

安全多方计算（ Secure Multi-Party Computation，MPC/SMPC） 是一类链下的密码学技术，与具体的某个区块链无关， 在签名算法层面 MPC 协议可以做到 t/n 多签。通过多方计算的方式，在私钥生成、使用、刷新、重新分片等过程，保证密钥的可用但不可见。所以 MPC 可以直接管理 EOA，也可以结合智能合约钱包管理资产。

通俗来讲，通过 MPC 管理钱包时，需要先分布式生成私钥分片，比如 2/2 双方各自生成私钥分片 KeyShare_A、KeyShare_B，对应的钱包地址 Address 2 。

转账时使用进行分布式签名，使用 KeyShare_A 和 KeyShare_B 执行签名协议，授权钱包转账。

私钥分片刷新指在保持钱包地址 Address 2 不变的情况下，这一组私钥分片 KeyShare_A 和 KeyShare_B 经过分布式刷新协议后，持有私钥分片的双方各自可以分别得到新的一组私钥分片 KeyShare_A’ 和 KeyShare_B’ ，后续可以使用 KeyShare_A’ 和 KeyShare_B’ 授权钱包转账。但是 KeyShare_A 和 KeyShare_B 依然也可以使用。

私钥分片重新分片（re-shareing）类似刷新，与刷新不同的地方在于，重新分片可以修改门限，比如 2/2 对应的一组私钥分片 KeyShare_A 和 KeyShare_B 执行重新分片协议后，门限修改为了 3/3 ，双方和新参与的一方分别得到了一组新的私钥分片 KeyShare_A’ 、 KeyShare_B’  和 KeyShare_C’，对于新的一组私钥分片必须三个私钥分片一起执行分布式签名协议才可以进行签名。但是 KeyShare_A 和 KeyShare_B 依然也可以按照 2/2 门限使用。

值得一提的是，上面四个过程中，背后原始的私钥只在数学意义上存在，在所有的过程中实际没有出现过，各方也无法得到其他参与方的私钥分片。

（3）MPC 钱包在什么场景下无法撤销密钥

首先需要澄清 MPC 密码学协议和 MPC 钱包是两个概念，MPC 钱包通过设计密钥分片分布和门限管理机制 + MPC 密码学协议构建钱包。而智能合约钱包则可以理解为使用可编程智能合约设计私钥管理机制 + 签名算法构建钱包。并且，智能合约使用的签名算法可以是单私钥的签名算法，也可以是基于 MPC 的门限签名算法。

针对 MPC-TSS 协议，由于密码学的特性，如第二个问题中解释重新分片和刷新问题，重新分片和刷新后，原有的私钥分片 KeyShare_A 和 KeyShare_B 依然可用，在 MPC 协议层面， 每一组私钥分片是无法撤销的 ；这和第一个问题中智能合约钱包验证方式从私钥 SK_A 和 SK_B 切换到私钥 SK_C 和 SK_D 之后类似， 密码学层面私钥 SK_A 和 SK_B 依然可用，无法被撤销。

那么什么情况下 MPC 钱包无法撤销密钥？比如，MPC 钱包设计的门限是 2/2 ，管理方式是用户 A 和用户 B 管理，分别持有 KeyShare_A 和 KeyShare_B。 如果要变更这个钱包的管理权限，通过 MPC 刷新/重新分片协议，用户 C 和用户 D 得到  KeyShare_A’ 和 KeyShare_B’ 。虽然进行了刷新和重新分片，用户 C 和用户 D 可以管理钱包， 但是从使用钱包的角度来看，用户 A 和用户 B 作为曾经的分片持有人，依然可以管理钱包，也就是说，这种 MPC 钱包是无法撤销密钥的。

（4）MPC 钱包在什么场景下可以撤销密钥

以个人级钱包 Zengo 为例，底层的签名门限为 2/2 ，用户自己持有私钥分片 KeyShare_A，Zengo 持有私钥分片 KeyShare_B。如果客户怀疑自己的私钥分片 KeyShare_A 被窃取了，理论上讲，在保持钱包地址不变的前提下，用户可以请求和 Zengo 进行一次密钥刷新，双方各自得到 KeyShare_A’ 和 KeyShare_B’ ，刷新成功后 Zengo 物理删除 KeyShare_B 以及拒绝使用 KeyShare_B 继续参与后续签名，只使用 KeyShare_B’，用户使用 KeyShare_A’。 从使用钱包的角度看，由于 KeyShare_A 无法和 KeyShare_B’ 无法计算出正确的签名，所以此时攻击者窃取的 KeyShare_A 已经被撤销。

以企业级钱包 Safeheron 为例，底层的签名门限为 3/3 ，成员 1 参与签名时，私钥分片的分布为成员本地的手机设备中的 KeyShare_A、Safeheron 云端在可信计算环境中的 KeyShare_B、可信第三方云端在可信计算环境中的 KeyShare_C。当成员 1 怀疑自己的私钥分片 KeyShare_A 被窃取了，在保持钱包地址不变的前提下，成员 1 可以请求与云端进行一次密钥刷新，类似 Zengo 场景，刷新成功后三方各自得到新的私钥分片 KeyShare_A’、KeyShare_B’ 和 KeyShare_C’，云端可信执行环境中物理删除 KeyShare_B 和 KeyShare_C， 此时从使用钱包的角度看 KeyShare_A 就被撤销了。

如果企业在管理过程中，需要将成员 1 更换为成员 2 来共同管理资产，此时云端可信执行环境会删除成员 1 对应的两个私钥分片 KeyShare_B 和 KeyShare_C ，添加成员 2 后团队创建者为成员 2 激活一组新的私钥分片  KeyShare_A 2、KeyShare_B 2 和 KeyShare_C 2 ，成员 2 的私钥分布方式和成员 1 相同。 此时从使用钱包的角度看撤销了成员 1 的 KeyShare_A，新增了成员 2 使用 KeyShare_A 2 参与团队资产管理。

总结

理清此次讨论的争议点后，我们再来理解 Vitalik 的回答就相对容易。个人认为 在上述第三个问题举的场景中，Vitalik 的观点是没有问题的，但是 Vitalik 的回答以偏概全。 就回答本身而言，并非所有 MPC 钱包在使用时都不可以撤销密钥，各种 MPC 钱包方案也有所差异。MPC 钱包与智能合约钱包解决问题的侧重点也不相同，MPC 钱包更偏向于解决多链通用多签的资产安全管理问题。

而且， MPC 钱包和智能合约钱包并非对立关系，通过结合链下 MPC 和链上智能合约钱包优势，相信在未来可以看到许多有创新性的 MPC + 智能合约产品和解决方案。