MPC(マルチパーティ計算)ウォレットは、過去3年間で、取引所、機関投資家向けカストディアン、企業の財務部門において、標準的な鍵インフラとして定着してきました。 しかし、機関がMPC上で数十億規模の資産を保管するようになると、課題は「署名できるか」から、「シェアが漏洩したり、リージョンがダウンしたり、ノードが侵害されたりした場合、業務を中断することなくどのように鍵をローテーションし、災害復旧を完了させるか」へと移行します。 SoonTechのMPCウォレットにおける鍵のローテーションおよび災害復旧機能は、予防的なシェアの更新、リージョン横断的な再署名、鍵の復旧、監査証跡、および機関向けSLAを網羅しており、ホワイトラベル取引所、機関向けカストディアン、および企業の財務部門にとって、製品レベルでの基準となるソリューションです。

3つの世代:
1. 第1世代(2019年~2022年) — t-of-nしきい値署名。主に単一障害点を排除するために使用された。
2. 第2世代(2022年~2024年) — シェアの更新、ポリシーエンジン、監査証跡 — MPCがカストディの標準となる。
3. 第3世代(2024年~現在) — 地域間、クラウド間、機関を跨ぐ鍵耐障害性システム。
SoonTechのホワイトラベル導入事例全体を通じて、機関系カストディアンが重視しているのは「対応資産の増加」ではなく、「情報漏洩、地域的なサービス停止、規制当局の命令が発生した場合における鍵の復旧およびローテーションに関するSLA」です。
繰り返し指摘される課題:
・シェアの更新が持続不可能 — 手動による更新ワークフローは複雑であり、機関は定期的なSLAを遵守できない。
・リージョン間での再署名処理が機能しない — リージョンの障害発生時に1分未満でのフェイルオーバーが実現できない。
・不透明な鍵の復旧 — カストディアンは24時間以内の復旧を求めているが、確約可能なワークフローが存在しない。
・監査証跡の断片化 — シェアノード間のログが、一貫性のある監査証跡チェーンを形成しない。
・コンプライアンスとの連携がない — 規制当局による凍結命令がMPCのアクションに反映されない。
最近のカストディオンオンボーディングに関する対話から:
側面 機関投資家の重点事項 プラットフォームの機能 シェアの更新頻度 | 定期的 + SLA | 自動更新+設定可能な更新頻度 |
リージョン横断的な再署名 | 1分未満のフェイルオーバー | マルチリージョンノード + ハートビート |
キーの復旧 | 復旧時間と説明責任 | 24時間SLA+プレイブック |
監査証跡 | エンドツーエンドの監査チェーン | 統合イベントストリーム |
コンプライアンス | 凍結/転送ルール | ポリシーエンジン+コンプライアンスルール |
SLA | 定量的なコミットメント | 更新/署名/復旧3段階SLA |
機関向けMPCは、シェア数ではなく、主要なレジリエンスSLAにおいて競争力を発揮します。
匿名化されたシナリオ:ある機関向けカストディアンが、4つのリージョン(SG、TY、FR、SP)に9ノード中5ノードのMPCノードを展開し、「シンガポール全域停止」を想定した演習を実施する:
・ステップ1:SGがダウン。30秒以内にハートビートによる検知が行われる。
・ステップ2:署名プロトコルが残りの6つの正常なノードに自動切り替え;「9ノード中5ノード」の閾値は依然として満たされている。
・ステップ3:クライアントからの署名要求は中断されることなく継続される。
・ステップ4:復旧時、シェアの更新によりSGリージョンのシェアが再構築される。
・ステップ5:完全な監査イベントストリームがクライアントレポートに記録され、SLA補償が自動的に適用される。
SoonTech MPCでは、この一連の処理が5分以内に完了し、クライアントの業務に一切の影響を与えません。
MPCの鍵の回復力とは、「シェアの数を増やす」ことではなく、フェイルオーバー、シェアの更新、鍵の復旧、および監査証跡を、コミット可能、リハーサル可能、かつ照合可能にすることです。
6つのモジュール:
・毎日/毎週/毎月の周期。
・リフレッシュ中も署名処理は中断されません。
・更新イベントは監査ストリームに記録される。
・マルチリージョンの署名ノード(3~4リージョンを推奨)。
・ハートビート機能および自動フェイルオーバー。
・クラウド/オンプレミス/HSMノードの混在構成。
・24時間以内の復旧を保証するSLA。
・実行可能なプレイブック。
・3層の復旧体制:ソーシャル・ハードウェアキー・コンプライアンス。
・統合イベントストリーム(署名/更新/復旧/凍結/転送)。
・改ざん防止ログ。
・SIEMとの連携。
・ポリシーエンジンが凍結/移転に対応。
・現地の規制当局による凍結命令と連携します。
・各ポリシーのトリガーごとにイベントが記録される。
・更新頻度に関するSLA(例:毎月)を共有します。
・署名可用性SLA(例:99.99%)。
・鍵復旧SLA(例:24時間)。
1. 共有レイアウトを策定する — 少なくとも3つのリージョン、5-of-9またはそれ以上の保守的な閾値を設定する。
2. コンプライアンス要件に沿って更新頻度を定義する。
3. 四半期ごとにリージョン横断的な再署名演習を実施する。
4. 鍵復旧手順書を公開する — 誰が、どのような条件下で実行できるかを明記する。
5. 断片化を防ぐため、統一された監査イベントストリームを送信する。
6. 3段階のSLA(更新、署名、復旧)を確立する。
・署名処理を中断することなく、定期的にリソースを更新できること。
・3リージョン以上の署名ノードの展開。
・24時間以内の鍵復旧SLA。
・SIEMと連携した統合監査イベントストリーム。
・コンプライアンス・ポリシー・エンジンおよび現地規制への統合実績。
・実稼働中の機関向けカストディ事例が少なくとも1件あること。
2026年~2028年:
1. クラウドとしてのキーレジリエンス — MPCがSLAベースのクラウド製品となる。
2. 機関間署名 — 複数機関による共同署名が一般的となり、SoonTechはマルチパーティ・ガバナンスをサポートする。
3. コンプライアンス方針の標準化 — 凍結/移転/承認に関する標準的な表現が、管轄区域をまたいで統一される。
MPCウォレットは、「署名ツール」から、機関、コンプライアンス、監査向けのキー・レジリエンス製品へと進化する。
Q1: なぜ定期的にシェアの更新が必要なのですか?
A1: 定期的なリフレッシュを行うことで、漏洩したシェアであっても次のリフレッシュ後は使用不能となり、攻撃対象領域を事実上リセットできます。これは、機関向けカストディにおけるデフォルトの要件です。
Q2: リージョン間の再署名は、署名のレイテンシに影響しますか?
A2: SoonTech MPCは非同期署名プロトコルを採用しています。リージョン間の遅延による影響は300ms以内に収まっており、取引所の署名処理には十分な性能です。極めて低い遅延が求められるユースケースでは、ノードを単一のリージョンに固定することも可能です。
Q3: 鍵の復旧は、内部者リスクをどのように回避していますか?
A3: SoonTechは、ソーシャル(多者間)、ハードウェア(クライアント保有)、コンプライアンス(第三者監査)の3層による復旧を採用しています。いずれかの層が欠けていると、復旧はブロックされます。
Q4:監査イベントストリームをSIEMに取り込むことはできますか?
A4: はい。SoonTechは、主要なSIEMと互換性のあるSyslog、Kafka、Webhookによるアウトバウンドフローを提供しています。
Q5: 規制当局による凍結命令は、MPCとどのように連携しますか?
A5: ポリシーエンジンにより、特定のアドレスや資産を凍結できます。凍結期間中の署名リクエストは拒否され、コンプライアンス監査のためにログに記録されます。
MPCウォレットの次の競争は、鍵の耐障害性に関するSLAを巡って繰り広げられます。 SoonTechの鍵ローテーションおよび災害復旧機能により、シェアの更新、リージョン間の再署名、鍵の復旧、監査証跡、コンプライアンス連携が、確実に実行可能で、リハーサルが可能、かつ照合可能な製品へと進化します。これにより、ホワイトラベル取引所、機関向けカストディアン、企業の財務部門が、次なる機関投資家向け市場の波において信頼を獲得できるよう支援します。
🌐 SoonTechで、安全かつスケーラブルなWeb3プラットフォームを構築しましょう。
ホワイトラベル暗号資産取引所、予測市場、MPCウォレット、マッチングエンジン、流動性統合、コンプライアンス向けのソリューションをご覧ください。