This page may contain third-party content, which is provided for information purposes only (not representations/warranties) and should not be considered as an endorsement of its views by Gate, nor as financial or professional advice. See Disclaimer for details.
深度剖析:イーサリアムアカウントの抽象化EIP-7702の革命的な突破
イーサリアムアカウント抽象の過去と未来の深い解読
本文は二つの大きな部分に分かれています:
上半分は2015年の最初のAA提案から始まり、システムは現在までの主要なEIP提案内容を整理し、AAの歴史的提案の発展過程を探り、各提案を総合的に評価します。
下半部分重点対比分析EIP4337導入後市場反応が冷淡な理由、そして次のイーサリアムのバージョンアップに組み込まれるEIP7702を深く解析します。この提案が合併されると、チェーン上のアプリケーションの形態が全方位的に変わります。
EIP-7702は画期的な意義を持っており、詳しく見ていきましょう。
1. アカウント抽象の背景
1.1 アカウント抽象の意義の定位
イーサリアム創始者Vitalikが2023年末にETHロードマップを更新した際、アカウント抽象の設定は変更されていない。現在の主流モデルはEIP-4337から次の段階の自発的なEOAアカウントへの移行に発展している。
EIP4337が導入されてから一年以上が経ち、(2023年3月1日にデンバーのWalletConで正式に発表されました)。ユーザーから広く認識されていますが、使用率は高くありません。この矛盾した市場環境の中で、EIP-7702の進捗が大幅に前倒しされ、次回のアップグレードで統合されることが決定しました。
1.2 アカウント抽象的な市場状況
一年半の発展を経て、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(をデカップリングすることで、上記の問題を段階的に解決することにあります。
歴史上、さまざまな方案があり、最終的には二つのルートに集約されました。
! [イーサリアムアカウント抽象化トラックの過去と未来の詳細な解釈])https://img-cdn.gateio.im/webp-social/moments-65d1ef9656425666ee30c38bbb63e769.webp(
3. AAヒストリカルプロポーザルコンテクストコーミング
問題の解決策は多くのEIP提案があるように見えるが、結局のところ、二つの核心的な考え方しかない。通過しなかった各EIPが考慮した問題は最終的に既存の方案の突破口に集約される。
) 3.1 第一種ルート: EOAアドレスをCAアドレスに変換する
2015年11月15日に、EIP-101に関して、Vitalikはアカウントの新しい構造としてコントラクトを提案しました。アドレスをコードとストレージスペースのみになるように変更し、手数料のサポートをERC20によって行うこと、プリコンパイルコントラクトを通じてネイティブトークンをERC20のようなもので残高###を持たせることができる機能（代金の自動引き落としなど）(を持ち、トランザクションフィールドをto、startgas、data、codeのみに簡素化しました。
今のところ、これは大躍進的な変革であり、基盤設計が大幅に変更され、各アカウントアドレスが独自の"コード"ロジック)を持つことになります。これがまさにEIP-7702が実現しようとしている効果(です。
それは他の機能を派生させることもできます、例えば:
取引により多くの暗号アルゴリズムを使用し、各アドレスの内部コードによって署名検証認証方法を指定できる。
量子攻撃に対する耐性を持ち、コードがアップグレード可能です。
イーサリアムをERC20契約と一致する機能特性を持たせることで、コア効果は代金引き落としの許可を実現し、ネイティブコインの損失を必要としない。
アカウントのカスタマイズスペースを強化し、ソーシャルリカバリー、SBTサポート、キーリカバリーなどに対応します。
未能続けて進められなかった理由は簡単で、明らかに一歩が大きすぎたこと、現在の取引ハッシュ衝突問題と安全性の懸念について十分に考慮されていなかったため、ずっと保留されていた。しかし、すべての利点の理念は、後続のEIP4337とEIP7702のコア機能の一つとなった。
後にこの論理を改善しようとする一連のEIPがありました:
EIP-859:メインチェーンアカウント抽象)2018-01-30(
Codeのデプロイメントの問題を解決しようとしています。核心的な役割は、取引先の契約がデプロイされていない場合、取引に付随するcodeパラメータを使用して契約ウォレットをデプロイすることです。次に、新しいPAYGASオペコードが提案されており、ガスの支払いに加えて、取引パラメータの検証部分と実行部分の区切りにもなります。
当時無事に終わったが、これも現在のEIP7702の核心的な論理の一つとなった。EIP7702の各取引は特別な取引構造と組み合わされ、一定のコードを添付できるため、EOAアドレスは今回の取引で契約能力を持つことができる。
EIP-7702:EOAアカウントコード)2024-05-07(
これはこの記事の後続の議論メカニズムの核心EIPです。VitalikはEIP-7702をEIP-3074の代替案として発表しました。したがってEIP-3074は廃止され、EIP-7702は今後のETH Prague/Electra)Pectra(ハードフォークに組み込まれることが確定しています。具体的な内容については後ほど詳しく説明します。
) 3.2 第二のルート: EOAアドレスがCAアドレスを駆動させる
EIP-3074: AUTH および AUTHCALL オペコード ###2020-10-15( を追加
EVMに新しいOpCodes 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を直接考慮しないのでしょうか？
! イーサリアムアカウント抽象化トラックの過去と未来の詳細な解釈
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、 ガスリミット, 行き先 価値 データ、 アクセスリスト, authorization_list、 signature_y_parity、 signature_r、 signature_s ]###
重要なのは、新たにauthorization_listオブジェクトが追加され、署名者が自分のEOAで実行したいコードを保存することです。ユーザーが取引に署名する際、同時に実行したい契約コードにも署名します。それは二次元リストとして存在し、複数の操作情報を一括して保存でき、バッチ操作を実行することを示しています。
authorization_list = [[chain_id, 住所, nonce, y_parity, r, s], ...]
(