イントロダクション

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

EOAは「委任指定」を設定することでアップグレードされ、これはEOAを管理するデレゲートスマートコントラクトへのポインタです。アップグレードされたEOAは、したがって、関数を持ち、ストレージを設定し、イベントを発行し、スマートコントラクトができるすべてのことを行うことができます。EOAはいつでも新しい署名されたEIP-7702認証を使用してこの委任を変更または削除できます。この機能は多くの新しい可能性を開放しますが、この強力な機能は、慎重な考慮と革新的な解決策を必要とする新たなセキュリティの課題ももたらします。

EOAがスマートコントラクトウォレットとして機能できるように、私たちは軽量なEIP7702Proxyを開発しました。ERC-1967 プロキシ EOAのためのEIP-7702デレゲートとして機能するように設計されたコントラクト。プロキシによって行われる基本的な論理転送に加えて、EIP7702ProxyはEIP-7702デレゲートアカウント特有のいくつかの課題を解決する追加機能と設計選択を含んでいます。EIP7702Proxyを設計する際の目標は、「標準デプロイ」CoinbaseスマートウォレットとEIP-7702デレゲートCoinbaseスマートウォレットとの間で可能な限りの均一性を実現することでした。これには、EIP-7702のメカニクスによって要求される追加の複雑さを専用プロキシに抽象化し、Coinbaseスマートウォレットの元の実装に依存し続けることが含まれます。この課題の解決策は、Coinbaseスマートウォレットの実装に限らず、あらゆる実装ロジックに有用に適用でき、EOAが7702対応の環境で安全を保つのに役立ちます。

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

課題 #1: セキュアな初期化の強制

EIP-7702の実装における最初の大きな障害は、その初期化制約に起因します。CoinbaseSmartWalletを含む従来のスマートコントラクトウォレットは、通常、別のファクトリーコントラクトを介してデプロイメント中にアカウントの所有権を確立する安全な初期化を原子的に処理します。この原子性により、そのような実装の多くには、正確に1回だけ呼び出すことができる保護されていない初期化子関数があります。しかし、EIP-7702の設計では、コードデリゲーションプロセス中に初期化コールデータの実行を許可しておらず（「デプロイメント」に相当するステップ）、したがってこれは原子的に行うことができません。

このステップの分離は、重要な脆弱性ウィンドウを生み出します。実装契約がEIP-7702を介してEOAに「デプロイ」されるとき、この7702アップグレードとウォレットを初期化する標準EVMトランザクションが原子的に実行される保証はありません。権限設定コードは、初期化トランザクションとは独立して適用される可能性があり、たとえ同時に提出されても、攻撃者が自分のペイロードで初期化トランザクションを先行させ、スマートアカウントの所有権を主張することができるかもしれません。

解決策：EOA署名を必要とし、実装を原子的に設定し、初期化する

既存のCoinbaseスマートウォレットが、の背後に展開されていることに注意してください。ERC-1967プロキシ with a UUPSアップグレード可能実装（実際のCoinbaseSmartWalletロジック）。実際のアカウントアドレスにあるコードはプロキシであり、プロキシはERC-1967によって定義された従来のストレージ位置を使用して、その実装ロジックへのポインタを保持します。7702コンテキストにおける初期化脆弱性に対する私たちの解決策は、実装ロジックが実際にアクティブ（したがって危険）になるのは、プロキシが実際にそれとの接続を確立したときだけであることを認識することを含みます。したがって、初期化とともに原子的なデプロイメントを強制できない場合、代わりに初期化とともに原子的な実装設定を強制することができます。

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

EIP-7702の文脈において、EOA自体がそのアカウントへの変更に関する初期の権限を持ち、新しいスマートアカウントの所有者を設定するために初期化を承認する署名を提供する必要があります。私たちのEIP7702Proxyコントラクトは、new logical implementationを原子的に設定しアカウントを初期化するsetImplementation関数を実装しています。setImplementation関数は次の通りです:

1. EOAからの署名を検証し、新しい実装コントラクトのアドレス、初期化コールデータ、結果として得られるアカウント状態の安全性を評価するバリデーターコントラクトのアドレス、ノンスや有効期限などの基本的な署名リプレイ保護などの重要なデータを含みます。
2. ERC-1967ポインタの値を新しい実装に設定し、新しい論理実装に対して提供されたコールデータを実行します。
3. 署名に含まれるバリデーターが実装しなければならないvalidateAccountState関数を呼び出します。

