ビットコイン11,069,678円▼4.78%
イーサリアム313,379円▼2.84%
XRP163.2円▼1.35%
ソラナ12,906円▼1.55%
BNB102,438円▼2.64%
イーサリアムのコンセンサスクライアントLighthouseで、次期アップグレードGloasの境界に伴う公開鍵キャッシュの不整合を防ぐ修正案が出され、誤った署名拒否によるノード分岐を避ける狙いだ。
問題となるのは、フォーク境界の前後でバリデーターの公開鍵と番号の対応がずれ、ノードごとに参照する鍵が食い違うケースだ。これは修正案に記された想定上の攻撃シナリオで、発生済みの障害を示すものではない。
想定では、境界直前に3件の入金が保留される。1件は既存バリデーターへの追加入金で、残る2件は新しい公開鍵への入金だ。攻撃者側のチェーンで既存バリデーターがスラッシュされると、入金の処理順が正規チェーンと異なる可能性がある。
この順序差により、キャッシュが公開鍵Aを次のバリデーター番号に登録した一方、正規チェーンでは同じ番号が公開鍵Bに割り当てられ得る。影響を受けたノードは、Bに対応する正当な署名をすべて拒否し、別チェーンへ分岐する恐れがある。
修正案は、バリデーターの有効化適格エポック（activation_eligibility_epoch）が確定してから、その公開鍵をグローバルキャッシュに登録する。確定前のバリデーターの公開鍵は、現在のhead stateとキャッシュを組み合わせるHeadPubkeys構造で参照する。
提案は11月13日午後9時34分（日本時間）時点で未マージで、コードオーナーのレビューと少なくとも1件の承認を待っていた。Gloasは、実行層のAmsterdamとコンセンサス層のGloasから成るGlamsterdamの一部だ。メインネット導入は2026年第4四半期の見込みだが、具体的な日程は未確定である。
