イーサリアムFusakaアップグレード事件の解析：Prysm事後レポートが失敗の根本原因を明らかに

Prysm 開発チームは近日、事後分析レポートを公開し、2025年12月4日のFusakaアップグレード後に発生したメインネットの異常事象について詳細に説明しました。この問題は一時的にイーサリアムネットワークの安定性を脅かしましたが、最終的にはクライアントの多様性メカニズムの働きにより解決されました。

レポートによると、問題はFusakaアップグレードの有効化後の第411,392エポック（12月4日 21:49 UTC）で発生しました。Prysmコンセンサスクライアントは、特定の証明データを処理する際に、多数の履歴状態の重複計算を引き起こし、CPUとメモリリソースが急速に枯渇し、ノードはサービス拒否（DoS）状態のパフォーマンス低下を招きました。これはプロトコル設計の欠陥ではなく、クライアントの特定の境界条件下での実装問題です。

影響を受けたPrysm検証ノードは全ネットワークの約15%から22.71%を占めています。事件期間中、検証者の全体参加率は正常な95%以上から約75%に急落し、ネットワークは連続して41エポックを逃し、約382 ETHの証明報酬を失い、一時的に最終性を失う危険に瀕しました。Prysmのコア開発者Terence Tsaoは、履歴状態のリプレイ計算量が非常に大きく、マルチスレッド並列処理がトリガーされるとノードのパフォーマンスが著しく低下すると指摘しています。

注目すべきは、Fusakaアップグレード自体は成功したことです。このアップグレードではPeerDAS（ピア・データ可用性サンプリング）技術が導入され、Layer 2のblob容量を元の8倍に拡大することを目的としていました。アップグレードの過程でダウンタイムやコンセンサスのフォークは発生しませんでした。

イーサリアムネットワークがより深刻な結果を回避できたのは、クライアントの多様性が鍵となっています。Prysm以外にも、Lighthouse、Teku、Nimbusなどの他の10のコンセンサスクライアントがこの過程で正常にブロックを生成し、約75%から85%の検証者が継続的にオンラインを維持したため、ネットワークの最終性は破壊されませんでした。もしこのような問題がより高い割合のクライアントで発生した場合、Layer 2のサマリー停止や検証者の引き出し遅延など、より深刻な結果を招く可能性があります。

事件後、イーサリアム財団は迅速に緊急ガイドラインを発表し、Prysmチームは一時的なランタイム修正を展開し、v7.0.1およびv7.1.0で恒久的な解決策を導入しました。12月5日までにネットワークの参加率はほぼ99%に回復し、イーサリアムメインネットは24時間以内に正常運用に完全復帰しました。