バリデーターは、結果のアカウント状態が安全であると見なすかどうかを評価するロジックを含む、実装特有のコントラクトです。たとえば、CoinbaseSmartWalletの場合、CoinbaseSmartWalletValidatorはアカウントの所有権状態が空でないかどうかを確認し、そのため恣意的な初期化に対してもはや脆弱ではないことを確認します。

チャレンジ #2: EIP-7702 デレゲート間の共有ストレージ

EIP-7702の最も複雑な課題の1つは、ストレージ管理に関係しています。EOAは、ロジックを異なるコントラクトに自由に再委任したり、いつでも委任を完全に解除したりできます。すべてのデリゲートはEOAアドレスで同じストレージスペースを共有します。複数のコントラクトが時間をかけて同じストレージにアクセスを共有することは、「ストレージ衝突」問題につながる可能性があります。ストレージ衝突は、2つのコントラクトが同じストレージ位置に対して異なる変更を加えたり、仮定を行ったりする場合に発生し、予測不可能なバグを引き起こす可能性があります。

ストレージ衝突の管理は、共有ストレージを統治するために可変実装ロジックが使用されるプロキシ設計空間ではすでに馴染みのある問題です。アップグレード可能なプロキシは実装を変更できますが、プロキシコード自体（非7702アドレスの場合）は変更できません。これにより、アップグレードプロセスに対する確実性と保証がもたらされます。7702再委任は、この共有ストレージを統治する可能性のあるロジックに対して完全な可変性の別の層を導入します。これは、任意のdeleGateがストレージに与える影響に関する保証を本質的に取り除きます。例えば、EOAがdeleGate AからBに委任し、再びAに戻る場合、戻ってきたdeleGateはそのストレージの状態について仮定を立てることができません。なぜなら、ストレージがdeleGate Bによって消去されたり操作されたりして、deleGate Aのロジックのみでは達成不可能な状態になっている可能性があるからです。これは、委任パターンにかかわらず、あらゆる7702のdeleGateに当てはまります。なぜなら、前のdeleGateが任意のストレージ位置に何かを保存したり削除したりしている可能性があるからです。

DeleGate Aによって引き起こされた無効な状態の例 A → B → Aの委任パターン

解決策：セキュリティクリティカルなストレージ値の外部化

EOAの委任は、アカウントの状態に任意に影響を与えることができます。もしEOAが悪意のあるまたは破壊的なコントラクトに委任した場合、現行の委任者はこれに対して保護することはできません。ドレイン取引に署名するように、悪意のある7702委任者を承認することは破滅的な結果をもたらす可能性があり、これらの結果に対する保護は私たちの設計範囲を超えています。

EIP7702Proxyは、意図は良いが潜在的に混沌としたアクターのマルチウォレット、7702対応エコシステムにおける予見可能な問題に対して自己防衛できるように設計されました。真に悪意のあるまたはバグのあるdelegaを承認するEOAを保護することはできません。

予見可能な問題の一つは、setImplementation呼び出しに対する署名と、可変アカウント状態によって引き起こされるリスクに関するものです。EIP7702Proxyは、EOA署名に依存して実装ロジックを設定し、安全な状態に初期化します。これらの署名は、再利用可能な場合、負担となる可能性があります。例えば、署名が初期オーナーを承認し、その後オーナーが侵害されて削除された場合、再利用可能な署名が侵害されたオーナーを再確立したり、実装を強制的にダウングレードしたりすることができます。

署名のリプレイに対する一般的な保護は、署名されたメッセージに含まれるノンスを使用し、検証時に使用済みとしてマークされます。7702アカウントのリスク: 他のデレゲートがこのノンス追跡ストレージを侵害する可能性があります。ストレージがノンスの使用状況を追跡する情報が消去されると、EOAのsetImplementation署名（メモプール内で公開されている）をEIP7702Proxyに戻す際に再適用できる可能性があります。

署名の再利用を防ぐために、アカウントのストレージの外にある不変の契約場所でノンスの状態を維持する別のNonceTrackerシングルトンを実装しました。EOAのみが自分のノンスに影響を与えることができ（増分のみ）、他のデレゲートがこれらのセキュリティに重要な値を操作することを防ぎます。NonceTrackerは、アカウントのストレージの変更に関係なく、各setImplementation署名が一度だけ機能することを保証します。

チャレンジ #3: 共有された従来のストレージ場所のリスクが高まる

標準化されたストレージスロットは、次のように定義されます。ERC-1967は、複数のデリゲート実装によって使用される可能性のある従来の場所であるため、潜在的なストレージ衝突に特に脆弱です。 ERC-1967実装スロットはEIP7702Proxyで使用される唯一の標準ストレージ場所であり、プロキシによって指示される論理実装のアドレスを保持します。私たちの設計は、このストレージ場所の値（アカウントで利用可能なロジックの多くを決定する）に関係なく、EIP7702Proxyが常にEOAによって望まれる契約に実装ロジックを正常に設定できることを保証します。

