イーサリアムアカウントの抽象化トラックの過去と未来を深く読み解く

イントロダクション

本文は二つの主要なモジュールに分かれています:

上半分は2015年の最初のAA提案から始まり、システムはこれまでの主要なEIP提案の内容を整理し、AAの歴史的提案の経緯を振り返り、各提案の長所と短所を総合的に評価しています。

下半部分重点対比EIP4337推出後に直面した市場の反応が良くない状況を深く分析し、次のイーサリアムのバージョンアップグレードに組み込まれるEIP7702について詳しく説明します。この提案が合併されると、チェーン上のアプリケーションの形態を全方位的に変えるでしょう。

EIP-7702は画期的な意義を持ちます。それについて詳しく見ていきましょう。

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

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

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

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

1年半の発展を経て、EIP4337の主要チェーン上のアカウント総数はわずか1200万であり、その中でイーサリアムメインネットのアクティブアドレスは6,764個だけで、EOAおよびCAアドレス数との間には巨大な差があります。イーサリアムメインネットの独立アドレス数は2.7億に達しており、EIP4337はメインネット上でほとんど実質的な発展がないことがわかります。

しかし、これは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(。EOAの所有権と署名権は実際には同一の主体によって保持されます。秘密鍵を持つ人は、アカウントの"所有権"を持つだけでなく、"すべての資産を署名して移転する"こともできます。

これはイーサリアムアカウントの取引構造によって決まります。標準取引構造には実際にはFromフィールドがなく、資金の転送はVRSパラメータ)ユーザー署名(から逆解析してFromアドレスを実現しています。

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

権利の分離がこれほど重要な理由は、EOAの設計が多くの問題を引き起こすからです。

1. 秘密鍵の保護が難しい: 秘密鍵を失うことは、すべての資産を失うことを意味します。

2. 署名アルゴリズムが単一:ネイティブプロトコルはECDSAアルゴリズムのみを使用して取引を検証できます。

3. サイン権限が過剰:ネイティブなマルチシグはなく、単一のサインで任意の操作を実行できます。

4. 取引手数料はETHのみで支払い可能であり、バルク取引には対応していません。

5. 取引のプライバシー漏洩: 一対一の取引はアカウント保有者の情報を分析しやすい。

これらの制限により、一般ユーザーがイーサリアムを使用することが難しくなっています:

まず、イーサリアムアプリケーションを使用するにはETHを保有し、価格変動リスクを負う必要があります。

次に、ユーザーはGas price、Gas limit、取引のブロッキングなどの複雑な料金ロジックを処理する必要があります。

最後に、多くのブロックチェーンウォレットが製品の最適化を通じてユーザー体験を向上させようとしていますが、その効果は限られています。

したがって、突破口はアカウントの抽象化を実現し、所有権)Owner(と署名権)Signer(をデカップリングすることで、段階的に上記の問題を解決することにあります。

歴史的に様々な提案があり、最終的には二つのルートに集約されました。

! [イーサリアムアカウント抽象化トラックの過去と未来の詳細な解釈])https://img-cdn.gateio.im/webp-social/moments-65d1ef9656425666ee30c38bbb63e769.webp(

3. AAヒストリカルプロポーザルコンテクストコーミング

問題の解決策には多くのEIP提案があるように見えるが、結局のところ、2つの核心的な考え方だけがある。通過しなかった各EIPが考慮した問題は、現在の提案の突破口に集約されている。

) 3.1 第一のルート: EOAアドレスをCAアドレスに変換する

2015年11月15日に、VitalikはEIP-101でアカウントの新しい構造として契約を提案しました。アドレスをコードとストレージスペースのみと変更し、ERC20で手数料を支払うことをサポートし、プリコンパイルされた契約を通じてネイティブトークンをERC20のようにストレージ残高に変更し、取引フィールドをto、startgas、data、codeに簡略化しました。

このプランから多くの機能が派生します:

1. 取引は、アドレス内部のCodeによって指定された署名検証方法を使用して、より多くの暗号アルゴリズムを利用できます。

2. 量子攻撃に対する耐性を持ち、コードがアップグレード可能である

