9 月 22 日の夜、ユーザーが ATOM 送金を送信しました。
一晩経ちましたが、取引はまだ「確認待ち」のままでした。
秘密キーは紛失しておらず、ウォレットに署名例外もありませんでした。翌日再度確認すると、複数のパブリック RPC により、Cosmos Hub がブロック高さ 33,086,740 で停止したことがわかりました。
新しいブロックが生成されない場合、当然、このトランザクションをパッケージ化する場所がなくなります。
約 1 日後に Cosmos Hub がブロックの生成を再開したとき、待ち続けていた ATOM の転送が最終的に成功しました。
一般のユーザーにとって、これはブロックチェーンのコンセンサスを理解するための最も直感的なレッスンかもしれません。
私たちは「いかなる中央組織もパブリックチェーンを閉鎖することはできない」とよく言いますが、現実は明らかにはるかに複雑です。十分に分散化されたブロックチェーンには通常、サーバー ルームに「シャットダウン ボタン」がありませんが、それでも停止する可能性があります。
今回のCosmos Hubの停止により、普段は底部に隠されているこの仕組みが一般ユーザーに完全に暴露された。
1. なぜコスモスは突然「ブロックの生産を停止」したのでしょうか?
まず最初に、混乱しやすい問題を明確にする必要があります。今回直接攻撃されたのはコスモスハブではない。
事件は最初にニュートロンで発生した。
9月22日、「AIATO: AI Agent Takeover」と呼ばれるNeutronガバナンス提案が可決された。攻撃者はチェーンレベルのガバナンス権限の抜け穴を利用し、wasmd フレームワークによってネイティブに提供される特権命令を使用して、Astroport や Drop などのアプリケーションのコントラクト管理者を攻撃者が制御するアドレスに変更しました。
これは、私たちが通常理解している種類の「コードの脆弱性」や「プロトコルの欠陥」ではありません。
アプリケーション自体が独自の「ドアロック」を持っていると単純に理解できますが、Neutron のチェーンレベルのガバナンスはより高い権限を持つ「マスターキー」も保持しています。攻撃者がガバナンス結果を制御する場合、この鍵を取得したことと等価となり、管理者の再指定や契約の移行、さらには資産の移管などが可能となります。
Cosmos Hub が実際に関与するようになったのは、その後のクロスチェーン資金移動でした。
Cosmos Labs のレビューによると、Neutron の実行が停止する前に、攻撃者は一部の資産を複数のネットワークに転送していました。約 170 万個の ATOM が Cosmos Hub に転送され、クロスチェーン流動性を通じて交換が開始されました。
つまり、Cosmos Hub自体が直接攻撃されたわけではなく、Neutronの脆弱性により一般のHubユーザーの資金が直接盗まれたわけでもありません。
しかし、攻撃により入手したATOMはすでにハブ内に侵入していた。残った ATOM の流出を防ぐため、一部の Cosmos Hub バリデーターがノードの動作を停止し始めました。
9 月 22 日の 19 時 18 分頃 (SGT) までに、停止したバリデーターが総投票権の 3 分の 1 以上を占めたため、Cosmos Hub は新しいブロックの形成を続けることができなくなり、最終的には 33,086,740 で停止しました。
このステップは非常に重要です。
これは、企業が Cosmos Hub 上で直接クリックできる「一時停止」ボタンが存在せず、最初にオンチェーン ガバナンス投票を経ることもないことを意味します。ネットワークが実際に停止するのは、十分な数のバリデーターが合意形成に参加しなくなった場合です。
しかし、実際には、さらに注目すべきはその後の回復プロセスです。
チェーンが一時停止されてから約 4 時間後、検証者は完全な回復計画を受け取りました。それは、チェーンの一時停止の高さに合わせて 1 回限りのステータス変更を実行し、攻撃者のアドレスに残っている ATOM をコミュニティのバリデーターが共同管理するマルチシグネチャ アドレスに転送するというものでした。
その後、Cosmos Labs は、検証者が到達したソリューションに基づいて Gaia v28.3.0 パッチを作成し、テストして、検証者に配布しました。
このバージョンの Gaia は、指定された回復高さで 1 回限りの状態変更を実行し、攻撃者のアドレスの 1,227,121 ATOM を、Nansen、Keplr、Enigma、Silknodes、Kiln、および Polkachu で構成される 4/6 マルチ署名アドレスに転送します。
9 月 23 日の早朝までに、v28.3.0 をインストールしたことが確認されたバリデーターの数は総投票権の 67% を超えていました。そのため、その日の 12:00 UTC に、Cosmos Hub は再起動を調整しました。約 6 分後、この 1 回限りのステータス変更がブロック高さ 33,086,741 で実行され、ネットワークは通常のブロック生成に戻りました。
結局のところ、Cosmos がブロックの生成を停止してから運用を再開するまでの全プロセスにおいて、最初にネットワークの Liveness を失わせたのはバリデーターであり、その後、投票権の 3 分の 2 以上が新しい状態遷移ルール セットを受け入れ、最終的にこのルール セットが復元された正規状態になりました。
この時点で、一見単純な疑問が生じます。分散型パブリック チェーンであるのに、なぜ検証権限の 3 分の 1 以上がチェーンを阻止でき、ネットワークを復元するには、十分な数のバリデータが同じソフトウェア セットを受け入れて実行する必要があるのでしょうか。
その答えは実は「コンセンサス」という言葉にあります。
2. いわゆるコンセンサスは「決して止まらない」ものではありません。
ブロックチェーンに関して最も誤解されている点の 1 つは、「分散化」が「ダウンタイムなし」と同等であるということです。
実際、コンセンサスメカニズムが実際に解決する問題は、中央の簿記担当者がいない場合に、どれだけのノードがトランザクションシーケンスと台帳ステータスについて合意に達することができるかということです。
ただし、パブリック チェーンが異なれば、これを実装する方法も異なります。
ビットコインの最も典型的な例は PoW です。これは作業証明であり、マイナーはコンピューティング能力に基づいてブロックを生成するために競争します。短期間に 2 つの法的ブランチがネットワークに出現すると、ノードは蓄積されたワークロードに応じてそのうちの 1 つを選択して構築を続行します。
したがって、ビットコインには明確な「このブロックは67％の投票後に永久に最終決定される」という瞬間がありません。それは確率論的な最終性に近いものです。後続のブロックが増えるほど、以前のトランザクションを再編成するために必要な計算能力コストがますます高くなります。
これが、ビットコイントランザクションは確認のために 6 ブロック待つのが最善であると誰もが言っていた理由です。結局のところ、コンピューティング能力がどれほど高くても、ノードによって実行されているコンセンサス ルールを単純にバイパスすることはできません。
もちろん、これはビットコインの状態がいかなる状況においても「絶対に変更できない」という意味ではありません。理論的には、エコシステム全体がハードフォークを通じて新しいクライアントのセットと新しいコンセンサスルールを受け入れる場合、過去のルールでは無効であったステータスの変更も有効にすることができます。
しかし、ここで問題は、そのような新しいルールセットを受け入れるのに十分なマイナー、フルノード、取引プラットフォーム、ウォレット、ユーザーを獲得する能力を誰が持っているのかということです。
しそうにない。
開発チームはビットコインネットワーク全体のコンセンサスルールを決定することはできません。また、通過する必要があるコンセンサス閾値が非常に高いため、マイナーや取引プラットフォームにとっても困難です。バイナンスから7,000BTCが盗まれたとき、CZが大手マイナーに連絡して運営するよう提案する人もいたが、結局何も起こらなかった。
イーサリアムは別の典型的な例を提供します。
PoS に切り替えた後、イーサリアムは Casper FFG と LMD-GHOST で構成される Gasper コンセンサスを使用するようになりました。簡単に理解すると、メカニズムの 1 つの部分は「現在どのチェーンに従うべきか」を決定する役割を果たし、もう 1 つの部分はブロックを本当の意味でファイナリティに到達させる役割を担います。
ステーキングされた ETH の少なくとも 3 分の 2 を代表するバリデーターが対応するチェックポイントで合意に達すると、ブロックはさらにファイナライズに向けて進むことができます。逆に、ステークの 3 分の 1 以上が長期間にわたって正しい投票に参加しない場合、ネットワークは一時的にファイナリティを形成できなくなる可能性があります。ただし、イーサリアムは、ファイナライズが長期間完了できない場合に、オフラインバリデーターの実効重みを徐々に減らす非アクティビティリークも設計しており、ネットワークに最終的にファイナリティを回復する機会を与えます。
この結果を実際に変更するには、プロトコル ルールとクライアントも変更する必要があります。
2016年のDAO事件と同様に、イーサリアムコミュニティは最終的にハードフォークを通じてブロック1,920,000でイーサリアム財団による不規則状態変更と呼ばれる特別な状態変更を実装し、該当するETHを回収コントラクトに移管しました。
しかし、アップグレードを拒否して元の状態を維持し続けた一部のマイナーやコミュニティは最終的にイーサリアム クラシック (ETC) を形成し、ETH と ETC の有名な分岐につながり、誰もがこの一連のルールを受け入れているわけではないことを示しています。
Cosmos Hubはまた違います。これは、典型的な BFT コンセンサスに近い CometBFT を使用します。
これは、より典型的な BFT コンセンサスとして理解できます。つまり、ブロックが実際に送信されるには、投票権の 3 分の 2 以上のコミットを取得する必要があります。
その利点は、Finality が非常に明確であることです。十分な検証権限を持った投票によってブロックが送信されたら、PoW のように確率と安心感を引き換えにブロックがさらに増えるのを待ち続ける必要はありません。
しかし、その反対側も非常に単純です。つまり、投票権の 3 分の 1 以上がコミットの形成に必要な投票を提供しなくなった場合、残りのバリデーターはどんなに頑張っても 3 分の 2 以上を獲得することはできません。
現時点でネットワークにとって最も安全な選択は、今回は「ブロックの生成を一時停止する」ことであるため、分散システムの観点から見ると、Cosmos Hub のこの短期間の停止は実際には不思議ではありません。
一言で言えば、十分な投票権を持つバリデーターのグループが参加を停止した後、コンセンサスプロトコルは、独自のルールに従って、十分なコンセンサスなしに新しいブロックの確認を続けるよりも可用性を失うことを選択します。
この背後には、実際には、一般ユーザーがよく混同する分散システムの 2 つの概念が対応しています。
安全性: 異なるノードは、矛盾する 2 つの最終状態を同時に確認することはできません。
Liveness: ネットワークは前進を続けて新しいトランザクションを処理できますか?
BFT システムの場合、コンセンサスに参加しているノードが十分でない場合、安全性を維持するために一時停止が代償として支払われることがあります。率直に言って、この分散型台帳は、残りの人々に自分のアカウントを保持させるよりも、むしろそこで停止するほうがよいでしょう。
この観点から振り返ると、パブリック チェーンの歴史の中で一見まったく異なる事故の多くが、実は同じことを中心に展開していることがわかります。
分散ノードが「正しい状態」について合意できなくなった場合、ネットワークはどうするのでしょうか?
3. ビットコインからソラナまで、パブリックチェーンの本当のリスク境界はどこにあるのでしょうか?
コスモスがこの問題を提起するのはこれが初めてではない。
2013 年には、ビットコインで非常に典型的なチェーンフォーク事故が発生しました。
当時、ビットコイン 0.8 では基盤となるデータベースが Berkeley DB から LevelDB に切り替わり、大量のトランザクション入力を含むブロックが出現しました。新しいバージョンのノードでは正常に処理できましたが、一部の古いバージョンのノードでは、Berkeley DB ロック数の制限によりブロックが無効であると判断されました。
とても恥ずかしい場面が出てきました。誰もがビットコインを実行していましたが、「このブロックが合法かどうか」について、古いクライアントと新しいクライアントは異なる答えを持ち始めました。
その結果、ネットワークは 2 つのチェーンに分割され、新バージョン 0.8 側が一時は計算能力の約 60% を獲得し、通常の計算能力競争に依存して自力で迅速に収束することができなくなりました。
最終的には、大規模なマイニング プールが調整して古いバージョンに切り替え、古いルール側でより多くのコンピューティング能力を取り戻し、ネットワークは再び収束しました。ビットコインはその後、BIP 50でこの事故を具体的に検討した。
2016 年、イーサリアムにおける DAO 事件により、問題はさらに一歩進みました。
DAO事件で前述したように、イーサリアムコミュニティは最終的にブロック1,920,000のハードフォークを通じてイーサリアム財団によって不規則な状態変更と明示的に呼ばれる特別な状態変更を実装し、関連するETHを回復コントラクトに移管しました。
しかし、誰もがこの決定に同意したわけではありません。ステータスの変更を受け入れることを拒否した一部のマイナーやコミュニティは元のルールを維持し続け、その後、長年続いてきたイーサリアムクラシック（ETC）が登場しました。
このDAOフォークも古典的なイベントであり、極端な出来事が起こったときにはコードの合意に加えて社会的な合意も存在することを皆に伝えるのと同じです。十分に一貫した意見を形成できない場合、連鎖が実際に 2 つに分裂する可能性があります。
2021年のソラナは、まったく異なる失敗の道を示しています。
その年の 9 月に、大量のロボット トランザクションがネットワークに流入し、検証ノードのメモリが不足し、多数のノードがクラッシュしました。結局、ネットワーク全体が現状について合意に達することができず、約17時間にわたって新たなブロックの確認が停止した。その後、バリデーターが協力してネットワークを復元しました。
これらの事故をまとめると、それらは同じものではないことがわかります。
2013 年のビットコインの問題は、異なるクライアントが異なる有効性ルールを実装し始めていることです。
2021 年の Solana の問題は、多数の検証ノードが正常にコンセンサスに参加し続けることができず、ネットワークが Liveness を失うことです。
イーサリアム DAO が直面しているのは、コミュニティが新しいプロトコル ルールを通じてステータスを積極的に変更すべきかどうかという問題に近いです。
今回の Cosmos Hub には、さらに特別な層があります。ネットワークはまず、攻撃資産が移動し続けるのを防ぐために、バリデーターの調整を通じて積極的に Liveness を失います。次に、十分に高い割合の検証権が新しいソフトウェアを共同で受け入れて状態を復元し、ネットワークの一貫性を再び高めます。
したがって、これらの事件を単に「ブロックチェーンが停止する可能性がある」「分散化は偽物」のせいにするのではなく、より現実的な事実を認めたほうがよいでしょう。
コンセンサスメカニズムは決して破壊できない機械ではありません。実際に提供するのは、意見の相違が発生した場合に誰が正しいチェーンを決定するかなど、一連の分散ルールです。何人の参加者が州決勝に進出できるか。障害が発生した場合、ネットワークは実行を継続するか停止するかを選択します。そして極端な場合、どのような集団行動が次の運用ルールを変える可能性があるのか。
このことからも、今回のコスモスの事件は、「チェーンを止めるべきなのか？」という問題以上に、一般ユーザーにとって検討に値する疑問を残していることになる。
最後に書きます
私たちはよく「鍵ではなく、コインでもありません」と言います。
もちろん、この文は今でも当てはまりますが、資産管理が強調されています。秘密鍵が自分の手元にある限り、ウォレット、取引プラットフォーム、その他の第三者は通常、あなたの代わりに送金に署名することはできません。
前提として、使用しているブロックチェーンがいつでもこの署名を処理できなければなりません。
Cosmos Hub がブロックの生成を停止した日でも、ユーザーは依然として秘密キーを保持しており、資産が突然消えることはありません。ただし、トランザクションに正しく署名したとしても、それを受け入れるための新しいブロックはありません。
回復プロセスではさらに、十分なコンセンサス参加者が新しいステータス ルールのセットを受け入れた場合、特定のアカウントのオンチェーン ステータスも元のアドレスの秘密キーの署名なしで変更される可能性があると説明しています。
これは、「あなたのキーではなく、コインではありません」を無効にするものではありませんが、秘密キーの自律性と基礎となるコンセンサス権は決して同じものではないことを思い出させます。
財布も同様です。
ウォレットは、秘密鍵と署名の権利がユーザーの手に渡っていることを保証し、チェーンレベルの異常をできるだけ早く特定し、トランザクションのステータスを正確に表示し、RPC とノードの冗長性を確立し、ネットワークが復元された後にトランザクションの最終結果を再確認します。
ただし、ウォレットはパブリック チェーンのコンセンサスを復元することはできません。また、基盤となるネットワークが決して中断されないことを保証することも、チェーンのルールやステータスがコンセンサス レベルで決して変更されないことを保証することもできません。
したがって、成熟した分散システムが本当に追求すべきことは、決して「何も変えられない」ということではないかもしれません。それどころか、これらの不完全な境界は可能な限り明確にされるべきです。誰が合意を保留できるのでしょうか?どのくらいの重量が必要ですか?どのような場合に緊急介入が許可されますか?
真の分散化のため、システムが事故にまったく遭遇しないことは不可能です。重要なのは、たとえ事故が発生したとしても、誰が、どのようなルールに従って、どのレベルの合意に基づいてこのアカウントを次にどのように記録するかを決定するのかを知ることができるということです。