从Multichain事件看MPC钱包的正确管理方式

一、Multichain事件背后暴露了MPC钱包管理的哪些问题？

7月14日，Multichain 发推称，其 CEO Zhaojun 于 5 月 21 日在家中被警方带走，此后与 Multichain 全球团队失去联系。团队联系了 MPC 节点运营商，得知其 MPC 节点服务器操作访问密钥已被撤销。

这则推特揭示了Multichain运营异常的原因，也带来了大家一个问题：为什么Multichain使用了MPC仍然会面临这样的风险？答案也非常简单，Multichain采用了MPC技术管理金库，但采用了去中心化技术并不等同于去中心化，而是需要在技术采用和管理方式上实现去中心化的统一。

相似的案例很多，BTC是去中心化的，但如果一个矿工垄断了100%的算力，那算法的去中心化毫无意义；ETH是去中心化的，但V神仍然在强调DVT（分布式验证技术）的重要性以避免中心化趋势出现。

对于Multichain也一样，更进一步查看公告详情我们就可以发现，Multichain出现问题的原因是所有节点服务器，实际上是在 Zhaojun 的个人云服务器账户下运行，这种节点服务器的集中和一个矿工垄断100%的算力性质上是一样的，Multichain的管理方式等同于Zhaojun使用单签钱包控制所有资产。基于这一点，Multichain的问题在于Zhaojun 【不应该】掌控所有MPC分片，且未提供极端不可抗力因素情况下的备份解决方案。

下一个问题是怎么样才能有效地发挥MPC技术的特性？主要有以下三点：

（1）提供更强的透明度以防范利益冲突；

（2）严格遵循去中心化的保管方式，避免权力的过度集中；

（3）做好极端不可抗力的应对预案。

【利益冲突防范：拒绝黑盒子】

一个需要关注的事实是在此次事件中Fantom也受到了极大的影响。FTM创始人AC在论坛表示：Multichain的失败是一个“重大的打击”，之前从团队那里得到了很多关于服务器去中心化、访问和地理位置分布的保证。事后来看，Multichain并没有做到【服务器、访问、地理位置分布的保证】，而Fantom并没有验证或者没有办法验证，选择简单地相信了Multichain，最终导致受到连带影响。

可以看出，Multichain的MPC方案本质上是一个“黑盒子”，而出现这个“黑盒子”的原因是Multichain既是服务的构建者，也是服务的使用者，这种属性的集中会带来不透明性与作恶空间。解决这个问题的方法就是引入一个完全中立、不涉及利益冲突的第三方主体，也就是使用一个具备足够公信力的第三方MPC服务代替自建的MPC服务。

除了跨链桥以外，利益冲突在Web3普遍存在，例如中心化交易所同时承担了提供交易服务和替用户保管资产的职能，同时交易所通过使用这些资金可以获益，例如链上挖矿、做市、投资。事实上这也是Sinohope构建Openloop的出发点，信任无法验证，可靠的机制是避免作恶的唯一途径。

回归到此次事件，如果Multichain使用的是具备足够公信力的第三方MPC服务，至少在Multichain允许的情况下，服务提供商至少可以为Fantom等利益相关主体提供托管方案的信息验证，消除“黑盒子”。

【去中心化保管：拒绝单点风险】

事后来看，Zhaojun的单点风险是事件的直接原因，而AC的回应也给出了我们正确的做法：【确保服务器、访问、地理位置分布的保证】。而这几条因素也正是Sinohope构建产品时遵循的法则。

首先，Sinohope采用 3-3 多方签名方案（也支持 t-n 阈值签名设置），其中2片由平台协管，通过高强度安全加密+可信执行环境确保安全，三方共同参与才能完成交易签名，避免用户的单点风险。

图：Sinohope MPC-TSS技术原理

其次，通常来说业务是分层级的，因此访问也理应是分层级的，所以Sinohope采用了多级私钥派生的设计，在便于管理者管控全局的同时也兼容一线操作人员管理特定权限，避免单点风险下全部业务流程受阻。

最后，Sinohope采用了在线异地多活分布式存储、 三级离线冷存储备份、集成专业机构备份恢复服务等方案，确保了最高级别的【地理位置分布保证】，这一系列机制可以最大程度地避免单点风险导致的资产损失或者服务不可用，包括私钥层面、人员层面和外部环境层面。

【做好极端情况下的社交恢复预案】

不可否认的是，所有方案都不是完美的，确保服务器、访问、地理位置的去中心化可以解决一部分问题，但并不是全部。我们必须承认许多风险仍然存在，例如物理世界的不可抗力因素，在无法避免的情况下，我们需要思考的是当这种极端不可抗力情况发生的时候我们应该如何应对？

基于此，Sinohope构想了针对物理世界不可抗力风险【SOS模式】。这种服务将作为非标准、可选服务向需要的用户提供，并依据实际需求进行定制化设计这种模式除了传统的私钥分片以外，还会设置若干个SOS分片，SOS分片将与普通私钥分片分开管理。

正常情况下，SOS分片无法发生任何作用。而在一些特定情况下SOS分片将被激活，例如紧急情况下私钥分片管理人/Owner使用收集手动激活、私钥分片断连达到一定时间阈值、SOS分片主动发起紧急事件、按照既定的规则治理投票通过。激活【SOS模式】后，SOS分片将代替私钥分片发挥作用，实现紧急情况下的资产转移或者资产处置。

当然，为了避免SOS分片持有人作恶，可以增加若干限制条件，例如设置【SOS模式】启动的延迟生效，普通私钥分片在这期间可以推翻【SOS模式】；或者【SOS模式】紧急转移资产后设置锁定期，期间不能进一步转移，以免发生资产流失。