4337から7702へ：イーサリアムアカウント抽象化トラックの過去と未来を深く解読する

著者：十四君

前言

この記事は全体で二つの大きなモジュールに分かれています：

上半分では、2015年からの最初のAA提案に基づき、これまでのEIP提案の主要内容を体系的に整理し、歴史的な提案の経緯を掘り下げ、各提案の長所と短所を総合的に評価することを期待しています。

下半分では、EIP4337が提案された後に直面した市場の低迷に対するフィードバックを重点的に比較し、次のバージョンのイーサリアムアップグレードに組み込まれるEIP7702をさらに深く分析します。この提案が統合されると、オンチェーンアプリケーションの形態が全方位的に変わります。

EIP-7702は画期的な変化をもたらします。十四君が詳しくお話しします。

1、アカウント抽象化の背景

1.1 アカウント抽象化の意義

イーサリアムの創設者であるVitalikは、2023年末に再度ETHの発展ロードマップを更新しましたが、アカウント抽象化に関する設定は変更されていません。現在の主流モデルはEIP-4337から始まり、次の段階であるVoluntaryEOA Conversion（自発的EOAアカウントへの変換）に進んでいます。

https://x.com/VitalikButerin/status/1741190491578810445

EIP4337が導入されてから1年以上が経過しました（2023年3月1日のデンバーのWalletConで、イーサリアム財団の開発者によって設計されたERC-4337のコア契約がOpenZeppelinの監査を通過し、正式にリリースされた歴史的な節目と見なされています）。

ユーザーからの広範な認知を得ているものの、広く使用されていないという矛盾した市場環境が、EIP-7702の進捗を大幅に前倒しさせ、次回のアップグレードに統合されることが確認されています。

1.2 アカウント抽象化の市場現状

多くを語る必要はありません、データを見てみましょう。

1年半の発展を経て、EIP4337は主流チェーンアカウントの集合の下で、わずか1200万のアドレス数を持っています。その中で最も驚くべきは、イーサリアムメインネット上でのアクティブアドレスがわずか6,764個であることです。統計の次元に問題があるかもしれませんが、少なくともEOAとCAのアドレス数には大きな差があります。イーサリアムメインネット上の独立アドレス数はすでに2億7千万に達しています（データソース：https://etherscan.io/chart/address）。

言うまでもなく、EIP4337はメインネット上で実質的な発展を遂げていません。

（グラフデータソース：https://dune.com/niftytable/account-abstraction）

しかし、これはAAの本質的な価値を損なうものではありません。なぜなら、EIP4337の設計は最初から、メインネットの深刻な後方互換性の問題に対処できないことが運命づけられていたからです。そのため、さまざまなL2層チェーンの普遍的な埋め込みとともに、EIP4337のアドレス数はL2上で爆発的に増加しました。7月の月間アクティブユーザーはそれぞれ100万と300万であり、かなりのものです。

したがって、EIP4337の設計が間違っていたわけではなく、多くの利点があります。後ほど体系的にまとめますが、現在の状況はメインネットとL2の間の差異に起因しています。彼らはそれぞれに適した解決策を必要としています。

2、アカウント抽象化とは？

アカウント抽象化は、一見難解に聞こえますが、実際には所有権の分離の問題を根本的に解決しています。

EVMアーキテクチャ（イーサリアム仮想マシン）には、外部アカウント（EOA）と契約アカウント（Contract Account）の2種類のアカウントがあります。外部アカウントの所有権と署名権は、実際には同一の主体が持っています。秘密鍵を持つ人は、このアカウントの「所有権」を持つだけでなく、「すべての資産を移転する権利」も持っています。

これはイーサリアムのアカウント取引構造によって決まっています。

下の図の構造からわかるように、イーサリアムの標準取引にはFrom側が存在しません。したがって、資金を転送した場合、具体的にどのアドレスの資金が消費されたのか？実際には、そのVRSパラメータ（ユーザー署名）を通じてFromアドレスを逆解析することによって明らかになります。

ここにはECDSAなどの非対称暗号、単方向閾値関数などの概念が関与していますが、詳細には立ち入らず、要するにここでは暗号学が安全性を保証しています。当然、これが現在の所有権が統合されたEOAアドレスの窮地を引き起こしています。

