「ポイズン・ピギー事件」──カルダノは何が起き、どうやって14時間で立て直したのか
Pi Lanningham の事後報告を読み解く
2025年11月21日、Cardano は約14時間にわたる「深刻なサービス劣化」を経験しました。
この出来事は一部で「Cardano はダウンした」「止まった」と騒がれましたが、実際にネットワークの内部で何が起きていたのかを、技術的・客観的に整理してくれたのが、Sunday Labs の Pi Lanningham による「Poison Piggy – After Action Report（ポイズン・ピギー事後報告）」です。
チャールズ・ホスキンソン氏はこのブログ全文を動画で読み上げ、自身のコメントも交えながら解説しました。
1. 何が起きたのか――14時間の「サービス劣化」の実像
Pi氏はまず、感情論やレッテル貼りを避けるために、「事実」と「影響」から説明を始めています。
- 発生日時：2025年11月21日
- 内容：Cardano ネットワークは約14時間にわたり、明確なサービス劣化を経験
- しかし：
- チェーンはブロック生成を継続
- トランザクションも流れていたが、最大約400秒（約6〜7分）の遅延が発生
- ブロック間隔は最悪 16 分まで伸びた
最終的にわかったことは次のとおりです。
- フォーク中に生成されたトランザクション総数：
- pig chain（誤ったフォーク側）：6,847 tx
- chicken chain（最終的に勝った側）：13,094 tx
- 両チェーンに共通して含まれていたトランザクション：8,168 tx
- pig のみに含まれ、chicken に含まれなかったもの：479 tx（全体の約3.3％）
IOG はこれら 479 件を再送しようとしましたが、
- 多くは有効期限外
- 一部はすでに別のトランザクションで消費済み といった理由で、すべて無効だったと報告されています。
つまり、
ネットワークは「止まってはいない」が、
ユーザー体験としては「かなりひどい遅延」が発生し、
一部のアプリケーション（とくに取引所やブリッジ）はリプレイ／ダブルスペンドリスクに晒された
というのが、Pi が示した「冷静な実像」です。
2. テストネットからメインネットへ──「白」の行為と「黒」の行為
インシデントは、最初からメインネットで起きたわけではありません。
- 11月20日・まずテストネットで問題発生
- preview テストネットに投げ込まれたあるトランザクションが、 一部ノードでは受理、一部では拒否される事象が発生
- これは「誤って投げられた」のか、「意図的なテスト」だったのかは不明
- しかし Pi もチャールズも、ここまでは「ホワイトハット的な行為」とみなしています
- テストネットは壊すためにある
- バグを見つけた人は、通常バグバウンティや称賛の対象
- 原因切り分けとパッチ作成
- Cardano DB Sync のシリアライズエラーから調査が始まり、
- ノードバージョンによるフォークが発生していることが判明
- Sunday Labs は古いバージョンを使っていたため、結果的に「健全な側のフォーク」を追っていた
- レジャーチームが「長さの異常なハッシュを誤って受け入れてしまうバグ」を特定し、修正パッチを作成
ここまでは、
「テストネットが壊れた、原因を特定し、パッチを用意して、メインネットにも落とし込む」
という、比較的よくある高優先度インシデント対応の流れです。
問題が本格化したのは、このあとです。
- 修正パッチの存在を知りながら、メインネットへ“攻撃トランザクション”を送った人物の登場
- Homer J はテストネット側の問題をリアルタイムで追っており、 Sunday Swap に関わるスクーパーとして高い技術理解を持っていました
- 彼は、
- テストネットでどんなトランザクションが問題を起こしたのか
- その結果として何が起きたのか
- メインネットも同じ条件で脆弱になっていること
- 修正パッチが急いで配布されていること を理解したうえで、
- 同じタイプのトランザクションをメインネットに作り出し投げ込むことを選びます。
- しかも、自分のプールではなく、チャールズの個人プール「RATS」に対する委任トランザクションとして送信したことが明らかになっています。
Pi氏のレポートはこの部分を淡々と記述していますが、
チャールズ氏のコメントでは、
- これは「テストネットでのホワイトハット的な発見」とはまったく別物
- パッチ配布の race condition を理解しながら、それを突いてメインネットをフォークさせた行為
- しかも個人的な感情をにじませるような形で特定プールを選んでいる
という点が強く指摘されています。
3. pig chain vs chicken chain──2つのチェーンのレースと14時間の攻防
メインネットに問題のトランザクションが送信されたことで、
Cardano は二つのチェーンに分かれました。
- より「緩い」ルールを採用してしまった側：pig chain（豚チェーン）
- より「厳格な」ルールを維持していた側：chicken chain（鶏チェーン）
ここから約14時間にわたり、
「どちらのチェーンが最終的に勝つのか」というレースが始まります。
なぜ「厳しい側（chicken）」を選んだのか？
理論的には、ステークの多数を握っていた「緩い側（pig）」を採用したほうが、
フォークの解消自体は早かった可能性があります。
しかし、Pi氏とウォールームの判断はこうでした。
- すでにテストネットの段階で「厳しい側」を前提にパッチが配布されている
- ここで方向転換するとコミュニケーションが大混乱
- 何よりも深刻だったのが、
- ウォレット
- 取引所
- オフチェーンインフラ に対する影響です。
「緩い側」を採用してしまうと、
ほぼすべてのウォレットがリセットを強いられ、
エクスプローラーも機能不全に陥り、
ユーザーは数日〜数週間にわたって「何も見えない状態」に置かれてしまう可能性がありました。
結果として、
ネットワークそのものよりも、「エコシステム全体」にとって
どちらの選択が致命傷にならないか
を優先し、より制限の厳しい「chicken chain」を正式な側として選ぶ方針が共有されました。
4. Ouroboros のエレガンス──なぜ「自己修復」できたのか？
Pi氏のレポートとチャールズのコメントで、
何度も強調されていたのが Ouroboros（オーロボロス）の設計です。
Kパラメータと「12時間ルール」
- Cardano には、だいたい 12 時間（2,160 ブロック）を超えるロールバックは起きない、という前提があります。
- これを越えると履歴は「イミュータブル（不変）」として扱われます。
今回問題となったのは、
- pig chain 側の「不正トランザクション」がイミュータブルになるタイミング
- chicken chain 側が pig chain を追い越すタイミング
この2つの時間関係でした。
ある時点までは、
「pig chain のほうが先にイミュータブルに到達してしまい、
その場合は pig 側を追っていたノードを手動でパージしなければならない」
という最悪の可能性も見えていました。
しかし、SPO のアップグレードが進み、
chicken chain 側への参加率が増えていくにつれて、
- pig 側：ブロック生成間隔が長くなる（時間が伸びる）
- chicken 側：ブロック生成間隔が短くなる（時間が縮む）
という「分散システムならではの時間の伸縮」が起きました。
その結果、
- 「不正トランザクションがイミュータブルになるまでの残り時間」よりも
- 「chicken chain が pig chain を追い越すまでの時間」のほうが短くなり
Cardano は「自己修復」が可能な状況へと移行しました。
ウォールームでは、
pig chain・chicken chain 両方のチェーン高さと、その差分をリアルタイムでモニタリングしながら、
「回復まであと何時間か」をかなり正確に予測できていたといいます。
チャールズはここを「他の暗号通貨にはない、Ouroboros 特有の強み」として強調しています。
5. 大規模インシデントの「分類法」──この事件はどのレベルか？
Pi が今回のレポートで非常に大切にしているのが、
「出来事を感情ではなく、共通の言葉で分類して話そう」という姿勢です。
彼は、ブロックチェーンで起こりうる大規模障害を
おおまかに次のように分類しています（一部要約）。
- ソブリンティ侵害
- リモートコード実行／署名偽造／資金奪取など
- チェーンの主権そのものが壊れる
- 実質的に致命傷
- レジャー侵害
- 2010 年の Bitcoin の Value Overflow（1844億 BTC 問題）のように、 「仕様の精神に明らかに反する状態」が実際に発生するケース
- コンセンサス侵害ハードフォーク
- DAO ハック後の Ethereum のように、 中央の意思決定主体が「履歴を書き換える特別ルール」を導入し、 事実上ハードフォークを強制したケース
- 大規模チェーン再編ソフトフォーク
- ネットワーク条件やバグでコンセンサスが長時間分岐するものの、 最終的にプロトコルと社会的コンセンサスの組み合わせで自動的に収束し、 「ノード実装を強制的に編集する必要はない」ケース
- ブリッジや取引所はリプレイリスクに晒される
- スマートコントラクトのエクスプロイト
- フルコンセンサス停止
- Solana などで見られた「チェーンが完全停止し、人間が起動し直さないと動かない」パターン
- サービス劣化
- Ethereum Shanghai DOS 攻撃や、Sunday Swap のローンチ時のようなケース
Pi の結論は明確です。
今回の Cardano のインシデントは、
「大規模チェーン再編ソフトフォーク」＋「サービス劣化」に該当する。
つまり、
- 深刻であることは否定しない
- しかし、「主権侵害」や「レジャーの破壊」には至っていない
- フルストップも起きていない（ブロックは生成され続けていた）
という位置づけです。
6. 良かった点──なぜこれで「済んだ」のか？
Pi氏とチャールズ氏は、「良かった点」もかなり丁寧に挙げています。
① Haskell（メモリ安全言語）でのノード実装
- 今回のバグは「バッファ長の扱いを誤ったシリアライズ周りのバグ」でした。
- もしノードが C/C++ で書かれていたら、
- 任意コード実行
- 秘密鍵の漏洩
- SPO の鍵を乗っ取られてのチェーン支配 といった事態に発展していても不思議ではありません。
Haskell（や Rust）のようなメモリ安全言語を選んだことが、
「レベル1〜2の致命傷」を避ける決定打になったと指摘されています。
② 監視・可視化・レポート基盤
- どのノードがどのバージョンを動かしているか
- 各フォークでのブロック生成ペース
- カナリアトランザクションによるユーザー体験の測定
こうしたデータがリアルタイムに取れていたおかげで、
- どの SPO に連絡するべきか
- 回復まで何時間かかるか
- どのフォークを採用した場合の影響は何か
といった判断が、数字に基づいて行えました。
③ Ouroboros の自己調整的なロールバック設計
すでに述べたとおり、
「チェーン密度が下がるほどロールバック可能時間が伸びる」という設計が、
今回の自己修復の鍵になりました。
④ ネットワークとノードバージョンの多様性
- すべてのノードが同じバージョンだったら問題は起きなかったが、
- 一方で、古いバージョンを使っていたノードが「安全側のフォーク」を維持し、 pig chain の拡大を抑える役割も果たした。
将来的に実装の多様性が増したときも、
同様に「1つの実装のバグがネットワーク全体を落とす」リスクを下げる方向に働くと考えられます。
⑤ 本当の意味での「分散したウォールーム」
- IOG
- Cardano Foundation
- EMURGO
- Intersect
- コミュニティの技術的リーダー（Andrew Westberg など）
- 取引所・dApp の担当者
が、Discord・Slack・Telegram・メール・Twitter などあらゆるチャネルを通じて集まり、
「ある一社が決定する」のではなく、「多くの関係者が議論して結論を出す」という形で、
フォーク選択がなされました。
7. 反省点──Cardano が直視すべき課題
同時に、Pi氏は「痛いところ」もはっきり書いています。チャールズ氏もそれを認めています。
① ユーザー体験のトラッキング
カナリアトランザクションが示す遅延（だいたい5分程度）と比べて、
実際のユーザー体験はもっと悪かったという証言も多くあります。
- CF がインフラ事業者（Blockfrost など）やウォレットと連携し、 「典型的なユーザーが今どんな状態か」をもっと正確に観測できる仕組みを整備する必要。
② DB Sync への依存と「目の喪失」
- 多くのエクスプローラーが Cardano DB Sync に依存していたため、 DB Sync が壊れると「チェーンの状態が見えない」状態に陥りました。
- ここはアーキテクチャの多様化が必要で、 他実装が出てくる 2026 年以降に大きく改善される見込みだとされています。
③ テスト厳格さの揺らぎ
- 8年間で大きなバグが1件という意味では「悪くない」と言える一方で、
- ガバナンス機能などの開発プレッシャーが高まった中で、 テストに割けるリソースが圧縮されていた可能性があると自己批判しています。
ここは、
「プレッシャーのせいだけではなく、ソフトウェアが長く生きれば確率的にバグは出る」という現実もありつつ、
それでも「テスト戦略の強化」は避けて通れないテーマだとされています。
④ 代替実装時代に向けた Blueprint とテスト戦略
- Sebastian氏（DC Spark 出身のほう）が提唱する 「仕様からコードを生成し、仕様に基づいたファジングを行う」アプローチ
- そして Sebastian氏（Blueprint 側）が進める 「Cardano ノードとは何かを形式仕様として定義し、テスト戦略と認証プログラムを整備する」プロジェクト
こうした取り組みが、今後の複数実装時代には必須になる、と Pi は強調しています。
⑤ SPO の意思決定支援──AI センチネルとネットワーク内 Pub-Sub
チャールズが強く推しているのが、
- 全ての SPO に配布できる「AI アップグレード・センチネル」
- ノードネットワークに組み込まれた Pub-Sub 的なメッセージングレイヤー
です。
- 前者は、SPO がアップグレード通知を受けたときに、 「どんなリスクがあるのか」「どのテストを行うべきか」を AI が一緒に考えてくれる仕組み。
- 後者は、Intersect や創業団体などが 「緊急アップグレードのお知らせ」をネットワーク経由で一斉に伝えられる仕組み。
これらは、今回のようなインシデントの影響と回復時間を大きく減らせる可能性があります。
8. それでも Cardano を選ぶ理由──「最悪に近い条件」のなかで見えたもの
Pi氏は最後に、こんな問いを読者に投げかけています。
あなたが一番信頼しているチェーンは、
今回のようなコンセンサス崩壊に直面したとき、どう振る舞うと思いますか？
そして、自分自身の答えとして、
- チェーンは進み続けたか？ → Yes
- サービスは劣化したか？ → Yes
- 資金が危険に晒された可能性はあったか？ → 一部には Yes
- 「ほぼ最悪の条件」に近い状態から回復できたか？ → Yes
- そのうえで、自分のビジネスをこのインフラの上に乗せるか？ → Absolutely Yes
と結論づけています。
チャールズ氏もまた、
「今回生き残れたのは、過去8年間にわたって積み重ねてきた“宿題”の成果だ」と語り、
「これで終わりではなく、ここからさらに強くなるためのポストモーテムが始まる」と締めくくっています。
9. 2026年へ──「人類史上最も信頼性の高い分散システム」を目指して
この「Poison Piggy」インシデントは、
Cardano にとって痛みを伴う出来事であったことは間違いありません。
しかし同時に、
- Ouroboros の設計と理論が、現実の攻撃の中でも機能したこと
- Haskell ベースの高保証エンジニアリングが、致命傷を防いだこと
- 分散したウォールームとコミュニティの連携が、自律的な回復を実現したこと
は、他チェーンとの比較においても大きな意味を持つ出来事になりました。
チャールズは動画の最後で、こうまとめています。
- Cardano は、2026 年に向けて 「単に良いチェーン」「優れたチェーン」ではなく、 「人類がこれまで作り上げた中で最も信頼性の高い分散システム」を目指す。
- バグは今後も必ず発生するが、 そのたびにより早く、より賢く、より透明性をもって対処できるようになる。
「完璧ではないこと」を認めたうえで、
それでも「どう修正し、どう次に活かすか」に全力を尽くす──
今回の Poizon Piggy 事後報告とチャールズ氏の解説は、
その姿勢を象徴する一つのエピソードと言えるのではないでしょうか。
以下はチャールズ・ホスキンソン氏動画「Poison Piggy – After Action Report (Thanks Pi)」を翻訳したものです。
チャールズ・ホスキンソン氏動画「Poison Piggy – After Action Report (Thanks Pi)」全翻訳：ポイズン・ピギー──事後報告（Piありがとう）
こんにちは。チャールズ・ホスキンソンです。暖かくて晴れたコロラドから生配信しています。
今日はコミュニティから出てきた、とある内容について動画を撮りたいと思います。Pi Lanningham（パイ・ラニンガム）によるものです。Pi は Sunday Labs の創業メンバーのひとりで、Sunday Swap や、Acropolis、Pragma などでの活動でご存じの方も多いと思います。
彼が本当に素晴らしいレポートを書いてくれたので、それをここで逐語的に読み上げて、少しコメントを挟ぎたいと思います。これは非常に優れたポストモーテム（事後分析）であり、それ以上のことも成し遂げていると私は考えています。単なるポストモーテムにとどまらず、今後も何度でも使える用語や枠組みを提示してくれているからです。
ということで画面共有をします。リンクはここにあります。タイトルは「poison piggy after-action report（ポイズン・ピギー事後報告）」です。公開されたばかりのものです。これを声に出して読んでいきます。もしそれが気に入らないなら、まあ、他の誰かを探してください。ここは私のチャンネルなので、私は好きなことをします。
では始めましょう。
2025年11月21日、Cardano は約14時間にわたって深刻なサービス劣化を経験した。
本ブログは、そこで起きた事象の私なりの独立した記録であり、その重大性に対する私の評価、そしてネットワーク・チェーンとコミュニティがどのように対応したかについての評価をまとめたものである。
この投稿の目的は、冷静な事実と、私の専門家的な見解を、誰もが自分の意見を形成できる程度にはわかりやすい言葉で提示することにある。
私が Cardano 上にプロジェクトを構築しているからといって、事件の重大さから目をそらしたり、言い訳をしたりしないよう努めたい。
一方で、この出来事の周辺にあるニュアンスを適切に説明し、いたずらに大げさに煽ることを避けつつ、何がうまくいかなかったのかを明らかにしたい。
私がそれをうまくできているかどうかは、読者であるあなたが判断することになる。
この出来事をどのような用語で表現するかについては、果てしなく疲れるだけで意味のない議論が延々と続く可能性が高いと思う。
私は、そうした議論は最終的には「自己満足」にすぎないと考えている。
一方には、Cardano の「ダウンタイムなし」という主張を引きずり下ろしたくて仕方がない人たちがいて、もう一方には、その「途切れない Duolingo ストリーク」を必死に守ろうとする人たちがいる。
重要なのは「ラベル」ではなく「影響」である。
私は、実際に起きた現実世界での影響と、自分がこうした出来事を分類するために一貫して用いている分類学（タクソノミー）を説明する。
そのうえで、あなたが「Cardano はダウンした」と判断するのであれば、私はその意見をとがめるつもりはない。そのラベルにこだわるつもりはないし、合理的な人々のあいだでも見解が分かれうることだと思う。
ただし、もしあなたが公の場で「善意」に基づいて議論をしたいのであれば、Twitter の論客があらかじめ決めつけた意味ではなく、自らの頭で考えたうえで結論を出してほしい。
そして、もしあなたがそうした Twitter の論客の一人なのであれば、自分のオーディエンスに対して、少なくとも自分がどのような閾値をもってラベルを用いているのかを明示し、後で紹介する他チェーンの類似事例にも一貫してその基準を適用するという「礼儀」くらいは示してほしい。
Twitter にそこまでの合理性を期待するのは無理難題かもしれないが、そうであってほしいと願っている。
まず、シリアライズのバグにより、片方向的な「ソフトフォーク」が Cardano 上で発生した。
最初は preview テストネットで、そのあとメインネットでも同様の状況が起きた。
テストネットで問題が見つかったあと、メインネットで問題が発生する前に、修正パッチが迅速にリリースされた。
このフォークはチェーンの品質を深刻に低下させたが、世間が想像しているほど致命的ではなかった。
堅牢なインフラを通じて送信されたトランザクションは、最大で約400秒の遅延が発生した。
ここは非常に重要な点だ。
Twitter界隈では「Cardano は止まった」「Cardano は死んだ」「その日は Cardano では何もできなかった」といった話が飛び交っている。
だが、我々は依然としてトランザクションをリレーすることができていた。ただし、最大で400秒ほどかかることがあった、という話である。
当然ながら「即時性」という点ではかなりよろしくない。
支配的なチェーン側でのブロック生成間隔は、最大で16分にまで伸びた。これも非常に問題がある。
一部のインフラでは、別の脆弱性のために、これよりも長い遅延が発生した可能性もある。
最終的に、約3.3％、つまり14,383件中479件のトランザクションが、現在支配的となっているフォークには取り込まれなかった。
特にブリッジや取引所など、一部のシステムはリプレイ／ダブルスペンドのリスクに晒された。
破棄されたフォーク上のトランザクションの分析は現在も進行中で、そのリスクが実際に被害として顕在化したのかどうかを調査している。
私が「数週間かけてクリーンアップする必要がある」と言っていたのは、まさにこの部分を指している。
つまり、ブリッジ、取引所、DeFi アプリケーションなど、長いチェーン再編に対して特に脆弱なアクターが存在しており、その精査に時間がかかるということだ。
これはユーザーにとって深刻なサービス劣化であるが、「高いナイン（99.9x%）」レベルの可用性を持つサービスとして想定される範囲には収まっている。
創業3団体に加え、Intersect、そして Sunday Labs を含む多数のコミュニティプロジェクトが協力し、問題の特定と修正、そしてどのノードバージョンを動かすべきかという形で、SPO コミュニティに「どのフォークを採用するか」の推奨を行った。
ここも非常に重要なポイントだ。
一部で言われているように「ネットワークを手動でリセットして全部作り直した」わけではない。
我々は「SPO は独立した主体として、このフォークを選択すべきだ」と推奨しただけであり、最終的な決定は彼らが下した。
それは分散的なプロセスだった。
SPO コミュニティは自律的にこの推奨を受け入れ、自身のノードをアップグレードし、その結果、約14時間で完全に自律的な回復が達成された。
中央集権的な権威がチェーンを再起動したり、介入して強制的に巻き戻したりする必要はなかった。
これが「事実」である。
では、ここから何が起きたのかを、私が把握できている範囲で時系列に沿って説明する。
ここでの時刻はすべて、私のタイムゾーン（EST）で表記されている。
私は当時ロンドンにいたので、Pi とはタイムゾーンがずれていた。Pi は東部時間帯で、私より少し遅れている。
2025年11月20日、15:39 頃、preview テストネットにあるトランザクションが投げ込まれた。
それは一部のノードには受け入れられ、別のノードには拒否された。
意図的か偶然かは不明だが、このトランザクションがどんな理由で、誰によって投げ込まれたのかはわかっていない。
ここは非常に重要なポイントだ。
これは「責任ある情報開示」の境界線に関わる話でもある。
テストネットを壊す、というのは、そもそもテストネットの存在理由そのものだ。
テストネットは壊されるために存在し、テストされるために存在し、ストレステストのために存在する。
誰かがそれを壊したとき、その行為は「ホワイトハット」と見なされる。
人々はそういうことをすべきであり、巧妙な攻撃やバグを見つけたときには、バグバウンティや称賛が与えられ、「これはかなりまずいバグだ、修正しよう」と皆が動く。
実際にそれをやった人が誰なのかがわかっているかどうかは、本質的にはあまり関係がない。
それは善良なアクターであり、「ホワイトゾーン」の行為と言える。
テストネットが存在する理由は、「ネットワークが信頼できるかどうかを議論するための安全な場」を提供することにある。
その後、およそ18:19 頃、つまり約3時間後、私は Homer J によって SPO テストネットチャンネルでタグ付けされた。
Homer J は、メインネット側の攻撃者である（その話は少し後で出てくる）。その時点では、問題のトリアージ（原因切り分け）が行われていた。
この時点でわかっていたのは、「テストネットが壊れた」ということ、つまり何かが起きてフォークが発生し、すでにトリアージが進んでいたということだ。
ちょうどその時間帯のブロックには Sunday Swap のトランザクションが含まれていたので、「なぜ Homer が Pi をタグ付けしたのか」がわかる。
Homer は Sunday Swap のスクーパーであり、高度な技術的知識を持っていて、リアルタイムでこれらの状況を追いかけていた。
結果的にこれは「レッドヘリング（ミスリード）」だったが、Pi が状況を認識するきっかけにはなった。
Pi は Sunday Swap のインフラをチェックし、自分たちがどのバージョンを動かしていて、どちらのフォークを追っているのかといった情報を共有した。
ポリシーとして、我々はハードフォークかセキュリティ脆弱性への対応が必要になるまでは、インフラのアップグレードを避けるようにしている。
そのため、Sunday は旧バージョンのソフトウェアを動かしており、それがフォークの原因の一つになっていた。
旧バージョンのソフトを動かすノードは、新バージョンのソフトを動かすノードと話が合わなくなってしまうからだ。
初期診断では、Cardano DB Sync が何らかのシリアライズエラーによってクラッシュしているように見えた。
そこで我々は、これはネットワーク分断やチェーンフォークの問題というよりも、そちらが「根本原因」なのではないかと考えた。
Cardano DB Sync は、ほぼすべてのブロックチェーンエクスプローラーでクエリの基盤として用いられているため、
もし DB Sync が壊れれば、チェーンの状態を確認する目として普段使っているツールが、ことごとく誤作動することになる。
つまり、我々は「目隠し状態」で飛ぶことになった。
いつもチェーンの状態を観測するために使っているツールが、止まっていたり、密度の低いフォーク側を追っていたりしたからだ。
複数のチェーンの tip を比較した結果、チェーン上にフォークが存在すること、そしてそれがノードバージョンに相関していることが明らかになった。
Sunday Labs は旧バージョンのノードを動かしており、それが最終的に「ヘルシーなフォーク」とみなされる側を追っていた。
そこで私は CardanoScan の Ashish と連携し、彼のインフラから私たちのフォークを読み取れるように、我々のリレーを開放した。
これによって「目」が戻ったわけだ。
私は Cardano プロダクト委員会のチェアである Sam Leathers と直接メッセージのやり取りを始めた。
彼はチェーン間の分岐ポイントを特定するための診断ツールを素早く実装していた。
余談だが、ここは Amaru チームの大きな勝利でもある。
我々が提供してきたライブラリ群が、この診断ツールの基盤として役立ったからだ。
これは、ノード実装の多様性が生きた一例でもある。
このツールを使うことで、我々は分岐の原因となったトランザクションの生バイト列を取り出すことができた。
そして私は core IOG と CF のエンジニアたちとの Google コールにも招かれた。
ほぼ同じタイミングで、Andrew Westberg と私はそのトランザクションの不正なハッシュを特定した。
それは、本来の2倍の長さを持つステークプール識別子への委任証明（delegation certificate）だった。
本来は「easy1」というプールに委任するはずが、「easy1easy1」に委任していた、ということだ。
実際の委任証明ではプールはハッシュで参照されているが、ここでは説明しやすいようにティッカーを使っている。
レジャーチームはこのバグを素早く追跡し、いつ導入されたのかを特定し、修正を作成した。
ここまでの 1〜8 の流れは、いわば「知る必要のある人だけが知っている領域」で起きたことだ。
高度な専門知識を持つ人たち、テストネットを追っている人たち、Cardano 上でプロダクトを作っている人たち、
Cardano のコア開発者、Cardano Foundation や Intersect、Pragma、IOG といったコア組織──
そうした人たちの間で起きていた話であり、もしここで話が終わっていたなら、
大半の一般ユーザーは「そんなのどうでもいい」「ふーん」で終わっていたと思う。
テストネットを直し、メインネットにもパッチを当てて、「はい終わり」という話で済んでいたはずだ。
過去にもそういうことは何度もあった。
しかし今回、それとはまったく違う展開が起きた。
修正パッチが用意され、その存在をこの人物──Homer J──が知ることになった。
そして「9」から状況が一気にややこしくなる。
私はこの問題をかなり早い段階で知らされていた。
当時私はロンドンのギリシャ料理店 Milos にいて、オフサイトのワークショップでアガロスたちと話していた。
そこに Jerem が近づいてきて、ちょうどブッシュ大統領が 9.11 の報告を受けたときのような感じで
「ミスター・プレジデント、問題が発生しました」と耳打ちしてきた。
私は「何が起きた？」と聞いた。
彼は「テストネットがフォークしました」と答えた。
私は「おお、神よ。修正方法はわかっているのか？」と尋ねた。
彼らは「はい。すでにパッチは作成中で、対応を進めています」と答えた。
その時点で、私は「パッチをできるだけ早く出すためのレース状態になった」と理解した。
もちろん、こういう状況で Twitter に出て行って「今メインネットは脆弱です」と大声で叫んだりはしない。
それをやったら、メインネットの弱点を世界中に告げるだけだからだ。
やるべきことは、通常の責任ある開示手順に従い、SPO や関係者に連絡して
「問題があるので、ダウングレードするか、アップグレードするか、どちらかを選んでほしい。
フォークを起こさないバージョンに揃える必要がある」と伝えることだ。
この時点では、まだメインネット側は実際には攻撃を受けておらず、「脆弱だが、まだ刺されてはいない」状態だった。
問題が起きたのはここからだ。
ここで「氷山」にぶつかった。
9）2025年11月21日、15:02 頃。
私の時間だと 20:00〜20:30 前後だったと思うが、そのあたりで、メインネットに類似のトランザクションが投げ込まれた。
これも同様に、今度は「rats rats」への委任を行うものだった。
RATS は、私チャールズ・ホスキンソンの個人ステークプールである。
Homer J は、自身の証言によれば、この一連の流れをずっと追っており、関係者と直接コミュニケーションを取っていた。
そして、テストネットに何が起きたのか、メインネットも同じ条件下にあること、
そしてみんなが急いでパッチを出そうとしていることを十分理解していた。
Cardano エコシステムで 6〜7年も SPO をやってきた人間であれば、
この攻撃がシステム内部でフォークを引き起こすことは容易に想像できたはずだし、
すでに修正パッチが提供されている以上、「誰かがこの攻撃を利用する前に、自分たちが修正を適用する」のが
SPO としての責務であることも理解していたはずだ。
しかし彼はそうしなかった。
代わりに、その攻撃方法をリバースエンジニアリングし、メインネットでも動作させる方法を見つけ出し（AI を使ったのかどうかは不明だが）、
それをメインネットに実際に投げ込むかどうかの判断を下す立場になった。
そして、SPO である自分自身のプールを標的にするのではなく、
なぜか、自分があまり好ましく思っていない人物──つまり私の──プールを選んだ。
彼が私を好んでいないことは、偽の Fred Discord に参加していたことなどからも明らかだ。
ここから先は Pi 本人の文章ではなく、私独自の補足説明だが、
「彼は無実で、何をしているのか理解していなかった」と主張する人たちのために、少しメタ的な背景を示しておきたい。
1〜8 までの時点で、我々はすでにこの問題を「高い重大度を持つインシデント」として扱い、
トリアージと修正モードに入っていた。
つまり、メインネットが脆弱であることに気づいた時点で、すでに「ウォールーム」は立ち上がっており、
全員が「一丸となってできるだけ早く問題を解決する」というモードに入っていた。
そのため、多くの人が徹夜で対応にあたったのだ。
10）私はちょうどこの頃、偶然目を覚ました。
かなりひどい風邪をひいていて、その夜はほとんど眠れなかったのだが、そのときに
「メインネットでも同様の問題が起きている」という最初のメッセージを目にした。
Pi も同じような体験をしていて、「あ、やばい」と感じたと書いている。
Pi は、「Sunday Labs のインフラはすでにバグのない旧バージョンを使っているので、
この夜中に自分ができることはそれほど多くない」と判断し、
「むしろ翌日に備えて少しでも睡眠をとったほうがよい」と考えた。
そこで、他の人たちに対応を任せ、自分は休む決断をした。
夜のあいだに、IOG、CF、Intersect、多くの取引所、そして多数の SPO がノードをパッチバージョンにアップグレードした。
いわゆる「コール祭り」になった。
ウォールームに集まった人たちは、片っ端から電話をかけまくった。
「今すぐアップグレードしてくれ」「本当に急ぎだ」「今すぐやらないといけない」と。
最終的な公式の推奨は「より制限の厳しいフォークを選択すること」だった。
理論的には、「制限のゆるいチェーン」を選んだほうが、
そちらのほうがステークの多数を持っていたため、フォークをより早く解消できたかもしれない。
しかし、それには2つの大きな問題があった。
A）すでにテストネット段階での影響が確認された時点で修正版がリリースされており、
その後で「やっぱり方向転換します」と言い出すと、コミュニケーションが混乱し、
「本当の推奨は何なのか」がわかりにくくなってしまう。
B）より重大なのは、ウォレットや取引所などのオフチェーンツールが、
はるかに長く混乱状態に陥る可能性が高い、という点だった。
チェーンそのものは比較的素早く回復できたとしても、
エコシステム全体が受ける影響ははるかに長く続いたかもしれない。
たとえば Daedalus ユーザーは全員、自分のウォレットを手動でリセットしなければならなくなっていただろう。
あらゆるオフチェーンインフラが動かなくなり、エクスプローラーも数日から数週間は何も表示しなくなる。
その状態では、Cardano 上でまともに何かを動かすことはほぼ不可能だ。
要するに、Cardano のオフチェーンエコシステムが丸ごと1週間近くシャットダウンされ、
誰もが巨大な混乱を経験することになっていただろう。
今言ったのはむしろ控えめな表現であり、「大したことない」とはまったく言えないレベルだ。
だからこそ、我々は旧フォーク側（制限が厳しいほう）を選択した。
13）もう一方のチェーンは「pig chain（豚チェーン）」とあだ名が付けられた。
おそらく fat pool への委任が絡んでいたからだろう。
推奨された側のチェーンは「chicken chain（チキンチェーン）」と呼ばれた。
つまり「豚」と「鶏」のレースが始まったわけだが、この豚は本当にひどい豚であって、
ナイキの豚みたいにいい豚ではない。最悪の豚である。
一方で、鶏のほうは良い鶏であり、「私たちは鶏の方へ戻ろうとしている」というイメージだ。
午前4時頃には、既存のモニタリングツールが更新され、
pig chain 側のメトリクスも収集できるようになった。
これで、両チェーンの進捗と最終的な決着の見通しをリアルタイムで監視できるようになった。
その後、ウォールームでは、pig chain のメトリクスと chicken chain のメトリクスが
それぞれ別々のモニターに映し出され、両者の「レース」が観察された。
舞台裏では、誰がこの攻撃を仕掛けたのかを突き止める作業も進められていた。
これは主に、「今後も回復を妨害するような追加攻撃があるかどうか」を見極めるためだ。
午前4時から午前10時までのあいだ、チェーンは分岐状態が続いていた。
つまり、pig chain 上の不正トランザクションが「完全にイミュータブルになる」タイミングが、
chicken chain がそれを追い抜くまでの時間よりも先に来る可能性があった、ということだ。
もしそうなっていたら、pig chain を追っているノードは全て手動介入が必要になっていた。
ノードを停止し、データベースを切り詰めて、より長いフォークまでリプレイし直さなければならない。
Cardano には K というパラメータがあり、ざっくり12時間を過ぎると
「もうこの履歴は再編されない（mutable から immutable へ）」と見なすようになっている。
今回は、その閾値に近づきつつあった。
そのため、こうした不正な履歴を消すには、スクリプトを使って手動で状態をパージする必要があった。
つまり「復旧不能」というわけではないが、自動で直るわけではなく、
手動でパージするスクリプトを用意して実行する必要があった。
そのスクリプトは、ウォールームの中で作られ、その場で配布された。
午前11時頃、一筋の光が差し込んだ。
不正トランザクションがイミュータブルになるまでの推定時間が、
もう一方のフォーク（chicken chain）が追いつくまでの時間よりも長くなったのだ。
この時点で、「おそらく18時間以内にチェーンは完全に回復するだろう」と見通せるようになった。
これは、私の時間で言うと19:00 頃だったと思う。
正確には時差を確認する必要があるが、とにかく遅い時間帯だった。
もしかすると 17:00 かもしれないが、いずれにせよ我々はみんなへとへとで、
多くの人が前日の夜からずっと起き続けて、このレースをリアルタイムで見守っていた。
Pi は実際に、このときのグラフも掲載している。
この時点からは、主にチェーンをモニタリングしつつ、
後でこうした事後報告を書くための完全なデータダンプを確保する作業が中心になった。
SPO たちが次々とアップグレードを行ったことで、回復に必要な時間は徐々に短くなっていった。
そして 17:16 頃、chicken chain は pig chain を追い抜いた。
chicken chain は pig chain を追っていたノードにとっても依然として「有効なチェーン」だったため、
ノードは自動的により長い chicken chain 側へ切り替わり、
チェーンは完全に回復した。
「終わった」。
大変だったが、これで終わりだ。
ルートコーズ（根本原因）
ここまでを読み飛ばした人のために、バグのルートコーズをあらためて明示的に述べておく。
プール識別子、トランザクションハッシュ、アドレスなどのハッシュをパースする際、
各ハッシュには「期待される長さ」が存在する（28バイト、32バイトなど）。
理論的には、短すぎるハッシュや長すぎるハッシュは、どちらも「正しくない」として拒否されるべきである。
古いバージョンのノードは、長すぎるハッシュを正しく拒否していた。
しかし、2024年11月24日のコミットによって導入された、あまり目立たないコードパスの中に、
「長すぎるハッシュも受け入れてしまい、余分なバイトを切り捨ててしまう」という挙動が紛れ込んでいた。
つまり、「長さが不正なハッシュを丸めてしまう」という、ごく小さくて目立たないバグが根本原因だった。
それが実際にトリガーされ、その後、攻撃者がそれを悪用した。
分析
背景として、先に私が書いた「War Arrow」に関する説明を読んでおくことを勧める。
ここでは、この出来事に関して興味深いデータやグラフをいくつか紹介する。
ここにチェーンのグラフがある。
これが我々がウォールームで見ていたものだ。（笑）
上のグラフでは、時間に対する chicken chain（緑）の高さ、
pig chain（赤）の高さ、
そしてその差分（紫）が示されている。
赤いほうが pig chain だが、
緑の chicken chain が徐々に追い上げていき、その差が縮まっていく様子がわかる。
これは、私のキャリアの中で最も気持ちのいい「差分グラフ」だった。
見ていて本当に安心した。
このグラフは、我々が回復のペースを把握するために、何度も何度も更新して見続けていた。
私が目を覚ました頃には、ちょうど状況が好転し始めていて、
グラフもそれを映し出していた。
意義
このグラフは、Ouroboros の設計が選び取っている「収束パス」が、
どれほど明確で予測可能なものかを示している。
我々は、チェーンがいつ回復するのかを、数時間前の時点でかなり正確に予測できていた。
こうしたことができる暗号通貨は他に存在しない。
Ouroboros にはそれができる。これは Ouroboros プロトコルの収束性が持つユニークな特徴だ。
上に示した表では、イベント発生中に追跡されていたデータ──
各フォークでの1時間あたりのブロック数、
不正トランザクションがイミュータブルになるまでの時間、
そしてそれと回復までの時間との差──が示されている。
同じデータを別のグラフにしたものもある。
意義
このデータは、Cardano がインフラのアップグレードにどれほど俊敏に反応しうるのか、
そしてその状態がどれほど「流動的」であるかを示している。
回復のペースが加速したという事実そのものが、その証拠だ。
データを見れば、「回復が加速していく様子」が文字どおり可視化されている。
これは実に素晴らしい。
ブロック間隔についても興味深い点がある。
回復を助けた要素の一つとして、「ステークが動いた」ということが挙げられる。
pig fork 側ではブロック間隔が伸び、
chicken fork 側ではブロック間隔が短くなった。
12時間というのは現実世界の時間だが、分散システムの世界では時間は異なる形で動く。
いわゆる「Lamport clock（ランポート時計）」の話だ。
ある側ではコンセンサスへの参加率が下がれば、時間は「伸び」る。
一方で、参加率が上がれば時間は「縮む」。
つまり、一方の時計はどんどん遅くなり、もう一方の時計はどんどん速くなる。
今回、その性質が我々にとって有利に働いた。
チェーン切り替え
ここが、複数の監視対象 IoG ノードが pig chain を諦め、
より長い chicken chain（正しいチェーン）へ切り替えた瞬間だ。
グラフ上の一点で、ブロック高が「ピョン」と跳ね上がっている。
本当に美しいグラフだ。
セクシーですらある。
オイルでも塗って眺めたくなるレベルだ。
プールツールから見た同じ瞬間を動画にしたものもある。
意義
これは、ナカモトコンセンサスが設計どおりに機能し、
ネットワーク全体が単一の正史（canonical history）に収束したことを示す、
非常に具体的な証拠である。
二つのチェーンが、最終的に一つのチェーンに収束する様子がわかる。
pig chain 側のブロック伝播が悪化し、ブロック高が伸びなくなっていく一方で、
chicken chain 側はジャンプするようにブロック高を伸ばしていく。
カナリアトランザクション
Cardano Foundation はメインネットに対して定期的にカナリアトランザクションを送信するサービスを運用している。
これは単純な価値移転トランザクションであり、さまざまな有効期限（validity range）を持たせることで、
ネットワーク上での実際のインクルージョン遅延──つまり「普通のユーザーのトランザクションがどれくらいでオンチェーンに載るか」──を測定するものだ。
イベント期間中のインクルージョン時間のグラフを見ると、
一時的に 300〜450 秒にまで跳ね上がっていることがわかる。
普段はすべてが非常に高速に処理されているのに、
突然「いったい何が起きたんだ？」というレベルで
トランザクションがチェーンに載るまで 8〜9 分かかるようになっていた。
その後、1時間単位で平均を取った値は、徐々に 20 秒近辺まで戻っていった。
最初は「すべてが壊れたように」見えるが、徐々に元に戻っていく。
意義
このデータは、今回の事件中に「典型的なユーザー」がどんな体験をしていたのかを客観的に示している。
平均すると、おおむね 5 分程度の遅延でトランザクションがオンチェーンに載っていたと考えられる。
もちろん、一部のユーザーは全く違う体験をしていたかもしれないが、
それはたいてい、ウォレットや dApp といったサードパーティインフラの問題によるものだろう。
通常、そうしたインフラの問題は、ネットワーク側の問題を 2〜3倍に増幅して見せる傾向がある。
実際、Lace 側ではまさにそういう挙動を観測していた。
チェーン品質
もう一つ興味深い指標は「チェーン品質（chain quality）」だ。
これは「期待されるブロック数に対して、実際にどれだけブロックが生成されたか」の割合を測る指標である。
通常、ランダム化されたブロックスケジュールの影響で、100％の上下を行き来する。
つまり、多少のブレは普通にある。
しかし今回は、「一体何が起きたんだ？」というレベルで品質がゼロに落ち込み、
その後、chicken chain がブロックを積み上げるのにつれて、徐々に回復していった。
グラフを見ると、最終的にチェーン品質は再び本来あるべきレベルに戻っている。
メンプール
偶然にも、Leios チーム（24時間体制で動いている）が
「トランザクションがブロックに含まれる前に、どれくらいの頻度でノードのメンプールに届くか」を測定する実験を行っていた。
そのおかげで、この事件中にメンプールがどのような挙動をしたのかについて、興味深い洞察が得られた。
ここで重要な領域はグラフの「緑」の部分だ。
他のリージョンは、まだノードを立ち上げている途中だった。
大きな緑の落ち込みは、新しいフォークへアップグレードし、
データベースを再検証する必要があったために発生したものであり、
データそのものの喪失を意味するものではない。
このグラフからは、「チームがノードをアップグレードする決断を下すまでは、
多くのトランザクションがブロックに含まれる前にノードのメンプールに到達していた」ことがわかる。
これは健全な状態の挙動である。
また、トランザクションが両方のチェーンに届いていたことを示しており、
フォークのあいだもユーザーのトラフィックの大部分が生き残っていたことがわかる。
これは非常にユニークな性質だ。
通常、ネットワーク分断が起きると、ネットワークはほぼ完全に分断されてしまう。
しかし今回は、多くのノードが両方のチェーンのトランザクションを見ており、
これがダブルスペンドの発生を防ぐ方向に働いた。これは非常にクールな性質だ。
チェーン統計
これらの統計をきれいに可視化したグラフはまだ用意できておらず、
解析も進行中だが、関連するチェーンデータのダンプから
いくつかの初期的な知見を抽出することはできた。
pig chain 側では合計 846 ブロックが生成された。
これらは技術的にはすべて「孤立ブロック（オーファンブロック）」である。
pig chain には合計 6,847 件のトランザクションが含まれていた。
一方、chicken chain には合計 13,094 件のトランザクションが含まれていた。
chicken chain 側で最もブロック間隔が長かったのは 964 秒、約16分である。
両チェーンに共通して含まれていたトランザクションは 8,168 件であり、
pig chain のみに含まれ、chicken chain には含まれなかったトランザクションは 479 件だった。
ネットワーク分断の状況としては、これはかなり優秀な結果だ。
つまり、ユーザーのトランザクションのうち、勝ち側のチェーンに載らなかったものは 3.33％に過ぎない。
IOG はこれらのトランザクションを再送しようとしたが、すべて無効だった。
そのうち 23.16％は、有効期限（validity interval）外だったために失敗しており、
もしそうでなければ成功していたであろうトランザクションだ。
107 件は出力が不正で、すでに使われてしまった UTXO に依存していたか、
あるいはチェーン上に存在しないトランザクションを参照していた。
約 349 件は、入力が不正であると同時に有効期限外でもあった。
これらのトランザクションについては、今後さらに詳細な分析が必要になる。
フォレンジック的に1件ずつ調べていく必要があり、かなり時間がかかる。
なお、ここでの数字には、そもそも Cardano ネットワークまで届かなかったトランザクション──
たとえば、ユーザーとネットワークのあいだにあるサードパーティインフラの問題で弾かれたもの──は含まれていない。
それは Cardano の問題ではなく、「お金の送り方が間違っているだけ」という話になる。
さて、ここからが彼のレポートの中で最も重要な部分のひとつだ。
私が Pi を非常に評価している理由でもあるが、
我々にはこうした出来事について議論するときに共有できる「共通の語彙」が必要だ。
分類と歴史
ここで、私がブロックチェーンにおける大規模障害を分類するために使っている、
個人的なタクソノミー（分類体系）を紹介したい。
このタクソノミーは、他の有名ブロックチェーンで起きた歴史的な障害をもとに形成されたものである。
前回のインシデントについて書いたときにこのメンタルモデルを作っていたのだが、
そのときに文章として残しておかなかったのは残念だ。
（今はこうして書き残したので、Pi、よくやったと言いたい。今まさに多くの人がこれを読んでいる）
これは、私自身が事実に対して責任を持ち、
自分のキャリアを賭けているチェーンに対する「確証バイアス」を抑えるための試みでもある。
まず、「ソフトフォーク」と「ハードフォーク」という用語について、私なりの定義を述べる。
（Viagra の話ではない）
ソフトフォーク
ソフトフォークとは、二つのチェーンのコンセンサスに差があるものの、
一方のチェーンが受け入れているブロック集合が、他方のチェーンのブロック集合の「スーパーセット」になっている状態を指す。
例として、集合 {1,2,3} と {1,2,3,4} があるとする。
{1,2,3,4} のほうは {1,2,3} を完全に含んでおり、それにブロック 4 が追加されている。
このとき {1,2,3,4} は {1,2,3} のスーパーセットである。
この場合、ナカモトコンセンサスには「回復のチャンス」がある。
もしサブセット側のチェーン（{1,2,3} 側）がスーパーセット側（{1,2,3,4} 側）より長くなれば、
スーパーセット側のノードは自動的にそちらに切り替わる。
つまり、より制限の厳しいほう（1,2,3）を残し、不正なブロック（4）を捨てる。
一般的には、「新しいノードが、より古いノードの受け入れるブロック集合のサブセットを受け入れるとき」
それをソフトフォークと呼ぶことが多いが、私はそこまで時間方向に縛られた定義を有用だとは思っていない。
今回のケースではむしろ、旧バージョンのノードのほうが制限の厳しい側だったが、
それでも同じ性質（スーパーセット／サブセット構造）のおかげで、
最終的に収束させることができた。
ハードフォーク
ハードフォークとは、二つのチェーンが受け入れるブロック集合が「互いに比較不可能」な状態を指す。
一方のチェーンにとっては永遠に受け入れられないブロックが、もう一方のチェーンでは受け入れられている、
という状況が両方向で存在する。
この場合、手動介入なしに二つのチェーンが再び収束することはできない。
これは Solana が歴史的に経験してきたフォークで起きた現象だ。
ある出来事が引き金となって二つのチェーンが完全に分かれ、
最終的には人間が介入して編集し、無理やり繋ぎ合わせるしかなかった。
一方、ソフトフォークは、技術的な観点から言えば Bitcoin でも起きている。
マイナー A がブロックを見つけ、ほぼ同時にマイナー B もブロックを見つける。
すると次のブロックの取り合いになり、仮に B 側が勝てば、A 側のブロックはオーファンとなり捨てられる。
このとき、一方のチェーンのブロック集合は他方のスーパーセットになっている。
分類の優先度
以下に挙げるカテゴリは、「最も深刻なもの」から「比較的軽微なもの」へという順序で並べている。
最後のほうのカテゴリどうしの並び順については、議論の余地がある。
1）ソブリンティ侵害（Sovereignty violation）
リモートコード実行、署名の偽造、台帳上の資金の奪取などを可能にしてしまうバグやエクスプロイトで、
チェーンのコアな主権性と安全性を侵害するもの。
結果：信頼の完全な喪失。ほぼ回復不可能。
メジャーな L1 で実際に発生した既知の例はないが、
Bitcoin は 2018年の CVE-2018-17144（重複入力を許してしまう可能性があった）や、
2012年のコインベース重複バグ（理論上は署名偽造攻撃につながる可能性があった）など、
ギリギリのところまで行ったことがある。
ECDSA への量子攻撃などが現実化した場合は、
多くのチェーンがこのカテゴリに該当することになるだろう。
要するに、「誰かがあなたの秘密鍵を奪ったり、署名を偽造して資金を奪い取れる」ような世界だ。
これが最悪のパターンであり、チェーンは死ぬ。
Pi は触れていないが、かつて Zcash に存在したバグも、
理論上は「トークンを偽造できるが、ゼロ知識の性質上それが検出できない」という、
ソブリンティ侵害に近いものだった。
幸い、実際に悪用された形跡はないと見られている。
2）レジャー侵害（Ledger violation）
台帳のコアな保証を破壊するバグで、
「合理的な人なら誰でも、それは本来意図していたチェーンの姿ではない」と判断するような状態を引き起こすもの。
結果：深刻な信頼の喪失。
ケースバイケースで回復可能ではあるが、
信頼を取り戻すにはエンジニアリング体制に極めて大きな変革が必要になる。
例：2010年8月、Bitcoin で Value overflow bug が発生した。
その結果、1844 億4千万 BTC が生成されてしまった。
21,000,000 BTC という供給上限の 9,000 倍以上である。
つまり、「Bitcoin は 2,100 万枚しか発行されない」と言われているが、
2010年8月には実際に「1844億4千万 BTC」が存在していた瞬間があった、ということだ。
これは、プロトコルの精神に完全に反していると、
合理的な人なら誰でも認めざるをえない事態だった。
この問題を解決するために、Bitcoin はソフトフォークを行い、
オーバーフローを含むトランザクションを拒否するノードバージョンにマイナーをアップグレードさせた。
回復までには19時間かかった。
つまり、Bitcoin はこの問題を直すのに 19 時間かかっており、
Cardano が今回の問題を解決するのに要した 14 時間よりも長い。
Bitcoin の場合、問題の結果として 1844 億 BTC が誤って発行され、
その履歴は放棄され、旧ノードが新しい長いチェーンに切り替える形で修正された。
3）コンセンサス侵害ハードフォーク（Consensus violation hard fork）
中央集権的な意思決定主体が、事実上の強制力を持って
「ある時点以前にチェーンを巻き戻す」ようなノードバージョンを配布し、
コンセンサスルールを変更させるようなケース。
結果：ブロックチェーンのライフサイクル初期ならギリギリ許されるかもしれないが、
時間が経つにつれて許容されにくくなる。
代表例は Ethereum の DAO ハックだ。
スマートコントラクトの脆弱性によって資金が抜かれた事件に対し、
Ethereum は「特別なレジャールール」を追加し、
チェーンをハードフォークさせることで履歴を書き換えた。
Ethereum Foundation や取引所は、マイナーに対してこのフォークを選ぶよう強い圧力をかけた。
「このフォークを選ばなければ上場廃止になり、トークン価格がゼロになる」といった形で、
事実上の「強要」が行われた。
これは、私が Ethereum Classic に関わるきっかけにもなった出来事だ。
簡単に言えば、「気に入らない履歴を消すために、人間がチェーンを編集した」のである。
4）大規模チェーン再編ソフトフォーク（Large chain reorg soft fork）
バグやネットワーク状態によってコンセンサスが長時間にわたり分岐するが、
最終的には有機的に、あるいは社会的コンセンサスによって「自己修復」され、
ノード実装に永続的な変更を強制しないケース。
ただし、ブリッジや取引所といった特定のアプリケーションは、
リプレイ攻撃や「間違ったフォーク側にいること」によって金銭的損失を被るリスクがある。
たとえば、ボンディングを用いたスキームなど。
結果：極めてまれである限り、教訓の多い「回復可能」なインシデントと見なされる。
Polygon は 2022〜2023 年に、かなり大きなリオーグを複数回経験している。
今回の Cardano のインシデントも、このカテゴリに分類される。
つまり、「大規模なチェーン再編を伴うソフトフォーク」である。
5）スマートコントラクトのエクスプロイト（Smart contract exploit）
広く使われているプロトコルのスマートコントラクトにバグがあり、
ユーザーに大きな金銭的損失をもたらすケース。
主たる責任はスマートコントラクトの作者側にあるが、
そうしたバグを避けるのを難しくしている言語仕様にも一定の責任があることが多い。
結果：L1 自体は回復可能だが、バグの内容によっては懸念が残る。
こうした事故は無数に起きており、
合計すると1日あたり 8,000 万ドル規模の被害が出ている。
6）フルコンセンサス停止（Full consensus halt）
バグやネットワーク条件によってコンセンサスが完全に停止し、
人間の介入なしには一切前に進めなくなるケース。
結果：何度も繰り返されるようであれば、受け入れがたいレベルの問題。
Solana ではこのパターンの例がいくつもある。
Binance Smart Chain のブリッジエクスプロイトや、Avalanche のゴシップバグも類似の事例だ。
簡単に言えば、「チェーンが止まり、蹴飛ばして再起動しないと動かない」という状態だ。
場合によっては、再起動するためにチェーンを編集する必要すらある。
7）サービス劣化（Degradation of service）
バグやネットワーク条件によって、エンドユーザーに対するサービス品質が大きく低下するケース。
結果：回復可能。
例：Ethereum の Shanghai DOS 攻撃（サービス妨害攻撃）、
あるいは Sunday Swap のローンチ時（2022年1月23日のトラブル）など。
今回のインシデントの分類
上記のタクソノミーに基づくと、
今回起きたのは「大規模チェーン再編／ソフトフォーク」であり、
結果的に自己修復した事例である。
これは「深刻ではあるが、存在論的な（致命的な）危機ではない」というレベルの問題だ。
Cardano コミュニティには、稼働時間の実績についてやや鼻持ちならないところがあるので、
今回の災難を喜んで攻撃してくる人たちが大勢いるだろう。
それは理解できるし、ある意味「仕方ない」とも言える。
しかし私は、そうした人たちと不毛な「ストーリー戦争」をするつもりはない。
争っても無意味だからだ。
実際のところ、サービス劣化以外で最も懸念すべき点は、
チェーンフォークの存在を認識しておらず、
両チェーンに対するリプレイ攻撃のリスクに晒されていたシステムである。
たとえば、取引所が「間違ったフォーク側」にいて、
ユーザーがそこに資金を入金し、別のトークンに売却し、
さらに別チェーンへ出金できる状態になっていたとすると、
チェーン再編が起きたとき、取引所は一方的に価値を吸い取られる可能性がある。
現時点では、そうしたことが実際に起きたかどうかを確認する分析が続いているが、
取引所の迅速な対応と、pig chain にしか存在しないトランザクション数の少なさから考えると、
現段階では発生していない可能性のほうが高いと私は見ている。
私もそう思うが、数週間かけて検証する必要がある。
最終的に重要なのは次の点だ。
・チェーンは進み続けていたか？
→ はい。
・サービスは劣化したか？
→ はい。
・資金が危険に晒された人はいたか？
→ 一部の人にとっては潜在的にイエス。
・Cardano ネットワークは、事実上「最悪に近い条件」のもとで回復に成功したか？
→ はい。
・自分のビジネスをこの程度の堅牢性を示したインフラの上に構築することに自信が持てるか？
→ 間違いなくイエスだ。
良かった点と悪かった点
では「良かった点」と「悪かった点」について話そう。
まず良かった点からだ。
今回の一件を通じて、Cardano のエンジニアリングの卓越性と分散性が際立った。
一部の人たちには「やりすぎなほど慎重」に見えていたいくつかの設計判断が、
その真価を発揮した場面がいくつもあった。
また、Cardano がフォークに対してどのように自らを防御しているのかについて、
私自身、新たな発見がいくつもあり、非常に感銘を受けた。
1）まず、ノード実装が「メモリ安全性を極めて重視する言語」で書かれていることに、改めて強く感謝している。
バッファ境界チェックの不備によるシリアライズ／デシリアライズのバグは、
他の多くの言語では非常に危険な結果を招きかねない。
たとえば C や C++ のような言語で同じバグがあれば、
任意コード実行を可能にする脆弱性に直結していてもおかしくない。
そうなれば、攻撃者が多くの SPO の秘密鍵を抜き取り、
チェーンやそこに紐づく資金を完全に掌握することすら想像できる。
つまり、もし我々が C で実装していたら、今回は「詰んでいた」可能性が高い。
チェーンは壊れ、死んでいたかもしれない。
しかし、Haskell で実装していたおかげで、それを回避できた。
Rust でも同じように回避できただろう。
私は、IOG が長年にわたって「高保証エンジニアリング」を重視してきたことに、非常に感謝している。
今回、8年間で初めて大きなバグが表面化したからといって、
それ以前に数えきれないほど多くのバグが未然に防がれてきた事実が消えるわけではない。
どんなソフトウェアも完全ではないし、我々は「墜落せずに帰ってきた飛行機」しか目にしない。
Cardano の場合、8年間で大きなバグは1件。
これは悪くない数字だ。
2）次に、創業団体が維持しているレポート／モニタリング基盤には強く感心した。
独立したフォークそれぞれの状態、ノードが動かしているバージョン、
各フォークでのブロック生成速度などを追跡し、
必要なツールをその場で実装していくことができた。
Amaru のライブラリや、カナリアトランザクション基盤などは、
フォークの最中に「どの SPO にどう連絡すべきか」「どのようなコミュニティ戦略を取るべきか」を判断するうえで、
極めて重要なインサイトを提供してくれた。
まだ改善の余地は多くあるが、現状でもかなりのレベルにあることは間違いない。
3）Ouroboros のエレガンスにも改めて感銘を受けた。
今回、アガロスと一緒にいられたのは本当に良かった。
我々は 2016 年に紙の上で Ouroboros を設計し、
「こういう攻撃が起こりうる」と想定しながら議論してきたが、
今回、まさにその種類の攻撃をプロトコルが実際に耐え抜く姿を目の当たりにした。
私は以前から、2,160 ブロック（約12時間）を「ロールバック限界」とする設計は知っていたが、
「真のファイナリティには 3 倍の時間（36 時間）を待つべきだ」という、
ややマニアックな知見がなぜ出てきたのかについては、長らくピンときていなかった。
今回のイベントで、それがようやく腹落ちした。
ネットワーク分断が起きた場合、両方のフォークでチェーン密度が低下する。
その結果、どちらのチェーンも 2,160 ブロックの深さに到達するまでの時間が長くなる。
つまり、ストレス時にはロールバック可能な時間窓が自動的に伸びるのだ。
これは、フォークの深刻度に応じてロールバックの限界が伸びる「自己調整メカニズム」であり、
数学的なエレガンスを体現している。
危機が起きたとき、時間は我々の味方として働く。
4）ネットワーキングスタックの設計にも、いくつもの素晴らしい点があった。
ホット／ウォーム／コールドといったピア構造のおかげで、
多くのノードは素早く「自分と同じチェーンを追っているピア」を見つけることができた。
pig fork 側のチェーン密度が下がると、ノードは「セーフモード」に移行し、
より慎重にピアを選ぶようになる。
セーフモードでは、ノードはブートストラップピア（今は EMURGO と Cardano Foundation）
およびローカルの信頼できるルートだけを頼りにするようになる。
ちなみに、Bitcoin にも同じようにブートストラップノードがハードコードされている。
各 SPO は、自分のブートストラップピアやローカルトラストピアを指定できるので、
ネットワークの「信頼の背骨」は各 SPO の手に委ねられている。
今回、そのようなピアたちは他よりも早くアップグレードされていたため、
pig chain のブロックが広がるのを防ぎ、チェーン密度をさらに下げ、
結果として Cardano ネットワークの回復を助ける方向に働いた。
5）プロトコルが互いに独立しているおかげで、
フォーク中もトランザクションの大部分が広く伝播し続けていたことも特筆すべき点だ。
その結果、フォークのあいだも、ほとんどのユーザートランザクションが両チェーンに届いており、
サービスは大きく劣化しつつも完全には止まらなかった。
ただし、このことは一方で、特定のアプリケーションがネットワーク分断やチェーンフォークなどの状況に対して
より防御的に振る舞う必要があることも意味している。
今後、こうしたメトリクスをどのように公開していくか、
ダブルスペンドリスクに備えるための設計パターンをどう整備するかについて、
議論が行われるだろう。
6）「分散性」にも強い感銘を受けた。
ここでいう分散性は、単なるバズワードではない。
ノードバージョンの多様性は、パラドキシカルに言えば「問題の源」であると同時に
「回復を助けた要因」でもあった。
もしすべてのノードが完全に同じバージョンだったら、今回の問題はそもそも起きなかったかもしれない。
しかし、現実にはこれほど大規模な分散システムにおいて、
完全な一様性を期待するのは非現実的だ。
そのため、一部のノードが旧バージョンのまま残っていたことで、
pig chain の拡散が抑えられ、回復が加速される結果になった。
将来的には、実装の多様性も同じ役割を果たすことになるだろう。
実装ごとに挙動の差異が出るリスクは高まるが、
逆に言えば「どれか一つの実装のバグがネットワーク全体を吹き飛ばす」リスクは下がる。
7）コミュニケーションインフラも見事だった。
Discord、Slack、Telegram、メール、Twitter など、
多様なチャネルを通じて数千人規模の SPO に連絡を届けることができた。
ウォールームには、創業3団体だけでなく、
Intersect、Andrew Westberg のような技術的リーダー（彼は本当にヒーローだった）、
取引所や dApp の代表者など、さまざまな組織のメンバーが参加していた。
どこか一つの団体が「どのフォークを採用するか」を一方的に決めたわけではなく、
多くの関係者が議論に参加して結論を出した。
他にも評価すべき点はたくさんあるが、特に印象に残ったのはこのあたりだ。
悪かった点
とはいえ、Cardano に足りなかった部分も、きちんと正面から見なければならない。
今回のインシデントは、改善すべき領域もはっきりと浮き彫りにした。
1）逸話ベースではあるが、多くのユーザーは、
カナリアテストが示すものよりもはるかにフラストレーションの大きい体験をしていたようだ。
Cardano Foundation には、この点についてさらに強化を図り、
Blockfrost やウォレットなどのエコシステムインフラと連携しながら、
「ある時点の典型的なユーザー体験」をより正確にトラッキングできるようにしてほしい。
いわば「本物のカナリア」をもっと良くする必要がある。
2）多く、もしくはすべてのチェーンエクスプローラーが Cardano DB Sync に依存しているため、
DB Sync の単一コンポーネントにバグがあると、我々は一気に「目を奪われた」状態になってしまった。
このレイヤーでのアーキテクチャの多様性も必要だ。
2026年以降、他のノード実装が出てくるタイミングで、ここは大きく改善されるだろう。
3）そもそも今回のようなバグが紛れ込んでいたこと自体、
テストの厳密さという点では失敗だと言わざるを得ない。
Cardano は歴史的に、この領域では非常に優れた実績を持っている。
ただ、ここ1年半ほど、ガバナンスなど新機能のリリースプレッシャーが極めて強かったこともあり、
テストに割けるリソースが一時的に引っ張られていた側面があるのではないか──
これはあくまで私の推測だが、そう感じている。
もちろん、時間が経てばたつほど、どんなソフトウェアにも
「一定期間内に少なくとも一つバグが発生する確率」は高まっていく。
8年間で一つの大きなバグ、というのはそういう分布の中で起きた一件とも言える。
それでも、今回の件についてはきちんとポストモーテムを行い、
新しいツール、新しい手続き、新しいポリシーを導入していく必要がある。
4）Sebastian（E のほう。DC Spark 出身で、現在は Midnight の CTO）
が提唱している「仕様からコードを自動生成し、ファジングを行う」アプローチは、
まさに今回のような事態を防ぐのに適していると思う。
実装からスペックを生成するのではなく、
スペックから実装を生成し、その上でテストを行うべきだ。
実装から仕様を逆算するのは本末転倒であり、
Project Blueprint はまさにその問題を解決しようとしている。
これは、Sunday が関わっている Amaru や Acropolis にとっても非常に重要なポイントだ。
実装の微妙な挙動差が、ソフトフォークではなくハードフォークを生み出してしまう危険がある。
私は、代替ノード実装を早まって作ることに対して慎重だったが、
まさにこの理由による。
仕様やテスト戦略、認証プログラム、カナリアネットなどが揃う前に
複数実装を増やすと、
「違う決定のスタック」が積み重なっていき、
いざというときにネットワークを再度ひとつにまとめるのが非常に難しくなる。
Sebastian（A のほう）が率いる Cardano Blueprint イニシアチブは、
「Cardano ノードとは何か」を正式にドキュメント化し、仕様化することで、
そのリスクを下げようとしている。
つまり、代替実装を作る前に、
・形式仕様
・テスト戦略
・認証プログラム
・カナリアネット
を整備する、というアプローチだ。
5）dApp・ウォレット・取引所が、チェーンやネットワークの健全性をよりよく把握できるようにする
「ノードからクライアントへのミニプロトコル」も必要だと思う。
公式 API や、サーキットブレーカー／ファイナリティウィンドウ（どこまで遡るリスクを許容するか）に関する設計パターンを整備することで、
今回のようなインシデントに対してより強靭なアプリケーションを作れるはずだ。
これは今後必ず整備されるべきだ。
6）どのフォークを選択するかについての社会的コンセンサスは、かなり堅牢だったが、
まだ改善の余地はあると感じた。
多くの SPO は、おそらく「創業団体の推奨を信頼するしかない」という形で判断していたと思う。
フォークの意味や、さまざまな仮想シナリオにおける影響を十分に理解していたとは言い難い。
理論上は、こうしたプロセスが悪用されて、
悪意のある形でチェーンがフォークされてしまうシナリオも描ける。
我々は、Ouroboros がどのように動くのか、そのインプリケーションは何か、
そして時間的制約が厳しい状況であっても、各 SPO ができるだけ自律的に判断できるように、
教育やドキュメンテーションをもっと充実させる必要がある。
ここで、私が特に良いと思うアイデアがある。
すべてのステークプールオペレーターに配布できる「AI ベースのアップグレード・センチネル」を作ることだ。
SPO がアップグレード通知を受け取ったとき、その AI が
・どんな質問を投げかけるべきか
・どんなテストを実施すべきか
を一緒に考えてくれるようなシステムにすれば、
彼らは「盲目的にアップグレードする」のではなく、
ある程度の検証を行ったうえで判断できるようになる。
全ての SPO が Agelos Kiayias や Duncan Coutts、Pi のように
プロトコルを深く理解しているわけではないので、
そのギャップを埋める役割を AI に担わせることができる。
これは比較的短期間で作れると思うし、
トレジャリー資金を充てる価値もある。
もしコミュニティ内でやってみたい人がいれば、面白い実験になるだろう。
継続的にアップデートしていけば、やがて人間の能力を超えるサポートができるようになる。
ネットワークを迅速に「予防接種」するためのレイヤーとして、とても有用になるはずだ。
7）これに関連して、最近の動画で Charles Austin が提案していた「組み込み pub アーキテクチャ」も
非常に有望だと思う。
これは、Cardano ノードが形成するグローバルネットワークを活用し、
さまざまな用途のためのメッセージをブロードキャストできる
追加プロトコルのようなものだ。
こうしたネットワークがあれば、Intersect や他の組織が
「緊急アップグレードの必要性」を SPO に即座に伝えることができたはずだ。
これは Cardano に多くの新しい可能性をもたらす追加機能にもなりうる。
結論
最終的には、どんなチェーンであっても、
「たった1つの悪意あるトランザクション」で似たような事態が起きる可能性があると考えるべきだ。
「午後2時。あなたは自分の子どもがどこにいるか知っていますか？
そして、その友だちは誰か知っていますか？」
それと同じように、「1つの悪いトランザクション」で何が起きうるかを考える必要がある。
適切な呪文を見つけてしまえば、どのチェーンも同じ脆弱性を抱えているかもしれない。
Twitter の議論のためではなく、自分自身の心の平穏のために、
あなたが好きなチェーンがこうしたコンセンサス崩壊にどう耐えうるのか、
一度真剣に考えてみてほしい。
私は今回の出来事を経て、Cardano に対する印象はむしろ高まったし、
同時に自分自身の「やるべきことリスト」も増えた。
今後、さらに改善していきたいと思っている。
Pi、本当にこのレポートを書いてくれてありがとう。
膨大な時間と労力をかけてくれたし、
ネットワークのためにいつも素晴らしい仕事をしてくれている。
長い一日であり、長い一週間だった。
我々は必死に持ちこたえた。
しかし、その「事前の宿題」をしっかりやってきたからこそ、今回生き延びることができた。
この攻撃は、他のチェーンなら致命傷になっていてもおかしくないものだった。
リンクはそこにあるので、みなさん自身でも読んでほしい。
ただ、今こうして私がコメントを挟みながら読み上げたため、
元は 26 分の読み物だったものが、48 分の読み物になった。
それでも、皆さんの役に立ち、今回の出来事について理解を深める助けになったなら嬉しい。
Twitter の 99％は、情報が不十分で、反射的で、
率直に言えば「その意見にはほとんど価値がない」。
大事なのは、2025年11月24日の時点で、
Cardano が「ひとつのチェーンとして稼働している」ということだ。
そして、攻撃を受けたときよりも、今のほうが強くなっているということ。
これからもポストモーテムの作業は続き、
誰も気にしないような部屋で、技術者たちが大勢集まり、
どうやってさらに強くするかを延々と議論することになる。
その結果として、Cardano は 2026 年には
「ただの良いチェーン」でも「優れたチェーン」でもなく、
「人類がこれまで作り上げてきた中で最も信頼性の高い分散システム」になっているはずだ。
そこに到達するまでには時間もかかるし、やるべきことも山ほどある。
しかし、次に同じようなことが起きたとき（そしてバグは必ずまた起きる）、
今回はより早く対処できるだろう。
それは「完璧」であるという意味ではない。
誰も間違いを犯さないという意味でもない。
エコシステムとして、我々はこれからも間違いを犯す。
重要なのは「どうやってそれを修正するか」であり、
我々はこれからも誠実にそれに向き合っていくということだ。
今回の対応に関わった全ての人に感謝したい。
今回の一件で、Cardano の分散性が実際どう機能しているかがよくわかったはずだ。
もし Cardano に対して公平な目を向け、この出来事がどう進行し、どう解決されたかを見てくれれば、
きっと「かなり印象的な対応だった」と感じてもらえると思う。
もしあなたが単なる Twitter のトロールなら──
なぜあなたの意見が重要だと思うのだろうか？
あなたの意見には意味がない。
ポール・ハーベイの言葉を借りれば、
「これが物語の残りの部分だ」。
それでは皆さん、ありがとうございました。お疲れさま。
