# イーサリアムアカウントの抽象化トラックの歴史と未来の詳細分析## イントロダクション本文は二つの大きな部分に分かれています:上半分は2015年の最初のAA提案から始まり、システムは現在までのEIP提案の主要な内容を整理し、歴史的視点からAAの歴史提案の発展過程を探求し、各提案の長所と短所を包括的に評価することを望んでいます。下半部分では、EIP4337の導入後に直面した市場の冷淡な反応を重点的に比較し、イーサリアムの次回のバージョンアップグレードに含まれるEIP7702を深く分析します。この提案が合併されると、チェーン上のアプリケーションの形態が全面的に変わります。EIP-7702は画期的な意義を持ちます。それについて詳しく探ってみましょう。## 1. アカウントの抽象化の背景### 1.1 アカウントの抽象化の意義定位イーサリアムの創設者Vitalikは2023年末に再びETHの開発ロードマップを更新し、その中でアカウントの抽象化に関する設定は変わらない。現在の主流モデルはEIP-4337から次の段階「自発的にEOAアカウントに移行する」へと進んでいる。EIP4337が発売されてから1年以上が経過した後、(年3月1日にデンバーのWalletConで、公式はイーサリアム財団の開発者が設計したERC-4337コア契約がOpenZeppelinの監査を通過し、正式に発売された歴史的な節目と見なされたことを発表しました)。市場はユーザーの広範な認識があるものの、広範には使用されていない矛盾した状態を呈しています。このような環境下で、EIP-7702の進捗は大幅に前倒しされ、次回のアップグレードで統合されることが決定しました。### 1.2 アカウントの抽象化の市場現状1年半の発展を経て、EIP4337のメインチェーン上のアカウント総数はわずか1200万で、その中でイーサリアムメインネット上のアクティブアドレスはわずか6,764個であり、EOAとCAアドレス数との間に大きな差があります。イーサリアムメインネットの独立アドレス数は2.7億に達しています。EIP4337がメインネット上で実質的に発展していないと言えるでしょう。しかし、これはAAの本質的な価値には影響を与えません。EIP4337の設計当初から、メインネットの深刻な前方互換性の問題を解決することは難しいことが予期されていました。さまざまなL2チェーンが一般的にネイティブAAを組み込むにつれて、L2におけるEIP4337アドレス数は急増しました。その中で、BaseとPolygonチェーンの7月の月間アクティブユーザーはそれぞれ100万人と300万人に達し、まずまずの成果を示しています。したがって、EIP4337の設計に誤りがあるわけではなく、多くの利点があります。後で体系的にまとめます。現在の状況は、メインネットとL2の間の違いに起因しており、それぞれに適したソリューションが必要です。## 2. アカウントの抽象化とは何ですか?アカウントの抽象化は本質的に所有権の分離問題を解決します。EVMアーキテクチャには2種類のアカウントがあります: 外部アカウント(EOA)と契約アカウント(Contract Account)。外部アカウントの所有権と署名権は実際には同一の実体によって保持されています。秘密鍵を持つ人は、アカウントの「所有権」を持つだけでなく、「すべての資産の移転に署名する権利」を持っています。これはイーサリアムアカウントの取引構造によって決まっています。取引構造から見ると、イーサリアムの標準取引にはFromフィールドがありません。実際にはVRSパラメータ(を通じてユーザーが署名した)からFromアドレスを逆解析しています。これはECDSAなどの非対称暗号、単方向閾値関数などの概念に関係しており、ここでは詳述しません。要するに、ここでは暗号学が安全性を保障し、現在のEOAアドレスの所有権統合の困難を引き起こしています。EIP4337の核心的な効果は、トランザクションフィールドにSender Addressを追加することで、プライベートキーと操作対象のアドレスを分離することです。権利の分離がこれほど重要な理由は、外部アカウント(EOA)の設計がさらなる問題を引き起こすからです:1. 秘密鍵の保護が難しい: ユーザーが秘密鍵(を紛失したり、ハッキングや暗号解読)により、すべての資産を失うことを意味します。2. 署名アルゴリズムが単一:ネイティブプロトコルのトランザクション検証は、ECDSA署名および検証アルゴリズムのみを使用できます。3. サイン権限が過剰:ネイティブなマルチシグ(はスマートコントラクトによってのみ実現でき)、シングルサインで任意の操作を実行できます。4. 取引手数料はETHでのみ支払い可能であり、バルク取引には対応していません。5. 取引のプライバシー漏洩: 一対一の取引はアカウント保有者のプライバシー情報を分析しやすい。これらの制限は、一般ユーザーがイーサリアムを使用するのを難しくしています:まず、イーサリアム上のいかなるアプリケーションを使用する場合、ユーザーはエーテル(を保有し、価格変動リスク)を負う必要があります。次に、ユーザーは複雑な手数料のロジックを処理する必要があります。ガス価格、ガスリミット、取引のブロック、(ノンスの順序)などの概念は、ユーザーにとって非常に複雑です。最後に、多くのブロックチェーンウォレットやアプリが製品の最適化を通じてユーザー体験を向上させようとしていますが、効果は限定的です。したがって、ブレークスルーはアカウントの抽象化を実現し、所有権(Owner)と署名権(Signer)をデカップリングすることで、上記の問題を徐々に解決することにあります。歴史的に多くの提案がされましたが、最終的には2つのルートに集約されました。! [イーサリアムアカウント抽象化トラックの過去と未来の詳細な解釈](https://img-cdn.gateio.im/social/moments-cecbf67df71971d38b0a927be5e4c4d90192837465674839201## 3. AAヒストリカルプロポーザルコンテクストコーミング) 3.1 第一のルート: EOAアドレスをCAアドレスに変換する2015年11月15日、ヴィタリックはEIP-101でアカウントとしての契約の新しい構造を提案しました。アドレスをコードとストレージスペースのみとし、手数料のサポートをERC20によって行い、プレコンパイル契約を通じてネイティブトークンをERC20タイプのストレージバランス###に変更し、代金引き落としの権限などの機能を持たせ(、トランザクションフィールドをto、startgas、data、codeに簡素化しました。この提案は大躍進的な変革と見なされ、基盤設計に大幅な変更をもたらすものであり、各アカウントアドレスが独自の「コード」ロジックを持つことになります)。これが現在のEIP-7702が実現しようとしている効果です(。それは他の機能を派生させることができます、例えば:1. 取引はより多くの暗号アルゴリズムを使用し、各アドレス内のCodeによって署名検証メソッドが指定されることができます。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(上で、AUTHおよびAUTHCALLオペコードを使用してそのEOAの代わりに取引を送信できます。EIP-4337:トランザクションメモリプールを使用してアカウントの抽象化)2021-09-29(MEVからインスパイアを受けて設計されており、その核心的な価値はコンセンサスレイヤープロトコルの変更を完全に回避できることです。EIP4337は新しい取引オブジェクトUserOperationを提案し、ユーザーはこのオブジェクトをメモリプールに送信し、バンドラーはマイナーの観点から一括でパッケージ化して契約実行取引を提供します。本質的には、基盤となる取引とアカウントの運用を契約レベルで実行することになります。EIP-5189:エンドースメントによるアカウントの抽象化)2022-06-29(これはEIP4337のロジックの最適化であり、悪意のある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 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](重要なのは、新たにauthorization_listオブジェクトが追加され、署名者がそのEOA内で実行したいコードを保存することです。ユーザーは取引に署名すると同時に、実行する契約コードにも署名します。これは二次元リストとして存在し、複数の操作情報を一括で保存できることを示し、一括操作を実行します。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を使用して署名者のアドレス###を復元します。これはイーサリアム自体のメカニズムであるため、このEIPは署名アルゴリズム(を変更していません。権限 = ecrecover)keccak(MAGIC || rlp([chain_id, address, nonce](), y_parity, r, s]) 前の署名解除によって取得された差出人アドレスと同様に、 ここでの結果は、このリストのローカル署名アドレスの(です2. チェーンID)の検証フォークチェーンのリプレイ(。3. authorityの署名者のコードが空であるか、既に)に委託されているかを確認する
EIP-7702: イーサリアムアカウントの抽象化の重大な突破
イーサリアムアカウントの抽象化トラックの歴史と未来の詳細分析
イントロダクション
本文は二つの大きな部分に分かれています:
上半分は2015年の最初のAA提案から始まり、システムは現在までのEIP提案の主要な内容を整理し、歴史的視点からAAの歴史提案の発展過程を探求し、各提案の長所と短所を包括的に評価することを望んでいます。
下半部分では、EIP4337の導入後に直面した市場の冷淡な反応を重点的に比較し、イーサリアムの次回のバージョンアップグレードに含まれるEIP7702を深く分析します。この提案が合併されると、チェーン上のアプリケーションの形態が全面的に変わります。
EIP-7702は画期的な意義を持ちます。それについて詳しく探ってみましょう。
1. アカウントの抽象化の背景
1.1 アカウントの抽象化の意義定位
イーサリアムの創設者Vitalikは2023年末に再びETHの開発ロードマップを更新し、その中でアカウントの抽象化に関する設定は変わらない。現在の主流モデルはEIP-4337から次の段階「自発的にEOAアカウントに移行する」へと進んでいる。
EIP4337が発売されてから1年以上が経過した後、(年3月1日にデンバーのWalletConで、公式はイーサリアム財団の開発者が設計したERC-4337コア契約がOpenZeppelinの監査を通過し、正式に発売された歴史的な節目と見なされたことを発表しました)。市場はユーザーの広範な認識があるものの、広範には使用されていない矛盾した状態を呈しています。このような環境下で、EIP-7702の進捗は大幅に前倒しされ、次回のアップグレードで統合されることが決定しました。
1.2 アカウントの抽象化の市場現状
1年半の発展を経て、EIP4337のメインチェーン上のアカウント総数はわずか1200万で、その中でイーサリアムメインネット上のアクティブアドレスはわずか6,764個であり、EOAとCAアドレス数との間に大きな差があります。イーサリアムメインネットの独立アドレス数は2.7億に達しています。EIP4337がメインネット上で実質的に発展していないと言えるでしょう。
しかし、これはAAの本質的な価値には影響を与えません。EIP4337の設計当初から、メインネットの深刻な前方互換性の問題を解決することは難しいことが予期されていました。さまざまなL2チェーンが一般的にネイティブAAを組み込むにつれて、L2におけるEIP4337アドレス数は急増しました。その中で、BaseとPolygonチェーンの7月の月間アクティブユーザーはそれぞれ100万人と300万人に達し、まずまずの成果を示しています。
したがって、EIP4337の設計に誤りがあるわけではなく、多くの利点があります。後で体系的にまとめます。現在の状況は、メインネットとL2の間の違いに起因しており、それぞれに適したソリューションが必要です。
2. アカウントの抽象化とは何ですか?
アカウントの抽象化は本質的に所有権の分離問題を解決します。
EVMアーキテクチャには2種類のアカウントがあります: 外部アカウント(EOA)と契約アカウント(Contract Account)。外部アカウントの所有権と署名権は実際には同一の実体によって保持されています。秘密鍵を持つ人は、アカウントの「所有権」を持つだけでなく、「すべての資産の移転に署名する権利」を持っています。
これはイーサリアムアカウントの取引構造によって決まっています。取引構造から見ると、イーサリアムの標準取引にはFromフィールドがありません。実際にはVRSパラメータ(を通じてユーザーが署名した)からFromアドレスを逆解析しています。
これはECDSAなどの非対称暗号、単方向閾値関数などの概念に関係しており、ここでは詳述しません。要するに、ここでは暗号学が安全性を保障し、現在のEOAアドレスの所有権統合の困難を引き起こしています。
EIP4337の核心的な効果は、トランザクションフィールドにSender Addressを追加することで、プライベートキーと操作対象のアドレスを分離することです。
権利の分離がこれほど重要な理由は、外部アカウント(EOA)の設計がさらなる問題を引き起こすからです:
秘密鍵の保護が難しい: ユーザーが秘密鍵(を紛失したり、ハッキングや暗号解読)により、すべての資産を失うことを意味します。
署名アルゴリズムが単一:ネイティブプロトコルのトランザクション検証は、ECDSA署名および検証アルゴリズムのみを使用できます。
サイン権限が過剰:ネイティブなマルチシグ(はスマートコントラクトによってのみ実現でき)、シングルサインで任意の操作を実行できます。
取引手数料はETHでのみ支払い可能であり、バルク取引には対応していません。
取引のプライバシー漏洩: 一対一の取引はアカウント保有者のプライバシー情報を分析しやすい。
これらの制限は、一般ユーザーがイーサリアムを使用するのを難しくしています:
まず、イーサリアム上のいかなるアプリケーションを使用する場合、ユーザーはエーテル(を保有し、価格変動リスク)を負う必要があります。
次に、ユーザーは複雑な手数料のロジックを処理する必要があります。ガス価格、ガスリミット、取引のブロック、(ノンスの順序)などの概念は、ユーザーにとって非常に複雑です。
最後に、多くのブロックチェーンウォレットやアプリが製品の最適化を通じてユーザー体験を向上させようとしていますが、効果は限定的です。
したがって、ブレークスルーはアカウントの抽象化を実現し、所有権(Owner)と署名権(Signer)をデカップリングすることで、上記の問題を徐々に解決することにあります。
歴史的に多くの提案がされましたが、最終的には2つのルートに集約されました。
! [イーサリアムアカウント抽象化トラックの過去と未来の詳細な解釈](https://img-cdn.gateio.im/webp-social/moments-cecbf67df71971d38b0a927be5e4c4d9.webp0192837465674839201
3. AAヒストリカルプロポーザルコンテクストコーミング
) 3.1 第一のルート: EOAアドレスをCAアドレスに変換する
2015年11月15日、ヴィタリックはEIP-101でアカウントとしての契約の新しい構造を提案しました。アドレスをコードとストレージスペースのみとし、手数料のサポートをERC20によって行い、プレコンパイル契約を通じてネイティブトークンをERC20タイプのストレージバランス###に変更し、代金引き落としの権限などの機能を持たせ(、トランザクションフィールドをto、startgas、data、codeに簡素化しました。
この提案は大躍進的な変革と見なされ、基盤設計に大幅な変更をもたらすものであり、各アカウントアドレスが独自の「コード」ロジックを持つことになります)。これが現在のEIP-7702が実現しようとしている効果です(。
それは他の機能を派生させることができます、例えば:
取引はより多くの暗号アルゴリズムを使用し、各アドレス内のCodeによって署名検証メソッドが指定されることができます。
量子攻撃に対する耐性を備えており、コードはアップグレード可能です。
エーテルが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(上で、AUTHおよびAUTHCALLオペコードを使用してそのEOAの代わりに取引を送信できます。
EIP-4337:トランザクションメモリプールを使用してアカウントの抽象化)2021-09-29(
MEVからインスパイアを受けて設計されており、その核心的な価値はコンセンサスレイヤープロトコルの変更を完全に回避できることです。
EIP4337は新しい取引オブジェクトUserOperationを提案し、ユーザーはこのオブジェクトをメモリプールに送信し、バンドラーはマイナーの観点から一括でパッケージ化して契約実行取引を提供します。本質的には、基盤となる取引とアカウントの運用を契約レベルで実行することになります。
EIP-5189:エンドースメントによるアカウントの抽象化)2022-06-29(
これはEIP4337のロジックの最適化であり、悪意のある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 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](
重要なのは、新たにauthorization_listオブジェクトが追加され、署名者がそのEOA内で実行したいコードを保存することです。ユーザーは取引に署名すると同時に、実行する契約コードにも署名します。これは二次元リストとして存在し、複数の操作情報を一括で保存できることを示し、一括操作を実行します。
authorization_list = [[chain_id, 住所, nonce, y_parity, r, s], ...]
) 4.3 取引ライフサイクル
4.3.1 検証フェーズ
トランザクションの実行開始時に、[chain_id, address, nonce, y_parity, r, s] の各authorization_listタプルについて、次の操作を行います。
署名r、sからecrecoverを使用して署名者のアドレス###を復元します。これはイーサリアム自体のメカニズムであるため、このEIPは署名アルゴリズム(を変更していません。 権限 = ecrecover)keccak(MAGIC || rlp(chain_id, address, nonce, y_parity, r, s]) 前の署名解除によって取得された差出人アドレスと同様に、 ここでの結果は、このリストのローカル署名アドレスの(です
チェーンID)の検証フォークチェーンのリプレイ(。
authorityの署名者のコードが空であるか、既に)に委託されているかを確認する