MetaMaskは、同社のステーキング・サービスを利用する一部のイーサリアム・バリデーターの実行層報酬が、攻撃者により一時的に別アドレスへ送られるよう改ざんされ、約0.385 ETHが横取りされた後、同日内に検知・復旧されたことを確認した。詳細は11月5日のインシデント更新で公表され、同社が9月28日に最初に確認したセキュリティ・インシデントに関する最新の報告である。横取り額は小さいものの、この一連の出来事はイーサリアムの設計において見落とされがちな点、すなわちバリデーターのステーキングETHが最終的にどこへ行くかと、継続的な報酬収入がどこへ送られるかの区別を浮き彫りにしている。

MetaMaskがこれまでに公表した内容

更新情報によると、攻撃者はMetaMaskステーキングの基盤インフラの一部に不正アクセスした。そこでは、バリデーターの実行層報酬を回収するアドレスが中央管理されて保存されていた。侵入者は一部のバリデーターについてこれらのアドレスを変更した。MetaMaskは、約0.385 ETHの報酬が流用された後、同日中に変更を発見し修正したと説明している。影響を受けたバリデーターの数や攻撃者がアクセスを獲得した方法は未公表である。

引き出し側は守られた。MetaMaskステーキングは顧客のステーキングETHの引き出し鍵を保持しておらず、同社はステーキング元本、引き出し鍵、MetaMaskウォレットが侵害された証拠は見つかっていないとしている。一般のMetaMaskウォレット・ユーザーは対応を取る必要はない。

0.385 ETHは事件の全損害ではない。MetaMaskは予防措置として影響を受けたすべてのバリデーターを退避させ、現在そのすべてが完了している。一部の顧客は一時的な出金遅延を経験し、同社はバリデーターの退避中や再ステーキング待ちの間に報酬の取り逃しが発生した可能性を認めている。MetaMaskはこれらの損失を定量化しておらず、流用された報酬が補償されるかどうかも明言していない。影響を受けた顧客やパートナーと直接連携を進めていると述べるのみである。

報酬流用そのものは11月5日の報告でのみ言及されている。MetaMaskの9月30日および10月1日の通知は、インシデントと予防的な退避について説明し、その時点ではウォレットや顧客資金に影響が及んだ兆候はないとしていた。関係したバリデーターの数、攻撃者の侵入経路、補償の問題は、MetaMaskからの今後の更新で注視すべき未決事項である。

元本は守られたが収入は守られなかった理由

すべてのイーサリアム・バリデーターは、異なる場所で設定される2つのアドレスに従っている。イーサリアムの引き出しガイダンスでは、引き出し資格情報（withdrawal credentials）とフィーレシピントは、両者が同じウォレットを指しうる場合でも、別個の設定として扱われている。

引き出し資格情報はビーコンチェーンに登録される。一度実行層アドレスを指すと、そのアドレスは変更できず、バリデーターが退避する際にそのETHが送られる先となる。オペレーターのサーバーがこれを差し替えることはできない。

フィーレシピントは異なる仕組みだ。これはバリデーターを運用する者が設定するソフトウェア設定である。ノンカストディアル・サービスでは、それがオペレーターであり、バリデーターが署名に使う鍵も保持している。この設定は、バリデーターがブロックを提案するたびに、実行層の収入——トランザクション優先手数料およびブロックビルダーからの支払い——をどこへ送るかをネットワークに指示する。対照的にベースフィーは焼却され、バリデーターには届かない。オペレーターは、ステーカーの引き出し鍵なしで、いつでもフィーレシピントを更新できる。MetaMaskが中央管理していたと明かしたのがこの設定であり、攻撃者が変更したのもこの設定である。

同じこの二分構造が、損失が小さく抑えられた理由でもある。コンセンサス層の報酬はバリデーターの残高に留まるか、自動的に引き出しアドレスへ送られるため、改ざんされた設定の影響を一切受けなかった。実行層の収入はバリデーターがブロックを提案したときにしか届かず、単一のバリデーターでこれはまれにしか起こらず、MetaMaskは1日以内に修正した。この期間内に行われた提案のみが誤ったアドレスに支払われた。

同じリスクはプール型ステーキングにも及ぶ

このリスクはMetaMaskに固有のものではない。第三者がバリデーターを運用するすべての場所で、フィーレシピントはその第三者の設定の中に存在し、このリスクは一社限定の欠陥ではなく、第三者ステーキングの構造的特徴となっている。バリデーターを独立系ノードオペレーターが運用するLidoは、ルールでこのリスクに対処している。既存のMEVポリシーでは、すべてのLidoバリデーターにプロトコルのExecution Layer Rewards Vaultをフィーレシピントとして指定することを義務付けており、違反にはすでに独自の対応プロセスが存在する。

このボールトはコントラクトである。Lidoのドキュメントによれば、MEVや優先手数料を含む実行層の収入を回収し、メインのLidoコントラクトだけがそこから引き出せる。引き出されたETHはstETH保有者向けのプロトコルの会計に組み込まれる。他の場所へ送られた支払いはその会計には決して入らない。

stETH保有者は、MetaMaskステーキングの顧客よりもさらに一歩外側に位置する。彼らは特定のバリデーターの引き出し資格情報ではなく、譲渡可能なトークンを所有しているため、その保護は完全にLidoのコントラクトとオペレーターのルールに依存している。

