Prysmの開発者たちは、イーサリアムブロックチェーンの安定性を脅かした12月4日のFusakaメインネット事故について、事後分析を発表しました。
コンセンサスクライアントは、特定の証明を処理する際に高コストの状態再計算によりリソース枯渇に苦しみ、バリデーターに深刻な運用問題を引き起こしました。
このバグは、2025年12月4日21:49 UTCにエポック411392でFusakaが有効化された直後に表面化しました。
バリデーター参加率が75%に急落したため、ネットワークは41エポックを逃し、約382 ETHの証明報酬が失われました。Prysm開発者たちは、バージョンv7.0.1とv7.1.0で恒久的な修正を実装する前に、緊急ランタイムフラグを展開しました。
技術的な障害は、影響を受けたノードにサービス拒否状態を作り出した古い履歴状態に集中していました。
Prysmのコア開発者であるTerence Tsaoは、「履歴状態は計算メモリを大量に消費し、並行して発生する多数の状態リプレイによってノードがDoS攻撃を受ける可能性がある」と説明しました。
ネットワークバリデーターの約15%から22.71%を占めるPrysmを実行していたバリデーターは、深刻なパフォーマンス低下に直面しました。通常95%以上から75%への参加率の低下により、イーサリアムはファイナリティを失う危険な状態に近づきました。
もしこのバグがPrysmではなくLighthouseのような別のコンセンサスクライアントに影響していたら、ネットワークは完全にファイナリティを失っていた可能性があります。
そのような事態は、レイヤー2のロールアップ操作を凍結し、開発者が問題を解決するまでバリデーターの引き出しをブロックする可能性がありました。
Fusakaアップグレード自体は、レイヤー2のスケーリングのためにブロブ容量を8倍に増やすように設計されたPeerDAS(Peer Data Availability Sampling)技術を導入しました。
Prysmのバグが表面化する前に、アップグレードはダウンタイムゼロで正常に実行されました。
イーサリアムのクライアント多様性アーキテクチャが壊滅的な障害を防ぎました。Prysmバリデーターが苦戦する中、Lighthouse、Nimbus、Tekuを含む他の10のコンセンサスクライアントは中断なくブロックの検証を続けました。
分散型クライアント構造により、危機の間も約75%から85%のバリデーターが正常な運用を維持しました。これによりファイナリティの喪失を防ぎ、Prysmの状態が低下しているにもかかわらず、ネットワークはトランザクションの処理を続けることができました。
イーサリアム財団はPrysm運用者向けに緊急ガイダンスを迅速に発行しました。バリデーターは一時的な修正を適用する一方、Prysm開発者たちは恒久的な解決策を構築しました。
12月5日までに、ネットワーク参加率はほぼ99%に回復し、事故発生から24時間以内に通常運用が復旧しました。