EIP4337の核心的な効果は、取引フィールドにSender Addressフィールドを追加することで、秘密鍵と操作されるアドレスを分離できるようにすることです。

では、なぜ所有権の分離がそんなに重要なのでしょうか？

外部アカウント（EOA）の設計は、より多くの問題を引き起こすことになります：

1. 秘密鍵の保護が難しい：ユーザーが秘密鍵を失う（紛失、ハッキング、暗号学的に破られる）と、すべての資産を失うことになります。

2. 署名アルゴリズムが少ない：ネイティブプロトコルでは、取引の検証にECDSA署名と検証アルゴリズムしか使用できません。

3. 署名権限が高い：ネイティブのマルチシグ（マルチシグはスマートコントラクトを通じて協力して実現する必要があります）、単一署名であれば任意の操作を実行できます。

4. 取引手数料はETHでのみ支払うことができ、バッチ取引をサポートしていません。

5. 取引のプライバシーが漏洩する：一対一の取引は、アカウント保有者のプライバシー情報を分析しやすくなります。

これらの制約により、一般ユーザーがイーサリアムを使用するのは非常に困難です：

まず、イーサリアム上の任意のアプリケーションを使用するには、ユーザーはイーサを保有し（イーサの価格変動リスクを負う）、さらに複雑な手数料ロジックを処理する必要があります。Gas price、Gas limit、トランザクションブロッキング（Nonceの順序）などの概念は、ユーザーにとって非常に複雑です。

最後に、多くのブロックチェーンウォレットやアプリケーションが製品の最適化を通じてユーザー体験を向上させようとしていますが、その実際の効果は微々たるものです。

したがって、解決策はアカウント抽象化を実現し、所有権（Owner）と署名権（Signer）をデカップリング（分離）することにあります。そうすることで、上記の問題を一つずつ解決できるのです。

実際、歴史的な提案は多くあり、最終的には二つのルートに集約されます。

3、AA歴史提案の脈絡整理

問題の解決策は多くのEIP提案に見えるかもしれませんが、根本的には二つの核心的な考え方に集約されます。過去に通過しなかった各EIPが考慮した問題も、現在の提案の解決策に集約されています。

3.1 第一のルートはEOAアドレスをCAアドレスに変えること

2015年11月15日、EIP-101に関してVitalikはアカウントの新しい構造として契約を提案しました。アドレスをコードとストレージスペースのみのものに変更し、手数料の支払いをERC20に変更し、プリコンパイル契約を通じてネイティブトークンをERC20のような形で残高を保持できるようにしました（代金引き落としの権限などの機能を持つことができます）。取引フィールドをto、startgas、data、codeのみに簡素化しました。

今振り返ると、これはまさに大躍進的な変革であり、基盤設計を大幅に変更し、各アカウントアドレスがそれぞれの「コード」ロジックを持つことを可能にしました（実際、これは現在EIP-7702が達成しようとしている効果でもあります）。

他の機能も派生することができます。例えば：

1. 取引でより多くの暗号アルゴリズムを使用できるようにし、各アドレス内部のコードで検証方法を指定できます。

2. 量子攻撃に対する耐性を持つ特性を持たせることができ、コードにはアップグレード機能があります。

3. イーサリアムがERC20契約と同じ機能特性を持つようにし、コア効果として代金引き落としの権限を持たせることで、ネイティブコインの損失を避けることができます。

4. アカウントのカスタマイズ空間を拡大し、ソーシャルリカバリー、sbtサポート、秘密鍵の回復などに対応します。

進めなかった理由は簡単です。明らかに歩みが大きすぎて、現在の取引ハッシュの衝突問題や安全性の懸念が考慮されていなかったため、ずっと保留されていました。しかし、各利点の理念は、後のEIP4337やEIP7702の核心機能の一つとなりました。

その後、一連のEIPがこのロジックを改善しようとしました。

EIP-859：メインチェーンアカウント抽象化--2018-01-30

