イーサリアムの過去と未来におけるアカウント抽象化の徹底分析
前書き
記事は主に2つのセクションに分かれています:
最初の部分では、2015年の最初のAA提案から始まり、現在までのEIP提案の主な内容を体系的に整理します。AA提案の歴史的な発展を探求し、各提案の長所と短所を包括的に評価することを目指しています。
第2部では、EIP-4337導入後の市場フィードバックの比較に焦点を当て、次回のEthereumアップグレードに含まれる予定のEIP-7702の分析に入ります。この提案がマージされると、オンチェーンアプリケーションの性質が大幅に変化することが期待されています。
EIP-7702は革命的な変化を約束しており、詳細について議論します。
1. アカウント抽象化の背景
1.1 アカウント抽象化の意味
2023年末、イーサリアム創設者のVitalik Buterinが再びETH開発ロードマップを更新しました。ただし、口座抽象化に関連する規定は変更されていません。現行の主流モデルは引き続きEIP-4337から次の段階、自発的EOAコンバージョン（自己イニシエーション型のEOAアカウント変換）に進化しています。
https://x.com/VitalikButerin/status/1741190491578810445
EIP-4337が1年以上前にリリースされて以来（2023年3月1日、デンバーのWalletConで、Ethereum Foundationの開発者はERC-4337のコア契約がOpenZeppelinの監査に合格したことを発表し、公式のローンチの歴史的なマイルストーンを示した）、広範なユーザーからの認知を得ているが、広く普及していない。この逆説的な市場環境は、次のアップグレードに含まれることが確認されたEIP-7702の進捗を加速させています。
1.2 アカウント抽象化の現在の市場状況
さて、データを見てみましょう。
開発から1年半が経過したEIP-4337は、主要なチェーンアカウントでわずか1200万のアドレスしか集められていません。特に驚くべきことは、Ethereumメインネットワーク上にはわずか6,764のアクティブなアドレスしかないことです。統計的な側面に問題があるかもしれませんが、この数値は依然としてEOAとCAのアドレス数とは大きく異なります。なお、Ethereumメインネットワーク上のユニークなアドレス数は2億7000万に達しています（出典: https://etherscan.io/chart/address).
メインネットでは、EIP-4337は実質的な進展を遂げていないと言えます。
(チャートソース：https://dune.com/niftytable/account-abstraction)
ただし、これにより、Account Abstraction（AA）の固有の価値が低下するわけではありません。最初から、EIP-4337の設計は、メインネットでの重要な後方互換性の問題に直面する運命でした。その結果、さまざまなLayer 2チェーンがネイティブAAを統合する中で、EIP-4337はLayer 2のアドレス数において急成長を遂げています。たとえば、7月には、BaseとPolygonチェーンのアクティブユーザー数がそれぞれ100万人と300万人に達し、非常に印象的です。
したがって、EIP-4337の設計に問題があるわけではありません。多くの利点があり、それらを体系的にまとめます。現在の状況は、メインネットとレイヤー2の間の違いから生じており、それぞれに合わせた解決策が必要です。
2. アカウント抽象とは何ですか？
アカウント抽象化は複雑に聞こえるかもしれませんが、基本的には所有権の分離の問題に対処しています。
イーサリアム仮想マシン（EVM）アーキテクチャでは、Externally Owned Accounts（EOAs）とContract Accountsの2種類のアカウントがあります。 EOAsでは、所有権と署名権限が同じエンティティによって保持されます。 私鍵を持つ人物は、口座の所有者であるだけでなく、すべての資産に署名して転送する権利も持っています。
このセットアップは、イーサリアムのアカウントトランザクション構造によって決まります。標準のイーサリアムトランザクションでは、直接的な「From」アドレスは見えません。資金の送金が発生すると、資金が支出された実際のアドレスはVRSパラメーター（つまり、ユーザーの署名）を介して推測されます。
これには、ECDSA非対称暗号化や一方向閾値関数などの概念が関わっていますが、ここではそれらの詳細には立ち入りません。基本的に、暗号化はセキュリティを確保し、それが所有権と署名権限がEOAで結合された現在の状況につながります。
EIP-4337の主要な効果は、取引に送信者アドレスフィールドを追加し、秘密キーと操作されるアドレスを分離することです。
だから所有権を分離することがなぜ重要なのですか？
Externally Owned Accounts（EOAs）の設計によっていくつかの問題が引き起こされるため：
プライベートキーの保護: プライベートキーを失うと（紛失、ハッキング、または暗号の侵害による）、すべての資産を失うことになります。
限られた署名アルゴリズム**：ネイティブプロトコルは、署名と検証に対してECDSAのみをサポートしています。
ハイシグネチャ権限：ネイティブなマルチシグネチャのサポートがないため（これはスマートコントラクトを介してのみ達成できます）、単一の署名で任意の操作を実行できます。
トランザクション手数料：手数料はETHのみで支払うことができ、高い取引量をサポートしていません。
トランザクションプライバシー：1対1の取引は、口座所有者の個人情報を分析しやすくします。
これらの制約は、一般ユーザーがイーサリアムを利用するのを難しくしています。
イーサリアム上の任意のアプリケーションを使用するには、ユーザーはETHを保持している必要があります（そしてETH価格の変動リスクを負わなければなりません）。
ユーザーは、ガス価格、ガスリミット、およびトランザクションブロッキング（ノンスオーダー）など、複雑な手数料ロジックに対処する必要があり、これはあまりにも複雑である可能性があります。
多くのブロックチェーンウォレットやアプリケーションは、製品の最適化を通じてユーザーエクスペリエンスを向上しようとしていますが、その効果は限定されています。
解決策は、これらの問題に対処するために所有権（所有者）と署名権限（署名者）を切り離すアカウント抽象化を実装することにあります。歴史的には、多くの解決策が現れ、最終的には2つの主要なアプローチに収束してきました。
3. アカウント抽象化提案の歴史的概要
多くの問題に対処するEIP提案があるように見えるかもしれませんが、基本的には2つの核心的なアプローチしかありません。過去の提案で検討された問題は、最終的に現在の解決策に収束しました。
3.1最初のルートは、EOAアドレスをCAアドレスに変換することです
2015年11月15日、Vitalik ButerinはEIP-101を中心とする新しいアカウント構造を提案しました。これには契約をアカウントとして使用することが含まれました。これにより、アドレスがコードとストレージスペースのみを持つエンティティに変換され、手数料サポートがERC20トークン経由で支払われるようになり、ネイティブトークンをERC20のようなトークンに変換するためにプリコンパイルされた契約が使用され、残高の保存（委任された認可などの機能を備える）に使用されました。トランザクションフィールドは、to、startgas、data、codeのみを含むように簡略化されました。
結果論的には、これは革命的な変化であり、基本的な設計を劇的に変更し、それぞれの口座アドレスに独自の「コード」ロジックを与えることになります。これは実質的にEIP-7702が今日達成しようとしているものです。このアプローチは、追加の機能を可能にする可能性もあります:
内部コードで指定された各アドレスの検証と認証に使用する暗号アルゴリズムをより多くの取引に許可する。
コードのアップグレード可能性による量子耐性の提供。
ERC20契約と同じ機能的特性を持つようにEtherに賦与し、委任された承認などの機能を備え、ネイティブコインの支出の必要性を排除します。
アカウントのカスタマイズを強化し、ソーシャルリカバリー、SBT（ソウルバウンドトークン）、キーリカバリーをサポートします。
この提案を前に進めなかった理由は単純でした：手順があまりにも野心的でした。トランザクションハッシュの衝突やセキュリティ上の懸念などの問題が完全に解決されていなかったため、延期されました。しかし、その多くの利点は、後続のEIP（EIP-4337やEIP-7702を含む）の中核的な機能となっています。
いくつかのEIPは後にこのロジックを磨こうと試みました。
EIP-859: Account Abstraction on Mainnet (January 30, 2018) aimed to address code deployment issues. Its core function was to use the コードトランザクションにアタッチされるパラメーターは、契約ウォレットを展開するためのものであり、契約が展開されていない場合に使用されます。また、新しいPAYGASオペコードが導入され、トランザクションの検証部分と実行部分が分離されました。
当時進展しなかったものの、この論理は、特別なトランザクション構造を介してコードを含めることができるEOAアドレスに契約機能を持たせるEIP-7702の中核的なコンポーネントとなりました。
EIP-7702：EOAアカウントコードの設定（2024年5月7日）は、ここで議論されている重要なEIPです。 VitalikはEIP-3074の代替案としてEIP-7702を提案しました。その結果、EIP-3074は廃止され、EIP-7702は近日公開予定のETH Prague/Electra（Pectra）ハードフォークに含まれる予定です。詳細は以下で議論されます。
3.2 第二のアプローチは、EOAアドレスがCAアドレスをドライブするようにすることです。
EIP-3074: AUTHおよびAUTHCALLオペコードの追加（2020年10月15日）
このEIPは、EOAが契約に自分のアイデンティティを置き換え、他の契約を呼び出すことを許可する、AUTHおよびAUTHCALLという2つの新しいオプコードをEVMに導入します。基本的に、EOAは信頼できる契約（Invokerと呼ばれる）に署名されたメッセージ（トランザクション）を送信できます。Invoker契約はその後、AUTHおよびAUTHCALLオプコードを使用して、EOAの代わりにトランザクションを送信できます。
EIP-4337: 2021年9月29日にトランザクションプールを介したアカウント抽象化の実装
MEVに触発されたこのEIPのコアバリューは、コンセンサスレイヤープロトコルへの変更を回避することです。EIP-4337 では、ユーザーがメモリプールに送信する新しいトランザクションオブジェクト UserOperation が導入されています。その後、バンドラーはこれらのトランザクションをバッチ処理して契約実行に配信し、下位レベルのトランザクションとアカウント操作を契約レイヤーに効果的に移行します。
EIP-5189: 抽象アカウント操作エンドーサーを介して (2022年6月29日)
このEIPは、悪意のあるバンドラーに関する潜在的な問題に対処することで、EIP-4337を最適化しています。エンドーサー支援ファンドのメカニズムを導入して、悪意のある行為者を罰することでDoS攻撃を防ぐ仕組みを導入しています。
3.3 他のアカウント抽象化をサポートする提案
EIP-2718: 新しいトランザクションタイプエンベロープ（2020年6月13日）
この最終的な提案は、将来の取引タイプの封筒として新しい取引タイプを定義します。新しい取引タイプが導入される際に、特定のエンコーディングによって区別されることを保証し、レガシータイプに影響を与えることなく後方互換性を維持します。一般的な例として、EIP-1559は、新しい取引タイプのエンコーディングで取引手数料を区別し、レガシータイプを保存しました。
EIP-3607: EOAアドレスから契約の展開を防止（2021年6月10日）
この補足提案は、契約の展開アドレスがEOAアドレスと競合する問題に対処しています。契約の作成方法を制御し、コードがEOAによって既に使用されているアドレスに展開されるのを防ぎます。イーサリアムアドレスの160ビットの長さを考えると、リスクは最小限ですが、理論的にはキーの衝突を通じて可能ですが、それにはかなりの計算コストが必要です。
3.4 アカウント抽象化の開発の理解
CAアドレスへの移行の価値を理解するには、EIP-4337の実用的な効果を把握することが不可欠です。
しかし、EIP-4337の中核的な欠点は、人間のインセンティブの原則に違反していることです。改善を提供するように見えるが、市場開発の行き詰まりに陥ってしまいます。多くのDappsはまだそれと互換性がないため、ユーザーはCAアドレスを使用することをためらっています。さらに、CAを使用することで、取引コストが高くなる可能性があります（たとえば、通常の送金シナリオでは取引手数料が倍増することがあり、Dappsの互換性に大きく依存しています）。
その結果、これまでにイーサリアムのメインネットワークで広く普及していません。コストはユーザーにとって最も重要な要素であり、それを削減する必要があります。GASのコストを実際に下げるには、イーサリアム自体がソフトフォークのアップグレードが必要で、GASの計算を変更したり、オペコードのGAS消費を変更する必要があります。ソフトフォークが必要とされる状況を考えると、直接EIP-7702を検討するのはどうでしょうか？
4. EIP-7702の包括的な分析
4.1 EIP-7702とは何ですか
新しいトランザクションタイプによって特徴付けられており、これによりEOAは1つのトランザクションで一時的にスマートコントラクトの機能を持つことができ、これによりバッチトランザクション、ガスフリートランザクション、およびビジネスでのカスタマイズされた許可管理をサポートし、新しいEVMオペコードを導入する必要がなくなります（将来の互換性に影響を与える）。
ユーザーは、スマートコントラクトを展開せずに、AAのほとんどの機能を取得でき、第三者にユーザーの代わりに取引を開始する機能さえ提供できます。ユーザーは秘密鍵を提供する必要はありませんが、認可された情報に署名する必要があります。
4.2 データ構造
彼は新しいトランザクションタイプ0x04を定義しました。このトランザクションタイプのTransactionPayloadは、次の内容のRLPエンコードシリアル化結果です。
rlp([
chain_id、// リプレイ攻撃を防ぐために使用されるチェーンID。
nonce、// トランザクションの一意性を確保するためのトランザクションカウンター。
max_priority_fee_per_gas, //1559 トランザクション料金
max_fee_per_gas, //1559 トランザクション手数料
ガスリミット,
宛先,// トランザクションの対象アドレス
値,
データ,
access_list, //アクセスリスト、EIP-2929でのガス最適化に使用されます。
認可リスト,
signature_y_parity、// 3つの署名パラメータ、トランザクション署名を検証するために使用されます。
signature_r,
署名_s
])
重要なのは、authorization_listオブジェクトが追加され、署名者が自分のEOAで実行したいコードを格納することです。ユーザーがトランザクションに署名すると、実行する契約コードにも署名します。これは、複数の操作情報を一括で格納できることを示す2次元リストとして存在します。一括操作を実行します。
authorization_list = [[chain_id, address, nonce, y_parity, r, s], …]
4.3 トランザクションライフサイクル
4.3.1 バリデーションフェーズ
トランザクション実行フェーズの開始時に、それぞれの[chain_id, address, nonce, y_parity, r, s]tuple in the認証リスト:
使用するecrecover署名から署名者のアドレスを取得する機能(r, s)Ethereumの既存のメカニズムを使用していることに注意してください。したがって、このEIPによって署名アルゴリズムは変更されません。アドレスは次のように回復されます:authority = ecrecover(keccak(MAGIC || rlp([chain_id, address, nonce])), y_parity, r, s)これは、これが似ているようにからアドレスは署名から派生していますが、特定のリスト署名に適用されます。
異なるチェーンでのリプレイ攻撃を防ぐために、チェーンIDを確認してください。
チェックしてください権威サイン者のコードが空であるか、または委任されています（トランザクションが有効なEIP-7702トランザクションであるかどうか、実行を処理する委任メカニズムが扱っているかを確認するため）。
Verify the 権威署名者のナンスは、署名に対するリプレイ攻撃を防ぐためのものです。
設定権限署名者のコード0xef0100 || アドレス（EIP-3607 衝突防止戦略をバイパスするために）
インクリメント ザ権威署名者のノンス（ローカル署名リプレイを防ぐため）
Add the 権威サイン者のアカウントをアクセスリストに追加する（ホットストレージに移行して、アクセスのガスコストを削減する）。
4.3.2 実行フェーズ
契約コードと運用指示はどこで実行されますか？
新しいバージョンでは、契約コードの展開方法が変更されます。アカウントコードを直接設定する代わりに、からコードを取得します。認可リストアドレスを設定して、アカウントコードとして設定します。
許可されたコードを実行する際は、指定されたアドレスからコードを読み込んでください認可リストそして、サイン者のアカウントのコンテキストで実行します。つまり、ユーザーの契約コードは、トランザクションに直接含まれているのではなく、ブロックチェーン上の特定のアドレスに保存されています。
操作手順および関連パラメータはに保存されていますデータトランザクションペイロードのフィールド。
4.4 EIP-7702の価値は何ですか？
EIP-7702は、Web3ウォレットの取引プロセス全体を根本的に変え、ユーザーエクスペリエンスを劇的に変革するため、重要な価値をもたらします。EOA（外部所有アカウント）によって開始された通常の取引は、バッチ転送などのスマートコントラクトの実行と同様に複数のロジックを実行できるようになりました。これはCeFiシナリオにも影響し、引き出しや統合のための取引識別と手数料に影響を与えます。
EIP-7702は多くの長年の仮定を破っています。そのアカウント残高は、そのアカウントから発信される取引によってのみ減少する可能性があるという不変条件を破ります。EOA nonceが取引の実行が開始された後に1増加するという不変条件も破ります（今では複数の値が同時に増加することがあります）。比較に依存する保護ロジックを破りますtx.originそしてmsg.sender,多くの既存の契約に潜在的なリスクをもたらす可能性があります。 EOA自体がイベントを発行することができないという事実も破られており、これは特定のオンチェーンイベントの識別と監視に影響を与える可能性があります。 最後に、EOAアドレスが常にERC20、721、1155、およびその他のアセットを正常に受け取るという前提が破られます（コールバックメカニズムによる失敗の可能性があるため）。
EIP-7702とEIP-4337の比較4.5
1.EIP-7702の利点
EIP-7702にはいくつかの利点があります。1つは、エントリーポイントモジュールを経由する必要がないため、ガスコストが低くなり、オンチェーンの操作が削減されます。もう1つは、事前にオンチェーン契約を展開する必要がないため、ユーザーの移行コストが低くなります。
EIP-4337に比べて、EIP-7702は委任されたコード実行をサポートし、2種類の委任も提供します:
フルデリゲーション：これは、特定のアドレスに対して特定の操作の完全な管理権限を委任することを意味します。例えば、ユーザーはすべてのERC-20トークンの管理をスマートコントラクトアドレスに委任し、契約によってユーザーの代わりに関連するすべての操作を実行させることができます。
保護された委任：これには、委任中に制限と保護を追加して、委任された操作のセキュリティと制御可能性を確保することが含まれます。例えば、ユーザーはERC-20トークンの部分的な管理権利のみをスマートコントラクトに委任したり、条件を設定したりすることができます（例：1日あたりの残高の最大1％を支出する）。
2.EIP-7702の欠点
EIP-7702の主な欠点は、ソフトフォークアップグレードを必要とし、コミュニティの合意が前進するために必要となることです。その変更は実質的であり、オンチェーンエコシステムに広範な影響を与える可能性があります。シシ・ジュンによる初期評価に基づくと、いくつかの課題が特定されていますが、これらの課題は市場機会を表す可能性もあります。
高い自由度は監査を困難にし、ユーザーはセキュリティ保護を確実にするためにより信頼性の高いウォレットを要求しています。
元のアーキテクチャの変更は重要です。異なるトランザクションの種類を区別することができますが、特に不変のオンチェーン契約など、多くの基盤インフラストラクチャは直接互換性がないかもしれません。
EIP-7702はEOAアドレスに契約機能を提供しますが、対応するストレージスペースは保持されません。
個々の取引のコストがわずかに高くなっています。これは Calldata セクションの大幅な増加によるものです。呼び出しの見積もり総コストは 16 (ガス) になります。15 (バイト) = 240 (ガス)のcalldataコストに加えて、EIP-3860のコストは2です15 = 30、および実行コストは約150です。したがって、操作がないアカウントを準備しても、ガスコストが約500増加します。
「受信者が受信機能を欠いたコードに署名した場合、送信者は資産を送信しようとする際にDoSに直面する可能性があります。」ケースを参照してください。この問題は、EOA Aが行うべきでないこと、つまり正しく実装されていない（欠落している）再生可能なファイルに署名したときに発生します。receive()).
オンチェーンの統合と引き出しの論理は一貫していないかもしれません。たとえば、ERC-20トークンを転送する際、受信者のアカウントにコードがある場合、トークン契約が呼び出されます。onERC20Received受信者アカウントに。 もしonERC20Received不正な値を戻すか返すと、トークンの転送が元に戻ります。
また、EOAがイベントを発行できる場合、問題はありますか？一部のインフラストラクチャはこれに注意を払う必要があります。
これらは、現行のEIP-7702提案および公式フォーラムでの議論に基づいて、Shisi Junがまとめた不利な点の一部に過ぎません。完全な分析には、最終的な実装コードの検討が必要です。
5. サマリー
この記事は広範囲に見えるかもしれませんが、約6,000語しか含まれていません。過去のEIP解釈への多くの参照がテキスト内にリンクされており、さらなる探求のためにはそちらを参照してください。
現時点では、アカウントの抽象化は、すべてを前に押し進める前の最終段階である第六モジュールにしか配置できないようです。EIP-7702の急速な進展は、主にシステムセキュリティへの課題をもたらしています。最終的には実装されると予想されます。何しろ、コンセンサスアルゴリズムの大規模な改修を伴うEthereumのマージはすでに起こっています。新しいトランザクションタイプは比較的小規模です。
ただし、今回の変更はかなりの破壊力があり、これまでの多くの「不可能」とされていたオンチェーンのルールを破り、ほとんどのDAppsのロジックを変更しています。しかし、EIP-7702は最も重要なポイントをしっかりと把握しています：ユーザーコストを大幅に削減しています。一方、EIP-4337はトランザクションコストをほぼ倍増させています。
ユーザーは、必要に応じてCA（Contract Account）ロジックを呼び出して使用しますが、EOA（Externally Owned Account）アドレスのままです。これにより保有コストが削減されます。アクションを実行する前にオンチェーンのCAアイデンティティに変換する必要はないため、ユーザーは登録する必要がありません。
ユーザーは、自分のEOAを使用して複数のトランザクションを並行して簡単に実行することができ、これによりユーザーのトランザクションコストが本質的に低下します。DAppsにとって、特に取引所などのオンチェーンの企業レベルの管理を必要とするプロジェクトでは、この最適化が革命的です。バッチの統合がネイティブで実装されれば、取引所の基本的な運用コストが半分以上削減され、最終的にはユーザーにも恩恵が及びます。
そのため、EIP-7702は多くの変更を導入していますが、単独のコストへの影響だけで、すべてのDAppsのために研究し、適応する価値があります。今回、ユーザーは間違いなくEIP-7702の側にいます。
免責事項：
相关文章
Polygon 2.0 (POL)とは? MATICからPOLへ
ガスレス取引とは?
ラップイーサリアム(WETH)とは何ですか?
イーサリアムの過去と未来におけるアカウント抽象化の徹底分析
前書き
記事は主に2つのセクションに分かれています:
最初の部分では、2015年の最初のAA提案から始まり、現在までのEIP提案の主な内容を体系的に整理します。AA提案の歴史的な発展を探求し、各提案の長所と短所を包括的に評価することを目指しています。
第2部では、EIP-4337導入後の市場フィードバックの比較に焦点を当て、次回のEthereumアップグレードに含まれる予定のEIP-7702の分析に入ります。この提案がマージされると、オンチェーンアプリケーションの性質が大幅に変化することが期待されています。
EIP-7702は革命的な変化を約束しており、詳細について議論します。
1. アカウント抽象化の背景
1.1 アカウント抽象化の意味
2023年末、イーサリアム創設者のVitalik Buterinが再びETH開発ロードマップを更新しました。ただし、口座抽象化に関連する規定は変更されていません。現行の主流モデルは引き続きEIP-4337から次の段階、自発的EOAコンバージョン（自己イニシエーション型のEOAアカウント変換）に進化しています。
https://x.com/VitalikButerin/status/1741190491578810445
EIP-4337が1年以上前にリリースされて以来（2023年3月1日、デンバーのWalletConで、Ethereum Foundationの開発者はERC-4337のコア契約がOpenZeppelinの監査に合格したことを発表し、公式のローンチの歴史的なマイルストーンを示した）、広範なユーザーからの認知を得ているが、広く普及していない。この逆説的な市場環境は、次のアップグレードに含まれることが確認されたEIP-7702の進捗を加速させています。
1.2 アカウント抽象化の現在の市場状況
さて、データを見てみましょう。
開発から1年半が経過したEIP-4337は、主要なチェーンアカウントでわずか1200万のアドレスしか集められていません。特に驚くべきことは、Ethereumメインネットワーク上にはわずか6,764のアクティブなアドレスしかないことです。統計的な側面に問題があるかもしれませんが、この数値は依然としてEOAとCAのアドレス数とは大きく異なります。なお、Ethereumメインネットワーク上のユニークなアドレス数は2億7000万に達しています（出典: https://etherscan.io/chart/address).
メインネットでは、EIP-4337は実質的な進展を遂げていないと言えます。
(チャートソース：https://dune.com/niftytable/account-abstraction)
ただし、これにより、Account Abstraction（AA）の固有の価値が低下するわけではありません。最初から、EIP-4337の設計は、メインネットでの重要な後方互換性の問題に直面する運命でした。その結果、さまざまなLayer 2チェーンがネイティブAAを統合する中で、EIP-4337はLayer 2のアドレス数において急成長を遂げています。たとえば、7月には、BaseとPolygonチェーンのアクティブユーザー数がそれぞれ100万人と300万人に達し、非常に印象的です。
したがって、EIP-4337の設計に問題があるわけではありません。多くの利点があり、それらを体系的にまとめます。現在の状況は、メインネットとレイヤー2の間の違いから生じており、それぞれに合わせた解決策が必要です。
2. アカウント抽象とは何ですか？
アカウント抽象化は複雑に聞こえるかもしれませんが、基本的には所有権の分離の問題に対処しています。
イーサリアム仮想マシン（EVM）アーキテクチャでは、Externally Owned Accounts（EOAs）とContract Accountsの2種類のアカウントがあります。 EOAsでは、所有権と署名権限が同じエンティティによって保持されます。 私鍵を持つ人物は、口座の所有者であるだけでなく、すべての資産に署名して転送する権利も持っています。
このセットアップは、イーサリアムのアカウントトランザクション構造によって決まります。標準のイーサリアムトランザクションでは、直接的な「From」アドレスは見えません。資金の送金が発生すると、資金が支出された実際のアドレスはVRSパラメーター（つまり、ユーザーの署名）を介して推測されます。
これには、ECDSA非対称暗号化や一方向閾値関数などの概念が関わっていますが、ここではそれらの詳細には立ち入りません。基本的に、暗号化はセキュリティを確保し、それが所有権と署名権限がEOAで結合された現在の状況につながります。
EIP-4337の主要な効果は、取引に送信者アドレスフィールドを追加し、秘密キーと操作されるアドレスを分離することです。
だから所有権を分離することがなぜ重要なのですか？
Externally Owned Accounts（EOAs）の設計によっていくつかの問題が引き起こされるため：
プライベートキーの保護: プライベートキーを失うと（紛失、ハッキング、または暗号の侵害による）、すべての資産を失うことになります。
限られた署名アルゴリズム**：ネイティブプロトコルは、署名と検証に対してECDSAのみをサポートしています。
ハイシグネチャ権限：ネイティブなマルチシグネチャのサポートがないため（これはスマートコントラクトを介してのみ達成できます）、単一の署名で任意の操作を実行できます。
トランザクション手数料：手数料はETHのみで支払うことができ、高い取引量をサポートしていません。
トランザクションプライバシー：1対1の取引は、口座所有者の個人情報を分析しやすくします。
これらの制約は、一般ユーザーがイーサリアムを利用するのを難しくしています。
イーサリアム上の任意のアプリケーションを使用するには、ユーザーはETHを保持している必要があります（そしてETH価格の変動リスクを負わなければなりません）。
ユーザーは、ガス価格、ガスリミット、およびトランザクションブロッキング（ノンスオーダー）など、複雑な手数料ロジックに対処する必要があり、これはあまりにも複雑である可能性があります。
多くのブロックチェーンウォレットやアプリケーションは、製品の最適化を通じてユーザーエクスペリエンスを向上しようとしていますが、その効果は限定されています。
解決策は、これらの問題に対処するために所有権（所有者）と署名権限（署名者）を切り離すアカウント抽象化を実装することにあります。歴史的には、多くの解決策が現れ、最終的には2つの主要なアプローチに収束してきました。
3. アカウント抽象化提案の歴史的概要
多くの問題に対処するEIP提案があるように見えるかもしれませんが、基本的には2つの核心的なアプローチしかありません。過去の提案で検討された問題は、最終的に現在の解決策に収束しました。
3.1最初のルートは、EOAアドレスをCAアドレスに変換することです
2015年11月15日、Vitalik ButerinはEIP-101を中心とする新しいアカウント構造を提案しました。これには契約をアカウントとして使用することが含まれました。これにより、アドレスがコードとストレージスペースのみを持つエンティティに変換され、手数料サポートがERC20トークン経由で支払われるようになり、ネイティブトークンをERC20のようなトークンに変換するためにプリコンパイルされた契約が使用され、残高の保存（委任された認可などの機能を備える）に使用されました。トランザクションフィールドは、to、startgas、data、codeのみを含むように簡略化されました。
結果論的には、これは革命的な変化であり、基本的な設計を劇的に変更し、それぞれの口座アドレスに独自の「コード」ロジックを与えることになります。これは実質的にEIP-7702が今日達成しようとしているものです。このアプローチは、追加の機能を可能にする可能性もあります:
内部コードで指定された各アドレスの検証と認証に使用する暗号アルゴリズムをより多くの取引に許可する。
コードのアップグレード可能性による量子耐性の提供。
ERC20契約と同じ機能的特性を持つようにEtherに賦与し、委任された承認などの機能を備え、ネイティブコインの支出の必要性を排除します。
アカウントのカスタマイズを強化し、ソーシャルリカバリー、SBT（ソウルバウンドトークン）、キーリカバリーをサポートします。
この提案を前に進めなかった理由は単純でした：手順があまりにも野心的でした。トランザクションハッシュの衝突やセキュリティ上の懸念などの問題が完全に解決されていなかったため、延期されました。しかし、その多くの利点は、後続のEIP（EIP-4337やEIP-7702を含む）の中核的な機能となっています。
いくつかのEIPは後にこのロジックを磨こうと試みました。
EIP-859: Account Abstraction on Mainnet (January 30, 2018) aimed to address code deployment issues. Its core function was to use the コードトランザクションにアタッチされるパラメーターは、契約ウォレットを展開するためのものであり、契約が展開されていない場合に使用されます。また、新しいPAYGASオペコードが導入され、トランザクションの検証部分と実行部分が分離されました。
当時進展しなかったものの、この論理は、特別なトランザクション構造を介してコードを含めることができるEOAアドレスに契約機能を持たせるEIP-7702の中核的なコンポーネントとなりました。
EIP-7702：EOAアカウントコードの設定（2024年5月7日）は、ここで議論されている重要なEIPです。 VitalikはEIP-3074の代替案としてEIP-7702を提案しました。その結果、EIP-3074は廃止され、EIP-7702は近日公開予定のETH Prague/Electra（Pectra）ハードフォークに含まれる予定です。詳細は以下で議論されます。
3.2 第二のアプローチは、EOAアドレスがCAアドレスをドライブするようにすることです。
EIP-3074: AUTHおよびAUTHCALLオペコードの追加（2020年10月15日）
このEIPは、EOAが契約に自分のアイデンティティを置き換え、他の契約を呼び出すことを許可する、AUTHおよびAUTHCALLという2つの新しいオプコードをEVMに導入します。基本的に、EOAは信頼できる契約（Invokerと呼ばれる）に署名されたメッセージ（トランザクション）を送信できます。Invoker契約はその後、AUTHおよびAUTHCALLオプコードを使用して、EOAの代わりにトランザクションを送信できます。
EIP-4337: 2021年9月29日にトランザクションプールを介したアカウント抽象化の実装
MEVに触発されたこのEIPのコアバリューは、コンセンサスレイヤープロトコルへの変更を回避することです。EIP-4337 では、ユーザーがメモリプールに送信する新しいトランザクションオブジェクト UserOperation が導入されています。その後、バンドラーはこれらのトランザクションをバッチ処理して契約実行に配信し、下位レベルのトランザクションとアカウント操作を契約レイヤーに効果的に移行します。
EIP-5189: 抽象アカウント操作エンドーサーを介して (2022年6月29日)
このEIPは、悪意のあるバンドラーに関する潜在的な問題に対処することで、EIP-4337を最適化しています。エンドーサー支援ファンドのメカニズムを導入して、悪意のある行為者を罰することでDoS攻撃を防ぐ仕組みを導入しています。
3.3 他のアカウント抽象化をサポートする提案
EIP-2718: 新しいトランザクションタイプエンベロープ（2020年6月13日）
この最終的な提案は、将来の取引タイプの封筒として新しい取引タイプを定義します。新しい取引タイプが導入される際に、特定のエンコーディングによって区別されることを保証し、レガシータイプに影響を与えることなく後方互換性を維持します。一般的な例として、EIP-1559は、新しい取引タイプのエンコーディングで取引手数料を区別し、レガシータイプを保存しました。
EIP-3607: EOAアドレスから契約の展開を防止（2021年6月10日）
この補足提案は、契約の展開アドレスがEOAアドレスと競合する問題に対処しています。契約の作成方法を制御し、コードがEOAによって既に使用されているアドレスに展開されるのを防ぎます。イーサリアムアドレスの160ビットの長さを考えると、リスクは最小限ですが、理論的にはキーの衝突を通じて可能ですが、それにはかなりの計算コストが必要です。
3.4 アカウント抽象化の開発の理解
CAアドレスへの移行の価値を理解するには、EIP-4337の実用的な効果を把握することが不可欠です。
しかし、EIP-4337の中核的な欠点は、人間のインセンティブの原則に違反していることです。改善を提供するように見えるが、市場開発の行き詰まりに陥ってしまいます。多くのDappsはまだそれと互換性がないため、ユーザーはCAアドレスを使用することをためらっています。さらに、CAを使用することで、取引コストが高くなる可能性があります（たとえば、通常の送金シナリオでは取引手数料が倍増することがあり、Dappsの互換性に大きく依存しています）。
その結果、これまでにイーサリアムのメインネットワークで広く普及していません。コストはユーザーにとって最も重要な要素であり、それを削減する必要があります。GASのコストを実際に下げるには、イーサリアム自体がソフトフォークのアップグレードが必要で、GASの計算を変更したり、オペコードのGAS消費を変更する必要があります。ソフトフォークが必要とされる状況を考えると、直接EIP-7702を検討するのはどうでしょうか？
4. EIP-7702の包括的な分析
4.1 EIP-7702とは何ですか
新しいトランザクションタイプによって特徴付けられており、これによりEOAは1つのトランザクションで一時的にスマートコントラクトの機能を持つことができ、これによりバッチトランザクション、ガスフリートランザクション、およびビジネスでのカスタマイズされた許可管理をサポートし、新しいEVMオペコードを導入する必要がなくなります（将来の互換性に影響を与える）。
ユーザーは、スマートコントラクトを展開せずに、AAのほとんどの機能を取得でき、第三者にユーザーの代わりに取引を開始する機能さえ提供できます。ユーザーは秘密鍵を提供する必要はありませんが、認可された情報に署名する必要があります。
4.2 データ構造
彼は新しいトランザクションタイプ0x04を定義しました。このトランザクションタイプのTransactionPayloadは、次の内容のRLPエンコードシリアル化結果です。
rlp([
chain_id、// リプレイ攻撃を防ぐために使用されるチェーンID。
nonce、// トランザクションの一意性を確保するためのトランザクションカウンター。
max_priority_fee_per_gas, //1559 トランザクション料金
max_fee_per_gas, //1559 トランザクション手数料
ガスリミット,
宛先,// トランザクションの対象アドレス
値,
データ,
access_list, //アクセスリスト、EIP-2929でのガス最適化に使用されます。
認可リスト,
signature_y_parity、// 3つの署名パラメータ、トランザクション署名を検証するために使用されます。
signature_r,
署名_s
])
重要なのは、authorization_listオブジェクトが追加され、署名者が自分のEOAで実行したいコードを格納することです。ユーザーがトランザクションに署名すると、実行する契約コードにも署名します。これは、複数の操作情報を一括で格納できることを示す2次元リストとして存在します。一括操作を実行します。
authorization_list = [[chain_id, address, nonce, y_parity, r, s], …]
4.3 トランザクションライフサイクル
4.3.1 バリデーションフェーズ
トランザクション実行フェーズの開始時に、それぞれの[chain_id, address, nonce, y_parity, r, s]tuple in the認証リスト:
使用するecrecover署名から署名者のアドレスを取得する機能(r, s)Ethereumの既存のメカニズムを使用していることに注意してください。したがって、このEIPによって署名アルゴリズムは変更されません。アドレスは次のように回復されます:authority = ecrecover(keccak(MAGIC || rlp([chain_id, address, nonce])), y_parity, r, s)これは、これが似ているようにからアドレスは署名から派生していますが、特定のリスト署名に適用されます。
異なるチェーンでのリプレイ攻撃を防ぐために、チェーンIDを確認してください。
チェックしてください権威サイン者のコードが空であるか、または委任されています（トランザクションが有効なEIP-7702トランザクションであるかどうか、実行を処理する委任メカニズムが扱っているかを確認するため）。
Verify the 権威署名者のナンスは、署名に対するリプレイ攻撃を防ぐためのものです。
設定権限署名者のコード0xef0100 || アドレス（EIP-3607 衝突防止戦略をバイパスするために）
インクリメント ザ権威署名者のノンス（ローカル署名リプレイを防ぐため）
Add the 権威サイン者のアカウントをアクセスリストに追加する（ホットストレージに移行して、アクセスのガスコストを削減する）。
4.3.2 実行フェーズ
契約コードと運用指示はどこで実行されますか？
新しいバージョンでは、契約コードの展開方法が変更されます。アカウントコードを直接設定する代わりに、からコードを取得します。認可リストアドレスを設定して、アカウントコードとして設定します。
許可されたコードを実行する際は、指定されたアドレスからコードを読み込んでください認可リストそして、サイン者のアカウントのコンテキストで実行します。つまり、ユーザーの契約コードは、トランザクションに直接含まれているのではなく、ブロックチェーン上の特定のアドレスに保存されています。
操作手順および関連パラメータはに保存されていますデータトランザクションペイロードのフィールド。
4.4 EIP-7702の価値は何ですか？
EIP-7702は、Web3ウォレットの取引プロセス全体を根本的に変え、ユーザーエクスペリエンスを劇的に変革するため、重要な価値をもたらします。EOA（外部所有アカウント）によって開始された通常の取引は、バッチ転送などのスマートコントラクトの実行と同様に複数のロジックを実行できるようになりました。これはCeFiシナリオにも影響し、引き出しや統合のための取引識別と手数料に影響を与えます。
EIP-7702は多くの長年の仮定を破っています。そのアカウント残高は、そのアカウントから発信される取引によってのみ減少する可能性があるという不変条件を破ります。EOA nonceが取引の実行が開始された後に1増加するという不変条件も破ります（今では複数の値が同時に増加することがあります）。比較に依存する保護ロジックを破りますtx.originそしてmsg.sender,多くの既存の契約に潜在的なリスクをもたらす可能性があります。 EOA自体がイベントを発行することができないという事実も破られており、これは特定のオンチェーンイベントの識別と監視に影響を与える可能性があります。 最後に、EOAアドレスが常にERC20、721、1155、およびその他のアセットを正常に受け取るという前提が破られます（コールバックメカニズムによる失敗の可能性があるため）。
EIP-7702とEIP-4337の比較4.5
1.EIP-7702の利点
EIP-7702にはいくつかの利点があります。1つは、エントリーポイントモジュールを経由する必要がないため、ガスコストが低くなり、オンチェーンの操作が削減されます。もう1つは、事前にオンチェーン契約を展開する必要がないため、ユーザーの移行コストが低くなります。
EIP-4337に比べて、EIP-7702は委任されたコード実行をサポートし、2種類の委任も提供します:
フルデリゲーション：これは、特定のアドレスに対して特定の操作の完全な管理権限を委任することを意味します。例えば、ユーザーはすべてのERC-20トークンの管理をスマートコントラクトアドレスに委任し、契約によってユーザーの代わりに関連するすべての操作を実行させることができます。
保護された委任：これには、委任中に制限と保護を追加して、委任された操作のセキュリティと制御可能性を確保することが含まれます。例えば、ユーザーはERC-20トークンの部分的な管理権利のみをスマートコントラクトに委任したり、条件を設定したりすることができます（例：1日あたりの残高の最大1％を支出する）。
2.EIP-7702の欠点
EIP-7702の主な欠点は、ソフトフォークアップグレードを必要とし、コミュニティの合意が前進するために必要となることです。その変更は実質的であり、オンチェーンエコシステムに広範な影響を与える可能性があります。シシ・ジュンによる初期評価に基づくと、いくつかの課題が特定されていますが、これらの課題は市場機会を表す可能性もあります。
高い自由度は監査を困難にし、ユーザーはセキュリティ保護を確実にするためにより信頼性の高いウォレットを要求しています。
元のアーキテクチャの変更は重要です。異なるトランザクションの種類を区別することができますが、特に不変のオンチェーン契約など、多くの基盤インフラストラクチャは直接互換性がないかもしれません。
EIP-7702はEOAアドレスに契約機能を提供しますが、対応するストレージスペースは保持されません。
個々の取引のコストがわずかに高くなっています。これは Calldata セクションの大幅な増加によるものです。呼び出しの見積もり総コストは 16 (ガス) になります。15 (バイト) = 240 (ガス)のcalldataコストに加えて、EIP-3860のコストは2です15 = 30、および実行コストは約150です。したがって、操作がないアカウントを準備しても、ガスコストが約500増加します。
「受信者が受信機能を欠いたコードに署名した場合、送信者は資産を送信しようとする際にDoSに直面する可能性があります。」ケースを参照してください。この問題は、EOA Aが行うべきでないこと、つまり正しく実装されていない（欠落している）再生可能なファイルに署名したときに発生します。receive()).
オンチェーンの統合と引き出しの論理は一貫していないかもしれません。たとえば、ERC-20トークンを転送する際、受信者のアカウントにコードがある場合、トークン契約が呼び出されます。onERC20Received受信者アカウントに。 もしonERC20Received不正な値を戻すか返すと、トークンの転送が元に戻ります。
また、EOAがイベントを発行できる場合、問題はありますか？一部のインフラストラクチャはこれに注意を払う必要があります。
これらは、現行のEIP-7702提案および公式フォーラムでの議論に基づいて、Shisi Junがまとめた不利な点の一部に過ぎません。完全な分析には、最終的な実装コードの検討が必要です。
5. サマリー
この記事は広範囲に見えるかもしれませんが、約6,000語しか含まれていません。過去のEIP解釈への多くの参照がテキスト内にリンクされており、さらなる探求のためにはそちらを参照してください。
現時点では、アカウントの抽象化は、すべてを前に押し進める前の最終段階である第六モジュールにしか配置できないようです。EIP-7702の急速な進展は、主にシステムセキュリティへの課題をもたらしています。最終的には実装されると予想されます。何しろ、コンセンサスアルゴリズムの大規模な改修を伴うEthereumのマージはすでに起こっています。新しいトランザクションタイプは比較的小規模です。
ただし、今回の変更はかなりの破壊力があり、これまでの多くの「不可能」とされていたオンチェーンのルールを破り、ほとんどのDAppsのロジックを変更しています。しかし、EIP-7702は最も重要なポイントをしっかりと把握しています：ユーザーコストを大幅に削減しています。一方、EIP-4337はトランザクションコストをほぼ倍増させています。
ユーザーは、必要に応じてCA（Contract Account）ロジックを呼び出して使用しますが、EOA（Externally Owned Account）アドレスのままです。これにより保有コストが削減されます。アクションを実行する前にオンチェーンのCAアイデンティティに変換する必要はないため、ユーザーは登録する必要がありません。
ユーザーは、自分のEOAを使用して複数のトランザクションを並行して簡単に実行することができ、これによりユーザーのトランザクションコストが本質的に低下します。DAppsにとって、特に取引所などのオンチェーンの企業レベルの管理を必要とするプロジェクトでは、この最適化が革命的です。バッチの統合がネイティブで実装されれば、取引所の基本的な運用コストが半分以上削減され、最終的にはユーザーにも恩恵が及びます。
そのため、EIP-7702は多くの変更を導入していますが、単独のコストへの影響だけで、すべてのDAppsのために研究し、適応する価値があります。今回、ユーザーは間違いなくEIP-7702の側にいます。
免責事項：
相关文章
Polygon 2.0 (POL)とは? MATICからPOLへ
ガスレス取引とは?