EIP-7702はウォレットのセキュリティにどのような影響を与えるのか？委任のリスクと資産盗難を理解する

EIP-7702は、Ethereumのアカウント抽象化の発展における重要なプロトコル改善です。従来のEOAウォレットが、認可を通じてスマートコントラクトの実行ロジックを委任できるようにし、通常のアドレスでもバッチトランザクション、ガス代のスポンサー提供、より柔軟なアカウント管理をサポートできるようにします。完全に新しいスマートコントラクトウォレットを作成する方法とは異なり、EIP-7702は、アカウントによるトランザクション実行方法を変更しながらも、ユーザーの既存ウォレットアドレスと資産を維持します。

ただし、アカウント機能の拡張は、セキュリティ境界の変化も意味します。これまでユーザーは主に、秘密鍵が漏洩していないか、トークンのApprove権限が過大に設定されていないか、トランザクション署名に異常な送金が含まれていないかに注目していました。EIP-7702では、ユーザーが理解すべき別の種類の操作が導入されます。1回の認可により、ユーザーは自身のアドレスに対して、以後のトランザクションで指定されたコントラクトコードを実行することを許可する可能性があります。そのコードが悪意のあるものである場合、または委任が攻撃者により制御されている場合、資産リスクは単一のトランザクションを超えて広がる可能性があります。

したがって、EIP-7702を理解するには、提供されるアカウント抽象化の体験に注目するだけでは不十分です。委任認可がどのように有効になるか、悪意あるコードがどのような操作を実行できるか、一般ユーザーが危険な委任をどのように特定し、削除できるかを分析する必要もあります。本記事では、EIP-7702に関連する技術的な仕組み、潜在的な攻撃経路、ウォレットのセキュリティ対策について解説します。

要点

• EIP-7702は、EthereumのPectraアップグレードで導入されたアカウント機能です。従来の外部所有アカウント（EOA）が、資産を新しいアドレスへ移転することなく、委任を通じてスマートコントラクトロジックを実行できるようにします。

• EIP-7702の認可は、通常のERC-20 Approveとは異なります。前者はアカウントの実行ロジックを変更する可能性がある一方、後者は通常、特定の利用者に対して一定量のトークンを使用する権限を付与します。

• 悪意ある委任のリスクは、必ずしも秘密鍵の漏洩によって生じるものではありません。ユーザーが秘密鍵を保持していても、危険な委任認可に署名すると、資産がリスクにさらされる可能性があります。

• EIP-7702の委任は、単一のトランザクションの完了後に自動的に失効するものではありません。委任を取り消す、または置き換えるには新たな有効な認可が必要であり、委任を解除しても、すでに移転された資産を取り戻すことはできません。

• EIP-7702のセキュリティ評価では、署名の送信元を確認するだけでは不十分です。委任先コントラクトの権限、コードの挙動、アップグレード機能も理解する必要があります。

EIP-7702とは？従来のEOAウォレットが委任実行を必要とする理由

Ethereumのアカウントは主に、外部所有アカウント（Externally Owned Accounts、EOA）とスマートコントラクトアカウントに分けられます。EOAは秘密鍵によって管理され、トランザクションを開始できます。スマートコントラクトアカウントは、デプロイ済みのコードに従って操作を実行し、より複雑な権限管理とトランザクションロジックをサポートできます。

従来のEOAは、シンプルな構造と幅広い互換性を提供する一方、実行機能には制限があります。例えば、ユーザーは一連のオンチェーン操作を完了するために、複数のトランザクションへ個別に署名する必要がある場合があります。また、ネットワークガス代を支払うために、自らETHを保有している必要があります。スマートコントラクトウォレットはこれらの体験を改善できますが、多くの場合、新しいアカウントのデプロイ、資産の移行、追加の互換性要件への対応が必要になります。