コードのデプロイメント問題を解決しようとし、核心的な役割は、取引先の契約が未デプロイの場合、取引に付随するcodeパラメータを使用して契約ウォレットをデプロイすることです。次に、新しいPAYGASオペコードを提案し、ガスを支払うだけでなく、取引のパラメータの検証部分と実行部分の区切りとしても機能します。

当時は無事に終わりましたが、これも現在のEIP7702の核心ロジックの一つとなりました。EIP7702の各取引は特別な取引構造と結びついており、一定のコードを付随させることができ、今回の取引でEOAアドレスに契約能力を持たせることができます。

EIP-7702：EOAアカウントコードの設定 2024-05-07

これもこの記事の後続の議論メカニズムの核心EIPであり、VitalikがEIP-3074の代替案としてEIP-7702を発表しました（2024-05-07）。したがって、EIP-3074は廃止され、EIP-7702は今後のETH Prague/Electra（Pectra）ハードフォークに組み込まれることが決定されました。具体的な内容は後述します。

3.2 第二のルートはEOAアドレスがCAアドレスを駆動すること

EIP-3074：AUTHおよびAUTHCALLオペコードの追加--2020-10-15

EVMに新しい2つのOpCodes AUTHとAUTHCALLを追加し、EOAがこれらのオペコードを通じて契約に代わってEOAのアイデンティティを呼び出すことを可能にします。

下の図を組み合わせて言うと、EOAは自分が信頼する契約（Invokerと呼ばれる）に対して、署名済みのメッセージ（取引）を送信できます。このInvoker契約はAUTHおよびAUTHCALLオペコードを利用して、このEOAの代わりにこの取引を送信することができます。

EIP-4337：取引メモリプールを使用してアカウント抽象化を実現--2021-09-29

この分野については、以前に多くの記事でそのメカニズムを深く分析しており、拡張読書が可能です：

• https://research.web3caff.com/zh/archives/3212、

• イーサリアムアカウント抽象化ERC4337の承認案解読（上）

• 1時間でアカウント抽象化について説明する

要するに、彼はMEVからインスピレーションを受けて設計されており、その核心的な価値は、合意層プロトコルの変更を完全に回避できることです。

eip4337は新しいトランザクションオブジェクトUserOperationを提案し、ユーザーはこのオブジェクトをメモリプールに送信し、バンドラーがマイナーの観点から一括してパッケージ化して契約を実行する取引を提供します。本質的には、基盤の取引とアカウントの運用を契約レベルで実行することを意味します。

EIP-5189：エンドーサーを通じて抽象アカウントを操作する---2022-06-29

これはEIP4337のロジックを最適化したもので、悪意のあるバンドラーに対して資金罰金のエンドーサーを設立するメカニズムを通じて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が単一の取引内で一時的にスマートコントラクトの機能を持つことを許可し、ビジネス上のバッチ取引、無Gas取引、自動権限管理などをサポートします。また、新しいEVM opCodeを導入する必要はありません（前方互換性に影響を与えません）。

これにより、ユーザーはスマートコントラクトをデプロイすることなく、AAの大部分の機能を得ることができ、第三者がユーザーの代わりに取引を開始する能力を提供することも可能です。ユーザーは秘密鍵を提供する必要はなく、署名された承認情報のみで済みます。

4.2 データ構造

新しい取引タイプ0x04を定義し、その取引タイプのTransactionPayloadは以下の内容のRLPエンコードされたシリアライズ結果です。

• rlp([
  chainid, //チェーンID、リプレイ攻撃を防ぐため。 nonce, //取引カウンター、取引の一意性を確保。 maxpriorityfeepergas, //1559取引手数料 maxfeepergas, //1559取引手数料
  gaslimit, destination, //取引対象アドレス value, data, accesslist, //EIP-2929におけるGas最適化のためのアクセスリスト。
  authorizationlist, signatureyparity, //取引署名を検証するための3つの署名パラメータ。 signaturer,
  signature_s
  ])

重要なのは、authorization_listオブジェクトが新たに追加され、署名者がそのEOA内で実行したいコードを格納することです。ユーザーは取引を署名する際に、実行する契約コードも署名します。これは二次元リストとして存在し、複数の操作情報を一括して格納できることを示しています。

• authorizationlist = [[chainid, address, nonce, y_parity, r, s], …]

 

