原題：EIP-7702 アップグレードのセキュリティ保護：EOA からスマートウォレットへの安全な移行のためのプロキシパターン

原著者：Amie Corso
原訳：Foresight News

EIP-7702 により、シンプルな Ethereum ウォレット（EOA）をスマート コントラクト ウォレットにアップグレードできるようになり、セキュリティの強化、ハイエンド機能、ガス スポンサーシップの機会、その他のメリットが得られます。従来、スマートウォレットはゼロから構築する必要がありましたが、EIP-7702 の導入により、従来のウォレットをアップグレードして、同じウォレット アドレスを維持しながら、すべての資産とオンチェーン履歴を保持できるようになりました。これは、新しい番号を取得せずに固定電話からスマートフォンに切り替えるようなものです。

EOAは、「委任指定」と呼ばれる委任スマートコントラクトへのポインタを設定することでアップグレードされます。委任指定は、スマートコントラクトのロジックを委任してEOAを管理します。その結果、アップグレードされたEOAは、関数の実装、ストレージの設定、イベントの発行など、スマートコントラクトが実行できるすべてのアクションを実行できるようになります。EOAは、署名済みの新しいEIP-7702認証を使用することで、いつでもこの委任を変更または削除できます。これにより多くの新しい可能性が開かれる一方で、この強力な機能は、慎重な検討と革新的なソリューションを必要とする新たなセキュリティ上の課題も生み出します。

EOAをスマートコントラクトウォレットとして機能させるために、EOAのEIP-7702委任として使用するために設計された軽量のERC-1967プロキシコントラクトであるEIP7702Proxyを開発しました。プロキシによって実行される基本的なロジック転送に加えて、EIP7702Proxyには、EIP-7702委任アカウントに特有の課題に対処するための機能と設計上の選択肢も含まれています。 EIP7702Proxyの設計目標の一つは、「標準で導入された」Coinbase Smart WalletとEIP-7702委任型Coinbase Smart Walletとの間で可能な限りの整合性を維持することです。これは、EIP-7702メカニズムに必要な追加の複雑さを専用プロキシに抽象化し、CoinbaseSmartWalletの元の実装を引き続き利用し続けることを意味します。この課題に対する解決策は、CoinbaseSmartWallet実装だけでなく、あらゆる実装ロジックに効果的に適用でき、7702対応環境においてEOAのセキュリティを維持するのに役立ちます。

以下では、既存のスマートコントラクトウォレット実装をEIP-7702アップグレードに安全に適応させるための具体的な課題と、それに対応する設計ソリューションについて説明します。

課題1：安全な初期化の実施

EIP-7702の実装における最初の大きなハードルは、初期化の制約です。従来のスマートコントラクトウォレット（CoinbaseSmartWalletを含む）は通常、別のファクトリーコントラクトを介して、デプロイメント時に安全な初期化（アカウント所有権の確立）をアトミックに処理します。このアトミック性により、多くの実装では、一度しか呼び出せない保護されていない初期化関数が存在します。しかし、EIP-7702の設計では、コード委任プロセス（「デプロイメント」に相当するステップ）中に初期化呼び出しデータを実行することができないため、これをアトミックに実行することはできません。

このステップの分離により、重大な脆弱性が生じます。実装コントラクトがEIP-7702を介してEOAに「デプロイ」された場合、この7702アップグレードとウォレットの初期化のための標準EVMトランザクションがアトミックに実行されるという保証はありません。技術的には、承認を設定するコードは、初期化トランザクションと同時に送信されたとしても、独立して適用される可能性があり、攻撃者が初期化トランザクションを先制実行してスマートアカウントの所有権を主張できる可能性があります。

解決策：実装と初期化をアトミックに設定するためにEOA署名を要求する

既存のCoinbase Smart Walletは、UUPSUpgradeable実装（実際のCoinbaseSmartWalletロジック）を備えたERC-1967プロキシの背後にデプロイされていることに注意してください。実際のアカウントアドレスのコードは、ERC-1967で定義された通常のストレージ場所を使用して実装ロジックへのポインタを保存するプロキシです。 7702 における初期化脆弱性に対する当社の解決策は、実装ロジックはプロキシが実際に接続を確立した場合にのみアクティブになり（したがって危険になる）、そのことを認識することです。したがって、アトミックなデプロイメントと初期化を強制できない場合でも、アトミックな実装設定と初期化を強制することができます。

EIP-7702CoinbaseSmartWallet コントラクトアーキテクチャと論理委任プロセス

EIP-7702 の文脈では、EOA 自体がアカウントに変更を加える最初の権限を持ち、所有者が新しいスマート アカウントを初期化して確立することを承認するための署名を提供する必要があります。EIP7702Proxy コントラクトは、新しい論理実装をアトミックに設定し、アカウントを初期化する setImplementation 関数を実装しています。setImplementation 関数は次の処理を実行します。

EOA からの署名を検証します。署名には、新しい実装コントラクトのアドレス、初期化コールデータ、最終的なアカウント状態の安全性を評価するバリデータ コントラクトのアドレス、ノンスや有効期限などの基本的な署名リプレイ保護などの重要なデータが含まれています。

