イーサリアムのコンセンサスクライアントであるPrysmは、Fusakaアップグレード直後に発生したソフトウェアバグによるネットワーク障害で、バリデータが382ETH(100万ドル超相当)を逃したと発表した。
この事象は「Fusaka Mainnet Prysm incident」と題した事後報告で詳細が明らかにされた。リソースが枯渇する事態がほぼ全てのPrysmノードで発生し、その結果、多数のブロックおよびアテステーションが欠落した。
SponsoredPrysm停止の原因は何か
Prysmを開発したOffchain Labsによれば、12月4日に以前から存在していたバグが原因でバリデータのリクエストが遅延し、問題が表面化した。
この遅延により、ネットワーク全体で多くのブロックとアテステーションが失われた。
「Prysmビーコンノードは、ネットワークと同期していない可能性のあるノードからアテステーションを受信した。これらのアテステーションは前のエポックのブロックルートを参照していた」とプロジェクトは説明した。
この障害により41エポックが失われ、1344枠中248ブロックが欠落した。これは18.5%のスロット欠損率を示し、障害発生時にはネットワーク全体の参加率が75%に低下した。
Offchain Labsによると、今回の動作を引き起こしたバグは約1か月前にテストネットに導入されており、Fusakaアップグレード後にメインネットで発生した。
一時的な緩和策により直ちに大きな影響は抑えられたが、Prysmは今回を受けてアテステーション検証ロジックに恒久的な変更を実施し、再発防止を図った。
Sponsoredイーサリアムのクライアント分散状況
一方で今回の障害はイーサリアムのクライアント集中やソフトウェア単一文化がもたらすリスクを改めて浮き彫りにした。
Offchain Labsは、Prysmのシェアがイーサリアムのバリデータ基盤においてより高ければ、より深刻な影響となった可能性があると指摘した。同社はイーサリアムのクライアント多様性が、ネットワーク全体の障害拡大防止に重要だったとした。
「ネットワークの3分の1超を占めるクライアントであれば、一時的なファイナリティ喪失やさらに多くのブロック欠損が発生した可能性がある。もしバグのあるクライアントが3分の2超を占めた場合、不正なチェーンがファイナライズされるおそれもある」と指摘した。
とはいえ、今回の事例を受けクライアント多様化の必要性がさらに高まる結果となった。
Miga Labsのデータによれば、Lighthouseが依然として主要なイーサリアムコンセンサスクライアントとなっており、バリデータの51.39%を占める。Prysmは19.06%、Tekuが13.71%、Nimbusが9.25%となっている。
Lighthouseのシェアは、研究者がシステミックリスクと見なす閾値まで約15ポイントの差となっている。
このため、開発者やエコシステム関係者からはバリデータに対し、単一のソフトウェア欠陥によるブロックチェーン基幹機能の障害リスク軽減のため、他のクライアントへの移行を再度促す声が上がっている。