4.3 取引ライフサイクル

4.3.1 検証段階

取引の実行開始段階では、各authorizationlistの[chainid, address, nonce, y_parity, r, s]タプルに対して：

1. 署名r、sからecrecoverを用いて署名者のアドレスを復元します（これはイーサリアム自体のメカニズムであるため、このEIPは署名アルゴリズムを変更していません）。authority = ecrecover(keccak(MAGIC || rlp([chainid, address, nonce])), yparity, r, s]（以前の署名解除で得られたfromアドレスと似ていますが、ここで得られるのはこのリストに対する局所的な署名アドレスです）

2. チェーンIDを検証します（フォークチェーンのリプレイを防ぐため）。

3. authority署名者のコードが空でないか、すでに委任されているかを検証します（取引が有効な7702取引であるかどうかを確認し、後続のdelegationメカニズムを通じて取引を代理実行します）。

4. authority署名者のnonceを検証します（authorityの署名リプレイを防ぐため）。

5. authority署名者のコードを0xef0100 || addressに設定します（EIP3607の防衝突戦略を回避するため）。

6. authority署名者のnonceを増加させます（局所的な署名リプレイを防ぐため）。

7. authority署名者アカウントをアクセス済みアドレスリストに追加します（ホットアドレスに転送し、ストレージのガス費用を削減します）。

4.3.2 実行操作段階

実行する契約コードや操作指令はどこにありますか？

「新しい」バージョンは、コードデプロイメントの行動を変更しました。

もはやアカウントコードをcontractcodeとして設定するのではなく、authorizationlistからコードアドレスを取得し、そのコードをアカウントコードとして設定します。

したがって、承認されたコードを実行する必要がある場合、authorization_listのaddressフィールドで指定されたアドレスからコードをロードし、署名者アカウントのコンテキスト内で実行します。

これは、ユーザーの契約コードが実際にはチェーン上の特定のアドレスに保存されていることを意味し、取引に直接含まれているわけではありません。

操作指令や関連パラメータは、取引ペイロードのdataフィールドに保存されます。

4.4 EIP-7702の価値は？

これはWeb3ウォレットの全体の流れに変化をもたらし、ユーザー体験も大きく変わります。EOAが発起した通常の取引も、契約の実行に似たさまざまなロジックを持つことができ、例えばバッチ転送が可能になります。CeFiシーンでは取引の識別にも影響を与え、手数料の集約にも影響を与えます。

その登場により、多くの以前の慣習が打破されました。例えば：

1. アカウントの残高は、そのアカウントからの取引によってのみ減少するという不変性が打破されました。

2. 取引実行開始後にEOAのnonceが1増加するという不変性が打破されました（同時に複数増加する可能性があります）。

3. tx.originとmsg.senderの二つの比較の防護ロジックが打破され、多くの過去の契約にリスクが生じました。

4. EOA自体がイベントを発信できないという現状が打破され、一部のオンチェーンイベントの識別と監視に注意が必要です。

5. EOAアドレスがERC20、721、1155などの資産を必ず受け取るという現状が打破されました（コールバックメカニズムにより、失敗する可能性があります）。

4.5 EIP-7702とEIP-4337の比較

1. EIP-7702の利点

• ガスが低く、エントリーポイントモジュールを経由しないため、チェーン上の操作が減少します。

• ユーザーの移行コストが低く、事前にチェーン上の契約をデプロイする必要がありません。

• EIP4337と同様に、コードの委任実行があり、二つの方法があります：

完全委任（Full Delegation）

• 完全委任とは、特定のアドレスに対して操作のすべての権限を委任することを指します。例えば、ユーザーはすべてのERC-20トークンの管理権限をスマートコントラクトアドレスに委任し、このスマートコントラクトがユーザーを代表してすべての関連操作を実行できるようにします。

保護された委任（Protected Delegation）

• 保護された委任とは、委任の過程でいくつかの制限や保護措置を追加し、委任操作の安全性と制御性を確保することを指します。

• 例えば、ユーザーは一部のERC-20トークンの管理権限のみをスマートコントラクトに委任したり、1日あたりの総残高の1%を超えないように制限条件を設定したりできます。

1. EIP-7702の欠点

