イーサリアム「フサカ」実装直後にPrysm障害、1.8億円の報酬損失が判明

事後分析を公開

イーサリアム（ETH）の大型アップグレード「フサカ」は4日に無事完了したが、実装直後にソフトウェアバグにより、主要クライアントPrysmでネットワーク障害が発生した。この障害でバリデータが総額382ETH（当日時価約1億8,860万円相当）の報酬機会を失っていたことが明らかになった。

Prysmは、イーサリアムネットワークを支えるコンセンサス層クライアントソフトウェアの一つで、Prysmatic Labsによって開発されている。バリデータ（検証者）がブロックの生成や検証を行うために使用する基盤ソフトウェアであり、イーサリアムの分散型ネットワークを維持する重要な役割を担っている。

Prysmチームはこの「フサカメインネットPrysm事件」の事後分析で、ステート再計算（state recomputation）のアルゴリズムが適切に最適化されておらず、実環境下での十分なストレステストが行われていなかったことが根本原因であると特定している。

フサカがブロック18,200,000で有効化された直後、Prysmノードは過去ステート（historical state）の過剰生成により、リソースが大量消費され、深刻なパフォーマンス低下が発生した。ブロックの確定が遅延し、DoS（サービス拒否）攻撃を受けたかのような事態に陥った。

Prysmコア開発者のTerence Tsao氏は、「過去ステートの生成は計算とメモリを大量に消費するため、並行して大量のステート再生が行われると、ノードがDoS攻撃状態に陥る可能性がある」と説明。これがアテステーションやブロック確定の遅延につながった。

最終的にPrysmのバリデーター参加率は75％まで急落。ネットワークは41エポックにわたって正常に機能せず、その結果、約382ETH相当のバリデータ報酬が失われた。

イーサリアム財団は即座に、Prysm運営者に向けて緊急対応手順を発表した。バリデーターは緊急回避策を適用し、開発者側も恒久的な修正版（v7.0.1とv7.1.0）をリリースした。その結果、ネットワーク参加率はほぼ99％まで回復し、障害発生から24時間以内に通常運用に戻った。

Prysmを実行しているバリデータは、イーサリアムのノード運営者全体の約18~22%を占めている。beaconcha.inによると、事件発生時には約22.71%のバリデータがPrysmクライアントを使用していたが、その後18%まで低下した。

Offchain Labsは、Prysmがイーサリアムのバリデーターベースに占める割合がさらに大きければ、今回の障害はより深刻な影響を及ぼしていた可能性があると述べた。同社は、イーサリアムのクライアント多様性が、より広範なネットワーク障害を防ぐ重要な要素であると指摘している。

今回、ネットワークへの負荷が増加する中、Lighthouse、Teku、Nimbus、Lodestarなどの他のクライアントは、正常にブロック検証を続けた。その結果、イーサリアムネットワークのコンセンサスは維持され、ブロックのファイナライズも継続された。

ステーキングプロトコルLido Financeは、他のステーキングソリューションと比べて影響は最小限だったと報告。分散型のバリデーター運営体制によってネットワークのレジリエンスが保たれたと指摘した。

一方、Miga Labsのデータによると、Lighthouseがイーサリアムのコンセンサスクライアントとして最も多く利用されており、バリデーターの51.39%を占めている。

Offchain Labsは、ネットワークの3分の1以上を占めるクライアントに障害が発生した場合、ファイナリティの一時的な喪失や、より多くのブロック生成の失敗を引き起こす可能性があり、さらに3分の2以上を占める場合は、無効なチェーンを最終確定させてしまうこともあり得ると指摘した。

一つのソフトの欠陥がネットワーク運用に支障をきたす可能性を低減するため、開発者やエコシステム参加者は、バリデータに対し、代替クライアントへの切り替え検討を促している。

CoinPost App DL