要約
- Ethereumの開発者は、同じ公開鍵を共有するビルダーにバリデーターの入金をルーティングする可能性のあるフォーク遷移ロジックを発見した後、Glamsterdamの修正をマージしました。
- このバグは、ビルダーおよびバリデータレジストリの作成中に保留中の入金が誤って分類される可能性があるGloasのオンボーディングに影響を与えましたが、ライブのメインネット攻撃ではありませんでした。
- プルリクエスト#5736は、出金認証情報によって入金ルーティングを分離し、バリデーターの入金をキューに保持し、デプロイ前に回帰テストを追加しました。
Ethereumの開発者は、Gloasのフォークオンボーディングバグを特定した後、Glamsterdam用のコンセンサス仕様の修正をマージしました。このバグは、同じ公開鍵を共有するバリデーターの入金をブロックビルダーにルーティングする可能性がありました。Pull request #5736は10月26日にmasterにマージされ、フォーク中に保留中の入金が分類される方法を変更しました。この欠陥は、現在のメインネットプロトコルではなく、Ethereumの今後のアップグレードの移行ロジックに影響を与え、問題はEthereumの開発およびテストパス内にとどまりました。
Gloas Fixはバリデーターとビルダーの入金パスを分離します
根本的な問題は、Gloasが独自のbuilder registryを初期化する瞬間に関係していました。以前のルーティングルールでは、保留中の入金がビルダーを登録すると、同じ公開鍵を使用する後続の入金は、引き出し認証情報に関係なくそのビルダーの残高を増加させることが可能でした。そのため、バリデーター入金がバリデーターキューから外れ、代わりにビルダーに計上される可能性がありました。このバグにより、ステーキング用に提供された資金が、別の当事者が管理する口座に到達する条件付きのパスが生じました。
問題の説明では、ステーキングプロトコルが他の当事者によって運用されるバリデーターに資金を提供する状況でリスクを示しています。運用者が同じキーを使用して有効なビルダー入金をキューに登録し、両方の入金がフォーク時に未処理のまま残った場合、プロトコルが資金を提供したバリデーター入金もビルダーに流れてしまう可能性があります。その入金からはバリデーターは作成されず、プローフベースの会計または回復プロシージャに支障をきたす可能性があります。文書化されたシナリオはプロトコルレベルのエッジケースであり、Ethereumメインネットの入金が転送されたという証拠ではありません。
マージされた修正により、Gloasのオンボーディング中に入金が引き出し認証情報に基づいて分離されます。バリデーターの入金は、ビルダーが同じ鍵を使用してもバリデーターキューに残り、有効なビルダーの入金は独立してビルダーを登録または追加入金できます。改訂されたルールに基づき、既存のビルダー入金にも追加入金が可能になります。この変更は、EIP-8282で説明されている独立したバリデーターおよびビルダー登録システムにオンボーディングを統一し、入金の順序とルーティング動作をカバーする回帰テストを追加しています。
タイミングが重要なのは、Glamsterdamがアムステルダムの実行層変更とGloasのコンセンサス層変更を組み合わせ、特にプロポーザー・ビルダー分離を明文化しているためです。この広範なアップグレードは既にパブリックテストを通過していますが、Hoodiのデプロイは追加のレビューのために延期され、メインネットでの有効化は未確認です。したがって、入金ルーティングの修正は、ライブなEthereumの脆弱性を修復するのではなく、将来のフォークに対する仕様を強化するものです。また、ステーキングおよびブロック構築インフラに関する移行ロジックが、プロトコル変更が本番環境に安全に導入される前にテストされる必要がある理由をさらに強調しています。