EIP-7702は異なる解決策を提供します。EOAは認可を通じて、指定されたアドレスにあるスマートコントラクトロジックへアカウントコードの実行を委任できます。ユーザーはウォレットアドレスを変更することなく、既存のウォレットアドレスから一部のスマートアカウント機能を利用できます。

プロトコルレベルでは、EIP-7702は新しいトランザクションタイプと認可リストを導入します。適格な認可は、EOAのコードフィールドを、指定されたコントラクトアドレスを指す特別な委任インジケーターに設定できます。別のトランザクションがそのアカウントを呼び出すと、Ethereumは関連ルールに従って委任先コードを実行します。

この設計により、ウォレット製品はバッチ操作、柔軟なトランザクション検証、ガス代のスポンサー提供、コントラクトベースの権限管理をより柔軟にサポートできます。ただし、EIP-7702自体がこれらすべての機能を自動的に提供するわけではありません。具体的な機能は、委任先コントラクトがどのように実装されているかに依存します。

EIP-7702はどのように機能するのか？認可署名と委任先コントラクトの関係

EIP-7702の中核的な考え方は、アカウント所有権とコード実行ロジックを分離することです。ユーザーは既存の秘密鍵を通じてEOAを引き続き管理しながら、プロトコル準拠の認可を用いて、アドレスが使用すべきコントラクトコードを指定できます。

認可データには通常、チェーンID、委任先アドレス、アカウントnonce、アカウントの秘密鍵で生成された署名が含まれます。ネットワークが認可リストを含むトランザクションを処理すると、認可を検証し、プロトコルルールに従って対応するアカウントの委任状態を更新します。

一般的なEIP-7702の委任プロセスは、以下の4段階で構成されます。

1. 委任先を選択する：ウォレットまたはアプリケーションが、使用する必要のあるスマートコントラクト実装アドレスを決定します。

2. 認可署名を生成する：ユーザーは、EOAの秘密鍵を使用して、指定された委任先の認可データに署名します。

3. オンチェーンで認可を処理する：認可はEIP-7702をサポートするトランザクションに含まれます。検証後、ネットワークはアカウントの委任インジケーターを設定します。

4. 委任先コードを実行する：以後、アカウントが呼び出されると、指定された実装コントラクトのコードがEIP-7702のルールに従って実行されます。

ここでは、混同されやすい2つの概念を区別する必要があります。認可署名は、通常のトランザクション署名と完全に同じではありません。通常の送金署名は一般に特定のトランザクションを承認するために使用されますが、EIP-7702の認可はアカウントが使用するコード実装を設定します。これは、複数の後続トランザクションの実行動作に影響する可能性があります。

委任先アドレスは、ユーザーがそのアドレスに秘密鍵を渡したことを意味するものではなく、そのアドレスの所有者が自動的に資産移転の権限を得ることも意味しません。実際のリスクは、委任先コードがトランザクション検証、実行エントリーポイント、アクセス制御をどのように処理するかに依存します。コードがアカウント所有者からの追加認可なしに攻撃者による資産操作を許可する場合、危険な委任が資産窃取の入口となる可能性があります。

EIP-7702はERC-20 Approveとどのように異なるのか？

従来のDeFiトランザクションでは、ユーザーはERC-20 Approveを使用して、分散型取引所または別のスマートコントラクトに特定のトークンを使用する権限を付与することがよくあります。例えば、ユーザーはコントラクトに対して最大100 USDCまで使用することを許可できます。この認可は通常、トークンコントラクトに記録され、特定の利用者が使用できるトークン量を制御します。

EIP-7702は異なる認可レベルで動作します。特定量のトークンを使用することをコントラクトに単に承認するのではなく、アカウントが実行するスマートコントラクトコードを指定します。委任先コードには、トランザクション検証、資産移転、バッチ呼び出し、その他のアカウント管理機能が含まれる可能性があるため、潜在的な影響範囲はより広くなる可能性があります。

