公链はなぜ停止するのか？Cosmosの25時間停止から、ブロックチェーンのコンセンサスを本当に理解する

9月22日の夜、あるユーザーがATOMの送金を行った。

一夜が明けても、トランザクションは依然として「確認待ち」のままだった。

秘密鍵を失ったわけでもなく、ウォレットに署名の異常が現れたわけでもない。翌日もう一度確認すると、複数の公開RPCがいずれもCosmos Hubがブロック高33,086,740で停止していることを示していた。

新しいブロックが生成されなければ、当然ながらこのトランザクションをどこかに取り込んでもらうこともできない。

約1日後、Cosmos Hubがブロック生成を再開するまで、このATOM送金は待機状態のままだったが、最終的に成功した。

一般ユーザーにとって、これはブロックチェーンのコンセンサスを理解する最も直感的な授業だったかもしれない。

私たちはよく「どのような中央機関もパブリックチェーンを止めることはできない」と言うが、現実は明らかにより複雑である。十分に分散化されたブロックチェーンには、通常サーバールームにあるような「電源ボタン」は確かに存在しないが、それでも停止する可能性はある。

今回のCosmos Hubの停止は、普段は低層に隠れているこの仕組みを、一般ユーザーの目の前にはっきりと晒け出した。

一、Cosmosはなぜ突然「ブロック生成を停止」したのか？

まず、紛らわしい問題をはっきりさせておく必要がある。今回直接攻撃されたのは、Cosmos Hubではない。

事件は最初、Neutronで発生した。

9月22日、「AIATO: AI Agent Takeover」というNeutronのガバナンス提案が可決された。攻撃者はチェーンレベルのガバナンス権限の隙を突き、wasmdフレームワークがネイティブに提供する特権命令を利用して、AstroportやDropなどのアプリケーションのコントラクト管理者を攻撃者が制御するアドレスに変更した。

これは私たちが通常理解する「コードの脆弱性」や「プロトコルの欠陥」ではない。

簡単に言えば、アプリケーション自体には「ドアの鍵」があるが、Neutronのチェーンレベルのガバナンスはさらに高い権限を持つ「マスターキー」を握っている。攻撃者がガバナンスの結果を制御すれば、この鍵を手に入れたのと同じであり、管理者を再指定し、コントラクトを移行し、さらにその中の資産を移動させることができる。

そして本当にCosmos Hubを巻き込んだのは、その後に発生したクロスチェーン資金移動である。

Cosmos Labsの振り返りによると、Neutronが停止する前に、攻撃者はすでに一部の資産を複数のネットワークに移しており、そのうち約170万枚のATOMがCosmos Hubに移され、クロスチェーン流動性を通じた交換が始まっていた。

つまり、Cosmos Hub自体は直接攻撃を受けておらず、一般のHubユーザーの資金もNeutronの脆弱性によって直接盗まれたわけではない。

しかし攻撃で得られたATOMはすでにHubに入っている。残りのATOMがさらに流出するのを阻止するため、一部のCosmos Hubバリデータがノードの運行を停止し始めた。

9月22日19:18頃（SGT）、運行を停止したバリデータはすでに総voting powerの3分の1以上を代表しており、Cosmos Hubはそれ以上新しいブロックを形成できなくなり、最終的に33,086,740で停止した。

この一歩は非常に重要である。

それは、Cosmos Hubにはある企業が直接クリックできる「Pause」ボタンが存在せず、事前にオンチェーンガバナンス投票を経たわけでもないことを意味する。実際にネットワークを停止させたのは、十分に多くのバリデータがコンセンサス形成に参加しなくなったことである。

しかしより注目に値するのは、その後の復旧プロセスである。

チェーン停止から約4時間後、バリデータは完全な復旧案を受け取った。チェーン停止高に対して一度限りの状態変更を実行し、攻撃者アドレスに残るATOMをコミュニティバリデータが共同管理するマルチシグアドレスに移すというものである。

その後、Cosmos Labsはバリデータがすでに合意した案に基づいてGaia v28.3.0パッチを作成し、テストを行い、バリデータに配布した。

このバージョンのGaiaは、指定された復旧高で一度限りの状態変更を実行し、攻撃者アドレスにある1,227,121 ATOMを、Nansen、Keplr、Enigma、Silknodes、Kiln、Polkachuの6者による4-of-6マルチシグアドレスに移す。

