作者：新火科技資深研究員Loki
一、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模式】緊急轉移資產後設置鎖定期，期間不能進一步轉移，以免發生資產流失。
鄭重聲明：本文版權歸原作者所有，轉載文章僅為傳播信息之目的，不構成任何投資建議，如有侵權行為，請第一時間聯絡我們修改或刪除，多謝。