# EIP-7702:イーサリアム外部アカウントの重大変革イーサリアムはPectraアップグレードを迎えようとしており、その中でEIP-7702はイーサリアム外部アカウント(EOA)に対して画期的な改造を行いました。この提案はEOAと契約アカウントCAの境界を曖昧にし、ネイティブアカウント抽象化に向けた重要な一歩となり、イーサリアムエコシステムに新しいインタラクションモデルをもたらしました。Pectraはテストネットでの展開を完了し、近日中にメインネットに登場する予定です。本稿ではEIP-7702の実装メカニズムを詳しく分析し、そのもたらす可能性のある機会と課題について探討し、さまざまな参加者に実用的なガイドを提供します。## プロトコル分析###概要EIP-7702は新しい取引タイプを導入し、EOAがスマートコントラクトアドレスを指定し、そのコードを設定できるようにします。これにより、EOAはスマートコントラクトのようにコードを実行できる一方で、取引を開始する能力を保持します。この機能はEOAにプログラマビリティとコンポーザビリティを与え、ユーザーはEOA内でソーシャルリカバリー、権限管理、マルチシグ管理、zk検証、サブスクリプション型支払い、取引スポンサーシップ、取引バッチ処理などの機能を実現できます。EIP-7702はEIP-4337によって実現されたスマートコントラクトウォレットと完全に互換性があり、新機能の開発と適用を簡素化します。EIP-7702は、SET_CODE_TX_TYPE (0x04)の取引タイプを導入しました。そのデータ構造にはauthorization_listフィールドが含まれており、複数の承認エントリを含むことができます。各承認エントリにはchain_id、address、nonce、および署名データが含まれています。###実装権限者が権限データに署名する際には、chain_id、address、nonceをRLPエンコードし、MAGIC数とともにkeccak256ハッシュ計算を行い、その後に秘密鍵で署名する必要があります。MAGIC (0x05)は域の区切り文字として使用され、異なる種類の署名結果が衝突しないことを保証します。chain_idが0の場合、すべてのEIP-7702をサポートするEVM互換チェーンでのリプレイが許可されていることを示します。取引実行前に、Proposerは事前チェックを行い、取引が契約作成取引でないことを確認します。取引のauthorization_listフィールドには、少なくとも1項目の承認エントリが含まれている必要があります。ノードがトランザクションを実行する際、まず発信者のnonceを増加させ、その後各承認項目に対してapplyAuthorization操作を行います。エラーが発生した場合、その承認項目はスキップされ、他の項目は引き続き適用されます。承認が完了した後、承認者のアドレスのcodeフィールドは0xef0100||addressに設定されます。承認者は委託対象アドレスを0アドレスに設定することで承認を解除できます。## ベストプラクティスEIP-7702がイーサリアムエコシステムに新たな活力を注入したにもかかわらず、新しいリスクも伴っています。以下は、エコシステムの参加者が注意すべき点です:### 秘密鍵の保管EOAを委託した後でも、ソーシャルリカバリーなどの方法で資金損失の問題を解決することができますが、秘密鍵の漏洩リスクを回避することはできません。ユーザーは秘密鍵の保護を最優先にすべきです。### マルチチェーンリプレイユーザーはchainIdを0に設定して委託を選択することで、マルチチェーン上で有効にすることができます。ただし、異なるチェーン上の同じコントラクトアドレスは異なる実装を持つ可能性があります。ウォレットサービスプロバイダーは、委託が有効なチェーンと現在のネットワークが一致しているかどうかを確認し、ユーザーに関連するリスクを通知する必要があります。### 初期化できませんEIP-7702はERC-1967のプロキシコントラクトのようにデプロイ時に初期化関数を呼び出すことができません。開発者はウォレットの初期化操作で権限チェックを行い、先行リスクを回避する必要があります。### ストレージ管理異なるコントラクトアドレスへの再委託は、ストレージ構造の違いを引き起こし、アカウントのロックや資金の損失を引き起こす可能性があります。開発者はERC-7201ネームスペースフォーミュラに従い、変数を独立したストレージ位置に割り当てるべきです。### 偽チャージ中央集権型取引所はスマートコントラクトによる入金の普及に直面する可能性があるため、traceを通じて入金取引の状態を確認し、偽の入金リスクを防ぐ必要があります。### アカウント変換アカウントはEOAとSCの間で自由に変換でき、EOAのみがプロジェクトに参加するという安全な仮定を打破します。開発者は、将来の参加者がすべてスマートコントラクトである可能性があると仮定すべきです。### コントラクトの互換性開発者は、ユーザーが委託した対象コントラクトが対応するコールバック関数を実装し、主流のトークンと互換性があることを確認するべきです。### フィッシングチェックウォレットサービスプロバイダーは、ユーザーが署名を委託する際にターゲットコントラクトを目立たせ、深い自動分析を行うことで、フィッシング攻撃のリスクを軽減するために、できるだけ早くEIP-7702取引タイプをサポートする必要があります。## まとめEIP-7702は新しい取引タイプを通じて、EOAにプログラム可能性とコンポーザビリティを持たせ、EOAと契約アカウントの境界を曖昧にしました。異なるエコシステムの参加者は多くの課題と機会に直面しており、この記事で提供されるベストプラクティスは実際の操作で参考にする価値があります。
EIP-7702: イーサリアム外部アカウント重大変革 でエコシステムに新たな機会と挑戦をもたらす
EIP-7702:イーサリアム外部アカウントの重大変革
イーサリアムはPectraアップグレードを迎えようとしており、その中でEIP-7702はイーサリアム外部アカウント(EOA)に対して画期的な改造を行いました。この提案はEOAと契約アカウントCAの境界を曖昧にし、ネイティブアカウント抽象化に向けた重要な一歩となり、イーサリアムエコシステムに新しいインタラクションモデルをもたらしました。
Pectraはテストネットでの展開を完了し、近日中にメインネットに登場する予定です。本稿ではEIP-7702の実装メカニズムを詳しく分析し、そのもたらす可能性のある機会と課題について探討し、さまざまな参加者に実用的なガイドを提供します。
プロトコル分析
###概要
EIP-7702は新しい取引タイプを導入し、EOAがスマートコントラクトアドレスを指定し、そのコードを設定できるようにします。これにより、EOAはスマートコントラクトのようにコードを実行できる一方で、取引を開始する能力を保持します。この機能はEOAにプログラマビリティとコンポーザビリティを与え、ユーザーはEOA内でソーシャルリカバリー、権限管理、マルチシグ管理、zk検証、サブスクリプション型支払い、取引スポンサーシップ、取引バッチ処理などの機能を実現できます。EIP-7702はEIP-4337によって実現されたスマートコントラクトウォレットと完全に互換性があり、新機能の開発と適用を簡素化します。
EIP-7702は、SET_CODE_TX_TYPE (0x04)の取引タイプを導入しました。そのデータ構造にはauthorization_listフィールドが含まれており、複数の承認エントリを含むことができます。各承認エントリにはchain_id、address、nonce、および署名データが含まれています。
###実装
権限者が権限データに署名する際には、chain_id、address、nonceをRLPエンコードし、MAGIC数とともにkeccak256ハッシュ計算を行い、その後に秘密鍵で署名する必要があります。MAGIC (0x05)は域の区切り文字として使用され、異なる種類の署名結果が衝突しないことを保証します。
chain_idが0の場合、すべてのEIP-7702をサポートするEVM互換チェーンでのリプレイが許可されていることを示します。取引実行前に、Proposerは事前チェックを行い、取引が契約作成取引でないことを確認します。取引のauthorization_listフィールドには、少なくとも1項目の承認エントリが含まれている必要があります。
ノードがトランザクションを実行する際、まず発信者のnonceを増加させ、その後各承認項目に対してapplyAuthorization操作を行います。エラーが発生した場合、その承認項目はスキップされ、他の項目は引き続き適用されます。承認が完了した後、承認者のアドレスのcodeフィールドは0xef0100||addressに設定されます。承認者は委託対象アドレスを0アドレスに設定することで承認を解除できます。
ベストプラクティス
EIP-7702がイーサリアムエコシステムに新たな活力を注入したにもかかわらず、新しいリスクも伴っています。以下は、エコシステムの参加者が注意すべき点です:
秘密鍵の保管
EOAを委託した後でも、ソーシャルリカバリーなどの方法で資金損失の問題を解決することができますが、秘密鍵の漏洩リスクを回避することはできません。ユーザーは秘密鍵の保護を最優先にすべきです。
マルチチェーンリプレイ
ユーザーはchainIdを0に設定して委託を選択することで、マルチチェーン上で有効にすることができます。ただし、異なるチェーン上の同じコントラクトアドレスは異なる実装を持つ可能性があります。ウォレットサービスプロバイダーは、委託が有効なチェーンと現在のネットワークが一致しているかどうかを確認し、ユーザーに関連するリスクを通知する必要があります。
初期化できません
EIP-7702はERC-1967のプロキシコントラクトのようにデプロイ時に初期化関数を呼び出すことができません。開発者はウォレットの初期化操作で権限チェックを行い、先行リスクを回避する必要があります。
ストレージ管理
異なるコントラクトアドレスへの再委託は、ストレージ構造の違いを引き起こし、アカウントのロックや資金の損失を引き起こす可能性があります。開発者はERC-7201ネームスペースフォーミュラに従い、変数を独立したストレージ位置に割り当てるべきです。
偽チャージ
中央集権型取引所はスマートコントラクトによる入金の普及に直面する可能性があるため、traceを通じて入金取引の状態を確認し、偽の入金リスクを防ぐ必要があります。
アカウント変換
アカウントはEOAとSCの間で自由に変換でき、EOAのみがプロジェクトに参加するという安全な仮定を打破します。開発者は、将来の参加者がすべてスマートコントラクトである可能性があると仮定すべきです。
コントラクトの互換性
開発者は、ユーザーが委託した対象コントラクトが対応するコールバック関数を実装し、主流のトークンと互換性があることを確認するべきです。
フィッシングチェック
ウォレットサービスプロバイダーは、ユーザーが署名を委託する際にターゲットコントラクトを目立たせ、深い自動分析を行うことで、フィッシング攻撃のリスクを軽減するために、できるだけ早くEIP-7702取引タイプをサポートする必要があります。
まとめ
EIP-7702は新しい取引タイプを通じて、EOAにプログラム可能性とコンポーザビリティを持たせ、EOAと契約アカウントの境界を曖昧にしました。異なるエコシステムの参加者は多くの課題と機会に直面しており、この記事で提供されるベストプラクティスは実際の操作で参考にする価値があります。
中国語でコメントを生成してください:
儲けるチャンスが来るぞ