从Multichain事件看多方计算钱包的正确管理方式

近期，某跨链协议的CEO被警方带走，导致其全球团队无法联系，且多方计算节点服务器的操作访问密钥被撤销。这一事件揭示了该协议运营异常的原因，同时也引发了一个重要问题：为何采用了多方计算技术仍面临如此风险？

答案其实很简单，该协议虽然使用了多方计算技术管理资金，但技术的去中心化并不等同于管理的去中心化。真正的去中心化需要在技术应用和管理方式上达成统一。

类似的案例并不少见。比如，比特币是去中心化的，但如果一个矿工垄断了全部算力，那么算法的去中心化就失去了意义；以太坊也是去中心化的，但其创始人仍在强调分布式验证技术的重要性，以避免中心化趋势出现。

进一步了解公告细节可以发现，该协议出现问题的根源在于所有节点服务器实际上都在CEO的个人云服务器账户下运行。这种节点服务的集中化与单一矿工垄断全部算力在本质上是相同的，相当于CEO使用单一签名钱包控制所有资产。因此，该协议的问题在于CEO不应掌控所有多方计算分片，且未提供极端情况下的备份解决方案。

那么，如何才能充分发挥多方计算技术的特性呢？主要有以下三点：

1. 提高透明度，防范利益冲突；
2. 严格遵循去中心化的保管方式，避免权力过度集中；
3. 制定应对极端情况的预案。

利益冲突防范：拒绝不透明操作

在此次事件中，某公链也受到了严重影响。该公链创始人在论坛表示，之前得到了许多关于服务器去中心化、访问和地理位置分布的保证。然而事后证明，这些保证并未兑现，而该公链方面也未能或无法验证，选择了简单信任，最终遭受连带损失。

可以看出，该跨链协议的多方计算方案实质上是一个"黑箱"。出现这种"黑箱"的原因是该协议既是服务的构建者，又是服务的使用者，这种角色的重合inevitably带来了不透明性和潜在的作恶空间。解决这个问题的方法是引入一个完全中立、不存在利益冲突的第三方主体，即使用具备足够公信力的第三方多方计算服务，而非自建服务。

利益冲突在Web3领域普遍存在，例如某些中心化交易所同时承担了提供交易服务和替用户保管资产的职能，且可以通过使用这些资金获利，如参与链上挖矿、做市或投资。

回到本次事件，如果该跨链协议使用的是具备足够公信力的第三方多方计算服务，至少在协议允许的情况下，服务提供商可以为相关方提供托管方案的信息验证，从而消除"黑箱"。

去中心化保管：避免单点风险

事后分析表明，CEO的单点风险是此次事件的直接原因。正确的做法应该是确保服务器、访问和地理位置的分布。

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

此外，由于业务通常是分层级的，因此访问权限也应该是分层级的。可以采用多级私钥派生的设计，在便于管理者控制全局的同时，也兼容一线操作人员管理特定权限，避免单点风险导致所有业务流程受阻。

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

制定极端情况下的社交恢复预案

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

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

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

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

通过这些措施，我们可以在充分利用多方计算技术优势的同时，最大程度地降低各种风险，确保资产的安全和管理的有效性。