EIP-7702の委任は、ウォレットの所有権が直接コントラクトへ移転されることを意味しません。安全な委任実装では、引き続きアカウント所有者による有効な署名を要求し、トランザクション制限、時間制限、その他の保護措置を適用できます。

ただし、ユーザーが悪意あるコントラクトを認可した場合、その内部ロジックによって、ユーザーが承認する意図のなかった操作を攻撃者が実行できる可能性があります。したがって、通常のApprove認可と比べて、EIP-7702のセキュリティ確認では、認可額だけでなくコントラクトコード自体により注意を払う必要があります。

悪意あるEIP-7702認可は、どのようにウォレット資産の窃取につながるのか？

EIP-7702の主なセキュリティリスクの1つは、攻撃者が署名フィッシングを利用し、ユーザーをだまして悪意ある委任を承認させる可能性があることです。攻撃者は、認可リクエストをウォレットのアップグレード、アカウント検証、報酬の請求、トランザクション最適化などに見せかけ、ユーザーに通常の署名を行っていると思わせる可能性があります。

ユーザーが悪意あるコントラクトを指す有効な認可に署名すると、攻撃者はそれをオンチェーンに送信する可能性があります。認可署名そのものが、必ずしも直ちにアカウント状態を変更するわけではない点に注意が必要です。委任は、関連する認可が有効なトランザクションに含まれ、検証を通過した後にのみオンチェーンで有効になります。

委任先コードに攻撃者が呼び出せる資産移転機能が含まれている場合、攻撃者はその実行ロジックを使用して、アカウントからETHまたはその他のトークンを移転する可能性があります。

典型的なリスク経路は、以下のようにまとめられます。

1. 署名を誘導する：攻撃者は、偽のウェブサイトまたはアプリケーション画面を通じて、悪意ある委任先に対するユーザーの認可を取得します。

2. 認可を送信する：攻撃者または別のトランザクション送信者が、有効な認可をEIP-7702をサポートするネットワークに送信します。

3. 委任を設定する：認可を検証した後、ネットワークは影響を受けたアカウントに指定されたコントラクトコードを実行させます。

4. 悪意あるロジックを起動する：攻撃者は、悪意あるコード内の悪用可能な実行エントリーポイントを呼び出します。

5. 資産を移転する：悪意あるロジックが、アカウントのコンテキストで送金、トークン操作、またはその他の危険な操作を実行します。

この種の攻撃の危険性は、ユーザーが単一の署名リクエストしか目にせず、それによってアカウントによる後続トランザクションの実行方法が変わる可能性を認識しない点にあります。

2026年10月30日、Binance関連のホットウォレットに関する重大なセキュリティインシデントが発生しました。TRM Labsのインシデント分析では、攻撃者がEthereumネットワーク上でEIP-7702の委任を使用し、関連するホットウォレットを悪意ある実行コードに接続したと結論付けています。また、他のブロックチェーンでも異常な資金移転が確認されています。攻撃規模、署名の取得方法、初期侵入経路については、異なるセキュリティ分析で依然としてさらなる検証が必要な詳細が含まれています。

このインシデントは、EIP-7702が通常のウォレット自動化のためのインフラとして機能する一方で、認可または署名システムの制御喪失による影響を拡大させる可能性もあることを示しています。ただし、EIP-7702プロトコル自体に、任意の攻撃者が署名検証を回避できる脆弱性が存在することを示すものではありません。

ユーザーの秘密鍵が漏洩していなくても、攻撃者が資産を移転できるのはなぜか？

従来のウォレットセキュリティ教育では、秘密鍵を取得した攻撃者がアカウント所有者の有効な署名を偽造できるため、シードフレーズと秘密鍵の保護が重視されてきました。しかし、スマートコントラクトとのやり取りでは、秘密鍵が漏洩していないことだけで資産の安全が保証されるわけではありません。

