Ethereum ネットワーク大トラブル！Prysm バグの全貌

みなさん、こんにちは。今回は 2025 年 12 月 4 日に起きた Ethereum ネットワークの大きなトラブルについてお話しします。Prysm というコンセンサスクライアントのバグが原因で、ネットワークの安定性が一時的に危ぶまれた事件です。

Fusaka アップグレード直後に発生した Prysm のバグ

この問題は Fusaka というアップグレードが適用された直後、epoch 411392（2025 年 12 月 4 日 21:49 UTC）に Prysm クライアントで発生しました。具体的には、特定の証明処理（attestations）を処理する際に、過去の状態情報を再計算する負荷が非常に高くなり、リソースが枯渇してしまったのです。

その結果、Prysm を使うバリデーターの参加率が通常の 95% 以上から 75% まで急落し、41 エポック分の報酬約 382 ETH が失われました。Prysm 開発チームは緊急のランタイムフラグを導入し、その後 v7.0.1 と v7.1.0 で恒久的な修正を行いました。

ネットワークの最終確定性（finality）を危うくしたリソース枯渇

このバグの核心は、古い履歴状態の再生が大量に並行して行われることでノードがサービス拒否状態（DoS）に陥ったことにあります。Prysm のコア開発者によると、過去の状態は計算とメモリの負荷が非常に重く、これが原因でノードが機能不全に陥ったとのことです。

Prysm はネットワーク全体のバリデーターの約 15% から 22.7% を占めていましたが、この性能低下により Ethereum は最終確定性を失う寸前まで追い込まれました。もし Prysm ではなく Lighthouse など別のクライアントで同様の問題が起きていたら、最終確定性の完全な喪失もあり得たとされています。

最終確定性が失われると、Layer 2 のロールアップ処理が停止したり、バリデーターの引き出しができなくなったりする可能性がありました。

ちなみに Fusaka アップグレード自体は、Layer 2 のスケーリングを大幅に向上させる PeerDAS 技術を導入し、ダウンタイムなしで成功裏に実行されていました。

多様なクライアントが Ethereum ネットワークの崩壊を防ぐ

Ethereum の強みの一つはクライアントの多様性にあります。Prysm が問題を抱える中でも、Lighthouse、Nimbus、Teku など他の 10 種類のコンセンサスクライアントは正常に動作し続けました。

このため、全体の 75% から 85% のバリデーターは通常通り稼働し、ネットワークの最終確定性が保たれ、トランザクション処理も継続されました。

Ethereum Foundation は Prysm のオペレーターに緊急対応を呼びかけ、バリデーターは一時的な修正を適用。開発チームは恒久的な修正を迅速にリリースしました。結果として、翌日には参加率がほぼ 99% に回復し、正常な状態に戻っています。

今回の事件は、Ethereum のクライアント多様性がネットワークの安全性を高める重要な役割を果たしていることを改めて示したと言えそうです。技術的なトラブルがあっても、分散された仕組みが大きな障害を防いでいるのは心強いですね。引き続きウォッチしていきたいですね！