9月23日未明までに、v28.3.0のインストールを確認したバリデータは総voting powerの67%を超えた。そのため同日12:00 UTC、Cosmos Hubは協調再起動を行い、約6分後、この一度限りの状態変更がブロック高33,086,741で実行され、ネットワークは正常なブロック生成に戻った。

結局のところ、Cosmosがブロック生成を停止してから復旧するまでの全プロセスでは、まずバリデータがネットワークのLivenessを失わせ、次に3分の2を超えるvoting powerが新しい状態遷移ルールを受け入れ、最終的にそのルールが復旧後のcanonical stateになったのである。

ここで、一見単純な問題が浮かび上がる。分散化されたパブリックチェーンであるのに、なぜ3分の1を超える検証権で停止でき、ネットワークを復旧するには十分に多くのバリデータが同じソフトウェアを共同で受け入れ、実行する必要があるのか？

その答えは、実は「コンセンサス」という二文字の中に隠されている。

二、いわゆるコンセンサスは、そもそも「永遠に止まらない」ものではない

ブロックチェーンについて最も誤解されやすいことの一つは、「分散化」と「絶対にダウンしない」を等号で結んでしまうことである。

実際には、コンセンサスメカニズムが本当に解決するのは、中央の帳簿管理者が存在しない状況で、多くのノードが取引順序と帳簿状態についてどのように一致するかである。

ただし、各パブリックチェーンがこれを実現する方法は同じではない。

Bitcoinで最も古典的なのはPoW、すなわちプルーフ・オブ・ワークである。マイナーは計算能力によってブロック生成を競い、ネットワークに短時間2本の正当な分岐が現れた場合、ノードは累積工作量に従ってそのうち1本を選んで構築を続ける。

したがってBitcoinには、はっきりとした「67%の投票後にこのブロックが永遠にFinalizedされる」瞬間は存在しない。それはむしろ確率的ファイナリティに近く、後続ブロックが増えるほど、前の取引を再編成しようとするにはますます高い計算コストを支払う必要がある。

これが、これまでBitcoinの取引は6ブロック確認を待つのがよいと言われてきた理由でもある。いくら計算能力が高くても、ノードが実行しているコンセンサスルールを簡単に迂回することはできないからだ。

もちろん、これはBitcoinの状態がいかなる場合でも「絶対に変更不可能」という意味ではない。理論上、エコシステム全体が新しいクライアントと新しいコンセンサスルールを受け入れれば、Hard Forkによって、過去のルールでは無効だった状態変更を有効にすることもできる。

しかし問題はここにある。十分に多くのマイナー、Full Node、取引所、ウォレット、ユーザーにそのような新ルールを一緒に受け入れさせる能力が誰にあるのか？

ほとんど誰にもない。

開発チームはBitcoinネットワーク全体に代わってコンセンサスルールを決めることはできず、マイナーや取引所にも難しい。乗り越える必要のあるコンセンサスのハードルが非常に高いからである。かつてBinanceが7,000枚のBTCを盗まれた際、CZに大手マイナーと連絡して操作するよう提案した人がいたが、最終的には立ち消えになった。

Ethereumはまた別の非常に古典的なサンプルを提供している。

PoSへ移行した後、現在のEthereumはCasper FFGとLMD-GHOSTを組み合わせたGasperコンセンサスを使用している。簡単に言えば、一部のメカニズムは「現在どのチェーンに従うべきか」を判断し、別の部分はブロックに真の意味でのFinalityを与える役割を担う。

少なくとも3分の2のステークETHを代表するバリデータが対応するcheckpointで合意したとき、ブロックはさらに最終確定へ進むことができる。逆に、3分の1を超えるstakeが長期間正しい投票に参加しなければ、ネットワークは一時的にFinalityを形成できなくなる可能性がある。ただしEthereumにはinactivity leakも設計されており、長期間finalizingできない場合、オフラインバリデータの有効な重みを徐々に下げることで、最終的にネットワークがFinalityを回復できる機会を作る。

このような結果を本当に変えるには、同様にプロトコルルールとクライアントを変更する必要がある。

2016年のThe DAO事件のように、Ethereumコミュニティは最終的にHard Forkを通じて、ブロック1,920,000でEthereum Foundationが当時irregular state changeと呼んだ特殊な状態変更を実行し、関連するETHを復旧コントラクトに移した。

ただし、アップグレードを拒否し、元の状態を維持し続けた一部のマイナーとコミュニティは最終的にEthereum Classic（ETC）を形成し、よく知られるETHとETCの分岐を引き起こした。これは誰もがこのルールを受け入れたわけではないことを示している。

