イーサリアムのPrysmクライアントでリソース枯渇が発生、ネットワーク参加率が一時75%に低下

Prysmクライアントで障害が発生し、参加率が75%まで低下

イーサリアム（Ethereum）のコンセンサスクライアント「Prysm（プリズム）」の開発チーム（旧プリズマティックラボ / Prysmatic Labs）が、大型アップグレード「フサカ（Fusaka）」有効化の数時間後にあたる12月4日に発生した障害の事後分析レポートを公開した。なおPrysm開発チームは2022年10月より、イーサリアムレイヤー2ネットワーク「アービトラム（Arbitrum）」開発元のオフチェーンラボ（Offchain Labs）傘下となっている。

ほぼすべてのPrysmノードが、特定のアテステーション（検証証明）の処理時にリソース枯渇を経験し、バリデーター（検証者）からのリクエストに適時応答できなくなった。この間、ブロックとアテステーションの検証が大幅に遅延し、バリデータは約382ETH（当時のレートで約1億8,860万円相当）のアテステーション報酬を逃した。

影響を受けたのはエポック411439から411480までの42エポックで、1344スロットのうち248ブロックが欠落し、18.5%のブロック欠落率を記録した。ネットワーク参加率は最低で75%まで低下したという。

根本原因は、ネットワークと同期していない可能性のあるノードからのアテステーションをPrysmが受信した際、前のエポックのブロックルートを参照するアテステーションを検証するため、過去のビーコンステート（状態）を再作成しようとしたことだ。これにより過去のエポックブロックが複数回処理され、計算負荷の高いエポック遷移の再計算が発生した。この問題を引き起こしたバグは、PrysmのプルリクエストPR 15965で導入され、事故発生の1ヶ月前にテストネットに展開されていたが、トリガーとなる条件が発生しなかったため発見されなかったという。

具体的な例として、エポック411442で受信したアテステーションが、エポック411441のスロット13166123にある0xc6e4ffというブロックルートを参照していた。Prysmは11回のステート遷移を再生し、さらに複数の空のステート遷移とエポック遷移を実行してアテステーションを検証した。同チームのインフラストラクチャでは、この特定のアテステーション挙動が3,927回観測され、一部のノードでは同一チェックポイントに対するアテステーション処理を700回以上同時に試行していたという。これによりクライアントがリソース枯渇の限界に達し、バリデータリクエストへの応答が遅延した。

解決策として、ユーザーにはバージョンv7.0.0のビーコンノードで「–disable-last-epoch-target」フラグを使用するよう指示された。v7.0.1およびv7.1.0のリリースには長期的な修正が含まれており、推奨フラグはもはや不要になった。長期的な修正では、アテステーション検証ロジックが変更され、以前のステートを再生成することなく、ヘッドステート（最新の状態）を使用してアテステーションを検証できるようになった。

新しいリリースには「–ignore-unviable-attestations」というフラグが存在するが、使用すべきではないとされている。イーサリアムのコンセンサス仕様によると、これらの問題のあるアテステーションは処理されなければならず、現在は以前のエポックからステートを再計算するのではなく、ヘッドステートを正しく使用している。この新しいフラグを不適切に使用すると、エポックの最初のスロットがスキップされた場合に、アテステーションが誤って破棄される可能性があるという。

障害の検出は、メインネットの参加率が75%に低下したという他のコア開発者やエンドユーザーからの報告によって行われた。ほとんどのPrysmユーザーは、gRPC成功率の低下と高いリソース使用率を観察した。また、Prometheusメトリクス「replay_blocks_count_counter」が極めて高い速度で増加したという。

プリズマティックラボによると、今回の障害でクライアント多様性の重要性が改めて浮き彫りになったという。ネットワークの3分の1以上を占めるクライアントにバグがあった場合、一時的なファイナリティ（確定性）の喪失とより多くのブロック欠落を引き起こす可能性があり、3分の2以上を占める場合は無効なチェーンを確定させる可能性があるという。

今回の障害では、v7.0.0にすでに回避策が存在していたため、Prysmは緊急リリースを発行する必要がなく、ユーザーは新しいバージョンをダウンロードまたはコンパイルする必要がなかった。設定にフラグを追加するだけで済み、可能な限り影響の少ない解決方法となった。

タイムラインによると、12月4日の協定世界時2時45分頃にPrysmノードで問題が発生し始め、2時50分にメインネットの参加率が80%に低下し始めた。3時30分にPrysmチームが最初の報告を受け、インシデント対応チームが発動された。4時20分にPrysmチームが回避策を承認し、4時34分に公式発表が行われた。4時45分にはメインネットの参加率が80%以上に回復し、7時12分には95%以上に回復した。エポック411480の時点で事態の緩和が判断されたという。

参考：プリズマティックラボレポート
画像：PIXTA

関連ニュース

• イーサリアム大型アップグレード「Fusaka」、メインネット実装完了
• イーサリアム次期アップグレード「Fusaka」最終テスト完了。メインネット実装は12/3予定
• イーサリアム次期アップグレード「Fusaka」、Sepoliaテストネットで稼働
• イーサリアム次期アップグレード「Fusaka」、Holeskyテストネットで稼働開始
• ヴィタリック、イーサリアム「Fusaka」のPeerDASが鍵となりスケーリングを実現と言及