USENIX Security '26で発表された査読付き研究により、ウォレット委任機能の運用開始初期の数か月間で、EthereumのEIP-7702承認トランザクションの63%が攻撃者に関連するコントラクトと結び付いていたことが明らかになった。研究者らは7つのチェーンにわたって2025年7月までの366万件の承認トランザクションを追跡し、確認済み損失236万ドルを計測するとともに、時代遅れのコントラクト防御によってリスクにさらされた資産がさらに1,014万ドルあることを特定した。

問題の機能であるEIP-7702は、通常のEthereumウォレットが一時的にスマートコントラクトのように動作できるようにするものだ。2025年5月7日、Pectraアップグレードの一環として導入された。Ethereumの共同創設者Vitalik Buterin氏らが共同執筆したこの提案は、Pectraの計画段階で以前のEIP-3074設計の代替として持ち込まれたもので、従来は別個のコントラクトを必要としていた機能を通常のウォレットに与えるという、Ethereumのより広範なアカウント抽象化の取り組みの一部である。

研究チームは、Ethereum、Binance Smart Chain、Polygon、Optimism、Arbitrum、Base、Gnosisの7つのブロックチェーンにわたる228億件超のトランザクションを調査した。このデータセットの中で、2025年7月15日までのEIP-7702承認トランザクションは3,664,166件見つかった。このうち2,322,548件、つまり63%が、研究者らが悪意があると特定したコントラクトに関連していた。チームはトランザクションフィルター、コード分析、手動レビューを用いて、合計924件の悪意あるコントラクトを確認した。

委任機能の仕組み

EIP-7702では、ウォレットアドレスを変更することなく、そのアドレスに別のコントラクトコードを指し示すことができる。元の所有者は秘密鍵を保持し続けるが、リンクされたコードはそのアカウントの全権限で動作できる。アドレスが変わらないため、資金、履歴、アイデンティティはそのまま引き継がれる。変わるのは、アカウントの動作が現在指し示しているコードによって定義されるという点だ。委任は新しい承認に署名することで変更または解除することもできるため、オンチェーンで確認できるコードは直近のものだけを反映している。

この仕組みにより、ウォレットは複数の操作を1つのトランザクションにまとめるバッチ処理や、ガス代を他人に支払わせるといった機能を追加できる。同時に、リンクされたコードがウォレットのセキュリティの一部になることも意味する。そのコードに欠陥があったり攻撃者が作成したものであったりすれば、アカウント所有者であるかのように送金を承認し、資金を移動し、アプリケーションとやり取りすることが可能になる。

研究者らによると、攻撃者はこうした承認を事前に用意し、被害者に署名させていた。場合によっては、どのコードを承認しているのかを明確に表示しないウォレットのプロンプトを通じて行われていたという。

確認された損失とリスクにさらされた資産

研究では、3種類の攻撃タイプにわたる確認済み損失額として2,362,848.76ドルが計測された。

研究の別の部分では、ウォレットアドレスがコントラクトのように動作することはあり得ないという前提を置いた古いコントラクトが調査された。この前提はEthereumのローンチ以来成り立ち、一般的な安全確認として使われてきたが、EIP-7702の導入によって破綻した。研究者らは、今なおこの前提をセキュリティチェックとして依存している967件の稼働中のEthereumコントラクトを発見し、約1,014万ドルの資産が潜在的なリスクにさらされていることを明らかにした。

研究者らはまた、攻撃者が攻撃後にアカウントを正常に見えるコードへと切り替えていることも記録した。これにより、ウォレットの現在の状態を確認しても、過去に侵害されたことを検出するのは難しくなる。さらに、まだコードがデプロイされていないアドレスを指し示す500件の委任ターゲットも発見された。こうしたアドレスには後からコードが追加され、記録されたターゲットは同じままで、ウォレットの実際の動作が変わる可能性がある。

研究の著者らは、この手法ではすべての悪意あるコントラクト、特に新しいものや異なる攻撃手法を使うものを検出できるとは限らないと指摘している。確認された924件のコントラクトは、研究者らが検証できた範囲を示すものであり、悪用の全容ではない。

ウォレットへのガイダンスと提案

これを受けてEthereum.orgは、ウォレットが委任コントラクトをホワイトリスト化し、ユーザーに対して承認しようとしているコードを明確に表示し、監査済みのスマートアカウント実装のみに依存することを推奨するガイダンスを公開した。関連する提案では、任意のアプリケーションにカスタム委任コードを要求させるのではなく、ウォレットが公開レビュー済みの少数のアカウントシステムのリストに限定すべきだとされている。委任リクエストはプロトコルレベルではなくウォレットのインターフェース内でユーザーに届くため、こうしたインターフェースレベルの防御手段の導入こそが、現時点での実効的な防御の要となる。

研究者とEthereum開発者らは現在、アカウントが委任するコードをウォレットが審査し、明確に表示するよう求めている。

出典:Blockonomi