Lidoのエンジニアが、EthereumのGlamsterdam移行中にステーキング入金が乗っ取られるリスクを警告
Ethereumの次の大規模なネットワークアップグレードは、エンシャインドなプロポーザー・ビルダー分離と高いガス制限を通じてベースレイヤーのスケーリングを目的としていますが、あるタイミング特有の脆弱性が、最大級のリキッドステーキングプロバイダーの1つから注目を集めています。2026年10月20日、Lido Financeのエンジニアリング責任者であるDima Gusakovは、Glamsterdamへの移行が悪意のあるノード運営者によってステーカーのバリデーター入金をフロントランニングする可能性があることを公に説明しました。この攻撃は、0xB0で始まる引き出し資格情報を持つビルダー入金を使用し、一時的に入金キューを共有することで、意図されたバリデーターではなくビルダー口座にETHを記録する可能性があります。この攻撃の機会はハードフォーク移行期間中に限定されています。アップグレード後、ビルダー入金は別の契約パスに移行します。
コンセンサス仕様におけるプロトコルレベルの修正案は「計画されていない」として閉じられ、防御の負担はステーキングプロトコルに移った。本記事では、リスクの技術的メカニズム、一時的な重複を生み出したアップグレードの設計選択、コア開発者がプロトコルパッチを拒否した理由、リキッドステーキングプロバイダーが取るべき実際の対応策、オペレーターに数日しか準備時間を与えないテストネットのタイムライン、およびEthereumがスケーリングロードマップを進める中で委任ステーキングセキュリティが学ぶべき広範な教訓を検討する。この分析は、過去30日間の報道と一次情報に基づいており、推測ではなく検証済みの詳細に焦点を当てている。
ディマ・グサコフは2026年10月20日、ステーキングプロトコルおよび委任ステーカーに対して警告を発しました。彼は、ノードオペレーターが正当なバリデータ入金トランザクションが確定する前に、同じパブリックキーを使用してビルダー入金を提出できると説明しました。Glamsterdamでは、0xB0で始まる引き出し認証情報に依存するビルダー入金を導入しており、移行中はこれらの入金がバリデータ入金キューを共有するため、最初の有効な入金が資金を獲得できます。その結果、ステーカーのバリデータはビーコンチェーンに表示されず、ETHは攻撃者のビルダー口座に記録されます。グサコフは、この攻撃がハードフォークの瞬間のみ可能であると強調しました。Glamsterdam以前では、ビルダー入金は既存のバリデータ入金キューを経由しますが、その後は専用の契約を経由します。彼は、この期間が限定されているため、準備ができているプロトコルにとっては対策が可能であると指摘しました。
同じ懸念が、All Core Devs Consensus call（ACDC #189）でも提起された。Gusakovは、Glamsterdamの一度限りのビルダーonboardingメカニズムが、ステーキングプロトコルが長年信頼してきた入金保護パターンを妨害する可能性があると指摘した。現在のルールでは、公開鍵に対する最初の有効な入金が引き出し認証情報を永続的に設定する。プロトコルは通常、まず少量の入金を行い、期待される認証情報が表示されることを確認した後、残高を補填する。フォーク移行中、特別なonboardingパスは3つ目の結果を生み出す可能性がある：バリデータがアクティブ化されず、全額の入金がビルダーに帰属する。コア開発者は、一度限りのonboarding中にバリデータ入金とビルダー入金の区別を維持するための遅い仕様変更を却下した。その理由として、Sepoliaは既に既存のルールでアクティブ化されており、Hoodiクライアントのリリースも既に準備中であることを挙げた。この段階で動作を変更すると、Sepoliaの再デプロイと追加のテストサイクルが必要になる。
Glamsterdamは、プロポーザー・ビルダー分離を確立する一環として、ビルダー入金を導入します。これらの入金は、0xB0で始まる引き出し認証情報を備えており、通常のバリデーター認証情報とは区別されます。移行期間中、这两种の入金は同じキュー処理パスを共有します。したがって、入金の送信順序を制御または影響できるノードオペレーターは、保留中のステーカーの公開鍵と一致するビルダー認証情報付きの入金を挿入できます。最初の入金が受け入れられると、ネットワークはその公開鍵をビルダー認証情報に基づいて確保されたものと認識します。同じ鍵による後続の入金は、バリデーターの有効化のために無視されるか、フォーク境界周辺に適用される新しい解釈ルールに従ってリダイレクトされます。
実際の影響として、ステーカーは期待されるバリデーターと預けられたETHの両方を失い、そのETHはビルダーの管理下に置かれます。既にアクティブ化されたバリデーターや既に処理された入金には影響がありません。リスクは、アクティベーションエポックを越える新規またはキューに残っている入金に限定されます。フォークが完了し、ビルダーの入金が専用契約に移動すると、共有キューの動作は終了するため、このリスクは一時的なものです。この一時的な性質が、Gusakovがパニックを避けるよう助言し、同時にメインネットアクティベーション前にすべての委任ステーキングサービスが入金前の検証を実装または強化するよう促した主な理由です。
プロトコルレベルの対策に関する技術的議論は、consensus-specsのイシュー#5735で行われました。この提案では、入金をキューに受け入れる前に特定の条件を検証する事前入金チェックを求めていました。審査の結果、このイシューは「計画されていない」として閉じられました。この決定により、防御の責任はコアプロトコルに追加のチェックを組み込むのではなく、アプリケーション層に置かれることになりました。したがって、Gusakovの公開ガイドラインは、ステーキングプロトコルが自ら事前入金検証を実施することに焦点を当てています。タイムリングの制約が結果に大きな影響を与えました。Sepoliaは既に2026年10月6日に、既存の仕様に基づいてフォークされています。
Hoodiクライアントのリリースは、10月26日のアクティベーションに向けて進んでいました。遅れて行動の変更を導入すると、Sepoliaの再デプロイとさらなるテストの遅延を引き起こすリスクがありました。コア開発者は、期間が限られており、アプリケーション層のチームがチェックを追加できるため、この段階ではプロトコルパッチは不要と判断しました。その結果、各ライクイッドステーキングプロバイダーが、0xB0で始まる入金がバリデーターの公開鍵を主張しようとする場合に、その入金パイプラインで正しく識別またはブロックすることを確認する、分散型セキュリティモデルが実現されました。
Lidoは、数年前にデポジット関連の脆弱性が明らかになって以来、デポジットセキュリティモジュールとガーディアン委員会を運営してきました。ガーディアンはバッチが進行する前にデポジットルートのスナップショットを確認し、1人の正直なガーディアンがデポジットを一時停止できます。現在の疑問は、既存のインフラが新しい0xB0資格情報タイプと一時的な共有キューのダイナミクスをすでに考慮しているか、それともGlamsterdam移行に追加のロジックが必要かどうかです。同様のマルチパーティ監督機構を持たない他のプロトコルは、より困難な準備作業を迫られます。
入金前のチェックは複数の具体的な形を取ることができます。プロトコルは、標準的なバリデーターの有効化を目的とする場合、引き出し認証情報が0xB0で始まる入金を拒否する可能性があります。公開鍵がビルダー認証情報下ですでに取得されていないことを、オンチェーンまたはオフチェーンで証明することを要求する可能性があります。また、共有キュー期間が終了するまで、有効化エポックを挟んだ短い期間、新規入金を一時的に停止する可能性があります。攻撃の可能性はキューが重複している間のみ存在するため、その期間中に一時的な停止や厳格な確認を行うことで、実用的なリスクの大部分を排除できます。メインネット移行を通じて入金を受け入れたいが、ガーディアンスタイルの委員会をまだ構築していない小規模または新興のステーキングサービスは、迅速に対応する必要があります。
Ethereum財団は、GlamsterdamがHoodiテストネットでエポック132,352、スロット4,235,264、すなわちUTC時間2026年10月26日17時42分48秒に活性化されることを確認しました。同じエポックで、Hoodiのガスリミットは2億に引き上げられます。Sepoliaはすでに10月6日に活性化されています。メインネットの活性化時期は未定で、候補日として12月上旬が検討中ですが、Hoodiのクリーンなフォークに依存しています。したがって、ノード運用者とステーキングチームは、Gusakovの警告後、数日以内にHoodiでの入金パイプラインを検証する必要があります。
クライアントチームは、コンセンサス層と実行層の両方に対応したリリースを公開しました。オペレーターは、ビーコンノードとバリデータークライアントの両方をアップグレードし、エンシュラインドプロポーザー・ビルダー分離によって導入されたビルダーインターフェースの変更を確認し、入金送信ロジックが新しい資格情報プレフィックスを正しく処理することを確認する必要があります。公開警告と最初のパブリックテストネット活性化の間の短い期間は、メインネット移行ウィンドウが開く前にアプリケーション層の防御策を準備しておく必要がある理由を示しています。
Glamsterdamは、Amsterdamの実行層変更とGloasのコンセンサス層変更を組み合わせたものです。その主な機能は、エンシュラインドプロポーザー・ビルダー分離（EIP-7732）とブロックレベルのアクセスリストです。ePBSでは、ビルダーは自身の残高と公開鍵をオンチェーンで登録し、入札を提出した後、実行ペイロードを公開します。プロトコル自体がプロポーザーへの支払いを処理するため、外部リレーへの依存が低減されます。ビルダーの入金と退出は、第一級の実行リクエストとなるため、0xB0資格プレフィックスと一時的なキューの重複が生じます。
設計は、バリデーターにより多くの時間を与えて大きなペイロードを処理可能にし、ガス制限を引き上げることでスケーラビリティを向上させます。同時に、通常のバリデーター入金とは明確に区別されるべきビルダーのための新しいオンボーディングパスを生み出します。一回限りの移行メカニズムが一時的な曖昧さの原因です。ネットワークが完全に移行した後、ビルダーの入金は独自の契約を通じて処理され、共有キューのリスクは消えます。したがって、このアップグレードは長期的なアーキテクチャを改善しますが、ユーザーに代わって入金を送信するすべてのサービスには短期間の注意が必要です。
Lidoは過去に入金フロントランニングのリスクに直面し、デポジットセキュリティモジュールとガーディアン委員会を正式に導入して対応しました。委員会はデポジットルートのスナップショットに署名し、単一のガーディアンが一時停止をトリガーできます。このインフラは、他の運用インシデントにおいてすでに有効であることが証明されています。Glamsterdam事例は、同じ制御が新しい資格情報タイプと一時的なキュー共有の期間を正しく認識できるかどうかをテストしています。
以前の事象後に類似のマルチシグネチャまたはガーディアンパターンを採用したプロトコルは、まだ同等のセーフガードを実装していないプロトコルよりも有利です。より広いパターンは既知です：プロトコルのアップグレードは、アプリケーション層システムが吸収しなければならないエッジケースを引き起こす可能性があります。コア開発者が遅い仕様変更を拒否したため、業界は預金検証をオプションの改善ではなく、恒久的な要件として扱う必要があります。既に預金ルートを監視し、迅速に一時停止できるチームは、移行中に低い運用リスクに直面します。
この攻撃には、正当な取引よりも前にデポジット取引を送信できる悪意のある、または侵害されたノード運営者が必要です。単にリキッドステーキングプロトコルにデポジットする通常のステーカーは、フロントランを実行することはできません。リスクは、最終的にオンチェーンデポジットに署名または送信する運営者にあります。既にアクティブなバリデーターと既に確認されたデポジットは、攻撃の対象外です。トランジションエポック中に未処理または新たに送信されたデポジットを持つ公開鍵のみが影響を受けます。
したがって、委任ステーカーは、Glamsterdamアクティベーションに関する入金処理に関する選択したプロトコルのガイドラインが公開されていることを確認する必要があります。オペレーター自身は、提出順序、レート制限、または入金のシーケンスを慎重に監査し、0xB0で始まる入金が標準バリデーター用のキーを不正に取得できないことを確認する必要があります。期間が短いため、新規入金のスループットを一時的に減らすか、モニタリング体制を強化することで、ステーキング操作への長期的な影響を最小限に抑えながら、ほとんどの実用的な攻撃経路を閉じることができます。
10月26日のHoodiアクティベーションは、ステーキングチームが現実的な条件下で共有キューの動作を観察する最初の公開機会です。プロトコルは、通常の資格情報と0xB0資格情報を使用してテスト入金を送信し、順序付けの結果を測定して、事前入金フィルターが不要なパスを拒否または隔離することを確認できます。クライアントチームは既にHoodi対応バージョンをリリースしています。オペレーターは、実行クライアントとコンセンサスクライアントの両方を更新し、外部ビルダーツールが新しいインターフェースに対応していることを確認する必要があります。
Hoodiでの成功したテストにより、メインネットの開幕前に業界の信頼が高まります。テストネットで発見された不具合や予期しないエッジケースは、プロトコルの再設計を必要とせずに、アプリケーション層の変更や短時間の停止で対応可能です。公開警告とHoodiの有効化の間の短いスケジュールにより、協調したテストが不可欠です。
コンセンサス仕様の問題を「計画されていない」として閉じることで、コア開発者は、一時的なリスクはアプリケーション層で対処するのが最善であることを示唆しました。したがって、リキッドステーキングプロバイダー、ソロオペレータープラットフォーム、およびユーザーに代わって入金を送信するあらゆるサービスは、独自のチェックを実装する必要があります。すでにガーディアン委員会や入金ルートの認証プロセスを維持しているプロバイダーは、そのプロセスを0xB0プレフィックスにも拡張できます。このようなインフラを備えていないプロバイダーは、同等のコントロールを追加するための締切がより厳しくなります。
分散モデルには利点と欠点の両方があります。ネットワーク全体でのハードフォーク変更を待つことなく、迅速でカスタマイズされた対応が可能になります。また、各ステーカーの入金のセキュリティは、彼らが選択したプロトコルの具体的な実践に依存することを意味します。アクティベーションエポック周辺での入金処理手順に関する透明性は、ユーザーが残存リスクを評価するのに役立ちます。
Glamsterdamは、実用的なガスリミットを2億近くまで引き上げ、ブロックレベルのアクセスリストを通じてトランザクションの並列処理を可能にし、ブロック生成のクリティカルパスから外部リレーを排除することで、EthereumのL1スケーリングロードマップを進展させています。これらの改善には、ビルダー向けの新しいオンチェーンプリミティブが必要であり、その結果、一時的な入金キューの重複が発生します。このパターンは主要なアップグレードの特徴です：長期的なアーキテクチャの改善により、アプリケーションチームが対処しなければならない一時的なエッジケースが表面化します。
これらのエッジケースをユーザー資金の損失なしに吸収する業界の能力は、今後のアップグレードに対する信頼に影響を与えます。今回の事例では、入金前の検証、一時的な入金停止、明確な運営側のコミュニケーションが実用的な手段です。リスクは既知で短い期間に限定されているため、準備にかかるコストは限定的であり、そのメリットは移行期間中のユーザー入金の保護です。
Glamsterdamルールが有効化される時点ですでに未処理の入金を有する公開鍵は、潜在的な攻撃ウィンドウ内に位置します。プロトコルは、エポック前に入金キューを空にしたり加速させたり、バリデーターの意図に対して0xB0の認証情報を拒否したり、有効化前後の一時的な期間中新規サブミッションを一時停止することで、これを軽減できます。重要な時間帯中にデポジットルートの変化と公開鍵の主張状況を継続的に監視することで、異常な活動が発生した場合に迅速に対応できます。
フォークが完了し、ビルダーの入金が個別の契約パスに移動すると、共有キューベクターは閉じられます。したがって、監視の負担には明確な終了日が設定されます。この移行を通常のアップグレードではなく、注目すべき運用期間と捉えるチームが、ステーカーの資金を保護する上で最適な位置にあります。
市場のニュースは速いですが、どこでそれに対応するか同样重要です。今月10月、KuCoinはKuCoin 5.0をリリースし、KuCoinを再構築されたプラットフォームに変貌させます。以下が実際にあなたにどう変わるかです：
-
すべてを一つの口座で。従来のプラットフォームは、資金を「スポット」「証拠金」「先物」の別々の口座に分けて管理し、その理由をユーザーに理解させました。KuCoin 5.0の統合口座は、その仕組みを完全に廃止。一度入金すれば、すべてが簡単に利用可能（現在はVIPユーザー限定）。
-
株式、インデックス、コモディティ。KuCoin 5.0は、暗号資産からグローバル市場へ拡張します。暗号資産が横ばいになり、株式が上昇する（またはその逆）場合、法定通貨の送金を待つ必要なく、数分で移動できます。
-
リアルワールドアセット（RWA）。商品などの従来の資産へのトークン化されたエクスポージャーが、あなたの暗号資産口座内で利用可能に。世界金融で最も急速に成長しているセグメントの一つが、もはや機関投資家だけのものではなく、あなたが取引に使っている同じ残高からアクセスできます。
-
学びながら収益を得ましょう。取引の準備ができていませんか？KCUSDで、ステーブルコインを毎日自動再投資して利子を獲得できます。4%の利回りで、闲置中の入金をストレスなく活用できる最適な方法です。
-
シンプルな言葉で動くAIアシスタント。質問して、市場の状況を把握し、見ているものを理解しましょう。プラットフォームに組み込まれており、専門用語は一切不要です。
-
圧倒されないアプリ。より速く、クリーンで一貫性があり、チュートリアルなしで最初のタップから直感的です。
-
信頼するだけでなく、確認できるセキュリティ。MiCAR認可を受けたEUの企業であり、Proof of Reservesを自分で確認でき、国際的なセキュリティ認証（SOC 2 Type II、ISO 27001:2022）を取得しています。
数分で口座を作成し、暗号資産が過去にあった場所ではなく、これから向かう場所に合わせて構築されたプラットフォームで始めましょう。
Glamsterdamアップグレードとは具体的に何であり、ステーキングにとってなぜ重要なのでしょうか？
Glamsterdamは、Amsterdamの実行層とGloasのコンセンサス層の変更を統合した名称です。その主な目的は、プロポーザー・ビルダー分離の確立と、ガス上限の引き上げとより効率的なブロック処理を支援するブロックレベルのアクセスリストです。ステーキングに関して、オンチェーンビルダー登録と関連する入金パスウェイの導入により、フロントランニングリスクの基盤となる一時的なキュー共有動作が生じます。
入金ハイジャックウィンドウはどのくらいの期間続くのですか？
ウィンドウは、ビルダーの入金がバリデーター入金キューを通過している間のみ存在します。この条件はハードフォーク移行自体中に維持されます。アップグレードが完了すると、ビルダーの入金は別の契約を通じて処理され、共有キューのパスは閉じられます。したがって、実際の期間は数日または数週間ではなく、アクティベーションエポック周辺の数時間で測られます。
リスクは既に有効化されたバリデーターや既にステークされたETHに影響しますか？
いいえ。この攻撃は、まだアクティブなバリデーターを生成していない公開鍵に対する新規または保留中の入金をターゲットとしています。既存のバリデーターとその残高は、確立された引き出し認証情報の下にあり、記述された攻撃面の外にあります。
一般のステーカーはどのようにして自分自身を守ることができますか？
リキッドステーキングプロトコルを通じて入金するステーカーは、Glamsterdamアクティベーションに関する入金処理の具体的なガイドラインがプロトコルによって公開されていることを確認してください。マルチパーティ入金セキュリティまたはガーディアンスタイルの監督を既に実装しているプロバイダーを選択することで、残存リスクを軽減できます。独自のバリデーターを運用するステーカーは、入金送信ロジックが競合する0xB0入金によって同じ公開鍵を主張しないようにする必要があります。
コア開発者はなぜプロトコルレベルの修正を拒否したのですか？
予備入金チェックの提案は、スケジュールの圧力により計画されないと判断され、閉じられました。Sepoliaは既存のルールに基づいてすでに有効化されており、Hoodiクライアントのリリースも進んでいました。遅れて行動を変更すると、テストネットの再デプロイと遅延がさらに発生するリスクがありました。開発者は、露出期間が限定的であることを考慮し、アプリケーション層の対策で十分であると判断しました。
免責事項：このコンテンツは情報提供を目的としたものであり、投資アドバイスではありません。仮想通貨への投資にはリスクが伴います。ご自身で調査してください（DYOR）。
免責事項: このページは、お客様の便宜のためにAI技術を使用して翻訳されています。最も正確な情報については、元の英語版を参照してください。