10月26日にマージされた仕様変更により、ネットワークのGlamsterdamアップグレードが有効化された際に、ノードオペレーターがステーカーのキューにあるデポジットを自身の管理下にある残高へ振り替えられる可能性のある、イーサリアムのデポジット処理の欠陥が解消された。この修正は、欠陥がGitHubで報告されてから2週間後に、イーサリアムのクライアントチームが実装する参照ルールであるconsensus-specsリポジトリに取り込まれた。フォーク有効化時点でキューに残っていたデポジットのみ誤った振り先となる可能性があり、Glamsterdamはまだメインネットに到達していないため、資金の損失は発生していない。

オペレーターがどのようにステーカーのデポジットを取得できたのか

プール型ステーキングプロトコルでは、バリデーターの運用業務を分割するのが一般的だ。プロトコルがETHを拠出し、外部のノードオペレーターがバリデーターの署名鍵を保持する。イーサリアムは署名と出金を分離しているため、オペレーターはプロトコルのステークを出金できないままバリデーターを運用できる。

Glamsterdamは実行レイヤーの変更をGloasと呼ばれるコンセンサスレイヤーのアップグレードと組み合わせ、en hrsined proposer-builder separation(提案者-ビルー分離の組み込み)の下で、ビルダーを新しい種類の参加者として追加する。ビルダーは各ブロックのトランザクションを含む部分を組み立て、独自の残高を保持する。フォーク時、イーサリアムはキューで待機中の適格なデポジットをビルダーアカウントに変換する。

この変換こそが欠陥のあった箇所だった。旧ルールでは、保留中のデポジットがある鍵のビルダーを登録すると、それ以降の同じ鍵へのデポジットは、出金クレデンシャルの宛先に関係なくビルダーへ上乗せされていた。オペレーターは自身が管理するアドレスから、新しい鍵のビルダーデポジットをキューに入れることができた。ステーキングプロトコルがその後同じ鍵のバリデーターデポジットを拠出し、両方がフォーク時点で保留中であれば、プロトコルのETHはオペレーターのビルダー残高に計上され、オペレーターはそれを出金できた。バリデーターも作成されない。一部のプロトコルは、新しいバリデーターが自身の出金クレデンシャルを備えていることの証明があって初めて残りのステークを解放する仕組みだが、その証明は永遠に届かなかったことになる。

フォローアップコメントで問題の報告者は、このバグが混乱させ得た設計として、Lidoのプレデポジット保証、OriginのOETH、Rocket PoolのSaturnを挙げたが、このリストは誤りを含む可能性のあるAI支援による簡易調査であると明示していた。いずれのケースでもリスクの対象は最初のデポジット、LidoとRocket Poolの例では1 ETHであり、残りのステークは復旧手順が実行されるまでロックされたままとなる。報告者はこれらを実際の悪用ではなく条件付きのコード上の発見と説明した。

誤った振り先となり得たのは、フォーク有効化時点でまだキューにあったデポジットのみであり、Glamsterdamはメインネットに到達していないため、資金の損失は発生していない。

10月19日に却下、1週間後にマージ

この修正は10月12日に提案された。2回のコア開発者コールでの議論を経て、10月19日にクライアントのサポートが不足しているとしてクローズされ、テストコールではスケジュールを乱すよりもHoodiテストネットのアップグレード後にプロトタイプを作る案が浮上していた。

その3日後、イーサリアム財団はEIP-8037が既存のスマートコントラクトとどう相互作用するかを調査するため、HoodiでのGlamsterdamの有効化を延期した。これはデポジットとは無関係の問題だった。この追加時間により議論が再燃した。次回テストコールの議題への10月23日のコメントがデポジット変更を改訂されたタイムラインに結び付け、報告者が同じ日にデポジット順序のテストを追加し、変更は10月26日にマージされた。

新ルールの内容

フォーク後、ビルダーとバリデーターのデポジットはEIP-8282の下で既に別々の経路を通る。この修正は同じ論理をフォーク時のキューに適用するもので、保留中の各デポジットの行き先は公開鍵ではなく出金クレデンシャルが決定する。

1つの鍵をバリデーターとビルダーで再利用することは引き続き許可されており、各デポジットに明示された目的がどのアカウントに資金を入れるかを決定する。

フォークまでに残る課題

仕様のマージは最初のステップに過ぎず、クライアントチームが同じルールを出荷する必要がある。10月27日にオープンされたTekuの変更はレビュー中であり、Lodestarの同等の変更もオープンのままだ。

また、後からの変更はすべてのクライアントに同一の形で実装されなければならない。古い参照テストは従来のルーティングを前提としているため、新ルールに従うクライアントはテストに合格しない。Tekuの作者は更新された仕様から生成されたテストに合格したと報告しているが、その仕様はまだ仕様リリースとしてパッケージ化されていない。もしクライアントが同じキューに異なるルールを適用したままフォークを迎えれば、異なる残高を計算し、チェーンの状態について合意できなくなる。

財団は新しいHoodiの日付もGlamsterdamのメインネットの日付も設定していない。デポジット証明に依存するステーキングプロトコルには独自の防御線もある。問題の報告者によれば、既にビルダーデポジットを保有する鍵を拒否するデポジット前のチェックにより、このシナリオを防ぐことができるという。今後注目すべき指標は、オープンのままの2つのクライアントのプルリクエスト、更新されたテストを含む仕様リリース、そしてHoodiとメインネットの新しい日付だ。