• Prysmバグの起源：テストネットでPR 15965を通じて1ヶ月前に導入され、非同期ノードのアテステーションによって引き起こされました。

• 影響の詳細：ノードが過去のエポックをリプレイし、42エポック以上にわたる過大な計算負荷を生じさせました。

• ネットワークの回復：クライアントの多様性が深刻な結果を緩和し、ClientDiversityデータによるとPrysmの市場シェアは17.6%でした。

イーサリアムのPrysmバグがFusakaアップグレード後に脆弱性を露呈し、参加率が75%に低下して382 ETHの損失を生じさせました。クライアントの多様性がネットワークを救った経緯と、バリデータのための重要な教訓を探ります。今日のイーサリアムの安定性に関する最新情報を入手しましょう。

イーサリアムのPrysmバグインシデントの原因は何でしたか？

イーサリアムのPrysmバグは、Fusakaメインネットアップグレードの約1ヶ月前にテストネットに展開されたPrysm PR 15965で導入された欠陥に起因します。この問題は、非同期ノードからのアテステーションを処理する際にPrysmノードがリソース枯渇を起こし、過去のエポックブロックをリプレイして高コストな状態遷移を再計算するよう強制しました。イーサリアム開発者のTerence Tsao氏は12月8日の包括的なポストモーテムでこれを詳述し、バグがテスト中に検出されなかった理由を強調しました。

Prysmバグはイーサリアムのネットワーク参加率にどのように影響しましたか？

Prysmバグはパフォーマンス問題の連鎖を引き起こし、ノードが現在のヘッド状態を使用せずに過去の状態をゼロから再生するようになり、膨大な計算負荷を課しました。ポストモーテム分析によると、42エポック以上にわたりイーサリアムのミススロット率が18.5%に達し、全体的なネットワーク参加率が75%に急落しました。この混乱により、バリデータはアテステーション報酬として約382イーサを逃しました。これは関与する財務的リスクを強調しています。

歴史的文脈が深刻さを増幅します：2023年5月の上海ハードフォーク直後、イーサリアムは取引のファイナリティを一時的に失い、最初は25分間、次に翌日1時間以上続きましたが、自力で回復しました。このような出来事は、マージ後のイーサリアムの継続的な成熟をコミュニティに思い出させ、コンセンサス層の安定性が最優先事項であることを示します。Terence Tsao氏はポストモーテムで、テストネットがバグ探しに有用であるものの、実際のトリガーはシミュレーション環境と大幅に異なる可能性があると強調しました。

ノードオペレーターは迅速に対応し、Prysmチームが恒久的なパッチを開発する間、臨時の回避策を実施しました。このパッチはすでに展開され、リソース枯渇問題を解決しています。この迅速な対応は長期的な損害を最小限に抑えましたが、プルーフ・オブ・ステークネットワークにおける堅牢なテストプロトコルの必要性を強調しました。

よくある質問

イーサリアムのPrysmバグの具体的なトリガーは何でしたか？

イーサリアムのPrysmバグは、非同期ピアからのアテステーションを処理する際に活性化され、歴史的なエポックの不要なリプレイを引き起こしました。PR 15965のコード変更を通じて導入され、テストネットで1ヶ月間休眠していましたが、Fusakaアップグレードの条件がこれを露呈し、影響を受けたクライアントに広範なリソース負担を生じさせました。

クライアントの多様性はイーサリアムが大規模な混乱を避けるのにどのように役立っていますか？

イーサリアムのエコシステムにおけるクライアントの多様性は、単一のクライアントが重要な閾値を超えて支配しないため、Prysmバグがネットワーク全体の停止を引き起こすのを防ぎました。ClientDiversityの指標によるとPrysmのシェアは17.6%で、インシデントは封じ込められました。Lighthouseのような支配的なクライアント（52.6%）が3分の2以上影響を受ければ無効なファイナリティのリスクが生じ、全体としてユーザー体験がスムーズに保たれました。

主な教訓

