イーサリアム Prysm クライアント事故の振り返り：1つのエポックで248ブロック欠落、バリデーターが382 ETHを損失

【比推】12月4日、イーサリアムメインネットは比較的深刻な技術的混乱を経験しました。Prysmクライアントチームは最近、詳細な事故分析レポートを公開し、その当時の状況を振り返っています。

その日Fusaka時間帯、Prysmフェザーノードは特定のattestationsを処理する際に大きな問題を引き起こしました——ノードのリソースが瞬時に枯渇し、バリデーターのリクエストが滞り、ブロックと証言の多くが欠落しました。数字は非常に衝撃的です：epoch 411439から411480まで、42エポックの期間において、1344スロット中248ブロックが欠落し、欠落率は18.5%に達しました。ネットワークの参加率は一時75%まで低下し、バリデーターは約382 ETHの証言報酬を失いました。

根本的な原因は何でしょうか？Prysmは同期を失った可能性のあるノードから送信されたattestationsを受信しました。これらのデータは前のepochのブロックルートを引用しています。これらのデータの合法性を検証するために、Prysmは何度も古いepochの状態を再生し、高コストのepoch transition操作を実行しなければなりませんでした。並行リクエストの積み重ねにより、最終的にノードはリソース枯渇を引き起こしました。興味深いことに、この不具合はPrysm PR 15965に起因し、1ヶ月前にはすでにテストネットにデプロイされていたものの、当時は同じ問題シナリオは発生しませんでした。

修正は二段階に分かれています。まず、v7.0.0バージョンで一時的に–disable-last-epoch-targetパラメータを有効にして対処しました。その後にリリースされたv7.0.1とv7.1.0には長期的な修正策が含まれており、head stateを使ってattestationsの検証を行い、過去の状態を繰り返し再生することを完全に避けるようになっています。問題はUTC 4:45以降徐々に緩和され、epoch 411480時点ではネットワーク参加率は95%以上に回復しました。

Proymsチームもこの機会に深い反省を行いました。彼らはこの事件はクライアントの多様性の重要性を再認識させるものだと指摘しています。もし単一のクライアントの比率が3分の1を超えると、ネットワークは一時的に終結しなくなる可能性があるということです。さらに、3分の2を超えるとチェーン全体の失効リスクも生じます。また、チームは機能スイッチのコミュニケーション不足や、テスト環境が大規模なノードの非同期シナリオを効果的にシミュレートできなかった点も認めており、今後はテスト戦略と設定管理の改善を行う予定です。