Humanity Protocol事件で、攻撃者が入手したのは秘密鍵そのものだったのか、それともマルチシグ検証を回避する何らかの脆弱性だったのか？この違いは重要なのか？
この違いは極めて重要だ。事後に公開された詳細によれば、攻撃者が入手したのは完全かつ本物の秘密鍵そのものだった——暗号学的な脆弱性を通じてでも、マルチシグコントラクトの検証ロジックを回避したのでもなく、侵害されたデバイスから直接、3本の本当に有効な署名鍵を手に入れたのだ。これは、ブロックチェーンとスマートコントラクトの観点から見れば、この事件で発生したすべての取引が、署名数の面で確かにしきい値を満たしており、検証も完全に通過していたことを意味する——どの段階も技術的な意味で「破られた」わけではなく、コントラクトのコード自体は要求されたことを完全に正しく実行していた。
これこそが、Humanity ProtocolのCTOがこの事件を「コントラクトのバグ」ではなく「運用面の失敗」と性格づけた理由だ。もし問題がコントラクトのロジック自体にあったなら、解決策はコードにパッチを当てることだっただろう。しかしここでの問題は鍵の物理的な保管方法にあった。これは、スマートコントラクト全体を百回監査し直したとしても、この弱点は決して発見されなかったことを意味する。なぜなら弱点はそもそもコントラクトの内側にはなく、その外側——「これらの鍵が実際にどこに置かれていたか」という、一度もコードに書き込まれたことはないが、資産の安全性に等しく関わる実務的な問題にあったからだ。
もしマルチシグの鍵保有者が業務上の利便性から鍵の集中管理に傾きがちなら、この「利便性」と「安全性」の間のせめぎ合いに対して、業界には分散を呼びかける以上の具体的な解決策はあるのか？
業界で現在比較的成熟している手法は、「地理的・デバイス的分散」を個々の署名者の自主的な判断に委ねるのではなく、正式な運用ポリシーに直接明文化することだ——例えば各鍵に異なるブランド、異なるモデルのハードウェアデバイスを使用することを明確に義務付け、単一のベンダーや単一の製品ラインの脆弱性がすべての鍵に同時に影響を及ぼすことを避ける。同時に鍵保有者を異なる物理的な場所、さらには異なる法域にまたがって分散させることを求め、単一地域に限定された物理的な脅威（オフィスへの侵入など）がすべての鍵に一度に影響を及ぼせないようにする。一部の機関投資家向けカストディサービス提供者は、正式な「鍵生成儀式」のプロセスを通じてこの原則を実践している。鍵を生成するその瞬間に、複数の権限を持つ人員が同時に立ち会い、あらかじめ定められた台本に従って操作することを求め、その後の分散保管のルールが最初から確実に実行されるようにする。鍵が生成された後になって場当たり的に補うのではなく。
構造的な分散に加えて、もう一つよく推奨される手法は、署名しきい値を資産規模に応じて動的に調整することだ。例えば日常的な少額支出を管理するマルチシグアカウントは、運用効率を維持するためにしきい値をやや緩く設定できる。しかしクロスチェーンブリッジやトークン鋳造権限といった、破られれば壊滅的な結果を招く重要インフラを管理するアカウントは、より厳格なしきい値を設定すべきであり、さらにタイムロックの仕組みも組み合わせるべきだ。これにより、たとえ承認しきい値を満たしたとしても、重大な操作が実際に有効化されるまでに緩衝期間が設けられ、他の誰かが異常に気づいて発動を止める機会を得られる。
Humanity Protocol事件と、本サイトですでに紹介したBybit事件は、どちらもマルチシグウォレットの問題に関わっているが、両者の根本的な原因にはどんな違いがあるのか？
この二つの事件はどちらもマルチシグウォレットに関わっているが、攻撃が発生した層はまったく異なり、丁寧に区別する価値がある。Bybit事件では、各署名者が保持していた鍵はそれぞれ適切に保管されており、互いに独立していた——鍵の分散という層においては、マルチシグアーキテクチャは健全だった。攻撃者が実際に迂回したのは、署名者が自分が何に署名しているかを理解するために依拠していたインターフェースソフトウェアであり、署名者に通常の取引が表示されているという錯覚の下で、実際には悪意ある取引に署名させた——インターフェース層が改ざんされたサプライチェーン攻撃だった。Humanity Protocol事件はまったく異なる。インターフェースが表示していた内容と署名者が実際に署名していた内容の間に乖離はなかった。署名者が（もし本当に複数の独立した署名者がこの操作に直接関与していたなら）見て、署名したのは、攻撃者が望んだその取引そのものだった——問題はより前段階、つまり鍵の物理的な保管場所で発生しており、そもそもマルチシグアーキテクチャの基本前提である「地理的・デバイス的分散」が最初から実践されていなかった。
この二つの事例を合わせて見ることで、より完全なリスクマップを構築する助けになる。マルチシグウォレットには少なくとも二つのまったく異なる、それぞれ個別に防御すべき攻撃対象領域が存在する——一つは「鍵そのものが本当に分散して保管されているか」であり、Humanity Protocolはこの層での失敗を示した。もう一つは「署名の瞬間に見ている内容が本当に真実か」であり、Bybitはこの層での失敗を示した。健全なマルチシグアーキテクチャは、この二つの検証を同時に通過する必要があり、どちらか一方だけをうまくやっていても、本当の意味での安全性を構成するには不十分だ。
自分は機関投資家でも大規模なプロトコルを管理しているわけでもなく、単に個人資産を守るためにマルチシグウォレットを使っているだけだ。この事件は自分にとってどんな実践的な参考価値があるのか？
個人ユーザーがマルチシグウォレットを設定する際、Humanity Protocol事件で犯された過ちを最も再現しやすいのは、通常不注意によるものではなく「利便性」によるものだ——例えば署名用のハードウェアウォレット2台を同じ引き出しや同じ金庫に入れる。整理しやすいからという理由で。あるいは2台の署名デバイスが同じブランド、同じモデルなのは操作画面に慣れているからという理由で。さらには一方の署名デバイスのバックアップシードフレーズを、もう一方のシードフレーズと同じ紙に書いて「一緒にまとめて保管する方が便利」だからという理由で。これらの習慣は日常的な操作では確かに手間を省けるが、Humanity Protocol事件における「鍵の集中」という核心的な弱点を正確に再現している——その共通の保管場所やデバイスの種類に何か問題が起きた瞬間、本来互いに独立しているはずの複数の防御線が一斉に破られてしまう。
具体的に取れる調整としては、少なくとも一台の署名デバイスは他のデバイスとは異なるブランドのハードウェアウォレットを使用し、単一ブランドのファームウェアの脆弱性がすべての鍵に同時に影響を及ぼすことを避けること。異なる署名デバイスを実際に異なる物理的な場所に保管すること——例えば一台は自宅の金庫、もう一台は銀行の貸金庫や信頼できる家族・友人の元に置き、「探しやすさ」のためにすべてを一箇所にまとめないこと。そして定期的に（例えば半年に一度）各デバイスが正常に動作するか、バックアップ情報が完全で使用可能な状態にあるかを実際に確認し、設定が完了した後は一度も検証しないままにしないことが挙げられる。これらの調整には追加の技術力は不要で、純粋に保管習慣の変更にすぎないが、それこそがマルチシグアーキテクチャに本来設計されていた保護効果を、実際に発揮させることにつながる。
2026年6月8日の夜、分散型本人確認プロジェクトHumanity Protocolは、イーサリアムとBNBスマートチェーンにまたがる協調攻撃を受け、3600万ドルを超えるHトークンを失った。プロトコルのネイティブトークン価格は約12時間で80%以上暴落した。この事件で最も興味深いのは損失額そのものではなく、その根本原因だ。本サイトですでに紹介したマルチシグウォレットの設計ロジックに従えば、Humanity Protocolのクロスチェーンブリッジの管理権限は、理論上イーサリアム側で6本中3本、BNBスマートチェーン側で5本中3本の鍵が必要とされていたはずだった。これはまさに、単一のデバイスや単一の個人が資産を勝手に動かせないようにするために、マルチシグアーキテクチャが設計された核心的な保障そのものだ。しかし攻撃者は最終的に、一台のデバイスを侵害するだけで、この二つの防御線を同時に突破してしまった。
Humanity Protocolの創設者テレンス・クオックが事後に公開した説明によれば、攻撃の起点は従業員一人のノートパソコンが侵害されたことだった——問題は、このノートパソコンに、イーサリアム側のHyperlaneブリッジの管理権限を統括するGnosis Safeマルチシグアカウントの6本の鍵のうち3本が同時に保管されていたことだった。攻撃者はこのデバイスへのアクセス権を得たことで、承認しきい値を突破するのに必要な鍵をすべて一度に手に入れた。そしてこの権限を使い、ブリッジコントラクトの管理権限（ProxyAdmin）を自分が管理するウォレットへ移し、ブリッジコントラクトを悪意あるバージョンにアップグレードし、単一の取引で約1億4120万Hトークンを移動させた。攻撃者はBNBスマートチェーン側でもまったく同じ手口を繰り返した——5本中3本の鍵が同じくこのデバイスに保管されていた——制御権を奪った後、無制限に鋳造できる機能を備えた悪意あるコントラクトをデプロイし、2回の取引で追加の2億Hトークンを鋳造した。この事件の対応にあたったセキュリティ企業HalbornとプロトコルCTO自身が公表した事後検討報告によれば、最終的にこの事件が影響を及ぼしたトークンの総規模は約4億4700万枚まで上方修正された。
マルチシグアーキテクチャの核心的な約束は、単一デバイスや単一個人のリスクを、複数の独立したデバイスと人員に分散させることだ——しかしこの約束が実際に果たされるかどうかは、完全に「独立」という言葉が本当に実践されているかどうかにかかっている。もし業務上の利便性やプロセス上の見落としから、複数の鍵の保有者が結果的に複数の鍵を同一のデバイス、同一の物理的な場所に集中させたり、あるいは同一人物が管理したりしてしまえば、そのマルチシグアーキテクチャは実質的にシングルシグへと退化してしまう——違いはただ、心理的な安心感を与えるための余分な署名ステップが増えるだけだ。一度この共通の弱点が突破されれば、本来互いに独立しているはずの複数の防御線が同時にすべて破られることになる。Humanity ProtocolのCTOであるメイア・ドレヴは事後、この事件を「スマートコントラクトの脆弱性ではなく、運用面の失敗だった」と直接的に性格づけた——コントラクトのコードは設計通りに完全に正しく実行されていた。問題は鍵の実際の保管方法が、そもそもマルチシグアーキテクチャが本来求めていた地理的・デバイス的な分散という原則を、最初から実践できていなかったことにあった。
もしあなたがマルチシグによって統治されているDAOやプロトコルに参加していたり、あるいは大きな金額の資産を守るために自分でマルチシグウォレットを設定していたりするなら、この事件は具体的で実行可能なチェックリストを提供してくれる。まず、各署名者が実際に使用しているデバイスと物理的な所在地が本当に互いに独立しているかを確認すること。業務上の利便性のために、複数の鍵の物理的な保管や署名用デバイスを一箇所に集中させていないかを確認する。次に、定期的な「鍵の分布監査」の習慣を確立する価値がある。署名者リストの中に、職務異動や離職によって、当初設計されていた地理的または人員的な分散構造に穴が生じている者がいないかを定期的に確認する。最後に、大規模な資産や重要なインフラ（クロスチェーンブリッジ、トークンコントラクトのアップグレード権限など）を管理するマルチシグアカウントについては、タイムロックの仕組みを追加で導入することで、悪意あるアップグレードが承認された後に緩衝期間を設け、他の誰かが異常に気づいて介入できる時間を稼ぐことができる。悪意ある取引が承認された瞬間に即座に有効化されてしまうことを防ぐためだ。マルチシグそのものは決して万能な保障ではなく、単に「攻撃者が突破しなければならない標的の数」を一つから複数へと変えるだけのものだ——しかしもしそれらの複数の標的が結局同じノートパソコンの中に押し込められていたなら、その数字は最初から一つ以上に増えたことは一度もなかったのだ。