その核心的な欠点はソフトフォークアップグレードに属し、皆の合意を推進する必要があり、変更が巨大で、チェーン上のエコシステムに広範な影響を与えることです。十四君が初歩的に評価したところ、以下のような課題がありますが、課題は市場の機会でもあります：

1. 自由度が非常に高く、監査が難しいため、ユーザーは信頼できるウォレットに安全防護を求めるでしょう。

2. 元のアーキテクチャの変化が大きすぎて、異なる取引タイプで区別されますが、多くの基盤、特にチェーン上の不可変更契約は直接適応できません。

3. EOAアドレスに契約能力を提供しましたが、対応するストレージスペースは保持できません。

4. 単独取引のコストがわずかに増加します。なぜなら、Calldata部分が大幅に増加するため、推定される総コストは16（ガス）* 15（バイト）= 240（ガス）calldataコスト、さらにEIP-3860のコスト2 * 15 = 30、加えて約150の実行時コストがかかります。したがって、アカウントを準備するだけでも、何もせずに500のガスが増加します。

5. "受信者が受信機能のないコードに署名した場合、送信者は資産を送信しようとするとDoSに直面する可能性があります。" 事例を参照してください。この問題は、EOA Aが署名すべきでないもの、すなわち誤った実装（receive()がない）を持つリプレイファイルに署名したことに起因します。

6. チェーン上の送金ロジックが不一致になる可能性があります。例えば、ERC-20トークンを転送する際、受信者アカウントにコードがある場合、トークン契約はonERC20Received受信者アカウントを呼び出します。もしonERC20Receivedが復元または誤った値を返すと、トークン転送が復元されます。

7. さらに、EOAがイベントを発信できる場合、何か問題があるでしょうか？一部の基盤インフラには注意が必要です。

これらは十四君が現在のEIP7702提案の内容と公式フォーラムの議論を基にまとめた欠点の一部に過ぎません。最終的には、最終的な実装コードに基づいて完全に分析する必要があります。

参考文献：

• https://eips.ethereum.org/EIPS/eip-7702
  https://ethereum-magicians.org/t/eip-set-eoa-account-code-for-one-transaction/19923
  https://github.com/ethereum/EIPs/pull/8527

5、全文まとめ

この記事は一見すると長大ですが、実際の文字数は6000字余りであり、途中で言及された多くの過去のEIP解読は、文中のリンクから拡張可能ですので、追跡する必要はありません。

現在のところ、アカウント抽象化は確かに第六モジュールに位置づけられ、すべてを修正するものであり、最終的には推進されるべきもので、現在EIP7702の進捗が大幅に加速しています。これがもたらすのは、システムの安全性への挑戦です。最終的には実現することが予想されます。なぜなら、イーサリアムの統合や合意アルゴリズムの変更といった破壊的なイベントが発生することができるのですから、ましてや新しい取引タイプについては言うまでもありません。

しかし、今回の破壊的な内容は非常に多く、複数のチェーン上の不可能な暗黙のルールを打破し、大多数のDappのアプリケーションロジックも打破しました。しかし、最も核心的な点は、ユーザーのコストが低くなったことです！EIP4337のほぼ倍増した取引コストと比較しても。

ユーザーは依然としてEOAアドレスを持ち、必要なときにCAロジックを駆動して使用するだけですので、保有コストが低くなりました。ユーザーはチェーン上のCAアイデンティティを事前に変換する必要がなく、操作を行うことができるため、ユーザーは登録する必要がありません。

ユーザーはEOAを使用して多くの取引を並行して行うことができ、例えば代金引き落としの承認と実行を一つにまとめることができ、これによりユーザーの取引コスト自体が低くなります。また、Dappにとっても、特にチェーン上の企業レベルの管理を必要とするプロジェクト、例えば取引所などにとっては、破壊的な最適化となります。バッチ集約が原生的に実現されれば、取引所のコストは瞬時に半分以上削減され、最終的にはユーザーにも恩恵をもたらすことができます。

したがって、彼は多くのことを変えましたが、コストという次元を占めることで、すべてのDappが研究し適応する価値があるのです。なぜなら、今回はユーザーが必ずEIP7702の側に立つからです。