ERC-1967 インジケーターの値を新しい実装に設定し、提供されたコールデータを新しい論理実装に対して実行します。署名に含まれるバリデータによって実装される必要がある、validateAccountState 関数を呼び出します。バリデータとは、最終的なアカウント状態が安全であると判断するロジックを含む、実装固有のコントラクトです。例えば、CoinbaseSmartWalletの場合、CoinbaseSmartWalletValidatorはアカウントの所有権状態がnull以外であることを確認し、任意の初期化による脆弱性を解消します。

課題2：EIP-7702委任間での共有ストレージ

EIP-7702における最も複雑な課題は、おそらくストレージ管理に関するものです。EOAは、いつでもロジックを別のコントラクトに再委任したり、委任を完全に削除したりできます。すべての委任は、EOAアドレスで同じストレージスペースを共有します。時間が経つにつれて、複数のコントラクトが同じストレージへのアクセスを共有すると、「ストレージ競合」の問題が発生する可能性があります。ストレージ競合は、2つのコントラクトが異なる変更を加えたり、同じストレージ場所について異なる想定を行ったりした場合に発生し、予期しないエラーを引き起こす可能性があります。

ストレージ競合の管理は、共有ストレージの管理に可変実装ロジックが用いられるプロキシ設計の分野では既に馴染みのある問題です。アップグレード可能なプロキシは実装を変更できますが、プロキシコード自体（7702以外のアドレスの場合）は変更できません。これにより、アップグレードプロセスに決定論と保証がもたらされます。7702の再委任は、この共有ストレージを管理する可能性のある基盤ロジックに、完全な可変性の新たなレイヤーを導入します。これにより、任意の委任がストレージに及ぼす影響に関する保証は実質的に失われます。例えば、EOAが委任先AからBに委任し、再びAに戻る場合、戻ってきた委任先はストレージの状態について想定できず、委任先Bがストレージを消去したり、委任先Aのロジックだけでは実現できない状態に操作したりしている可能性があります。これは、委任モードに関係なく、あらゆる7702委任に当てはまります。以前の委任では、任意のストレージロケーションで何かを保存または削除している可能性があるからです。

A → B → A 委任パターンによって委任先 A が無効な状態になる例

解決策: セキュリティ上重要な保存値の外部化

EOA 委任はアカウント状態に恣意的な影響を与える可能性があります。EOA が悪意のある、または破壊的なコントラクトに委任された場合、現職の委任者はこのシナリオから保護することはできません。ドレイナー トランザクションへの署名と同様に、悪意のある 7702 委任を承認すると壊滅的な結果を招く可能性があり、このような結果から保護することは私たちの設計の範囲外です。EXIP7702Proxy は、善意ではあるものの潜在的に混沌とした参加者で構成されるマルチウォレットの 7702 対応エコシステムで予測される問題に対して自己防衛的になるように設計しました。本当に悪意のある、またはバグのある委任を承認する EOA から保護することはできません。

予測される問題の 1 つは、setImplementation 呼び出しの署名と、変更可能なアカウント状態によってもたらされるリスクです。EIP7702Proxy は、実装ロジックを設定し、安全な状態に初期化するために EOA 署名に依存しています。これらの署名が再生可能である場合、負債になる可能性があります。たとえば、署名が、後で侵害されて削除された最初の所有者を承認した場合、再生可能な署名によって侵害された所有者が再作成されたり、実装のダウングレードが強制されたりする可能性があります。

署名の再生に対する一般的な保護方法は、署名メッセージで nonce を使用し、検証後に使用済みとしてマークすることです。7702 アカウントへのリスク: 他の委任によって、この nonce 追跡ストレージが破損する可能性があります。ストレージ追跡の nonce 使用状況が削除された場合、EOA の setImplementation 署名（メモリプールで公開されている）は、EIP7702Proxy に委任するときに再適用される可能性があります。

署名が再生されないようにするために、アカウント ストレージ外の不変のコントラクトの場所で nonce 状態を維持する、別の NonceTracker シングルトンを実装しました。EOA のみが nonce に影響を与えることができ（増分のみ）、他の委任がこれらのセキュリティ上重要な値を操作するのを防ぎます。NonceTracker は、アカウント ストレージに何が起こっても、各 setImplementation 署名が 1 回だけ機能することを保証します。

課題 3: 従来のストレージ場所を共有するリスクの増大

ERC-1967で定義されているような標準ストレージスロットは、複数のデリゲート実装が使用する可能性のある慣例的な場所であるため、特にストレージ競合が発生しやすい傾向があります。ERC-1967実装スロットは、EIP7702Proxyで使用される唯一の標準ストレージ場所であり、プロキシが指すロジック実装のアドレスを格納します。私たちの設計では、このストレージ場所の値（アカウントで利用可能なロジックの多くを決定します）に関係なく、EIP7702Proxyは常に、EOAが期待するコントラクトに実装ロジックを正常に設定できることが保証されています。