Cosmos Hubはまた異なり、CometBFTを使用しており、より典型的なBFTコンセンサスに近い。

より典型的なBFTコンセンサスと理解してよい。つまり、ブロックが実際にコミットされるには、3分の2を超えるvoting powerのCommitを得る必要がある。

その利点はFinalityが非常に明確であることだ。十分な検証権の投票を経てブロックがコミットされれば、PoWのようにさらに多くのブロックを待ち続け、確率で安全感を買う必要はない。

しかしその反面も非常に直接的である。つまり、3分の1以上のvoting powerがCommit形成に必要な投票を提供しなくなれば、残りのバリデータがどれだけ努力しても、3分の2を超える票を集めることはできない。

このときネットワークが取れる最も安全な選択が、今回の「ブロック生成停止」である。したがって分散システムの観点から見れば、今回のCosmos Hubの一時停止は実は神秘的なものではない。

一言で言えば、十分なvoting powerを握るバリデータ群が参加を停止した後、コンセンサスプロトコルは自らのルールに従い、可用性を失うことを選んでも、十分なコンセンサスを欠いたまま新しいブロックを確認し続けることはしない。

この背後には、実は分散システムにおいて一般ユーザーがよく混同する2つの概念がある。

• Safety：異なるノードが同時に互いに衝突する2つの最終状態を確認してはならない；
• Liveness：ネットワークが依然として前進し続け、新しい取引を処理できるか；

BFTシステムにとって、コンセンサスに参加するノードが不足しているとき、一時停止はしばしばSafetyを維持するために支払う代償である。はっきり言えば、この分散型帳簿はまずそこで止まることを選んでも、残った者たちが各自で別々に記帳することを許さないのである。

この観点から振り返ると、パブリックチェーンの歴史における多くの一見まったく異なる事故が、実は同じ一つのことを中心に展開していることがわかる。

分散ノードが「正しい状態」について一致した意見を形成できなくなったとき、ネットワークはどうすべきか？

三、BitcoinからSolanaまで、パブリックチェーンの真のリスク境界はどこにあるのか？

Cosmosがこの問題を表舞台に出したのは今回が初めてではない。

早くも2013年、Bitcoinでは非常に古典的なチェーン分岐事故が起きている。

当時、Bitcoin 0.8は基盤データベースをBerkeley DBからLevelDBへ切り替えた。その後、大量のトランザクション入力を含むブロックが現れ、新バージョンのノードは正常に処理できたが、一部の旧バージョンノードはBerkeley DBのロック数制限により、このブロックを無効と判断した。

そこで非常に気まずい状況が生まれた。全員がBitcoinを実行しているのに、新旧クライアントが「このブロックが本当に合法かどうか」について異なる答えを出し始めたのである。

そのためネットワークは2本のチェーンに分裂し、しかも新バージョン0.8側は一時約60%の計算能力を持ち、通常の計算能力競争に依存して迅速に自ら収束することができなかった。

最終的に、大手マイニングプールが調整を経て旧バージョンへ切り戻し、旧ルール側で再びより多くの計算能力を獲得したことで、ネットワークは再び収束した。Bitcoinは後にBIP 50でこの事故を専門に振り返っている。

2016年になると、EthereumのThe DAO事件が問題をさらに一歩前へ進めた。

上述のThe DAO事件のように、Ethereumコミュニティは最終的にHard Forkを通じて、ブロック1,920,000でEthereum Foundationが明確にirregular state changeと呼んだ特殊な状態変更を実行し、関連するETHを復旧コントラクトに移した。

しかし誰もがこの処理に同意したわけではなく、状態変更を受け入れることを拒否した一部のマイナーとコミュニティが元のルールを維持し続け、後に長く存在することになるEthereum Classic（ETC）が生まれた。

このDAO Forkも古典的な事件であり、すべての人にこう伝えた。極端な事件が発生したとき、コードのコンセンサスの外側には社会的コンセンサスも存在し、十分に一致した意見を形成できなければ、1本のチェーンは本当に2本に分かれ得る。

2021年のSolanaは、また別のまったく異なる障害経路を示した。

同年9月、大量のボット取引がネットワークに流入し、検証ノードのメモリ枯渇を引き起こし、多数のノードがクラッシュした。最終的にネットワーク全体が現在の状態について一致した意見を形成できなくなり、約17時間にわたって新しいブロックの確認を停止し、その後バリデータが共同で調整してネットワークを復旧した。

これらの事故を並べてみると、それ