3. ETHに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ハードフォークに組み込まれることが確定しています。

) 3.2 第2のルート: EOAアドレスがCAアドレスを駆動する

EIP-3074: AUTH および AUTHCALL オペコード ###2020-10-15( を追加

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

EOAは、署名されたメッセージ)を信頼できるコントラクト(に送信することができ、これをInvoker)と呼びます。このInvokerコントラクトは、AUTHおよびAUTHCALLオペコードを使用してEOAの代わりにトランザクションを送信できます。

EIP-4337:取引メモリプールを用いたアカウントの抽象化(2021-09-29)

MEVからインスパイアを受けて設計されており、核心的な価値はコンセンサスレイヤーのプロトコルの変更を完全に回避することです。

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

EIP-5189:背書人によるアカウントの抽象化(2022-06-29)

EIP4337のロジックを最適化し、資金罰金の裏付けとなるエンドーサーメカニズムを構築することで、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自体の互換性に過度に依存している。

したがって、イーサリアムのメインネットでは、いまだ普及していない。

コストはユーザーにとって最も重要な評価基準であり、コストを削減する必要があります。

真にガスを削減するには、イーサリアム自体をソフトフォークアップグレードし、ガス計算やオペコードのガス消費などのモジュールを修正する必要があります。ソフトフォークを行うのであれば、なぜEIP-7702を直接考慮しないのでしょうか?

! [イーサリアムアカウント抽象化トラックの過去と未来の詳細な解釈])https://img-cdn.gateio.im/webp-social/moments-3503a168bb61430839419efb40e130de.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タプルについて、次の操作を行います。

1. 署名のr、sを使用して署名者のアドレスをecrecoverで復元します。

2. チェーンID###の検証とフォークチェーンのリプレイ###。

3. authority署名者のコードが空であるか、委任されているかを確認します。

4. 機関の署名者を確認しnonce(機関の署名のリプレイ)を防ぎます。

5. オーソリティ署名者コードを 0xef0100 に設定する || アドレス。

6. authority署名者のnonce(を増加させ、局部署名のリプレイ)を防ぎます。

7. authority署名者アカウントをアクセス済みアドレスリストに追加します。

(# 4.3.2 実行フェーズ

"新"バージョンはコードのデプロイ動作のみを変更します。

アカウントコードをcontract_codeとして設定せず、authorization_listのaddressフィールドからコードを取得してアカウントコードとして設定します。

承認リストから指定されたアドレスからコードを読み込み、署名者のアカウントコンテキストで実行します。

ユーザー契約コードは実際にチェーン上の特定のアドレスに保存され、トランザクションには直接含まれていません。

操作指令と関連するパラメータは、取引ペイロードのdataフィールドに格納されています。

) 4.4EIP-7702の値

Web3ウォレットの全体的な流れに変化があり、ユーザーエクスペリエンスが大きく変わりました。EOAが通常の取引を開始すると、契約の実行のようにさまざまなロジックを実行できます。例えば、バッチ転送などです。CeFiシーンでの取引の識別、入出金の手数料の集約に影響を与えます。

既存の枠組みを打破する:

1. アカウントの残高は、そのアカウントの取引に由来しない理由で減少する可能性があります。

2. 取引実行開始後にEOAのノンスが複数増加する可能性があります。

3. tx.originとmsg.senderの比較保護ロジックを破ると、多くの既存の契約にリスクがあります。

4. EOA自体がイベントを発信し、一部のオンチェーンイベントの識別とリスニングに影響を与える。

5. EOAアドレスがERC20、721、1155などの資産を受信することは、コールバックメカニズム###のために失敗する可能性があります###。

! イーサリアムアカウント抽象化トラックの過去と未来の詳細な解釈

( 4.5 EIP-7702 と EIP-4337 の比較

1. EIP-7702の利点

• ガスが低く、エントリーポイントモジュールが不要で、チェーン上の操作が減少します。
• ユーザーの移行コストが低く、事前にオンチェーン契約をデプロイする必要がありません。
• EIP4337と同様にコード委託実行があり、2つの方法があります:

完全委託)フルデリゲーション###

• 特定の操作を行う