# イーサリアムアカウントの抽象化トラックの過去と未来の深い解読本文は二つの大きな部分に分かれています:上半分は2015年の最初のAA提案から始まり、システムはこれまでのEIP提案の主な内容を整理し、AAの歴史的提案の発展過程を探求し、各提案について総合的に評価します。下半部分重点対比EIP4337提案後の市場反応、深く分析するイーサリアムの次のバージョンアップグレードに組み込まれるEIP7702。この提案が統合されると、チェーン上のアプリケーションの形態が全面的に変わる。EIP-7702は画期的な意味を持ちます。それについて詳しく見ていきましょう。## 1. アカウントの抽象化の背景### 1.1 アカウントの抽象化の意義イーサリアム創設者Vitalikは2023年末に再びETHの開発ロードマップを更新しましたが、アカウントの抽象化の設定は変更されていません。現在、主流のモデルはEIP-4337から次の段階"自発的にEOAアカウントに移行する"へと移行しています。EIP4337が導入されてから1年以上が経過した2023年3月1日、デンバーのWalletConで正式に発表され、(はユーザーから広く認識されましたが、広く使用されているわけではありません。このような矛盾した市場環境の中で、EIP-7702の進捗が大幅に前倒しされ、次回のアップグレードで統合されることが確定しました。) 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-cecbf67df71971d38b0a927be5e4c4d90192837465674839201## 2. アカウントの抽象化とは?アカウントの抽象化は本質的に所有権の分離の問題を解決します。イーサリアム仮想マシン(EVM)アーキテクチャには2種類のアカウントがあります: 外部アカウント(EOA)と契約アカウント(Contract Account)。外部アカウントの所有権と署名権は実際には同一の主体によって保持されています。秘密鍵を持つ人は、アカウントの「所有権」を持つだけでなく、「すべての資産の移転に署名する権利」も持っています。これはイーサリアムアカウントの取引構造によって決まっています。標準のイーサリアム取引にはFromフィールドがなく、実際にはVRSパラメータ(、すなわちユーザーの署名)を通じてFromアドレスが逆解析されます。これにはECDSAなどの非対称暗号と単方向閾値関数などの概念が関与しています。暗号学は安全性を保証しますが、現在のEOAアドレスの所有権の統合という困難を引き起こしています。EIP4337の核心的な効果は、トランザクションフィールドにSender Addressフィールドを追加することで、秘密鍵と操作対象アドレスの分離を実現することです。所有権の分離がこれほど重要な理由は、外部アカウント(EOA)の設計がより多くの問題を引き起こすからです:1. プライベートキーの保護が難しい: プライベートキーを失うことは、すべての資産を失うことを意味します。2. 署名アルゴリズムが単一:ネイティブプロトコルは、取引を検証する際にECDSA署名と検証アルゴリズムのみを使用できます。3. サイン権限が高すぎる: ネイティブマルチシグ(のマルチシグはスマートコントラクトを通じてのみ実現でき)、単一のサインで任意の操作を実行できる。4. 取引手数料はETHのみで支払い可能であり、一括取引はサポートされていません。5. 取引のプライバシー漏洩: 一対一の取引は、アカウント保有者のプライバシー情報を分析しやすい。これらの制限により、一般ユーザーがイーサリアムを使用することが難しくなります:まず、イーサリアム上の任意のアプリを使用するには、ユーザーはエーテル(を保有し、価格の変動リスク)を負わなければなりません。次に、ユーザーは複雑な手数料のロジックを処理する必要があります。ガス価格、ガスリミット、取引のブロック(ノンスの順序)などの概念は、ユーザーにとって非常に複雑です。最後に、多くのブロックチェーンウォレットやアプリが製品の最適化を通じてユーザー体験を向上させようとしていますが、その効果は限られています。したがって、ブレークスルーの鍵はアカウントの抽象化を実現し、所有権(Owner)と署名権(Signer)をデカップリングすることにあり、それによって上記の問題を徐々に解決することです。歴史上、多くのプランがあり、最終的には二つのルートにまとめられました。! [イーサリアムアカウント抽象化トラックの過去と未来の詳細な解釈](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に新しいOpCodeであるAUTHとAUTHCALLを追加し、EOAがこれらの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)これはすでにFinalな提案であり、将来追加される取引タイプの封筒として、新しい取引タイプを定義しています。最終的な効果は、新しい取引タイプを導入する際に、特定のコーディングを使用してどの取引であるかを区別し、後方互換性のみを必要とし、前方互換性を必要としないことです。最も一般的な例はEIP1559で、これは取引手数料を区別し、新しい取引タイプのコーディングを使用して、元のレガシー取引タイプには影響を与えません。EIP-3607: EOAアドレスがコントラクトをデプロイできないように ###2021-06-10(これはAAパス上の補完方案であり、契約のデプロイ先アドレスとEOAアドレスの衝突を防ぐためのものです。それは契約生成方法を制御し、システムがすでにEOAアドレスであるアドレスにコードをデプロイすることを許可しないようにします。このリスクは実際には非常に小さいです。結局、イーサリアムアドレスは160ビットの長さがあり、特定の契約アドレスの私鍵を衝突させる方法が存在しますが、ビットコインの全算力を投入した場合、推定でもまだ1年の時間が必要です。) 3.4 アカウントの抽象化の発展の歴史をどのように理解しますか?まず、CAに転換された価値を理解する必要があります。基本的にEIP-4337の実際の効果であり、これにより実現可能です:- ユーザーはもはや直接ETHを保有する必要がなくなり、Gas費用を支払うことができます。- アカウントの権限を柔軟に設定でき、多署名やソーシャルリカバリーなどが可能です- バッチ取引をサポートし、取引コストを削減- カスタム署名検証アルゴリズム、安全性を向上させる- 一部の操作は第三者がGasを支払うことができますしかし、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が単一の取引で一時的にスマートコントラクトの機能を持つことを許可し、ビジネス上でのバッチ取引、Gasなし取引、カスタム権限管理などをサポートします。また、新しいEVM opCode(を導入することなく、前方互換性)に影響を与えません。それはユーザーがスマートコントラクトを展開することなく、ほとんどのAAの機能を得ることを可能にし、さらには第三者がユーザーに代わって取引を開始する能力を提供することができます。そして、ユーザーが秘密鍵を提供する必要はなく、署名による承認情報だけが必要です。### 4.2 データ構造それは新しいトランザクションタイプ0x04を定義し、そのトランザクションタイプのTransactionPayloadは以下の内容のRLPエンコードされたシリアライズ結果です:rlp([ chain_id、 ノンス, max_priority_fee_per_gas、 max_fee_per_gas、 ガスリミット, 行き先 価値 データ、 アクセスリスト, 認可リスト, signature_y_parity、 signature_r、 signature_s])重要なのは、新たに authorization_list オブジェクトが追加され、署名者がその EOA 内で実行したいコードを保存することです。ユーザーは取引に署名する際、実行する契約コードにも署名します。これは二次元リストとして存在し、複数の操作情報を一括で保存できることを示し、一括操作を実行します。認可_
EIP-7702: イーサリアムアカウントの抽象化の突破的進展
イーサリアムアカウントの抽象化トラックの過去と未来の深い解読
本文は二つの大きな部分に分かれています:
上半分は2015年の最初のAA提案から始まり、システムはこれまでのEIP提案の主な内容を整理し、AAの歴史的提案の発展過程を探求し、各提案について総合的に評価します。
下半部分重点対比EIP4337提案後の市場反応、深く分析するイーサリアムの次のバージョンアップグレードに組み込まれるEIP7702。この提案が統合されると、チェーン上のアプリケーションの形態が全面的に変わる。
EIP-7702は画期的な意味を持ちます。それについて詳しく見ていきましょう。
1. アカウントの抽象化の背景
1.1 アカウントの抽象化の意義
イーサリアム創設者Vitalikは2023年末に再びETHの開発ロードマップを更新しましたが、アカウントの抽象化の設定は変更されていません。現在、主流のモデルはEIP-4337から次の段階"自発的にEOAアカウントに移行する"へと移行しています。
EIP4337が導入されてから1年以上が経過した2023年3月1日、デンバーのWalletConで正式に発表され、(はユーザーから広く認識されましたが、広く使用されているわけではありません。このような矛盾した市場環境の中で、EIP-7702の進捗が大幅に前倒しされ、次回のアップグレードで統合されることが確定しました。
) 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-cecbf67df71971d38b0a927be5e4c4d9.webp0192837465674839201
2. アカウントの抽象化とは?
アカウントの抽象化は本質的に所有権の分離の問題を解決します。
イーサリアム仮想マシン(EVM)アーキテクチャには2種類のアカウントがあります: 外部アカウント(EOA)と契約アカウント(Contract Account)。外部アカウントの所有権と署名権は実際には同一の主体によって保持されています。秘密鍵を持つ人は、アカウントの「所有権」を持つだけでなく、「すべての資産の移転に署名する権利」も持っています。
これはイーサリアムアカウントの取引構造によって決まっています。標準のイーサリアム取引にはFromフィールドがなく、実際にはVRSパラメータ(、すなわちユーザーの署名)を通じてFromアドレスが逆解析されます。これにはECDSAなどの非対称暗号と単方向閾値関数などの概念が関与しています。暗号学は安全性を保証しますが、現在のEOAアドレスの所有権の統合という困難を引き起こしています。
EIP4337の核心的な効果は、トランザクションフィールドにSender Addressフィールドを追加することで、秘密鍵と操作対象アドレスの分離を実現することです。
所有権の分離がこれほど重要な理由は、外部アカウント(EOA)の設計がより多くの問題を引き起こすからです:
プライベートキーの保護が難しい: プライベートキーを失うことは、すべての資産を失うことを意味します。
署名アルゴリズムが単一:ネイティブプロトコルは、取引を検証する際にECDSA署名と検証アルゴリズムのみを使用できます。
サイン権限が高すぎる: ネイティブマルチシグ(のマルチシグはスマートコントラクトを通じてのみ実現でき)、単一のサインで任意の操作を実行できる。
取引手数料はETHのみで支払い可能であり、一括取引はサポートされていません。
取引のプライバシー漏洩: 一対一の取引は、アカウント保有者のプライバシー情報を分析しやすい。
これらの制限により、一般ユーザーがイーサリアムを使用することが難しくなります:
まず、イーサリアム上の任意のアプリを使用するには、ユーザーはエーテル(を保有し、価格の変動リスク)を負わなければなりません。
次に、ユーザーは複雑な手数料のロジックを処理する必要があります。ガス価格、ガスリミット、取引のブロック(ノンスの順序)などの概念は、ユーザーにとって非常に複雑です。
最後に、多くのブロックチェーンウォレットやアプリが製品の最適化を通じてユーザー体験を向上させようとしていますが、その効果は限られています。
したがって、ブレークスルーの鍵はアカウントの抽象化を実現し、所有権(Owner)と署名権(Signer)をデカップリングすることにあり、それによって上記の問題を徐々に解決することです。
歴史上、多くのプランがあり、最終的には二つのルートにまとめられました。
! イーサリアムアカウント抽象化トラックの過去と未来の詳細な解釈
3. AAヒストリカルプロポーザルコンテクストコーミング
問題の解決策には多くのEIP提案があるように見えますが、最終的には2つのコアアイデアしかありません。通過しなかった各EIPが考慮した問題は、現在の解決策の突破口に集約されています。
( 3.1 第一種ルート:EOAアドレスをCAアドレスに変換する
2015年11月15日に、VitalikはEIP-101で契約をアカウントとしての新しい構造を提案しました。アドレスをコードとストレージスペースのみのものに変更し、手数料の支払いをERC20トークンによってサポートするようにし、プリコンパイル契約を通じてネイティブトークンをクラスERC20に変更して残高)を保持できるようにし、代わりに代金の引き落とし権限などの機能###を持たせ、取引フィールドをto、startgas、data、codeに簡素化しました。
この変革は急進的に見え、基盤設計を大幅に変更し、各アカウントアドレスが独自の「コード」ロジックを持つことを可能にします(。これがまさにEIP-7702が実現しようとしている効果です)。
それは他の機能を派生させることもできます、例えば：
取引により多くの暗号アルゴリズムを使用させ、各アドレス内部のコードによって署名検証認証方法を指定します。
量子攻撃に対する耐性を備えており、コードがアップグレード可能です。
エーテルにERC20契約と同じ機能特性を持たせることで、核心的な効果は代わりに引き落としの権限を実現し、ネイティブコインを消費する必要がありません。
アカウントのカスタマイズスペースを向上させ、ソーシャルリカバリー、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に新しいOpCodeであるAUTHとAUTHCALLを追加し、EOAがこれらの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)
これはすでに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-3503a168bb61430839419efb40e130de.webp(
4. EIP-7702 は完全に解析されます
) 4.1 EIP-7702とは何ですか
新しい取引タイプを通じて区別され、EOAが単一の取引で一時的にスマートコントラクトの機能を持つことを許可し、ビジネス上でのバッチ取引、Gasなし取引、カスタム権限管理などをサポートします。また、新しいEVM opCode(を導入することなく、前方互換性)に影響を与えません。
それはユーザーがスマートコントラクトを展開することなく、ほとんどのAAの機能を得ることを可能にし、さらには第三者がユーザーに代わって取引を開始する能力を提供することができます。そして、ユーザーが秘密鍵を提供する必要はなく、署名による承認情報だけが必要です。
4.2 データ構造
それは新しいトランザクションタイプ0x04を定義し、そのトランザクションタイプのTransactionPayloadは以下の内容のRLPエンコードされたシリアライズ結果です:
rlp([ chain_id、 ノンス, max_priority_fee_per_gas、 max_fee_per_gas、 ガスリミット, 行き先 価値 データ、 アクセスリスト, 認可リスト, signature_y_parity、 signature_r、 signature_s ])
重要なのは、新たに authorization_list オブジェクトが追加され、署名者がその EOA 内で実行したいコードを保存することです。ユーザーは取引に署名する際、実行する契約コードにも署名します。これは二次元リストとして存在し、複数の操作情報を一括で保存できることを示し、一括操作を実行します。
認可_