# デプスの深い分析：イーサリアムアカウントの抽象化の歴史的進展と未来の展望## はじめにこの記事では、イーサリアムのアカウントの抽象化(AA)の発展の歴史を2つの主要な側面から探ります:まず、2015年の最初のAA提案以来の歴史的な脈絡を遡り、これまでの各EIP提案の主要な内容を系統的に整理し、AA提案の進化過程を深く掘り下げ、各方案の利点と欠点を包括的に評価します。次に、私たちはEIP4337の導入後に市場反応が低迷している理由を重点的に分析し、今後のイーサリアムのバージョンアップに含まれるEIP7702について深く探討します。この提案が統合されると、チェーン上のアプリケーションの形態が根本的に変わることになります。EIP-7702は時代を画す革命と称され、私たちはその奥秘を深く探求しましょう。! [イーサリアムアカウント抽象化トラックの過去と未来の詳細な解釈](https://img-cdn.gateio.im/social/moments-cecbf67df71971d38b0a927be5e4c4d90192837465674839201## 1. アカウントの抽象化の背景) 1.1 アカウントの抽象化の意味の定位イーサリアムの創始者は最近再びETHの開発ロードマップを更新しましたが、アカウントの抽象化に関する設定は変更されていません。現在の主流モデルはEIP-4337から、次の段階の「自発的にEOAアカウントに変換」へと移行しています。EIP4337の導入から1年以上が経過しましたが、市場の反応は相当矛盾しています - ユーザーはその価値を一般的に認めていますが、実際の使用率は高くありません。このような状況の中で、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-65d1ef9656425666ee30c38bbb63e769(## 2. アカウントの抽象化とは何ですか?アカウントの抽象化は本質的に所有権の分離問題を解決します。イーサリアム仮想マシン)EVM(アーキテクチャには2種類のアカウントタイプがあります: 外部アカウント)EOA(と契約アカウント)Contract Account(。EOAでは、アカウントの所有権と署名権は同一の実体が保持します。秘密鍵を持つ者は、アカウントの「所有権」を持つだけでなく、「すべての資産の移転に署名する権利」を持ちます。この特性はイーサリアムアカウントの取引構造によって決まります。イーサリアムの標準取引構造には実際にはFromフィールドがありません。取引の発起者のアドレスはVRSパラメータ)、すなわちユーザーの署名(を逆解析することによって得られます。このデザインは暗号学によって安全性を保証していますが、現在のEOAアドレスの所有権統合の困難を引き起こしています。EIP4337の核心的な効果は、トランザクションフィールドにSender Addressを追加することで、プライベートキーと操作対象アカウントの分離を実現することです。権利分離が非常に重要な理由は、EOA設計から多くの問題が派生するためです。1. 秘密鍵の保護が難しい: 秘密鍵を失うことは、すべての資産を失うことを意味します。2. 署名アルゴリズムが単一: ネイティブプロトコルはECDSA署名および検証アルゴリズムのみをサポートしています。3. サイン権限が高すぎる: ネイティブのマルチシグサポートがなく、シングルサインで任意の操作が実行可能。4. 取引手数料はETHでのみ支払われ、バルク取引には対応していません。5. 取引のプライバシーが漏洩しやすい: 一対一の取引はアカウント保有者の情報を分析しやすい。これらの制限により、一般ユーザーがイーサリアムを使用するのが難しくなっています:まず、ユーザーはエーテル)を保有し、価格変動リスク(を負担する必要があります。その上で、イーサリアム上のアプリケーションを利用できます。次に、ユーザーはGas price、Gas limit、取引のブロッキング)Nonceの順序(など、複雑な手数料ロジックを処理する必要があります。これらの概念はユーザーにとってあまりにも複雑です。最後に、多くのブロックチェーンウォレットやアプリは製品の最適化を通じてユーザー体験を向上させようとしていますが、その効果は限られています。したがって、困難を突破する鍵はアカウントの抽象化を実現し、所有権)Owner(と署名権)Signer(をデカップリングすることであり、これによって前述の問題を段階的に解決していく。歴史的に多くの提案がされ、最終的に二つの主要なルートに集約されました。## 3. AAヒストリカルプロポーザルコンテクストコーミング問題の解決策には複数のEIP提案があるように見えますが、結局のところ、2つの核心的な考え方しかありません。通過しなかったEIPが考慮した問題は、最終的に既存の解決策の突破口に集約されました。) 3.1 第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の核心的な論理の1つとなりました。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は署名されたメッセージ)を取引(として自分が信頼するコントラクト)に送信し、そのコントラクトはこのEOAの代わりにAUTHおよびAUTHCALLオペコードを使用して取引を送信することができるInvoker(です。EIP-4337:トランザクションメモリプールを使用してアカウントの抽象化)2021-09-29(この提案はMEVに触発されて設計されており、その核心価値はコンセンサス層プロトコルの変更を完全に回避することにあります。EIP-4337は新しいトランザクションオブジェクト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の実際の効果であり、以下を実現できます:1. マルチシグとソーシャルリカバリーをサポート2. バッチ取引をサポート3. ERC20トークンによるガス代の支払いをサポート4. 取引限度をサポート5. ガス不要の取引)のガス代###をサポート6. アカウントロック(ホットウォレットとコールドウォレットの切り替え)しかし、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 データ構造EIP-7702は新しい取引タイプ0x04を定義しており、この取引タイプのTransactionPayloadは以下の内容のRLPエンコードシリアライズ結果です:rlp)[ chain_id、ノンス, max_priority_fee_per_gas、 max_fee_per_gas、 ガスリミット、 行き先 価値 データ、 アクセスリスト, authorization_list、 signature_y_parity、 signature_r、 signature_s]###新たに追加されたauthorization_listオブジェクトは、署名者がそのEOAで実行したいコードを保存します。ユーザーは取引に署名する際、実行する内容にも署名します。
EIP-7702: イーサリアムアカウントの抽象化の新たな突破口と未来の発展
デプスの深い分析：イーサリアムアカウントの抽象化の歴史的進展と未来の展望
はじめに
この記事では、イーサリアムのアカウントの抽象化(AA)の発展の歴史を2つの主要な側面から探ります:
まず、2015年の最初のAA提案以来の歴史的な脈絡を遡り、これまでの各EIP提案の主要な内容を系統的に整理し、AA提案の進化過程を深く掘り下げ、各方案の利点と欠点を包括的に評価します。
次に、私たちはEIP4337の導入後に市場反応が低迷している理由を重点的に分析し、今後のイーサリアムのバージョンアップに含まれるEIP7702について深く探討します。この提案が統合されると、チェーン上のアプリケーションの形態が根本的に変わることになります。
EIP-7702は時代を画す革命と称され、私たちはその奥秘を深く探求しましょう。
! [イーサリアムアカウント抽象化トラックの過去と未来の詳細な解釈](https://img-cdn.gateio.im/webp-social/moments-cecbf67df71971d38b0a927be5e4c4d9.webp0192837465674839201
1. アカウントの抽象化の背景
) 1.1 アカウントの抽象化の意味の定位
イーサリアムの創始者は最近再びETHの開発ロードマップを更新しましたが、アカウントの抽象化に関する設定は変更されていません。現在の主流モデルはEIP-4337から、次の段階の「自発的にEOAアカウントに変換」へと移行しています。
EIP4337の導入から1年以上が経過しましたが、市場の反応は相当矛盾しています - ユーザーはその価値を一般的に認めていますが、実際の使用率は高くありません。このような状況の中で、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-65d1ef9656425666ee30c38bbb63e769.webp(
2. アカウントの抽象化とは何ですか?
アカウントの抽象化は本質的に所有権の分離問題を解決します。
イーサリアム仮想マシン)EVM(アーキテクチャには2種類のアカウントタイプがあります: 外部アカウント)EOA(と契約アカウント)Contract Account(。EOAでは、アカウントの所有権と署名権は同一の実体が保持します。秘密鍵を持つ者は、アカウントの「所有権」を持つだけでなく、「すべての資産の移転に署名する権利」を持ちます。
この特性はイーサリアムアカウントの取引構造によって決まります。イーサリアムの標準取引構造には実際にはFromフィールドがありません。取引の発起者のアドレスはVRSパラメータ)、すなわちユーザーの署名(を逆解析することによって得られます。
このデザインは暗号学によって安全性を保証していますが、現在のEOAアドレスの所有権統合の困難を引き起こしています。
EIP4337の核心的な効果は、トランザクションフィールドにSender Addressを追加することで、プライベートキーと操作対象アカウントの分離を実現することです。
権利分離が非常に重要な理由は、EOA設計から多くの問題が派生するためです。
秘密鍵の保護が難しい: 秘密鍵を失うことは、すべての資産を失うことを意味します。
署名アルゴリズムが単一: ネイティブプロトコルはECDSA署名および検証アルゴリズムのみをサポートしています。
サイン権限が高すぎる: ネイティブのマルチシグサポートがなく、シングルサインで任意の操作が実行可能。
取引手数料はETHでのみ支払われ、バルク取引には対応していません。
取引のプライバシーが漏洩しやすい: 一対一の取引はアカウント保有者の情報を分析しやすい。
これらの制限により、一般ユーザーがイーサリアムを使用するのが難しくなっています:
まず、ユーザーはエーテル)を保有し、価格変動リスク(を負担する必要があります。その上で、イーサリアム上のアプリケーションを利用できます。
次に、ユーザーはGas price、Gas limit、取引のブロッキング)Nonceの順序(など、複雑な手数料ロジックを処理する必要があります。これらの概念はユーザーにとってあまりにも複雑です。
最後に、多くのブロックチェーンウォレットやアプリは製品の最適化を通じてユーザー体験を向上させようとしていますが、その効果は限られています。
したがって、困難を突破する鍵はアカウントの抽象化を実現し、所有権)Owner(と署名権)Signer(をデカップリングすることであり、これによって前述の問題を段階的に解決していく。
歴史的に多くの提案がされ、最終的に二つの主要なルートに集約されました。
3. AAヒストリカルプロポーザルコンテクストコーミング
問題の解決策には複数のEIP提案があるように見えますが、結局のところ、2つの核心的な考え方しかありません。通過しなかったEIPが考慮した問題は、最終的に既存の解決策の突破口に集約されました。
) 3.1 第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の核心的な論理の1つとなりました。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は署名されたメッセージ)を取引(として自分が信頼するコントラクト)に送信し、そのコントラクトはこのEOAの代わりにAUTHおよびAUTHCALLオペコードを使用して取引を送信することができるInvoker(です。
EIP-4337:トランザクションメモリプールを使用してアカウントの抽象化)2021-09-29(
この提案はMEVに触発されて設計されており、その核心価値はコンセンサス層プロトコルの変更を完全に回避することにあります。
EIP-4337は新しいトランザクションオブジェクト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を使用すると取引コストが高くなることさえあります(通常の送金シーンでは、取引手数料が倍増する可能性があります)、Dapp自体の互換性に過度に依存しています。
これが、イーサリアムのメインネットで未だに普及していない理由です。
コストはユーザーにとって最も重要な評価基準であり、コストを削減する必要があります。
しかし、GASを本当に削減するには、イーサリアム自体のソフトフォークアップグレードを通じて、GAS計算やオペコードのGAS消費などのモジュールを修正する必要があります。ソフトフォークを行うのであれば、なぜEIP-7702を直接考慮しないのでしょうか？
! イーサリアムアカウント抽象化トラックの過去と未来の詳細な解釈
4. EIP-7702 は完全に解析されます
( 4.1 EIP-7702の概要
この提案は、新しい取引タイプを導入することによって、EOAが単一の取引の中で一時的にスマートコントラクトの機能を持つことを可能にし、バッチ取引、ガスなしの取引、およびカスタム権限管理などのビジネス操作をサポートします。また、新しいEVM opCode)を導入することなく、後方互換性###に影響を与えません。
これにより、ユーザーはスマートコントラクトを展開することなく、ほとんどのAA機能を利用でき、さらには第三者がユーザーの代わりに取引を開始することも可能になり、ユーザーが秘密鍵を提供する必要はなく、署名による承認情報のみが必要です。
( 4.2 データ構造
EIP-7702は新しい取引タイプ0x04を定義しており、この取引タイプのTransactionPayloadは以下の内容のRLPエンコードシリアライズ結果です:
rlp)[ chain_id、 ノンス, max_priority_fee_per_gas、 max_fee_per_gas、 ガスリミット、 行き先 価値 データ、 アクセスリスト, authorization_list、 signature_y_parity、 signature_r、 signature_s ]###
新たに追加されたauthorization_listオブジェクトは、署名者がそのEOAで実行したいコードを保存します。ユーザーは取引に署名する際、実行する内容にも署名します。