その理由は、ユーザーが危険な結果をもたらす認可に自ら署名する可能性があるためです。EIP-7702では、攻撃者が必ずしも秘密鍵を直接取得する必要はありません。攻撃者がユーザーを誘導して有効な悪意ある委任認可に署名させ、オンチェーン実行の条件を満たした場合、アカウントの後続動作に影響を与えられる可能性があります。

このリスクは従来の署名フィッシングに似ていますが、対象が単一のトランザクションや特定のトークン承認額から、アカウントの実行ロジックへと拡大しています。

攻撃者は、企業ウォレットの署名システム、権限承認プロセス、または操作端末を標的にする可能性もあります。署名システムが、本来の業務目的と一致しない有効な認可を生成するよう誘導された場合、基盤となる秘密鍵が直接漏洩していなくても、重大な結果が生じる可能性があります。

したがって、ウォレットのセキュリティは秘密鍵保護だけに依存することはできません。署名プロセス自体も保護する必要があります。ユーザーは、通常の送金、トークン認可、またはアカウント動作に長期間影響する可能性のあるコード委任のどれに署名しているのかを把握する必要があります。

機関向けウォレットでは、署名ポリシー、コントラクトの許可リスト、複数者承認、トランザクションシミュレーションについても、従来の送金額確認だけに依存するのではなく、EIP-7702の認可を対象に含める必要があります。

EIP-7702の委任は自動的に失効するのか？危険な認可を確認・取り消す方法

EIP-7702の重要な特徴の1つは、委任を設定したトランザクションが完了しても、委任状態が自動的に解除されないことです。

アカウントが委任を正常に設定すると、関連するコードインジケーターは通常、新しい有効な認可によって置き換えられるか解除されるまで維持されます。つまり、ユーザーがウェブサイトを閉じた場合、ウォレットを切断した場合、または元のトランザクションを完了した場合でも、委任は有効なままである可能性があります。

プロトコルレベルでは、ユーザーは新たな有効な認可を使用して委任先をゼロアドレスに設定することで、EIP-7702の委任インジケーターを解除できます。必要に応じて、信頼できる実装コントラクトを再認可することもできます。

委任を確認・管理するには、以下の手順を使用できます。

1. アカウントのコード状態を照会する：信頼できるブロックエクスプローラーまたはウォレットセキュリティツールを使用して、アドレスにEIP-7702の委任が存在するか確認します。

2. 委任先コントラクトを検証する：委任先が、使用しているウォレット製品によって公開された同じ実装コントラクトを指しているか確認します。

3. コントラクトリスクを評価する：コードが監査済みか、管理者権限があるか、アップグレード可能か、第三者による資産操作を許可しているかを確認します。

4. 異常な委任を解除する：手順とネットワーク条件を確認した後、信頼できるツールを使用して、新たな有効な認可を送信し、危険な委任を解除または置き換えます。

5. 関連リスクを確認する：ERC-20の承認額、異常なトランザクション履歴、他のチェーンにおけるアカウントの状態も確認します。

EIP-7702の委任が設定されたアカウントのコードを照会すると、ユーザーには0xef0100で始まり、その後に委任先アドレスが続く特別なインジケーターが表示される場合があります。これはプロトコルレベルの識別方法の1つです。ただし、一般ユーザーが生の16進数データを自ら解析する必要はありません。EIP-7702の状態を正確に表示する信頼できるツールを使用できます。

委任を取り消しても、資産が復元されるわけではなく、アカウントが完全に安全であることも保証されない点に注意が必要です。秘密鍵、署名デバイス、または操作環境がすでに侵害されている場合、委任の解除だけでは不十分な可能性があります。アカウントの侵害が疑われる場合は、関連する署名環境の使用を停止し、安全を確保したうえで残りの資産を移転することを検討してください。

EIP-7702のセキュリティモデルはERC-4337スマートアカウントとどのように異なるのか？

