Ethereumバリデーターに、古い状態リスクのためPrysmの無効化を指示

Prysmコンセンサスクライアントを使用しているEthereumバリデータオペレーターは、12月4日に緊急アラートを受け取りました。Prysmチームは、一部のノードが古い状態を生成し、過去のアテステーションを処理していることを確認しました。これを放置すると、検証動作が誤ったものになってしまう可能性があります。これを防ぐために、Prysmはすべてのオペレーターに対し、ビーコンノードに特定のフラグを追加して、すぐに機能を無効にするよう指示しました。この修正にはクライアントの完全なアップグレードは必要なく、バリデータクライアントにも影響しません。

チームはオペレーターに次の行を追加するよう指示しました：–disable-last-epoch-targets。このフラグはPrysm v7.0.0で動作し、ほとんどのノードは数分で修正を適用できます。この警告はバリデータコミュニティ全体で迅速な対応を引き起こしました。これはPrysmがEthereumのコンセンサスレイヤー内で大きな存在感を持っていることを示しています。

Prysmの市場シェアがネットワークレベルのイベントへ

MigaLabsのデータによると、PrysmはEthereumのコンセンサスクライアント市場シェアの約20%を占めています。これはLighthouseに次ぐ第2位のクライアントです。この規模だからこそ、クライアントサイドのバグがチェーン全体の懸念事項となりました。このような大きなシェアを持つクライアントが古い状態データを処理すると、それは単一のバリデータにとどまらず、次のような影響を及ぼす可能性があります：

• アテステーションの欠落
• 誤ったフォークチョイスシグナル
• ケースによってはペナルティやスラッシングのリスク増加

現時点では、この問題に関連したチェーン停止やファイナリティ障害の証拠はありません。しかし、これは損害制御ではなく、リスク防止に関する懸念です。Prysmは状況が悪化する前に対応しました。言い換えれば、これは事後処理ではなく、事前の火災訓練です。

Prysm内部で何が起きたのか

Prysmチームによると、影響を受けたノードは、過去のエポックからの古いアテステーションを処理しようとした際に、不要な古い状態を生成していました。この動作はCPUやメモリの負荷を増加させ、ストレス下でノードがチェーンの進行状況を追跡する方法を歪める可能性があります。この種の動作はEthereumの歴史で新しいものではありません。以下のような時期にも同様の状態管理問題が発生しています：

• 2023年5月のファイナリティインシデント
• 以前のデータベースインデックス破損バグ
• 複数クライアントにおける過去のメモリスパイク問題

今回の大きな違いは「対応の速さ」です。Prysmは問題を早期に検出し、ワンステップの回避策を公開。数千のバリデータが慌てて完全アップグレードする事態を回避しました。

バリデータが今すぐやるべきこと

Prysmを運用している場合、チェックリストは短く、かつ緊急です：

• –disable-last-epoch-targetsフラグを追加
• ビーコンノードを再起動
• ログで正常なアテステーションフローを確認
• 再起動後にメモリとCPUを監視

バリデータキーの変更は不要です。再同期も不要、エグジットも不要です。Ethereum全体にとって、この出来事は「クライアントの多様性が依然として重要である」というおなじみの事実を再認識させます。1つのクライアントがネットワークの約20%を占めると、扱いやすいバグでさえ見出しになるイベントになるのです。それでも、このインシデントはEthereumの運用成熟度も示しています。問題は数日ではなく数時間で特定、開示、緩和されました。これが、$400B+規模の決済レイヤーが堅牢性を保つ方法です。現在、チェーンは安定しています。唯一の本当の締め切りは、Prysmオペレーターが迅速に対応し安全スイッチを切り替えることです。