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