EIP-7702とERC-4337はいずれもEthereumのアカウント抽象化に関連していますが、異なる方法で課題に対応しています。

ERC-4337は、UserOperation、Bundler、EntryPointなどのコンポーネントを使用し、従来のEOAがすべての操作を直接開始することに依存せずに、スマートコントラクトアカウント向けのトランザクション実行フレームワークを提供します。アカウントの検証ルールと実行ルールは、スマートコントラクトによって実装されます。

EIP-7702は主に、従来のEOAがどのようにスマートコントラクト実行機能を取得できるかという課題に対応します。既存アドレスがコントラクトコードの実行を委任できるようにすることで、スマートアカウント機能を導入したいユーザーの障壁を下げます。

両者は完全な代替関係にはありません。一部のウォレットアーキテクチャでは、EIP-7702を使用して既存EOAにコード実行機能を提供し、その後ERC-4337のインフラと組み合わせることで、より充実したスマートアカウント体験を提供できます。

セキュリティの観点では、EIP-7702では悪意ある委任と署名詐欺に注目する必要があります。ERC-4337では、アカウントコントラクトの検証ロジック、実行モジュール、アップグレード権限、関連インフラのリスクに注意を払う必要があります。実際のセキュリティは、どの規格を採用するかではなく、具体的な実装に依存します。

一般ユーザーはEIP-7702の署名フィッシングからどのように身を守れるのか？

一般ユーザーにとって、EIP-7702のリスクを管理する鍵は、スマートアカウント機能を完全に避けることではなく、異なる署名が示す権限変更を認識することです。

1. ユーザーは、トランザクション署名、メッセージ署名、トークン認可、アカウント委任を区別する必要があります。ウォレット画面にEIP-7702、Delegation、Set Code、または類似の表示がある場合、その操作が本当にアカウントの実行ロジック変更を必要とするか確認してください。

2. 委任先アドレスには特に注意してください。通常のウォレット機能のアップグレードでは、検証済みのスマートアカウント実装コントラクトを設定する必要がある場合がありますが、見慣れないウェブサイトが未知のアドレスへの委任を求める場合、ユーザーは慎重であるべきです。コントラクトのソースコードが公開されていても、その権限設計が安全であるとは限りません。

3. ウェブサイト名、インターフェース設計、ソーシャルメディアのリンクだけで、認可リクエストの信頼性を判断しないでください。攻撃者は、偽のウォレット更新ページ、検索広告、侵害されたフロントエンドページを利用して、ユーザーをだまして署名させる可能性があります。

4. 可能な限り、認可内容を明確に表示し、トランザクションシミュレーションとリスク警告を提供するウォレットツールを使用してください。署名デバイスにユーザーが理解できない生データしか表示されない場合は、内容を確認せずに署名しないでください。

5. 資産規模と利用シナリオに応じたアカウント分離を検討してください。長期保有資産を、頻繁なDeFi操作、エアドロップ、新しいアプリケーションに使用するウォレットと分けることで、単一の悪意ある認可による潜在的な影響をある程度抑えられます。

ハードウェアウォレットは秘密鍵保護を向上させますが、ユーザーが自ら承認する委任が安全かどうかを自動的に判断できるわけではない点に注意が必要です。安全な署名には、信頼できる情報表示と、ユーザーによる十分な理解に基づく判断が引き続き必要です。

EIP-7702はウォレットセキュリティとアカウント抽象化の将来に何をもたらすのか？

EIP-7702は、Ethereumアカウントを、EOAの比較的固定された実行モデルから、より柔軟でプログラム可能なアカウントへと移行させます。ウォレット開発者にとって、これは既存アドレスを維持しながら、バッチトランザクション、ガス代のスポンサー提供、権限管理、自動実行を提供できることを意味します。

