Ethereum(ETH)開発者、Glamsterdam入金欠陥の修正をマージ

Glamsterdamに先立ち入金規則を改定

次期アップグレード「Glamsterdam」を進めるEthereum (ETH)のクライアント各チームは、入金規則の改定版をソフトウェアに取り込む段階に入った。開発者が月曜日の10月26日、ステーキングサービスの資金を乗っ取り可能にする欠陥をふさぐ修正をコンセンサス仕様へ反映したためだ。変更は、保留中の入金をどう並べ替えるかを書き直すコンセンサス仕様へのプルリクエストとして統合された。新しい規則では、バリデータの有効化のためステーキングサービスが送金した資金を、同じ識別子をビルダーとして登録した運営者が請求できなくなる。問題は、Glamsterdamが未計上の入金を処理する設計にあった。運営者は先に特定の公開鍵(バリデータやビルダーに紐づく識別子)を使ってビルダー登録ができる。ステーキングサービスが同じ鍵でバリデータ開始用のETHを入金すると、草案の規則では両方の入金がビルダー側に計上され、プロトコルの資金を引き出せた。バリデータは最終的に作成されないため、ステーキングサービスは返金に必要な証明を生み出せない。修正後は、入金の資金の行き先を指定する設定である出金クレデンシャルで保留入金を並べ替え、ビルダーが同じ鍵を使っていてもバリデータ用の入金はバリデータ側に残る。改定版は各クライアントが従う正規仕様の一部となった。なお、この欠陥がEthereum(ETH)の価格や既存のステーキング残高に影響することはない。対象は草案規則の下で処理される入金に限られ、損失報告も出ていない。

攻撃経路と採択までの経緯

欠陥の根っこは、Glamsterdam自身の設計思想にある。アップグレードは現在一つの役割に束ねられている二つの仕事を分離する。トランザクションのブロックを組み立てるビルダーと、プルーフオブステークのもとイーサリアム (ETH)をステークしてネットワークを保護するバリデータが選択・確定する、という分担だ。双方がETHを入金でき、資金は別々に管理される想定で、リキッドステーキング提供元とその預け入れ者の資産保全はこの分離に支えられている。攻撃シナリオは、研究者のavsetsinがconsensus-specsリポジトリのイシューで提示した。avsetsinはLido、Origin、Rocket Poolへの影響も検証したが、曝露の度合いは各プロトコルの入金処理方法次第だった。LidoのGitHub組織に所属名が載る同氏は、結果を確認済みの現行攻撃ではなく条件付きのコード上の発見と位置づけ、先行するビルダー入金を拒む既存チェックが実運用では攻撃を防げる可能性を指摘した。中核ケースの説明は率直だ。「運営者はプロトコルの資金を引き出すことができる」。修正の採択までの道のりは曲がりくねった。提案は10月19日、いったん却下された。Ethereumのコンセンサス仕様を保守するJustin Tragliaが当時はクライアント側の支持が不足していると書いたためだ。クライアントとは、バリデータがネットワーク参加に使う独立したソフトウェアのこと。その後の再検討を経てプルリクエストは再開され、avsetsinが10月23日にテストを追加、Tragliaが却下から1週間後の月曜日に変更を統合した。

クライアント対応とHoodi延期

何が修正されたかと同じくらい、修正がどう届くかが重要だ。GlamsterdamはすでにSepoliaのテストネットで稼働したが、第2のテストネットHoodiでの10月26日の展開は延期された。入金の変更が同じ日に仕様へ入ったことを考えれば、開発者は既知の入金計上欠陥を抱えたまま公開リハーサルに臨むのではなく、延期の期間を修正の着地に充てたと読める。残る作業は実装だ。コンセンサス仕様への統合は目標を定めた段階で、クライアント各チームが新しい並べ替え規則を自ソフトウェアに組み込まなければ、メインネットの日程は議論できない。改定後の入金処理がクライアントのリリースに載るまで、Glamsterdamの日程はクライアント開発者の手中にあり、再スケジュールされたHoodiはメインネット前の全体リハーサルの場として機能する。