EthereumのFusakaアップグレードを台無しにしたのは何か？ Prysmの事後調査が原因を明らかに

Prysmの開発者は、Ethereumネットワークの安定性を脅かした2025年12月4日のFusakaメインネット事故の事後分析を発表しました。
要約

• Fusaka後のPrysmのバグにより、バリデーターの参加率が75%に低下しました。
• ネットワークは41エポックを逃し、約382 ETHの証明報酬を失いました。
• Ethereumは、クライアントの多様性と迅速な修正により、確定性の喪失を回避しました。

コンセンサスクライアントは、特定の証明を処理する際の高価な状態再計算によるリソース枯渇により、運用上の深刻な問題に直面しました。

このバグは、2025年12月4日、UTC 21:49にエポック411392でFusakaが起動した直後に明らかになりました。

ネットワークは41エポックを逃し、バリデーターの参加率が75%に低下し、証明報酬の約382 ETHの損失となりました。 Prysmの開発者は、恒久的な修正を実装する前に緊急のランタイムフラグを展開しました（バージョンv7.0.1およびv7.1.0）。

リソース枯渇は確定性喪失に向かわせる

この技術的な失敗は、影響を受けたノードに対してサービス拒否（DoS）状態を引き起こす古い履歴状態に集中していました。

Prysmのコア開発者のTerence Tsaoは、「履歴状態は計算メモリを多く消費し、並行して多くの状態再生が行われるとノードがDoS攻撃を受ける可能性がある」と説明しています。

Prysmを実行しているバリデーターは、ネットワーク全体のバリデーターの約15%から22.71%を占め、深刻なパフォーマンス低下に直面しました。正常時の95%以上だった参加率が75%に低下し、Ethereumは危険なほど確定性を失う危機に瀕しました。

もしこのバグがPrysmではなく、Lighthouseなどの別のコンセンサスクライアントに影響した場合、ネットワークは完全に確定性を喪失していた可能性があります。

そのような事態は、Layer 2のロールアップの運用を凍結し、開発者が問題を解決するまでバリデーターの引き出しをブロックすることになったでしょう。

Fusakaのアップグレード自体は、Layer 2のスケーリング向けに8倍の容量増加を目的としたPeerDAS (Peer Data Availability Sampling)技術を導入しました。

このアップグレードは、Prysmのバグが表面化する前にダウンタイムゼロで成功裡に完了しました。

10のコンセンサスクライアントがEthereumネットワークの崩壊を防ぐ

Ethereumのクライアント多様性構造により、壊滅的な失敗を回避しました。 Prysmのバリデーターが苦戦する一方で、Lighthouse、Nimbus、Tekuを含む他の10のコンセンサスクライアントは、中断なくブロックの検証を続けました。

分散型クライアント構造により、約75%から85%のバリデーターが危機の間も通常運用を維持し続け、確定性の喪失を防ぎ、Prysmの状態低下にもかかわらずネットワークはトランザクションの処理を継続しました。

Ethereum財団は、Prysm運用者向けに緊急のガイダンスを迅速に発表しました。バリデーターは一時的な修正を適用し、Prysmの開発者は恒久的な解決策を構築しました。

12月5日までに、ネットワークの参加率はほぼ99%に回復し、事故から24時間以内に正常運用を取り戻しました。