Multichainの事件から見るMPCウォレットの正しい管理方法

著者：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シェアがアクティブになります。たとえば、緊急時にプライベートキーのシェア管理者/オーナーが手動でアクティブ化する、プライベートキーのシェアが一定の時間閾値に達して切断される、SOSシェアが緊急事態を自発的に発起する、既定のルールに従ってガバナンス投票が通過するなどです。【SOSモード】がアクティブ化されると、SOSシェアはプライベートキーのシェアの役割を果たし、緊急時の資産移転や資産処分を実現します。

もちろん、SOSシェアの保有者による悪用を避けるために、いくつかの制限条件を追加することができます。たとえば、【SOSモード】の起動に遅延を設定し、その間に通常のプライベートキーのシェアが【SOSモード】を覆すことができるようにすることや、【SOSモード】が資産を緊急移転した後にロック期間を設定し、その期間中はさらに移転できないようにすることで、資産の流出を防ぐことができます。