一、【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 模式】紧急转移资产后设置锁定期，期间不能进一步转移，以免发生资产流失。