Fusaka期間中、Prysmノードは重い証言負荷により失敗し、約18.5％のスロット未達成、参加率低下、382 ETHの損失を引き起こしました。
同期していない証言により、Prysmは古いビーコン状態を再生せざるを得なくなり、何千もの高コストな再計算とリソースの枯渇を引き起こしました。
Prysmは設定フラグや後のリリースを用いてこの問題を緩和し、証明の検証ロジックを更新して履歴状態の再生を回避しました。
EthereumのFusakaメインネットアップグレードは、2025年12月4日にPrysmノードが証言処理中に失敗したことで混乱に見舞われました。この問題はEthereumメインネットのFusakaアップグレード期間中に発生し、Prysmコンセンサスクライアントチームが関与していました。リソース枯渇によりバリデータの応答が遅れ、エポックの未達成、参加率の低下、バリデータ報酬の損失を引き起こしました。
リソース枯渇がFusakaエポックを妨害
事故発生時、ほぼすべてのPrysmビーコンノードが重負荷の中で特定の証言処理に苦労しました。特に、エポック411439から411480までの約42エポックに影響が及びました。ただし、ノードはバリデータのリクエストに時間内に応答できず、ブロックと証言の未達成を招きました。
この範囲内で、ネットワークは1,344スロットのうち248ブロックを失いました。その結果、未達成スロット率は約18.5％に達しました。ピーク時には、ネットワークの参加率も急激に低下し、75％近くまで下落しました。
バリデータは遅延中に測定可能な損失を被りました。Prysmチームによると、未達証言の報酬合計は約382 ETHに上ります。これらの損失は、バリデータが時間内に証拠を提出できなかったことによるものです。
同期していない証明は大量の再計算を引き起こす
Prysmのレポートによると、根本原因はおそらく同期していないノードからの証言に関係していました。これらの証明は、最新のチェーンビューではなく、過去のエポックのブロックルートを参照していました。しかし、PrysmはEthereumのコンセンサールールに従うために完全検証を試みました。
各証明を検証するために、Prysmは繰り返し古いビーコン状態を再構築しました。この過程では、過去のブロックのリプレイや高価なエポック遷移の処理が必要でした。高い同時実行性の下で、ノードは数百回の再計算を同時に試みました。
一例として、エポック411441のブロック0xc6e4ffを参照した証言がありました。Prysmはそれを検証するために複数の状態遷移をリプレイしました。エンジニアはこの挙動がインフラ全体で約4,000回観測されたと報告しています。
修正、検出、継続的監視
事故時、Prysmチームはユーザーに対し、バージョン7.0.0で --disable-last-epoch-target フラグを有効にするよう助言しました。この一時的措置により、状態の再計算負荷が軽減されました。重要なのは、緊急のクライアントリリースを必要としなかった点です。
その後、バージョン7.0.1と7.1.0で恒久的な修正が導入されました。これらのアップデートは、証言の検証を最新状態に依存させ、履歴のリプレイを回避しました。チームは --ignore-unviable-attestations フラグの使用を控えるよう警告しています。
検出は、コア開発者やユーザーからのレポートによって行われました。メトリクスはリプレイ回数の増加やリソース使用量の増大、gRPCリクエストの失敗を示しました。Prysmが引用したMiga Labsのデータによると、回復中にクライアントの分散状況が変化しており、多様性の継続的な懸念が浮き彫りになっています。
「PrysmのFusakaメインネットの停止と382 ETHの損失」に関する詳細はCrypto Front Newsに掲載されています。暗号通貨、ブロックチェーン技術、デジタル資産についての興味深い記事を読むには、ぜひ私たちのウェブサイトをご覧ください。
関連記事