ePBSが保証するのは支払いであり、アドレスではない

11月4日、Lidoは、EIP-7732で規定される設計である内蔵型プロポーザー・ビルダー分離（ePBS）に対応してそのMEVポリシーを更新する提案を公表した。ブロック構築を外部委託するバリデーターは現在、リレーという、落札したビルダーが実際に支払うことを保証する中間者に依存している。LidoはePBSを、プロトコル自体がビルダーへの支払いを保証することで、その信頼への依存を減らすものと説明している。

この保証には限界がある。Lidoが説明する設計では、単一の入札は、信頼不要（trustless）の価値——プロポーザーが入札を取り込んだ時点で債務が発生し、ビルダーがブロックを公開しない場合でも支払われる——と、プロトコル外で決済される任意の信頼型支払いを組み合わせることができ、後者は現在の市場と同じカウンターパーティー・リスクを負う。Lidoは登録済みのビルダーなら誰でも完全な信頼不要入札でスロットを獲得できるようにするが、信頼型支払いを追加できるのは審査済みの許可リスト（Allowed List）に載ったビルダーのみとする。

ステーカーにとってより重要なのは、この保証が支払額をカバーするのであって、着地点をカバーするわけではないという点だ。この設計では、バリデーターは今後のスロットのフィーレシピントを指定した署名済み設定をブロードキャストし、信頼不要の価値は入札で指定されたフィーレシピントへ支払われる。そのアドレスは依然としてオペレーター起点である。MetaMaskが説明したような形で改ざんされたフィーレシピントは、正しいアドレスと同じ確実性で保証付き支払いを受け取ることになる。

Lidoの草案は、フィーレシピントのルールを中核に据えている。両タイプの支払いはEL Rewards Vaultに届く必要があり、このポリシーはLidoのためにブロック提案が可能なすべてのノード、バックアップやフェイルオーバー用マシンを含めて拘束する。Lidoによれば、この提案は11月に投票にかけられ、Glamsterdamアップグレードがイーサリアム・メインネットに到達した後にのみ発効する。そのアップグレードが到来するまで、ボールト・ルールを含む既存のMEVポリシーがLidoバリデーターの基準であり続ける。

Lidoのチェックが検知するもの

ePBSはブロック提供の経路を広げるため、この提案はLidoのモニタリングを拡張する。バリデーターは、ボールト以外のアドレスを指定した場合や、許可リスト外のビルダーからの信頼型支払いを受け入れた場合にフラグが立つ。フラグの対象には、決済期間内に全額が到着しない信頼型支払いや、最低閾値を超える適格な外部入札があるのにローカル構築ブロックを提案した場合も含まれる。

入札価値チェックは、選ばれた各入札を、Lidoのモニタリングが観測した最高の適格入札と比較し、初期値の90〜95%を下回るものをフラグする。この閾値は質問を促すものであり、収入の保証割合ではない。草案では、正当な運用上・信頼性上の理由からオペレーターがトップ入札を見送ることを認めており、比較はLido自身のシステムが観測した入札のみを対象とする。

フラグが立っても資金が戻るわけではない。フィーレシピント違反はLidoの現行プロセスの下に留まり、その他のフラグは標準ノードオペレーター・プロトコルのセクションEに定められた連絡・エスカレーションの経路に従う。Lidoはまた、公開のFees Monitoring Dashboardを更新し、各Lidoブロックがどの経路を通ったかを表示する予定である。

自分のステーキング設定を確認する方法

実行層の支払いはオンチェーンに記録されており、MetaMaskでの改ざんアドレスが可視化されたのはまさにこのためである。自分のバリデーター・インデックスを知るステーカーは、ビーコンチェーン・エクスプローラーで該当バリデーターが提案した各ブロックを開き、どのアドレスがプロポーザー報酬を受け取ったかを確認できる。Lidoについては、フィーダッシュボードがプールのモニタリングの公開ビューである。

退避も同様に精査に値する。MetaMaskの更新情報が指摘するように、バリデーターの退避とETHの引き出しは別のプロセスであり、退避したバリデーターはETHが使用可能になる前に、イーサリアムのステーキング・ドキュメントに記載の通り、イーサリアムの引き出し処理を通過する必要がある。Pectraアップグレード以降、EIP-7002により、バリデーターの実行層引き出しアドレスの保持者は、オペレーターを通さずに直接退避をトリガーできるようになった。

この事件が露呈した空白をカバーするため、あらゆるステーキング提供者に問うべき4つの質問がある：

誰がフィーレシピントを変更できるか？ 中央に一括保存された設定ではなく、役割の明確化、変更前の承認、すべての編集記録を確認すること。

誤ったアドレスにどれだけ速く気づくか？ 定期的な手動レビューではなく、提案されるすべてのブロックに対する自動チェックとアラートを確認すること。

どのビルダー支払いが保証されるか？ ePBSの下では、プロトコル強制の価値と信頼型支払いの内訳、および未払い額の回収方法の説明を確認すること。

あなたなしで退避できるか？ 引き出し資格情報が自己トリガー型の退避に対応しているかを確認し、予防的退避中に取り逃した報酬を誰が負担するかを問うこと。