EIP-7702Proxyは、EOA...のEIP-7702デリゲート基本ロジックフォワーディングとして機能するように設計された軽量のERC-1967プロキシコントラクトで、EIP-7702デリゲートアカウントに固有の課題のいくつかに対処します。 この記事は、Boardlinkコミュニティによって書かれた記事からのものであり、ForesightNewsによって編集、編集、寄稿されています。 (あらすじ:イーサリアムペクトラは「ハッカーフリップ」をアップグレードし、Wintermuteは警告します:EIP-7702は多数の契約の展開を自動化します)(背景補足:イーサリアム財団の「1兆ドルセキュリティプロジェクト」が最初のレポートをリリース:スマートコントラクト、インフラストラクチャ、クラウドセキュリティの整理... 6つのエコロジカルチャレンジ EIP-7702は、シンプルなイーサリアムウォレット(EOA)をスマートコントラクトウォレットにアップグレードし、より優れたセキュリティ、高度な機能、ガススポンサーシップの機会、その他の利点を提供します。 歴史的に、スマートウォレットはゼロから構築する必要がありましたが、EIP-7702の導入により、従来のウォレットをアップグレードし、同じウォレットアドレスですべての資産とオンチェーン履歴を保持できるようになりました。 これは、新しい番号を取得せずに固定電話からスマートフォンに切り替えるようなものです。 EOAは、「委任指定」、つまりデリゲートスマートコントラクトへのポインタを設定し、スマートコントラクトのロジックをEOAの管理に委任することでアップグレードされます。 その結果、アップグレードされたEOAは、機能を持ち、ストレージを設定し、イベントを発行し、スマートコントラクトが実行できる他のすべての操作を実行できます。 EOA は、新しい署名済み EIP-7702 認証を使用して、このデリゲートをいつでも変更または削除できます。 これにより、多くの新しい可能性が解き放たれる一方で、この強力な機能によって、慎重な検討と革新的なソリューションが必要な新たなセキュリティ課題ももたらされます。 EOAがスマートコントラクトウォレットとして機能できるようにするために、EOAのEIP-7702デリゲートとして機能するように設計された軽量のERC-1967プロキシコントラクトであるEIP7702Proxyを開発しました。 エージェントによって実行される基本的な論理転送に加えて、EIP7702Proxy には、EIP-7702 委任アカウントに固有の課題の一部に対処する追加の機能と設計の選択肢が含まれています。 EIP7702Proxyを設計する目標の1つは、「標準でデプロイされた」CoinbaseスマートウォレットとEIP-7702が委任したCoinbaseスマートウォレットとの間のピア可能性を可能な限り維持することであり、これはEIP-7702メカニズムに必要な追加の複雑さを専用のプロキシに抽象化し、CoinbaseSmartWalletの元の実装に引き続き依存することを意味します。 この課題に対する解決策は、CoinbaseSmartWalletの実装だけでなく、あらゆる実装ロジックに効果的に適用でき、EOAが7702対応環境で安全を保つのにも役立ちます。 以下では、EIP-7702のアップグレードに既存のスマートコントラクトウォレットの実装を安全に適応させることを可能にする特定の課題と対応する設計ソリューションを示します。 課題 #1: セキュア初期化の強制 EIP-7702 を実装する際の最初の大きなハードルは、初期化の制約にあります。 CoinbaseSmartWalletを含む従来のスマートコントラクトウォレットは、通常、デプロイ中に安全な初期化(アカウントの所有権の確立)を、通常は別のファクトリーコントラクトを通じてアトミックに処理します。 この原子性は、そのような実装の多くが、一度しか呼び出すことができない保護されていない初期化子関数を持っていることを意味します。 ただし、EIP-7702 の設計では、コード デリゲート プロセス中に初期化 calldata を実行できないため (「デプロイ」と同等のステップ)、これをアトミックに実行することはできません。 このステップの分離により、重大な脆弱性ウィンドウが作成されます。 インプリメンテーションコントラクトがEIP-7702を介してEOAに「デプロイ」された場合、この7702アップグレードおよび初期化ウォレットの標準EVMトランザクションがアトミックに実行される保証はありません。 技術的には、同時にコミットされた場合でも、認証を設定するコードは初期化トランザクションアプリケーションから独立している可能性があるため、攻撃者は初期化トランザクションを先制的に実行し、スマートアカウントの所有権を主張できる可能性があります。 解決策: 実装をアトミックに構成し、初期化するには EOA 署名が必要です 既存の Coinbase スマート ウォレットは、UUPSUpgradeable 実装 (実際の CoinbaseSmartWallet ロジック) を使用して ERC-1967 プロキシの後にデプロイされることに注意してください。 実際のアカウント アドレスのコードは、ERC-1967 で定義された通常の格納場所を使用して実装ロジックへのポインターを格納するプロキシです。 7702 のコンテキストでの初期化の脆弱性に対する解決策には、エージェントが実際に接続を確立したときにのみ、実装ロジックがアクティブになる (したがって危険である) ことを認識することが含まれます。 したがって、原子性のデプロイと初期化を強制できない場合は、原子性の実装のセットアップと初期化を強制できます。 EIP-7702CoinbaseSmartWalletの契約構造と論理委任プロセス EIP-7702のコンテキストでは、EOA自体がアカウントに変更を加えるための最初の権限であり、新しいスマートアカウントを初期化して確立する所有者を承認するための署名を提供する必要があります。 当社のEIP7702Proxyコントラクトは、新しい論理実装をアトミックに設定し、アカウントを初期化するsetImplementation関数を実装しています。 setImplementation 関数: EOA からの署名を検証します。これには、新しい実装コントラクトのアドレス、初期化 calldata、最終的なアカウント状態のセキュリティを評価するバリデータ コントラクトのアドレス、nonce や有効期限などの基本的な署名リプレイ保護などの主要なデータが含まれます。 ERC-1967 ポインターの値を新しい実装に設定し、指定された calldata を新しい論理実装に対して実行します。 validateAccountState 関数を呼び出します。この関数は、署名に含まれる認証者によって実装される必要があります。 バリデーターは、最終的なアカウントの状態が安全であると考えるかどうかを評価するロジックを含む実装固有のコントラクトです。 たとえば、CoinbaseSmartWalletの場合、CoinbaseSmartWalletValidatorは、アカウントの所有権ステータスが空でなく、したがって任意の初期化に対して脆弱でなくなったかどうかを確認します。 課題 #2: EIP-7702 全体で委任された共有ストレージ 最も複雑な EIP-7702 の課題は、ストレージ管理に関連している可能性があります。 EOAは、いつでもそのロジックを別のコントラクトに再デリゲートしたり、デリゲートを完全に削除したりする自由があります。 すべての代表者は、次の場所でEOAアドレスを共有します...
イーサリアム EIP-7702 アップグレードの保証：安全な EOA から ウォレット への移行の代理モデル
EIP-7702Proxyは、EOA...のEIP-7702デリゲート基本ロジックフォワーディングとして機能するように設計された軽量のERC-1967プロキシコントラクトで、EIP-7702デリゲートアカウントに固有の課題のいくつかに対処します。 この記事は、Boardlinkコミュニティによって書かれた記事からのものであり、ForesightNewsによって編集、編集、寄稿されています。 (あらすじ:イーサリアムペクトラは「ハッカーフリップ」をアップグレードし、Wintermuteは警告します:EIP-7702は多数の契約の展開を自動化します)(背景補足:イーサリアム財団の「1兆ドルセキュリティプロジェクト」が最初のレポートをリリース:スマートコントラクト、インフラストラクチャ、クラウドセキュリティの整理... 6つのエコロジカルチャレンジ EIP-7702は、シンプルなイーサリアムウォレット(EOA)をスマートコントラクトウォレットにアップグレードし、より優れたセキュリティ、高度な機能、ガススポンサーシップの機会、その他の利点を提供します。 歴史的に、スマートウォレットはゼロから構築する必要がありましたが、EIP-7702の導入により、従来のウォレットをアップグレードし、同じウォレットアドレスですべての資産とオンチェーン履歴を保持できるようになりました。 これは、新しい番号を取得せずに固定電話からスマートフォンに切り替えるようなものです。 EOAは、「委任指定」、つまりデリゲートスマートコントラクトへのポインタを設定し、スマートコントラクトのロジックをEOAの管理に委任することでアップグレードされます。 その結果、アップグレードされたEOAは、機能を持ち、ストレージを設定し、イベントを発行し、スマートコントラクトが実行できる他のすべての操作を実行できます。 EOA は、新しい署名済み EIP-7702 認証を使用して、このデリゲートをいつでも変更または削除できます。 これにより、多くの新しい可能性が解き放たれる一方で、この強力な機能によって、慎重な検討と革新的なソリューションが必要な新たなセキュリティ課題ももたらされます。 EOAがスマートコントラクトウォレットとして機能できるようにするために、EOAのEIP-7702デリゲートとして機能するように設計された軽量のERC-1967プロキシコントラクトであるEIP7702Proxyを開発しました。 エージェントによって実行される基本的な論理転送に加えて、EIP7702Proxy には、EIP-7702 委任アカウントに固有の課題の一部に対処する追加の機能と設計の選択肢が含まれています。 EIP7702Proxyを設計する目標の1つは、「標準でデプロイされた」CoinbaseスマートウォレットとEIP-7702が委任したCoinbaseスマートウォレットとの間のピア可能性を可能な限り維持することであり、これはEIP-7702メカニズムに必要な追加の複雑さを専用のプロキシに抽象化し、CoinbaseSmartWalletの元の実装に引き続き依存することを意味します。 この課題に対する解決策は、CoinbaseSmartWalletの実装だけでなく、あらゆる実装ロジックに効果的に適用でき、EOAが7702対応環境で安全を保つのにも役立ちます。 以下では、EIP-7702のアップグレードに既存のスマートコントラクトウォレットの実装を安全に適応させることを可能にする特定の課題と対応する設計ソリューションを示します。 課題 #1: セキュア初期化の強制 EIP-7702 を実装する際の最初の大きなハードルは、初期化の制約にあります。 CoinbaseSmartWalletを含む従来のスマートコントラクトウォレットは、通常、デプロイ中に安全な初期化(アカウントの所有権の確立)を、通常は別のファクトリーコントラクトを通じてアトミックに処理します。 この原子性は、そのような実装の多くが、一度しか呼び出すことができない保護されていない初期化子関数を持っていることを意味します。 ただし、EIP-7702 の設計では、コード デリゲート プロセス中に初期化 calldata を実行できないため (「デプロイ」と同等のステップ)、これをアトミックに実行することはできません。 このステップの分離により、重大な脆弱性ウィンドウが作成されます。 インプリメンテーションコントラクトがEIP-7702を介してEOAに「デプロイ」された場合、この7702アップグレードおよび初期化ウォレットの標準EVMトランザクションがアトミックに実行される保証はありません。 技術的には、同時にコミットされた場合でも、認証を設定するコードは初期化トランザクションアプリケーションから独立している可能性があるため、攻撃者は初期化トランザクションを先制的に実行し、スマートアカウントの所有権を主張できる可能性があります。 解決策: 実装をアトミックに構成し、初期化するには EOA 署名が必要です 既存の Coinbase スマート ウォレットは、UUPSUpgradeable 実装 (実際の CoinbaseSmartWallet ロジック) を使用して ERC-1967 プロキシの後にデプロイされることに注意してください。 実際のアカウント アドレスのコードは、ERC-1967 で定義された通常の格納場所を使用して実装ロジックへのポインターを格納するプロキシです。 7702 のコンテキストでの初期化の脆弱性に対する解決策には、エージェントが実際に接続を確立したときにのみ、実装ロジックがアクティブになる (したがって危険である) ことを認識することが含まれます。 したがって、原子性のデプロイと初期化を強制できない場合は、原子性の実装のセットアップと初期化を強制できます。 EIP-7702CoinbaseSmartWalletの契約構造と論理委任プロセス EIP-7702のコンテキストでは、EOA自体がアカウントに変更を加えるための最初の権限であり、新しいスマートアカウントを初期化して確立する所有者を承認するための署名を提供する必要があります。 当社のEIP7702Proxyコントラクトは、新しい論理実装をアトミックに設定し、アカウントを初期化するsetImplementation関数を実装しています。 setImplementation 関数: EOA からの署名を検証します。これには、新しい実装コントラクトのアドレス、初期化 calldata、最終的なアカウント状態のセキュリティを評価するバリデータ コントラクトのアドレス、nonce や有効期限などの基本的な署名リプレイ保護などの主要なデータが含まれます。 ERC-1967 ポインターの値を新しい実装に設定し、指定された calldata を新しい論理実装に対して実行します。 validateAccountState 関数を呼び出します。この関数は、署名に含まれる認証者によって実装される必要があります。 バリデーターは、最終的なアカウントの状態が安全であると考えるかどうかを評価するロジックを含む実装固有のコントラクトです。 たとえば、CoinbaseSmartWalletの場合、CoinbaseSmartWalletValidatorは、アカウントの所有権ステータスが空でなく、したがって任意の初期化に対して脆弱でなくなったかどうかを確認します。 課題 #2: EIP-7702 全体で委任された共有ストレージ 最も複雑な EIP-7702 の課題は、ストレージ管理に関連している可能性があります。 EOAは、いつでもそのロジックを別のコントラクトに再デリゲートしたり、デリゲートを完全に削除したりする自由があります。 すべての代表者は、次の場所でEOAアドレスを共有します...