• バグ検出の課題：1ヶ月間のテストネット露出でもPrysmの欠陥を誘発できず、複雑なブロックチェーン環境でのシミュレーションテストの限界を示しています。
• 財務的影響の定量化：参加率75%の中で382 ETHの報酬損失が発生し、クライアントの安定性に依存するバリデータの経済的リスクを厳しく思い出させます。
• 多様性の推進：イーサリアム開発者は単一障害を避けるためにより強力なクライアント分散を提唱しており、Lighthouseが危険な支配レベルに近づいています—ClientDiversityのようなツールで変動を監視しましょう。

結論

Fusakaアップグレード後のイーサリアムのPrysmバグインシデントは、ブロックチェーンのレジリエンスに関する重要なケーススタディであり、一見小さなコード欠陥がネットワーク全体の参加率低下とバリデータの大幅なETH損失にエスカレートする可能性を示しています。ClientDiversityによるとPrysmが17.6%、Lighthouseが52.6%のシェアで、クライアントの多様性が封じ込めに英雄的な役割を果たし、イーサリアムの分散型アーキテクチャが潜在的な大惨事に対してその価値を証明しました。ネットワークが進化する中、クライアント開発と多様性イニシアチブへの継続的な警戒が重要です；バリデータとオペレーターは将来のPrysmのような脆弱性から守るために、多様なセットアップを優先し、イーサリアムのプルーフ・オブ・ステーク基盤を今後数年間にわたり強固に保つべきです。

イーサリアムのPrysmクライアントのバグにより、ネットワーク参加率が75%に低下し、バリデータが382 ETHを失いました。ノードがリソース枯渇を経験したためです。

Prysmは、イーサリアムのFusakaアップグレードの1ヶ月前にテストネットで導入されたバグが、今月初めのクライアントに影響を与えたイーサリアムノード検証問題の原因であることを明らかにしました。

イーサリアム開発者のTerence Tsao氏は日曜日に、12月4日にネットワークに影響を与えたFusakaメインネットのPrysmインシデントに関するポストモーテムを投稿しました。

非同期ノードからのアテステーションを処理する際にPrysmノードが「リソース枯渇」を経験したと述べました。これにより、Prysmが過去のエポックブロックをリプレイし、高価な状態遷移を再計算するようになり、過大なワークロードによるパフォーマンスへの重大な影響が生じました。

ポストモーテムは、このバグがインシデントの1ヶ月前にテストネットに存在していたが、トリガーが発生しなかったことを明らかにしました。

「このバグはPrysm PR 15965で導入され、インシデントの1ヶ月前にテストネットに展開されましたが、トリガーは発生しませんでした。」

テストネットはバグの特定を目的としていますが、万全の方法ではありません。

2023年5月—上海ハードフォークの1ヶ月後—イーサリアム開発者は、ネットワークが約25分間取引のファイナリティを一時的に失い、翌日さらに1時間以上続いた後、ブロックチェーンが自力で回復したことで大混乱に陥りました。

Prysmはパッチが適用されました

現在のヘッド状態を使用する代わりに、Prysmは過去の状態をゼロから再生し、膨大な計算負荷を生じさせました。

42エポック以上にわたり、ネットワークのミススロット率が18.5%に達し、参加率が75%に低下した一方で、バリデータはアテステーション報酬として約382イーサ（ETH）を失いましたと述べています。

関連：Vitalik Buterin氏、イーサリアムはファイナリティの一時的損失を処理できると語る

ノードオペレーターは、開発者がPrysmクライアントの更新パッチを開発する間、臨時の解決策を展開するよう指示されました。

クライアントの多様性が危機を救いました

開発者によると、このインシデントはイーサリアムの支配的なコンセンサスクライアントであるLighthouseに影響を与えていたら、はるかに深刻なものになっていた可能性があります。

Offchain LabsのPrysmは、ClientDiversityによるとシェア17.6%でイーサリアムの2番目に大きなクライアントです。

「クライアントの多様性がイーサリアムユーザーに顕著な影響を防ぎました。ネットワークの3分の1以上を占めるクライアントであれば、ファイナリティの一時的損失とより多くのミスブロックを引き起こしたでしょう。」

しかし、このインシデントは、単一のクライアントバグが無効なチェーンをファイナライズする可能性のある3分の2閾値にLighthouseが危険なほど近づいていることを強調しました。

Lighthouseの現在のクライアントシェアは52.6%で、インシデント時の約56%から低下しています。

雑誌：大きな疑問：ビットコインは10年間の停電に耐えられるか？