ただし、アカウントのプログラム可能性が高まるほど、より正確なセキュリティ確認が必要になります。これまで、ウォレットのリスク警告は主に送金先、トランザクション額、トークン承認額に焦点を当てていました。今後は、委任先、コントラクトの検証ルール、実行権限、潜在的な長期的影響も正確に表示する必要があります。

製品設計の観点から、EIP-7702のセキュリティ対策は3つの方向に発展する可能性があります。

• 認可の透明性。ウォレットは、単にコントラクトアドレスを表示するのではなく、委任によって何が変更されるかをユーザーが理解できるようにする必要があります。

• 最小権限。委任先コントラクトは、厳格なアクセス制御、上限、有効期限、複数の検証メカニズムにより、潜在的な損失を抑えることができます。ただし、これらの制限はフロントエンド表示だけに依存するのではなく、実際のコードによって確実に適用される必要があります。

• 継続的なリスク監視。委任は長期間維持される可能性があるため、ウォレットセキュリティツールは、初回署名時だけを確認するのではなく、異常な委任、コントラクトコードの変更、不審なアカウント操作を検出できる必要があります。

EIP-7702の意義は、ウォレット体験を改善することだけでなく、アカウントセキュリティを従来の秘密鍵保護から、署名意図、コード実行、継続的な権限を統合的に管理する領域へ拡張することにあります。

まとめ

EIP-7702は、従来のEthereum EOAにスマートコントラクト委任機能を導入し、ユーザーが既存のウォレットアドレスを維持しながら、より柔軟なアカウント実行機能を利用できるようにします。この仕組みはアカウント抽象化の新たな技術的基盤を提供しますが、従来のウォレットにおけるセキュリティ境界も変化させます。

主にトークン使用の承認額を制御するERC-20 Approveとは異なり、EIP-7702の認可は、アカウントが実行するコントラクトコードを変更する可能性があります。ユーザーが悪意ある委任に署名した場合、攻撃者はユーザーの秘密鍵を必ずしも直接取得することなく、安全でない実行ロジックを使用して資産を移転する可能性があります。

したがって、EIP-7702が安全かどうかを評価するには、認可がユーザーによって署名されたかを確認するだけでは不十分です。委任先、コントラクト権限、署名の送信元、後続の実行動作も確認する必要があります。スマートアカウント機能の導入が広がるにつれ、コード委任と権限管理を理解することは、ウォレットセキュリティ教育の重要な要素となるでしょう。

よくある質問

EIP-7702とは？

EIP-7702は、従来のEOAが認可を通じてスマートコントラクトコードの実行を委任し、一部のスマートアカウント機能を利用できるようにするEthereumのプロトコル改善です。

EIP-7702はウォレット資産を自動的に流出させるのか？

いいえ。EIP-7702自体は、資産を自動的に盗む機能ではありません。主なリスクは、悪意ある認可、安全でない委任先コード、または侵害された署名システムから生じます。

EIP-7702の認可はERC-20 Approveと同じか？

いいえ。ERC-20 Approveは通常、特定のアドレスにトークンを使用するための承認額を付与します。一方、EIP-7702の認可は、アカウントが実行するコントラクトコードを指定します。権限レベルが異なります。

EIP-7702の委任は取り消せるか？

はい。アカウント所有者は、新たな有効な認可を使用して委任を解除または置き換えることができます。ただし、秘密鍵または署名環境が侵害されている場合、委任の取り消しだけでは安全を保証できません。

ハードウェアウォレットはEIP-7702のフィッシングを防げるか？

完全には防げません。ハードウェアウォレットは秘密鍵の保護に役立ちますが、ユーザーがデバイス上で悪意ある認可を承認した場合、依然として資産リスクに直面する可能性があります。

ウォレットにEIP-7702の委任があるかどうかを確認する方法は？

EIP-7702をサポートするブロックエクスプローラーまたはセキュリティツールを使用して、アカウントコードと委任先を照会できます。見慣れない委任先アドレスを見つけた場合は、その送信元と権限を検証してください。