# イーサリアムアカウントの抽象化トラックの過去と未来を深く解読する## イントロダクション本文は二つの大きな部分に分かれています:第1部では、2015年の第1回AA提案から始まり、これまでの主なEIP提案を体系的に整理し、過去のAA提案の策定プロセスを議論し、各提案を総合的に評価します。第二部では、EIP4337の導入後に直面した市場の反応を重点的に比較し、次のイーサリアムのバージョンアップグレードに組み込まれるEIP7702を深く分析します。この提案が統合されると、オンチェーンアプリケーションの形態が根本的に変わるでしょう。EIP-7702は画期的な意義を持ちます。それについて深く理解していきましょう。! [イーサリアムアカウント抽象化トラックの過去と未来の詳細な解釈](https://img-cdn.gateio.im/social/moments-cecbf67df71971d38b0a927be5e4c4d90192837465674839201## 1. アカウントの抽象化の背景) 1.1 アカウントの抽象化の意義定位イーサリアム創設者Vitalikは2023年末に再度ETHの発展ロードマップを更新しましたが、アカウントの抽象化の位置付けは変わっていません。現在の主流モデルはEIP-4337から次の段階の"自発的にEOAアカウントに変換する"へと移行しています。### 1.2 アカウントの抽象化の市場現状1年半の開発を経て、EIP4337のメインストリームチェーン上の総アドレス数は1200万に過ぎず、その中でイーサリアムメインネット上のアクティブアドレスはわずか6,764個で、EOAとCAアドレス数との差は大きい。イーサリアムメインネットの独立アドレス数は2.7億に達しており、EIP4337はメインネット上での発展が遅いと言える。しかし、これはAAの本質的な価値には影響しません。EIP4337の設計は、メインネット上での良好な後方互換性を難しくしています。さまざまなL2チェーンが原生AAを一般的に組み込むにつれて、EIP4337のアドレス数はL2上で爆発的に増加し、BaseとPolygonチェーンの7月の月間アクティブユーザーはそれぞれ100万と300万に達し、好成績を示しています。したがって、EIP4337の設計は誤りではなく、多くの利点があります。現在の状況は、メインネットとL2の間の違いに起因しており、それぞれに適したソリューションが必要です。! [イーサリアムアカウント抽象化トラックの過去と未来の詳細な解釈]###https://img-cdn.gateio.im/social/moments-65d1ef9656425666ee30c38bbb63e769(## 2. アカウントの抽象化とは?アカウントの抽象化は本質的に所有権の分離の問題を解決するものです。EVMアーキテクチャには2種類のアカウントタイプがあります: 外部アカウント)EOA(と契約アカウント)CA(。外部アカウントでは、所有権と署名権は同一のエンティティによって保持されます。秘密鍵を持つ者は、アカウントの"所有権"を持つだけでなく、"すべての資産を転送する署名権"も持っています。これはイーサリアムアカウントの取引構造によって決まっています。取引構造から見ると、標準取引には実際にはFromフィールドがありません。資金の移動時、具体的な消費アドレスはVRSパラメータ)、すなわちユーザーの署名(を通じて逆解析されて得られます。そしてEIP4337の核心的な効果は、取引フィールドにSender Addressを追加することで、秘密鍵と操作対象のアドレスを分離することです。所有権の分離がこれほど重要な理由は、外部アカウント)EOA(の設計が多くの問題を引き起こすからです:1. 秘密鍵の保護が難しい: 秘密鍵を失うことは、すべての資産を失うことを意味します。2. サインアルゴリズムが単一: ネイティブプロトコルの取引検証はECDSAアルゴリズムのみを使用できます。3. サイン権限が高すぎる:ネイティブのマルチシグ機能がなく、シングルサインで任意の操作が実行できる。4. 取引手数料はETHでのみ支払うことができ、バッチ取引はサポートされていません。5. 取引のプライバシーが漏れる容易さ: 一対一の取引はアカウント保有者の情報を分析しやすい。これらの制限は、普通のユーザーがイーサリアムを使用するのを難しくしています:まず、ユーザーはエーテルを保有し、価格変動リスクを負わなければなりません。次に、ユーザーはGas price、Gas limit、取引のブロッキングなどの概念といった複雑な手数料ロジックを処理する必要があります。最後に、ブロックチェーンウォレットやアプリが製品の最適化を通じてユーザー体験を向上させようとしていますが、その効果は限られています。したがって、解決策はアカウントの抽象化を実現し、所有権)Owner(と署名権)Signer(をデカップリングすることにあり、これによって上記の問題を段階的に解決していきます。歴史的にさまざまな方案があり、最終的には二つのルートに集約される。! [イーサリアムアカウント抽象化トラックの過去と未来の詳細な解釈])https://img-cdn.gateio.im/social/moments-3503a168bb61430839419efb40e130de(## 3. AAヒストリカルプロポーザルコンテクストコーミング問題の解決策は多くのEIP提案があるようですが、結局のところ2つの核心的な考え方に集約されます。通過していない各EIPが考慮した問題は、既存の解決策の突破口に集約されています。) 3.1 第一のルート: EOAアドレスをCAアドレスに変換する2015年11月、Vitalikは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に2つの新しいOpCode: AUTHとAUTHCALLを追加し、EOAがこれらのopcodeを通じて契約に対してEOAの身分を代わりに使って他の契約を呼び出すことを可能にします。概括すると、EOAは署名されたメッセージ)トランザクション(を自分が信頼するコントラクト)に送信することができ、これをInvoker(と呼びます。このInvokerコントラクトはAUTHおよびAUTHCALLオペコードを利用してEOAの代わりにトランザクションを発行できます。EIP-4337:トランザクションメモリプールを使用してアカウントの抽象化)2021-09-29(MEVからインスパイアされた設計で、コアバリューはコンセンサスレイヤープロトコルの変更を完全に回避することです。EIP4337は新しいトランザクションオブジェクトUserOperationを提案し、ユーザーはこのオブジェクトをメモリプールに送信します。bundlersはマイナーの観点から一括してパッケージ化し、契約の実行トランザクションを配信します。本質的には、基盤となるトランザクションとアカウントの操作を契約レベルで実行することを意味します。EIP-5189:背書人によるアカウントの抽象化)2022-06-29(これはEIP4337のロジックの最適化であり、資金罰金の裏付けエンドーサーメカニズムを構築することによって悪意のあるBundlerのDoSブロッキング攻撃を防ぐことを目的としています。) 3.3 他のAAをサポートする提案EIP-2718:新しいトランザクションタイプのラッピングエンベロープ###2020-06-13(これはすでにFinalな提案で、将来の新しい取引タイプの封筒として新しい取引タイプを定義しています。最終的な効果は、新しい取引タイプを導入する際に、特定のエンコーディングで取引タイプを区別し、後方互換性のみを確保し、前方互換性は必要ないということです。最も一般的な例はEIP1559で、これは取引手数料を区別し、新しい取引タイプのエンコーディングを使用し、元のレガシー取引タイプには影響を与えません。EIP-3607:EOAアドレスにコントラクトをデプロイできない)2021-06-10(これはAAパス上の補完策で、契約デプロイメントアドレスとEOAアドレスの衝突を防ぐために使用されます。これは契約生成方法を制御し、コードがすでにEOAアドレスであるアドレスにデプロイされることを許可しません。このリスクは実際には非常に小さく、イーサリアムアドレスは160ビットの長さを持っています。指定された契約アドレスの秘密鍵を衝突させる方法は存在しますが、ビットコインの全算力を投入しても推定で1年の時間が必要です。) 3.4 アカウントの抽象化の発展の歴史をどのように理解するか?まず、CAへの変換後の価値を理解する必要があります。基本的にはEIP-4337の実際の効果です:1. バッチ取引をサポート2. ソーシャルリカバリーをサポート3. カスタム署名検証をサポート4. ネイティブトークンで手数料を支払う必要はありません5. より細かい粒度の権限管理6. スケーラビリティしかし、EIP-4337の核心的な欠点は、人間の動機原則に反していることです。見た目は良さそうだが、市場の発展のデッドロックに陥っている: 多くのDappはまだ互換性がなく、ユーザーはCAアドレスを使用したがらず、CAを使用すると逆に取引コストが高くなる###通常の送金シーンでは、取引手数料が倍増(、Dapp自体の互換性に過度に依存している。したがって、イーサリアムのメインネットでは、今日まで普及していません。コストはユーザーにとって最も重要な指標であり、コストを削減する必要があります。しかし、GASを本当に削減するには、イーサリアム自体がソフトフォークアップグレードを行い、GAS計算やオペコードのGAS消費などのモジュールを修正する必要があります。ソフトフォークを行うのであれば、EIP-7702を直接考慮した方が良いでしょう。! [イーサリアムアカウント抽象化トラックの過去と未来の詳細な解釈])https://img-cdn.gateio.im/social/moments-9d6eae95e3a0983a7b379ce2cfd7945f(## 4. EIP-7702 は完全に解析されます) 4.1 EIP-7702は何ですかそれは新しい取引タイプを通じて、EOAが単一の取引で一時的にスマートコントラクト機能を持つことを許可し、バッチ取引、ガスなし取引、カスタム権限管理などをサポートし、さらに新しいEVM opCode###を導入することなく前方互換性(に影響を与えます。ユーザーはスマートコントラクトをデプロイすることなく、ほとんどのAA機能を取得でき、さらには第三者がユーザーの代わりに取引を開始する機能を提供することも可能で、ユーザーが秘密鍵を提供する必要はなく、署名承認情報のみが必要です。) 4.2 データ構造新しい取引タイプ0x04を定義します。TransactionPayloadは以下の内容のRLPエンコードされたシリアライズ結果です:rlp###[chain_id、nonce、max_priority_fee_per_gas、max_fee_per_gas、gas_limit、目的地、値、データ、access_list、authorization_list、signature_y_parity、 signature_r、signature_s](重要なのは、署名者がそのEOAで実行したいコードを保存するauthorization_listオブジェクトが新たに追加されたことです。ユーザーは取引に署名する際に、実行する契約コードにも署名します。これは二次元リストとして存在し、複数の操作情報を一括で保存し、一括操作を実行できます。authorization_list = [[chain_id, 住所, nonce, y_parity, r, s], ...]) 4.3 取引ライフサイクル#### 4.3.1 検証フェーズ取引実行の開始時に、[chain_id, address, nonce, y_parity, r, s] タプルの各authorization_listについて、次のようになります。1. 署名のrおよびsから、ecrecoverを使用して署名者のアドレスを復元します。2. チェーンID###のフォーク防止チェーンリプレイ(を検証します。3. authorityの署名者のコードが空であるか、または委任されているかを確認します。4. 機関署名者が反機関署名リプレイ) nonce(を確認します。5. 権限署名者のコードを 0xef0100 || address)バイパスEIP3607衝突回避戦略(。6. 認証局nonce)署名者向けのアンチローカル署名リプレイ(を追加します。7. authority署名者アカウントをアクセスしたアドレスリスト)の転送アドレスに追加し、ストレージのガス代を(削減します。)# 4.3.2 実行フェーズ"新"バージョンはコードのデプロイ動作のみを変更しました。account_codeを contract_code に設定する代わりに、アドレスで指定されたコードをauthorization_listから取得し、account_code に設定します。承認リストのアドレスフィールドから指定されたアドレスをロードし、署名者アカウントのコンテキスト内でコードを実行します。これは、ユーザー契約コードが実際にチェーン上の特定のアドレスに保存されていることを意味し、直接取引に含まれていないことを示しています。
EIP-7702はイーサリアムエコシステムを再構築し、アカウントの抽象化は新しい時代に突入します
イーサリアムアカウントの抽象化トラックの過去と未来を深く解読する
イントロダクション
本文は二つの大きな部分に分かれています:
第1部では、2015年の第1回AA提案から始まり、これまでの主なEIP提案を体系的に整理し、過去のAA提案の策定プロセスを議論し、各提案を総合的に評価します。
第二部では、EIP4337の導入後に直面した市場の反応を重点的に比較し、次のイーサリアムのバージョンアップグレードに組み込まれるEIP7702を深く分析します。この提案が統合されると、オンチェーンアプリケーションの形態が根本的に変わるでしょう。
EIP-7702は画期的な意義を持ちます。それについて深く理解していきましょう。
! [イーサリアムアカウント抽象化トラックの過去と未来の詳細な解釈](https://img-cdn.gateio.im/webp-social/moments-cecbf67df71971d38b0a927be5e4c4d9.webp0192837465674839201
1. アカウントの抽象化の背景
) 1.1 アカウントの抽象化の意義定位
イーサリアム創設者Vitalikは2023年末に再度ETHの発展ロードマップを更新しましたが、アカウントの抽象化の位置付けは変わっていません。現在の主流モデルはEIP-4337から次の段階の"自発的にEOAアカウントに変換する"へと移行しています。
1.2 アカウントの抽象化の市場現状
1年半の開発を経て、EIP4337のメインストリームチェーン上の総アドレス数は1200万に過ぎず、その中でイーサリアムメインネット上のアクティブアドレスはわずか6,764個で、EOAとCAアドレス数との差は大きい。イーサリアムメインネットの独立アドレス数は2.7億に達しており、EIP4337はメインネット上での発展が遅いと言える。
しかし、これはAAの本質的な価値には影響しません。EIP4337の設計は、メインネット上での良好な後方互換性を難しくしています。さまざまなL2チェーンが原生AAを一般的に組み込むにつれて、EIP4337のアドレス数はL2上で爆発的に増加し、BaseとPolygonチェーンの7月の月間アクティブユーザーはそれぞれ100万と300万に達し、好成績を示しています。
したがって、EIP4337の設計は誤りではなく、多くの利点があります。現在の状況は、メインネットとL2の間の違いに起因しており、それぞれに適したソリューションが必要です。
! [イーサリアムアカウント抽象化トラックの過去と未来の詳細な解釈]###https://img-cdn.gateio.im/webp-social/moments-65d1ef9656425666ee30c38bbb63e769.webp(
2. アカウントの抽象化とは?
アカウントの抽象化は本質的に所有権の分離の問題を解決するものです。
EVMアーキテクチャには2種類のアカウントタイプがあります: 外部アカウント)EOA(と契約アカウント)CA(。外部アカウントでは、所有権と署名権は同一のエンティティによって保持されます。秘密鍵を持つ者は、アカウントの"所有権"を持つだけでなく、"すべての資産を転送する署名権"も持っています。
これはイーサリアムアカウントの取引構造によって決まっています。取引構造から見ると、標準取引には実際にはFromフィールドがありません。資金の移動時、具体的な消費アドレスはVRSパラメータ)、すなわちユーザーの署名(を通じて逆解析されて得られます。
そしてEIP4337の核心的な効果は、取引フィールドにSender Addressを追加することで、秘密鍵と操作対象のアドレスを分離することです。
所有権の分離がこれほど重要な理由は、外部アカウント)EOA(の設計が多くの問題を引き起こすからです:
秘密鍵の保護が難しい: 秘密鍵を失うことは、すべての資産を失うことを意味します。
サインアルゴリズムが単一: ネイティブプロトコルの取引検証はECDSAアルゴリズムのみを使用できます。
サイン権限が高すぎる:ネイティブのマルチシグ機能がなく、シングルサインで任意の操作が実行できる。
取引手数料はETHでのみ支払うことができ、バッチ取引はサポートされていません。
取引のプライバシーが漏れる容易さ: 一対一の取引はアカウント保有者の情報を分析しやすい。
これらの制限は、普通のユーザーがイーサリアムを使用するのを難しくしています:
まず、ユーザーはエーテルを保有し、価格変動リスクを負わなければなりません。
次に、ユーザーはGas price、Gas limit、取引のブロッキングなどの概念といった複雑な手数料ロジックを処理する必要があります。
最後に、ブロックチェーンウォレットやアプリが製品の最適化を通じてユーザー体験を向上させようとしていますが、その効果は限られています。
したがって、解決策はアカウントの抽象化を実現し、所有権)Owner(と署名権)Signer(をデカップリングすることにあり、これによって上記の問題を段階的に解決していきます。
歴史的にさまざまな方案があり、最終的には二つのルートに集約される。
! [イーサリアムアカウント抽象化トラックの過去と未来の詳細な解釈])https://img-cdn.gateio.im/webp-social/moments-3503a168bb61430839419efb40e130de.webp(
3. AAヒストリカルプロポーザルコンテクストコーミング
問題の解決策は多くのEIP提案があるようですが、結局のところ2つの核心的な考え方に集約されます。通過していない各EIPが考慮した問題は、既存の解決策の突破口に集約されています。
) 3.1 第一のルート: EOAアドレスをCAアドレスに変換する
2015年11月、VitalikはEIP-101でアカウントの新しい構造として契約を提案しました。アドレスをコードとストレージスペースのみのものに変更し、ERC20による手数料支払いをサポートし、プリコンパイルされた契約を通じてネイティブトークンをERC20のようなストレージ残高に変更し、トランザクションフィールドをto、startgas、data、codeに簡略化しました。
この提案はまさに大躍進的な変革であり、基盤設計を大幅に変更し、各アカウントアドレスが自分自身の"コード"ロジックを持つことができるようにします###。これは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に2つの新しいOpCode: AUTHとAUTHCALLを追加し、EOAがこれらのopcodeを通じて契約に対してEOAの身分を代わりに使って他の契約を呼び出すことを可能にします。
概括すると、EOAは署名されたメッセージ)トランザクション(を自分が信頼するコントラクト)に送信することができ、これをInvoker(と呼びます。このInvokerコントラクトはAUTHおよびAUTHCALLオペコードを利用してEOAの代わりにトランザクションを発行できます。
EIP-4337:トランザクションメモリプールを使用してアカウントの抽象化)2021-09-29(
MEVからインスパイアされた設計で、コアバリューはコンセンサスレイヤープロトコルの変更を完全に回避することです。
EIP4337は新しいトランザクションオブジェクトUserOperationを提案し、ユーザーはこのオブジェクトをメモリプールに送信します。bundlersはマイナーの観点から一括してパッケージ化し、契約の実行トランザクションを配信します。本質的には、基盤となるトランザクションとアカウントの操作を契約レベルで実行することを意味します。
EIP-5189:背書人によるアカウントの抽象化)2022-06-29(
これはEIP4337のロジックの最適化であり、資金罰金の裏付けエンドーサーメカニズムを構築することによって悪意のあるBundlerのDoSブロッキング攻撃を防ぐことを目的としています。
) 3.3 他のAAをサポートする提案
EIP-2718:新しいトランザクションタイプのラッピングエンベロープ###2020-06-13(
これはすでにFinalな提案で、将来の新しい取引タイプの封筒として新しい取引タイプを定義しています。
最終的な効果は、新しい取引タイプを導入する際に、特定のエンコーディングで取引タイプを区別し、後方互換性のみを確保し、前方互換性は必要ないということです。最も一般的な例はEIP1559で、これは取引手数料を区別し、新しい取引タイプのエンコーディングを使用し、元のレガシー取引タイプには影響を与えません。
EIP-3607:EOAアドレスにコントラクトをデプロイできない)2021-06-10(
これはAAパス上の補完策で、契約デプロイメントアドレスとEOAアドレスの衝突を防ぐために使用されます。これは契約生成方法を制御し、コードがすでにEOAアドレスであるアドレスにデプロイされることを許可しません。このリスクは実際には非常に小さく、イーサリアムアドレスは160ビットの長さを持っています。指定された契約アドレスの秘密鍵を衝突させる方法は存在しますが、ビットコインの全算力を投入しても推定で1年の時間が必要です。
) 3.4 アカウントの抽象化の発展の歴史をどのように理解するか?
まず、CAへの変換後の価値を理解する必要があります。基本的にはEIP-4337の実際の効果です:
しかし、EIP-4337の核心的な欠点は、人間の動機原則に反していることです。
見た目は良さそうだが、市場の発展のデッドロックに陥っている: 多くのDappはまだ互換性がなく、ユーザーはCAアドレスを使用したがらず、CAを使用すると逆に取引コストが高くなる###通常の送金シーンでは、取引手数料が倍増(、Dapp自体の互換性に過度に依存している。
したがって、イーサリアムのメインネットでは、今日まで普及していません。
コストはユーザーにとって最も重要な指標であり、コストを削減する必要があります。
しかし、GASを本当に削減するには、イーサリアム自体がソフトフォークアップグレードを行い、GAS計算やオペコードのGAS消費などのモジュールを修正する必要があります。ソフトフォークを行うのであれば、EIP-7702を直接考慮した方が良いでしょう。
! [イーサリアムアカウント抽象化トラックの過去と未来の詳細な解釈])https://img-cdn.gateio.im/webp-social/moments-9d6eae95e3a0983a7b379ce2cfd7945f.webp(
4. EIP-7702 は完全に解析されます
) 4.1 EIP-7702は何ですか
それは新しい取引タイプを通じて、EOAが単一の取引で一時的にスマートコントラクト機能を持つことを許可し、バッチ取引、ガスなし取引、カスタム権限管理などをサポートし、さらに新しいEVM opCode###を導入することなく前方互換性(に影響を与えます。
ユーザーはスマートコントラクトをデプロイすることなく、ほとんどのAA機能を取得でき、さらには第三者がユーザーの代わりに取引を開始する機能を提供することも可能で、ユーザーが秘密鍵を提供する必要はなく、署名承認情報のみが必要です。
) 4.2 データ構造
新しい取引タイプ0x04を定義します。TransactionPayloadは以下の内容のRLPエンコードされたシリアライズ結果です:
rlp###[chain_id、nonce、max_priority_fee_per_gas、max_fee_per_gas、gas_limit、目的地、値、データ、access_list、authorization_list、signature_y_parity、 signature_r、signature_s](
重要なのは、署名者がそのEOAで実行したいコードを保存するauthorization_listオブジェクトが新たに追加されたことです。ユーザーは取引に署名する際に、実行する契約コードにも署名します。これは二次元リストとして存在し、複数の操作情報を一括で保存し、一括操作を実行できます。
authorization_list = [[chain_id, 住所, nonce, y_parity, r, s], ...]
) 4.3 取引ライフサイクル
4.3.1 検証フェーズ
取引実行の開始時に、[chain_id, address, nonce, y_parity, r, s] タプルの各authorization_listについて、次のようになります。
)# 4.3.2 実行フェーズ
"新"バージョンはコードのデプロイ動作のみを変更しました。
account_codeを contract_code に設定する代わりに、アドレスで指定されたコードをauthorization_listから取得し、account_code に設定します。
承認リストのアドレスフィールドから指定されたアドレスをロードし、署名者アカウントのコンテキスト内でコードを実行します。
これは、ユーザー契約コードが実際にチェーン上の特定のアドレスに保存されていることを意味し、直接取引に含まれていないことを示しています。