問題をより明確に示すために、アカウントが異なるデリゲート間で遷移する際（A→B→A）、両方のデリゲートがERC-1967プロキシパターンを実装していることに注意してください。デリゲートBは、自然にデリゲートAが実装アドレスを保存するために使用していた同じストレージスロットを使用します。デリゲートBの任期中、このスロットを意図的にまたは自らのプロキシ操作の一環として変更または上書きする可能性があります。UUPSアップグレード可能プロキシパターンでは、実装をアップグレードするためのロジックは、実装契約自体に定義されています。デリゲートBによってこのポインタ位置に設定された実装に、実装で期待されるupgradeToAndCallインターフェースが含まれていない場合、デリゲートAに戻る際に、その実装を変更するためのメカニズムが現在の利用可能なロジックに存在しない可能性があります。

新しいデリゲートによる共有従来ストレージ位置の上書きの例

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

私たちのEIP7702Proxyは、setImplementation関数を通じてこれに対処します。この関数は、プロキシ自体に直接実装に依存しないアップグレードメカニズムを提供します。これにより、間に介入するデリゲートがERC-1967実装を無効な実装にポイントした場合（または完全に削除した場合）でも、元のEOAはEIP7702Proxyに戻すことで、プロキシのERC-1967ポインタを選択した論理実装に再構成する能力を維持します。

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

EIP7702Proxyの設計目標の一つは、新しいスマートコントラクト機能に加えて、アカウントのEOA機能との後方互換性を維持することでした。アドレスにコードが存在するかどうかは、そのアドレスと相互作用するプロトコルの実行フローに影響を与える可能性があります。プロトコルはこの特性に基づいてEOAとスマートコントラクトを区別します。これには、2つの主要な動作、すなわち署名検証とトークン受信動作を考慮する必要がありました。

署名検証

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

EOAの署名が7702アップグレード後も引き続きEOAで尊重されることを保証するために、EIP7702Proxyは、まず署名検証を論理的実装で定義されるべきisValidSignature関数に委任するisValidSignatureのバージョンを実装しますが、失敗した検証の後に最終的なecrecoverチェックが行われます。これが通過すると、署名は有効と見なされます。このようにして、EIP7702Proxyを使用するEOAは、スマートコントラクトウォレットのisValidSignature実装に関係なく、シンプルなEOA署名が常に自分のアドレスで尊重されることを保証できます。

トークン受取

いくつかのトークン標準（具体的にはERC-1155とERC-721) スマートコントラクト内でトークンがスタックするのを防ぐ試みです。これらのトークンは、トークン送信時にトークンコントラクトによって呼び出される標準トークン受信者インターフェースを実装して、この機能を宣言する必要があります。アップグレードされたEOAのロジックには、ネイティブトークンを受け取るための標準受信関数または支払い可能なフォールバックが含まれていることが不可欠です。アカウントは、ETHや他のトークンを受け取れない状態になってはいけません、たとえそれが一時的であっても。

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

結論

EIP7702Proxyの設計により、標準的に展開されたCoinbaseSmartWalletsと密接な均衡を保ち、EIP-7702の文脈で生じる独自のセキュリティ課題を解決しながら、既存のCoinbaseSmartWalletの実装を引き続き使用することが可能になります。初期化セキュリティ、ストレージの不変性と干渉の影響、途切れのないトークン処理の必要性、標準的なEOA署名検証との後方互換性を慎重に考慮することで、EIP-7702スマートコントラクトウォレットの安全な委任と管理のためのプロキシを作成しました。EIP7702ProxyはCoinbaseSmartWallet V1実装を念頭に置いて設計されましたが、このプロキシは最終的には実装に依存しません。開発者には、他のスマートコントラクトウォレット実装の7702対応のためにこのソリューションを評価することをお勧めします。

免責事項:

1. この記事は[から転載されています。ベースエンジニアリングブログ]. すべての著作権は原著作者に帰属します [アミー・コルソ].この再版に異議がある場合は、ゲートラーニングチームが迅速に対応します。
2. 免責事項：この記事に示される見解や意見は著者のものであり、投資アドバイスを構成するものではありません。
3. この記事の他の言語への翻訳は、Gate Learnチームによって行われています。特に記載がない限り、翻訳された記事のコピー、配布、または盗用は禁止されています。