何が解決されているかをより明確にするために、アカウントが異なるデリゲート間で遷移する場合（A→B→A）、両方のデリゲートがERC-1967プロキシパターンを実装している場合、デリゲートBはデリゲートAが実装アドレスの格納に使用するのと同じストレージスロットを当然使用します。デリゲートBは、その任期中に、意図的に、または自身のプロキシ処理の一部として、このスロットを変更または上書きする可能性があります。 UUPSUpgradeable プロキシ パターンでは、実装をアップグレードするためのロジックは実装コントラクト自体に定義されています。デリゲート B によってこのポインター位置に配置された実装に、実装に必要な upgradeToAndCall インターフェイスが含まれていない場合、デリゲート A に戻ったときに、その実装を変更するメカニズムが現在利用可能なロジック上に存在しない可能性があります。

新しいデリゲートが共有レガシー ストレージの場所を上書きする例

解決策: EIP7702Proxy で利用可能なアップグレード メカニズム

EIP7702Proxy は、setImplementation 関数によってこの問題を解決します。この関数は、実装に依存しないアップグレード メカニズムをプロキシ自体に直接提供します。これにより、中間デリゲートが ERC-1967 実装を無効な実装にポイントした（または完全に削除した）場合でも、EIP7702Proxy にデリゲートし直した後、元の EOA はプロキシの ERC-1967 ポインタを再構成して、選択した論理実装を指すようにする機能が保持されます。

課題 4: 標準の EOA 動作との後方互換性

EIP7702Proxy の設計目標の 1 つは、新しいスマート コントラクト機能に加えて、アカウントの EOA 機能との後方互換性を維持することでした。アドレス上のコードの有無は、そのアドレスと対話するプロトコルの実行フローに影響します。これは、この機能を使用して EOA とスマート コントラクトを区別するためです。考慮すべき主な動作は、署名の検証とトークンの受信動作の 2 つです。

署名の検証

スマート コントラクトの署名検証標準は、標準の EOA とは異なります。スマート コントラクトは、ERC-1271 で定義されている isValidSignature インターフェイスを実装し、コントラクトが署名を有効と見なすかどうかを判断するための任意のロジックを自由に定義できます。標準的な EOA の場合、署名は標準の ecrecover チェックによって検証され、署名者が期待される EOA アドレスに戻ることが保証されます。

7702 へのアップグレード後も、既存または将来の EOA 署名が EOA で引き続き認識されるように、EIP7702Proxy は、最初に署名検証をロジック実装で定義される isValidSignature 関数に委任するバージョンの isValidSignature を実装します。検証が失敗した場合は、最終的に ecrecover チェックが実行されます。このチェックに合格すると、署名は有効とみなされます。このように、EIP7702Proxy を使用する EOA は、スマート コントラクト ウォレットの isValidSignature 実装に関係なく、シンプルな EOA 署名が常にそのアドレスで認識されることを保証できます。

トークンの受信

一部のトークン標準（特にERC-1155とERC-721）では、管理できない可能性のあるスマートコントラクトにトークンが滞留するのを防ごうとしています。これらのトークンでは、トークンを受信するスマートコントラクトは、トークン転送時にトークンコントラクトによって呼び出される標準トークン受信インターフェースを実装することにより、この機能をアドバタイズする必要があります。また、アップグレードされたEOAのロジックには、ネイティブトークンを受信できるように、標準受信関数または支払い可能なフォールバックが含まれていることも重要です。アカウントは、たとえ短期間であっても、ETHまたはその他のトークンを受信できない状態になってはなりません。

このプロキシには初期実装がないため、ERC-1967インジケーターがない場合に備えて、EIP7702Proxyのデフォルトロジックとして不変のDefaultReceiver実装を組み込みました。このレシーバーは、これらの共通トークンの受信関数と標準レシーバーフックを実装し、新しい実装を明示的に設定する前にアカウントがトークンの転送を受け入れることができるようにします。

結論

EIP7702Proxy の設計により、標準で導入されている CoinbaseSmartWallet との整合性を維持し、既存の CoinbaseSmartWallet 実装を引き続き使用しながら、EIP-7702 のコンテキストで発生する固有のセキュリティ上の課題に対処できます。初期化のセキュリティ、ストレージの一時性と干渉の影響、中断のないトークン処理の必要性、標準の EOA 署名検証との下位互換性を慎重に考慮することで、EIP-7702 スマート コントラクト ウォレットを安全に委任および管理するためのプロキシを構築しました。EIP7702Proxy は CoinbaseSmartWallet V1 実装を念頭に置いて設計されましたが、このプロキシは最終的には実装に依存しません。開発者には、他のスマート コントラクト ウォレット実装の 7702 対応のためにこのソリューションを評価することをお勧めします。

元のリンク

BlockBeats の公式コミュニティに参加しよう：

Telegram 公式チャンネル：https://t.me/theblockbeats

Telegram 交流グループ：https://t.me/BlockBeats_App

Twitter 公式アカウント：https://twitter.com/BlockBeatsAsia