# イーサリアムのアカウントの抽象化の進化と未来の詳細解析## はじめに本文は二つの大きな部分に分かれています:第一部は2015年の最初のアカウントの抽象化提案から始まり、システムは現在までの主要なEIP提案の内容を整理し、アカウントの抽象化の歴史的進展を振り返り、各提案の長所と短所を評価します。第二部では、EIP4337の導入後に市場の反応が冷淡である状況を重点的に対比し、次のイーサリアムのバージョンアップに組み込まれるEIP7702について深く分析しています。この提案が統合されると、チェーン上のアプリケーションの形態が根本的に変わることになります。EIP-7702は画期的な変革として、私たちはその内容を詳しく探討しましょう。## 1. アカウントの抽象化の背景### 1.1 アカウントの抽象化の定位イーサリアムの創始者Vitalikは2023年末に再びETHの発展ロードマップを更新しましたが、アカウントの抽象化の設定は変更されていません。現在の主流の発展経路はEIP-4337から次の段階の自発的EOA変換(Voluntary EOA Conversion)に入ります。### 1.2 アカウントの抽象化の市場現状一年半の発展を経て、EIP4337の主流チェーン上のアドレス総数は1200万に過ぎず、その中でイーサリアムメインネット上のアクティブアドレスは6,764個にとどまり、EOAおよびCAアドレス数とは大きな差があります。イーサリアムメインネットの独立アドレス数は2.7億に達しており、EIP4337はメインネット上でほぼ実質的な発展がないと言えるでしょう。ただし、これはAAの本質的な価値には影響しません。EIP4337の設計の目的は、メインネットの前方互換性の問題を解決することですので、さまざまなネイティブでAAをサポートするL2チェーン上で爆発的な成長を遂げました。例えば、BaseとPolygonチェーンの7月の月間アクティブユーザーはそれぞれ100万人と300万人に達し、素晴らしいパフォーマンスを示しました。したがって、EIP4337の設計は誤りではなく、多くの利点があります。現在の状況は主ネットとL2の違いによって主に引き起こされており、それぞれに適したソリューションを採用する必要があります。## 2. アカウントの抽象化とは?アカウントの抽象化は本質的に所有権の分離の問題を解決することです。イーサリアム仮想マシン(EVM)アーキテクチャには2種類のアカウントタイプがあります: 外部アカウント(EOA)と契約アカウント(Contract Account)です。外部アカウントでは、所有権と署名権は実際には同一の主体によって保持されています。秘密鍵を持つ人は、アカウントの「所有権」を持つだけでなく、「すべての資産を移転する署名権」も持っています。これはイーサリアムのアカウント取引構造によって決まります。取引構造から見ると、イーサリアムの標準取引には実際にはFromフィールドがありません。では、資金の転送はどのように支出アドレスを決定するのでしょうか？実際には、VRSパラメータ(、すなわちユーザー署名)を通じてFromアドレスを逆算します。これはECDSAなどの非対称暗号や一方向閾値関数などの概念に関係しており、ここでは詳細を述べません。要するに、このメカニズムは暗号学を通じて安全性を確保していますが、現在のEOAアドレスの所有権統合の困難さをも引き起こしています。そしてEIP4337の核心的な役割は、取引フィールドに送信者アドレスを追加することで、秘密鍵と操作対象アドレスの分離を実現することです。権利の分離がこれほど重要な理由は、外部アカウント(EOA)の設計がさらに多くの問題を引き起こすからです:1. 秘密鍵の保護が困難: ユーザーが秘密鍵(を失ったり、ハッキングされたり、暗号が解読されたり)すると、すべての資産を失うことを意味します。2. 署名アルゴリズムが単一:ネイティブプロトコルは、取引を検証する際にECDSA署名および検証アルゴリズムのみを使用できます。3. サイン権限が高すぎる: ネイティブのマルチシグ(はサポートされておらず、マルチシグはスマートコントラクトを通じてのみ実現可能)、単一のサインで任意の操作を実行できます。4. 取引手数料はETHのみで支払い可能であり、バルク取引はサポートされていません。5. 取引のプライバシー漏洩: 一対一の取引はアカウント保有者のプライバシー情報を容易に暴露します。これらの制限により、一般ユーザーがイーサリアムを使用することが難しくなっています:まず、イーサリアム上の任意のアプリケーションを使用するには、ユーザーはエーテル(を保有し、その価格変動リスク)を負わなければなりません。次に、ユーザーは複雑な手数料ロジックを処理する必要があります。Gas price、Gas limit、トランザクションのブロッキング(Nonceの順序)などの概念は、ユーザーにとって過度に複雑です。最後に、多くのブロックチェーンウォレットやアプリが製品の最適化を通じてユーザー体験を向上させようとしましたが、その効果は限られています。したがって、解決策はアカウントの抽象化を実現し、所有権(Owner)と署名権(Signer)をデカップリング(Decoupling)することにあります。これにより、上記の問題を段階的に解決します。歴史的に多くの提案がされ、最終的に二つの主要なルートにまとめられました。! [イーサリアムアカウント抽象化トラックの過去と未来の詳細な解釈](https://img-cdn.gateio.im/social/moments-cecbf67df71971d38b0a927be5e4c4d90192837465674839201## 3. AAヒストリカルプロポーザルコンテクストコーミング問題の解決策には複数のEIP提案があるように見えますが、根本的には二つの核心的な考え方しかありません。通過されなかった各EIPが考慮していた問題は、現在の提案の突破口に集約されています。) 3.1 第一のルート: EOAアドレスをCAアドレスに変換する2015年11月15日、EIP-101に関する提案の中で、ヴィタリックは契約をアカウントとして使用する新しい構造を提案しました。主な変更点は以下の通りです:- アドレスをコードとストレージスペースのみのものに変更する- 手数料サポートの変更、ERC20トークンでの支払いを許可- ネイティブトークンをERC20トークンに変換するためにプリコンパイルされたコントラクトを使用し、代金の差し引き権限などの機能を持つ- トランザクションフィールドをto、startgas、data、codeに減らしますこの提案は革命的な変革と言え、基盤設計を大幅に変更し、各アカウントアドレスが自分自身の「コード」ロジック###を持つことになります。これが現在のEIP-7702が実現しようとしている効果(です。それは他の機能を派生させることもできます、例えば:1. 取引により多くの暗号アルゴリズムを使用でき、各アドレス内部のコードによって署名検証認証方法を指定できる。2. 量子攻撃に対する耐性を備えている。なぜなら、コードをアップグレードできるからだ。3. イーサリアムのERC20契約と同じ機能特性を持たせること、核心的な効果は代わりに引き落としの承認を実現し、ネイティブコインを消費する必要がない。4. アカウントのカスタマイズスペースを拡張し、ソーシャルリカバリー、SBTサポート、キーリカバリーなどの機能に対応するこの提案が進まなかった理由は簡単です: ステップが大きすぎたのです。当時の取引ハッシュ衝突問題と安全性の懸念が考慮されず、ずっと保留されていました。しかし、その中の各利点の理念は後のEIP4337およびEIP7702のコア機能の一部となりました。その後、EIPの一連の試みがこのロジックを改善しようとしました:EIP-859:メインチェーンアカウントの抽象化)2018-01-30(Codeのデプロイメント問題を解決しようとしています。核心的な役割は、取引先のコントラクトがデプロイされていない場合、取引に付随するcodeパラメータを使用してコントラクトウォレットをデプロイすることです。また、新しいPAYGASオペコードが提案されており、ガスの支払いに加えて、取引パラメータの検証部分と実行部分の区切りとしても機能します。当時は実現できませんでしたが、これが現在のEIP7702の核心的な論理の一つとなりました。EIP7702の各取引は特殊な取引構造を組み合わせることで、特定のコードを添付でき、この取引においてEOAアドレスに契約能力を持たせることができます。EIP-7702:EOAアカウントコード)2024-05-07(これも本文の後続の議論の核心EIPであり、Vitalikによって発表されたEIP-3074の代替案です。したがって、EIP-3074は廃止され、EIP-7702が今後のETH Prague/Electra)Pectra(ハードフォークに組み込まれることが決定されており、具体的な内容は以下に展開されます。) 3.2 第二のルート: EOAアドレスがCAアドレスを駆動するEIP-3074: AUTH および AUTHCALL オペコード ###2020-10-15( を追加EVMに新しいオペコードAUTHとAUTHCALLを追加し、EOAがこれらのオペコードを介して、EOAのアイデンティティの代わりに契約に他の契約を呼び出すことを許可する。簡単に言うと、EOAは署名されたメッセージ)を自分が信頼するコントラクト(に送信することができ、そのコントラクトはInvoker)と呼ばれます。このInvokerコントラクトは、AUTHおよびAUTHCALL操作コードを利用してこのEOAの代わりに取引を送信することができます。EIP-4337:トランザクションメモリプールを使用してアカウントの抽象化(2021-09-29)この提案はMEVに触発されて設計されており、その核心的な価値は合意層プロトコルの変更を完全に回避することにあります。EIP4337は新しいトランザクションオブジェクトUserOperationを提案しました。ユーザーはこのオブジェクトをメモリプールに送信し、bundlersがマイナーの観点から一括してパッケージ化して契約実行トランザクションを提供します。実質的には、基盤となるトランザクションとアカウントの操作を契約レベルで実行することを意味します。EIP-5189:エンドースによるアカウントの抽象化操作(2022-06-29)これはEIP4337のロジックの最適化と見なすことができ、資金罰金の裏付け(endorser)メカニズムを構築することで、悪意のあるBundlerによるDoSブロッキング攻撃を防ぐことができます。( 3.3 AAをサポートするための他の提案EIP-2718:新しい取引タイプのパッケージ封筒)2020-06-13###これは最終的に確定した提案であり、将来の新しい取引タイプの封筒としての新しい取引タイプを定義しています。最終的な効果は、新しい取引タイプが導入されるときに、特定のエンコーディングを使用して異なる取引を区別し、後方互換性を持つだけで、前方互換性を必要としないことです。最も一般的な例はEIP1559で、取引の手数料を区別し、新しい取引タイプのエンコーディングを使用し、元のレガシー取引タイプには影響を与えません。EIP-3607:EOAアドレスによる契約のデプロイを禁止(2021-06-10)これはAAパス上の補足方案で、契約のデプロイ先アドレスとEOAアドレスの衝突を防ぐためのものです。これにより、契約生成方法が制御され、システムはすでにEOAアドレスであるアドレスにコードをデプロイすることを許可しません。このリスクは実際には非常に小さいです。結局のところ、イーサリアムアドレスは160ビットの長さがあり、指定された契約アドレスの秘密鍵を衝突させる方法は存在しますが、ビットコイン全ネットワークの算力を考慮すると、約1年の時間が必要です。( 3.4 アカウントの抽象化の発展の歴史をどのように理解するか?まずCAに変換された価値を理解する必要があります基本的にそれはEIP-4337の実際の効果であり、次のことを実現できます:- ソーシャルリカバリー- ガスなし取引- バッチ取引- 時間に基づくルール- マルチシグ- ルールベースの支払いしかし、EIP-4337の核心的な欠点は人間の動機原則に反していることです。それはより良く見えるが、市場の発展における死の循環に陥っている: 多くのDappがまだ互換性がなく、ユーザーはCAアドレスを使用したがらない。CAを使用すると、通常の送金シーンでは取引手数料が2倍になる)、さらにDapp自体の互換性に過度に依存している。したがって、イーサリアムのメインネットでは今のところ普及していません。コストはユーザーにとって最も重要な評価基準であり、コストを削減する必要があります。しかし、GASを本当に削減するためには、イーサリアム自体がソフトフォークアップグレードを行い、GASの計算やオペコードのGAS消費などのモジュールを変更する必要があります。ソフトフォークを行うのであれば、なぜEIP-7702を直接考慮しないのでしょうか？! [イーサリアムアカウント抽象化トラックの過去と未来の詳細な解釈]###https://img-cdn.gateio.im/social/moments-65d1ef9656425666ee30c38bbb63e769(## 4. EIP-7702 は完全に解析されます) 4.1 EIP-7702とは何ですかそれは新しい取引タイプによって区別され、EOAが単一の取引で一時的にスマートコントラクトの機能を持つことを可能にし、ビジネス上でのバッチ取引、ガスなし取引、カスタム権限管理などをサポートし、新しいEVMオペコード(を導入することなく前方互換性に影響を与えません)。それはユーザーがスマートコントラクトをデプロイすることなく、ほとんどのAAの機能を得ることができ、さらには第三者がユーザーの代わりに取引を開始する能力を提供することができ、ユーザーが秘密鍵を提供する必要はなく、署名された承認情報だけで済む。### 4.2 データ構造それは新しい取引タイプ0x04を定義しており、その取引タイプのTransactionPayloadは以下の内容のRLPエンコーディングされたシリアライズ結果です:rlp([ chain_id, // チェーンID、リプレイ攻撃を防ぐために使用されます nonce, // トランザクションカウンター、トランザクションの一意性を確保する max_priority_fee_per_gas, // 1559取引手数料 max_fee_per_gas, // 1559取引手数料 gas_limit、 目的地, // 取引先アドレス 価値 データ,access_list, // アクセスリスト、EIP-2929のガス最適化に使用されます 認証リスト,signature_y_parity, // 3つの署名パラメータ、取引署名を検証するために使用されます signature_r、 signature_s])重要なのは、新たにauthorization_listオブジェクトが追加され、署名者がそのEOAで実行したいコードを保存することです。ユーザーは取引に署名する際、実行する契約コードにも署名します。これは二次元リストとして存在し、実行可能なことを示しています。
イーサリアムアカウントの抽象化の演進：EIP-4337からEIP-7702への画期的な変革
イーサリアムのアカウントの抽象化の進化と未来の詳細解析
はじめに
本文は二つの大きな部分に分かれています:
第一部は2015年の最初のアカウントの抽象化提案から始まり、システムは現在までの主要なEIP提案の内容を整理し、アカウントの抽象化の歴史的進展を振り返り、各提案の長所と短所を評価します。
第二部では、EIP4337の導入後に市場の反応が冷淡である状況を重点的に対比し、次のイーサリアムのバージョンアップに組み込まれるEIP7702について深く分析しています。この提案が統合されると、チェーン上のアプリケーションの形態が根本的に変わることになります。
EIP-7702は画期的な変革として、私たちはその内容を詳しく探討しましょう。
1. アカウントの抽象化の背景
1.1 アカウントの抽象化の定位
イーサリアムの創始者Vitalikは2023年末に再びETHの発展ロードマップを更新しましたが、アカウントの抽象化の設定は変更されていません。現在の主流の発展経路はEIP-4337から次の段階の自発的EOA変換(Voluntary EOA Conversion)に入ります。
1.2 アカウントの抽象化の市場現状
一年半の発展を経て、EIP4337の主流チェーン上のアドレス総数は1200万に過ぎず、その中でイーサリアムメインネット上のアクティブアドレスは6,764個にとどまり、EOAおよびCAアドレス数とは大きな差があります。イーサリアムメインネットの独立アドレス数は2.7億に達しており、EIP4337はメインネット上でほぼ実質的な発展がないと言えるでしょう。
ただし、これはAAの本質的な価値には影響しません。EIP4337の設計の目的は、メインネットの前方互換性の問題を解決することですので、さまざまなネイティブでAAをサポートするL2チェーン上で爆発的な成長を遂げました。例えば、BaseとPolygonチェーンの7月の月間アクティブユーザーはそれぞれ100万人と300万人に達し、素晴らしいパフォーマンスを示しました。
したがって、EIP4337の設計は誤りではなく、多くの利点があります。現在の状況は主ネットとL2の違いによって主に引き起こされており、それぞれに適したソリューションを採用する必要があります。
2. アカウントの抽象化とは?
アカウントの抽象化は本質的に所有権の分離の問題を解決することです。
イーサリアム仮想マシン(EVM)アーキテクチャには2種類のアカウントタイプがあります: 外部アカウント(EOA)と契約アカウント(Contract Account)です。外部アカウントでは、所有権と署名権は実際には同一の主体によって保持されています。秘密鍵を持つ人は、アカウントの「所有権」を持つだけでなく、「すべての資産を移転する署名権」も持っています。
これはイーサリアムのアカウント取引構造によって決まります。取引構造から見ると、イーサリアムの標準取引には実際にはFromフィールドがありません。では、資金の転送はどのように支出アドレスを決定するのでしょうか？実際には、VRSパラメータ(、すなわちユーザー署名)を通じてFromアドレスを逆算します。
これはECDSAなどの非対称暗号や一方向閾値関数などの概念に関係しており、ここでは詳細を述べません。要するに、このメカニズムは暗号学を通じて安全性を確保していますが、現在のEOAアドレスの所有権統合の困難さをも引き起こしています。
そしてEIP4337の核心的な役割は、取引フィールドに送信者アドレスを追加することで、秘密鍵と操作対象アドレスの分離を実現することです。
権利の分離がこれほど重要な理由は、外部アカウント(EOA)の設計がさらに多くの問題を引き起こすからです:
秘密鍵の保護が困難: ユーザーが秘密鍵(を失ったり、ハッキングされたり、暗号が解読されたり)すると、すべての資産を失うことを意味します。
署名アルゴリズムが単一:ネイティブプロトコルは、取引を検証する際にECDSA署名および検証アルゴリズムのみを使用できます。
サイン権限が高すぎる: ネイティブのマルチシグ(はサポートされておらず、マルチシグはスマートコントラクトを通じてのみ実現可能)、単一のサインで任意の操作を実行できます。
取引手数料はETHのみで支払い可能であり、バルク取引はサポートされていません。
取引のプライバシー漏洩: 一対一の取引はアカウント保有者のプライバシー情報を容易に暴露します。
これらの制限により、一般ユーザーがイーサリアムを使用することが難しくなっています:
まず、イーサリアム上の任意のアプリケーションを使用するには、ユーザーはエーテル(を保有し、その価格変動リスク)を負わなければなりません。
次に、ユーザーは複雑な手数料ロジックを処理する必要があります。Gas price、Gas limit、トランザクションのブロッキング(Nonceの順序)などの概念は、ユーザーにとって過度に複雑です。
最後に、多くのブロックチェーンウォレットやアプリが製品の最適化を通じてユーザー体験を向上させようとしましたが、その効果は限られています。
したがって、解決策はアカウントの抽象化を実現し、所有権(Owner)と署名権(Signer)をデカップリング(Decoupling)することにあります。これにより、上記の問題を段階的に解決します。
歴史的に多くの提案がされ、最終的に二つの主要なルートにまとめられました。
! [イーサリアムアカウント抽象化トラックの過去と未来の詳細な解釈](https://img-cdn.gateio.im/webp-social/moments-cecbf67df71971d38b0a927be5e4c4d9.webp0192837465674839201
3. AAヒストリカルプロポーザルコンテクストコーミング
問題の解決策には複数のEIP提案があるように見えますが、根本的には二つの核心的な考え方しかありません。通過されなかった各EIPが考慮していた問題は、現在の提案の突破口に集約されています。
) 3.1 第一のルート: EOAアドレスをCAアドレスに変換する
2015年11月15日、EIP-101に関する提案の中で、ヴィタリックは契約をアカウントとして使用する新しい構造を提案しました。主な変更点は以下の通りです:
この提案は革命的な変革と言え、基盤設計を大幅に変更し、各アカウントアドレスが自分自身の「コード」ロジック###を持つことになります。これが現在のEIP-7702が実現しようとしている効果(です。
それは他の機能を派生させることもできます、例えば:
取引により多くの暗号アルゴリズムを使用でき、各アドレス内部のコードによって署名検証認証方法を指定できる。
量子攻撃に対する耐性を備えている。なぜなら、コードをアップグレードできるからだ。
イーサリアムのERC20契約と同じ機能特性を持たせること、核心的な効果は代わりに引き落としの承認を実現し、ネイティブコインを消費する必要がない。
アカウントのカスタマイズスペースを拡張し、ソーシャルリカバリー、SBTサポート、キーリカバリーなどの機能に対応する
この提案が進まなかった理由は簡単です: ステップが大きすぎたのです。当時の取引ハッシュ衝突問題と安全性の懸念が考慮されず、ずっと保留されていました。しかし、その中の各利点の理念は後のEIP4337およびEIP7702のコア機能の一部となりました。
その後、EIPの一連の試みがこのロジックを改善しようとしました:
EIP-859:メインチェーンアカウントの抽象化)2018-01-30(
Codeのデプロイメント問題を解決しようとしています。核心的な役割は、取引先のコントラクトがデプロイされていない場合、取引に付随するcodeパラメータを使用してコントラクトウォレットをデプロイすることです。また、新しいPAYGASオペコードが提案されており、ガスの支払いに加えて、取引パラメータの検証部分と実行部分の区切りとしても機能します。
当時は実現できませんでしたが、これが現在のEIP7702の核心的な論理の一つとなりました。EIP7702の各取引は特殊な取引構造を組み合わせることで、特定のコードを添付でき、この取引においてEOAアドレスに契約能力を持たせることができます。
EIP-7702:EOAアカウントコード)2024-05-07(
これも本文の後続の議論の核心EIPであり、Vitalikによって発表されたEIP-3074の代替案です。したがって、EIP-3074は廃止され、EIP-7702が今後のETH Prague/Electra)Pectra(ハードフォークに組み込まれることが決定されており、具体的な内容は以下に展開されます。
) 3.2 第二のルート: EOAアドレスがCAアドレスを駆動する
EIP-3074: AUTH および AUTHCALL オペコード ###2020-10-15( を追加
EVMに新しいオペコードAUTHとAUTHCALLを追加し、EOAがこれらのオペコードを介して、EOAのアイデンティティの代わりに契約に他の契約を呼び出すことを許可する。
簡単に言うと、EOAは署名されたメッセージ)を自分が信頼するコントラクト(に送信することができ、そのコントラクトはInvoker)と呼ばれます。このInvokerコントラクトは、AUTHおよびAUTHCALL操作コードを利用してこのEOAの代わりに取引を送信することができます。
EIP-4337:トランザクションメモリプールを使用してアカウントの抽象化(2021-09-29)
この提案はMEVに触発されて設計されており、その核心的な価値は合意層プロトコルの変更を完全に回避することにあります。
EIP4337は新しいトランザクションオブジェクトUserOperationを提案しました。ユーザーはこのオブジェクトをメモリプールに送信し、bundlersがマイナーの観点から一括してパッケージ化して契約実行トランザクションを提供します。実質的には、基盤となるトランザクションとアカウントの操作を契約レベルで実行することを意味します。
EIP-5189:エンドースによるアカウントの抽象化操作(2022-06-29)
これはEIP4337のロジックの最適化と見なすことができ、資金罰金の裏付け(endorser)メカニズムを構築することで、悪意のあるBundlerによるDoSブロッキング攻撃を防ぐことができます。
( 3.3 AAをサポートするための他の提案
EIP-2718:新しい取引タイプのパッケージ封筒)2020-06-13###
これは最終的に確定した提案であり、将来の新しい取引タイプの封筒としての新しい取引タイプを定義しています。
最終的な効果は、新しい取引タイプが導入されるときに、特定のエンコーディングを使用して異なる取引を区別し、後方互換性を持つだけで、前方互換性を必要としないことです。最も一般的な例はEIP1559で、取引の手数料を区別し、新しい取引タイプのエンコーディングを使用し、元のレガシー取引タイプには影響を与えません。
EIP-3607:EOAアドレスによる契約のデプロイを禁止(2021-06-10)
これはAAパス上の補足方案で、契約のデプロイ先アドレスとEOAアドレスの衝突を防ぐためのものです。これにより、契約生成方法が制御され、システムはすでにEOAアドレスであるアドレスにコードをデプロイすることを許可しません。このリスクは実際には非常に小さいです。結局のところ、イーサリアムアドレスは160ビットの長さがあり、指定された契約アドレスの秘密鍵を衝突させる方法は存在しますが、ビットコイン全ネットワークの算力を考慮すると、約1年の時間が必要です。
( 3.4 アカウントの抽象化の発展の歴史をどのように理解するか?
まずCAに変換された価値を理解する必要があります
基本的にそれはEIP-4337の実際の効果であり、次のことを実現できます:
しかし、EIP-4337の核心的な欠点は人間の動機原則に反していることです。
それはより良く見えるが、市場の発展における死の循環に陥っている: 多くのDappがまだ互換性がなく、ユーザーはCAアドレスを使用したがらない。CAを使用すると、通常の送金シーンでは取引手数料が2倍になる)、さらにDapp自体の互換性に過度に依存している。
したがって、イーサリアムのメインネットでは今のところ普及していません。
コストはユーザーにとって最も重要な評価基準であり、コストを削減する必要があります。
しかし、GASを本当に削減するためには、イーサリアム自体がソフトフォークアップグレードを行い、GASの計算やオペコードのGAS消費などのモジュールを変更する必要があります。ソフトフォークを行うのであれば、なぜEIP-7702を直接考慮しないのでしょうか？
! [イーサリアムアカウント抽象化トラックの過去と未来の詳細な解釈]###https://img-cdn.gateio.im/webp-social/moments-65d1ef9656425666ee30c38bbb63e769.webp(
4. EIP-7702 は完全に解析されます
) 4.1 EIP-7702とは何ですか
それは新しい取引タイプによって区別され、EOAが単一の取引で一時的にスマートコントラクトの機能を持つことを可能にし、ビジネス上でのバッチ取引、ガスなし取引、カスタム権限管理などをサポートし、新しいEVMオペコード(を導入することなく前方互換性に影響を与えません)。
それはユーザーがスマートコントラクトをデプロイすることなく、ほとんどのAAの機能を得ることができ、さらには第三者がユーザーの代わりに取引を開始する能力を提供することができ、ユーザーが秘密鍵を提供する必要はなく、署名された承認情報だけで済む。
4.2 データ構造
それは新しい取引タイプ0x04を定義しており、その取引タイプのTransactionPayloadは以下の内容のRLPエンコーディングされたシリアライズ結果です:
rlp([ chain_id, // チェーンID、リプレイ攻撃を防ぐために使用されます nonce, // トランザクションカウンター、トランザクションの一意性を確保する max_priority_fee_per_gas, // 1559取引手数料 max_fee_per_gas, // 1559取引手数料 gas_limit、 目的地, // 取引先アドレス 価値 データ, access_list, // アクセスリスト、EIP-2929のガス最適化に使用されます 認証リスト, signature_y_parity, // 3つの署名パラメータ、取引署名を検証するために使用されます signature_r、 signature_s ])
重要なのは、新たにauthorization_listオブジェクトが追加され、署名者がそのEOAで実行したいコードを保存することです。ユーザーは取引に署名する際、実行する契約コードにも署名します。これは二次元リストとして存在し、実行可能なことを示しています。