序文
この記事は 2 つの主要なモジュールに分かれています。
前半では、2015 年の第 1 回 AA 提案からこれまでの EIP 提案の主な内容を系統的に整理し、AA の歴史的提案の歴史を掘り起こし、各案のメリット・デメリットを総合的に評価したいと考えています。
後半では、EIP 4337 が提案された後に直面した市場低迷のフィードバックの比較に焦点を当て、次に、この提案が完了すると次のバージョンのイーサリアム アップグレードに組み込まれる予定の EIP 7702 について詳細な分析を行います。統合されると、チェーン上のアプリケーション フォームが完全に変わります。
EIP-7702は画期的な変更点です、獅子さんの詳しい説明をお聞きください
1. アカウントの抽象的な背景
1.1 アカウントの抽象的な意味
ポジショニング イーサリアム創設者のヴィタリック氏は2023年末にETH開発ロードマップを再度更新したが、アカウント抽象化の設定は変更されていない。現在の主流モデルも、EIP-4337 から次の段階である VoluntaryEOA Conversion (EOA アカウントの自発的変換) に入りました。
https://x.com/VitalikButerin/status/1741190491578810445
EIP 4337 の立ち上げから 1 年以上が経過しました (2023 年 3 月 1 日にデンバーで開催された WalletCon で、イーサリアム財団開発者によって設計および実装された ERC-4337 のコア コントラクトが OpenZeppelin の監査に合格し、歴史的ノードが正式に開始される）。
常にユーザーに広く認知されているものの、あまり普及していないという矛盾した市場環境のもとで、EIP-7702の進歩は大きく進み、次のバージョンアップに組み込まれることも確認されています。
1.2 アカウント抽象化の現在の市場状況
早速、データを見てみましょう。
1 年半の開発を経て、EIP 4337 の主流チェーン アカウントのコレクションには 1,200 個の W アドレスしかありません。最も驚くべきことは、イーサリアムのメイン ネットワークにはアクティブなアドレスが 6,764 個しかないということです。おそらく、統計上の次元が異なります。問題はありますが、少なくとも EOA や CA のアドレス数とは大きく異なります。イーサリアム メインネット上の独立したアドレスの数が 2 億 7,000 万に達していることを知っておく必要があります (データ ソース: https://etherscan.io/chart/)。住所）。
基幹ネットワークでは EIP 4337 の実質的な発展はないと言えます。
データソース: https://dune.com/niftytable/account-abstraction)
ただし、これによって AA の本質的な価値が消えるわけではありません。EIP 4337 の設計の最初から、メイン ネットワークでの深刻な前方互換性の問題に直面してうまく機能しないことが運命づけられていたため、さまざまな L2 と同様に、レイヤー チェーン 一般にネイティブ AA に埋め込まれている EIP 4337 のアドレス数は、L2 で爆発的に増加しました。7 月のベース チェーンとポリゴン チェーンの月間アクティブ ユーザーはそれぞれ 100 W と 300 W で、これは非常に印象的です。
したがって、EIP 4337 の設計が間違っているというわけではありません。現在の状況は、メイン ネットワークと L2 の違いによるものです。ソリューション。
2. アカウントの抽象化とは何ですか?
アカウントの抽象化はわかりにくく聞こえますが、実際には、財産権の分離の問題を本質的に解決します。
EVM アーキテクチャには、外部アカウント (EOA) と契約アカウント (契約アカウント) の 2 種類のアカウントがあります。外部アカウントの所有権と署名権は、実際には同じ個人によって保持されます。ユニット。秘密鍵を持っている人は、アカウントの「所有権」を持っているだけでなく、「すべての資産に署名して譲渡する」権利も持っています。
これはイーサリアムアカウントのトランザクション構造によって決まります。
以下の図の構造からわかるように、実際には、イーサリアムの標準トランザクションには From パーティがありません。では、資金送金を行う場合、具体的にどのアドレスから資金を消費するのでしょうか。実際、From アドレスは VRS パラメータ (つまり、ユーザー署名) を通じてデコードされます。
これには、ECDSA などの非対称暗号化や一方向しきい値関数などの概念が含まれます。つまり、セキュリティを確保するために暗号化が使用されます。これは、現在の財産権合併の EOA アドレスのジレンマも引き起こします。 。
EIP 4337 の主な効果は、送信者アドレス フィールドをトランザクション フィールドに追加することにより、操作されたアドレスから秘密キーを分離することです。
では、なぜ財産権の分離がそれほど重要なのでしょうか?
外部アカウント (EOA) の設計では、さらに多くの問題が発生するためです。
秘密キーを保護するのは困難です。ユーザーが秘密キーを失う（紛失、ハッカー攻撃、暗号クラッキング）ことは、すべての資産を失うことを意味します。
署名アルゴリズムが少ない: ネイティブ プロトコルは、トランザクションの検証に ECDSA 署名と署名検証アルゴリズムのみを使用できます。
高い署名権限: ネイティブのマルチ署名は存在せず (マルチ署名はスマート コントラクトを介してのみ連携できます)、単一の署名であらゆる操作を実行できます。
取引手数料はETHを通じてのみ支払うことができ、バッチ取引はサポートされていません。
トランザクションのプライバシーの漏洩: 1 対 1 のトランザクションでは、アカウント所有者の個人情報を簡単に分析できます。
アピールの制約により、一般ユーザーがイーサリアムを使用することが困難になります。
まず、イーサリアム上のアプリケーションを使用するには、ユーザーはイーサを保有する必要があります（また、イーサ価格変動のリスクを負う必要があります）。
第 2 に、ユーザーは複雑なコスト ロジックに対処する必要があります。ガス価格、ガス制限、トランザクション ブロッキング (ノンス注文) の概念はユーザーにとって複雑すぎます。
最後に、多くのブロックチェーンウォレットやアプリケーションは製品の最適化を通じてユーザーエクスペリエンスを向上させようとしていますが、実際の効果は最小限です。
したがって、この状況を打開する方法は、アカウントの抽象化を実装し、所有権 (Owner) と署名権 (Signer) を切り離し、上記の問題を 1 つずつ解決することです。実際、歴史的な計画は数多くあり、最終的には2つのルートに収束します。
3. AA 提案の歴史を振り返る
この問題を解決するための EIP 提案は数多くあるようですが、最終的には 2 つの核となるアイデアがあり、したがって、過去に通過しなかったすべての EIP で考慮された問題も、現在のソリューションの解決策に収束しています。
3.1 最初のルートは、EOA アドレスを CA アドレスに変更することです
2015 年 11 月 15 日の時点で、EIP-101 に関して、Vitalik は契約をアカウントとして使用する新しい構造を提案しました。コードとストレージ領域のみを持つようにアドレスを変更し、ERC 20 による支払いをサポートするために手数料を変更し、残高を保存するためのプリコンパイルされた契約を通じてネイティブ トークンを ERC 20 のようなものに変更します (承認の保留などの機能を持つことができます)。トランザクション フィールドを to、startgas、data、code のみに合理化します。現在では、これは単なる大躍進スタイルの変更であるようで、基礎となる設計が大幅に変更され、各アカウント アドレスが独自の「コード」ロジックを持つようになります (実際、これはまさに EIP-7702 が現在達成しようとしていることです) ）。他の関数も派生できます。
トランザクションでより多くの暗号化アルゴリズムを使用できるようにし、署名検証方法を各アドレスの内部コードで指定できます。
コードにアップグレード特性があるため、量子攻撃に耐性があります。
イーサリアムに ERC 20 コントラクトと同じ機能特性を持たせ、コア効果には源泉徴収の承認があるため、ネイティブ通貨を失う必要はありません。
アカウントのカスタマイズスペースを改善し、ソーシャルリカバリ、sbtサポート、キー取得などと互換性があります。
進まない理由も非常に単純で、現状のトランザクションハッシュ競合問題とセキュリティリスクに関しては、それぞれの利点の概念が十分に考慮されていないため、見送られています。後続の EIP 4337 および EIP 7702 の中核機能となっています。
その後、このロジックを改善しようとする一連の EIP がありました。
EIP-859: メインチェーンアカウントの抽象化--2018-01-30
コード展開の問題を解決しようとする中核となる機能は、トランザクション当事者のコントラクトがデプロイされていない場合、トランザクションに添付されたコード パラメータを使用してコントラクト ウォレットのデプロイメントを実行することです。次に、新しい PAYGAS オペレーション コードも提案されています。ガスの支払いに加えて、トランザクションにもなります。トランザクションパラメータの検証部分と実行部分の間の区切り文字です。当時は無駄に終わりましたが、現在では EIP 7702 の各トランザクションは特別なトランザクション構造と結合され、特定のコードを伴うことができるため、EOA アドレスはコントラクト機能を備えています。この取引では。
EIP-7702: EOA アカウント コードを設定 2024-05-07
これは、この記事で後述するメカニズムのコア EIP であり、EIP-7702 は EIP-3074 (2024-05-07) の代替として Vitalik によって公開されました。したがって、EIP-3074 は放棄され、EIP-7702 は今後の ETH Prague/Electra (Pectra) ハードフォークに含まれることが決定されました。詳細については以下で説明します。
3.2 2 番目のルートは、EOA アドレスで CA アドレスを駆動させることです。
EIP-3074: AUTH および AUTHCALL オペコードを追加します--2020-10-15
2 つの新しいオペコード AUTH および AUTHCALL が EVM に追加され、EOA が EOA の ID の代わりにこれら 2 つのオペコード認可コントラクトを通じて他のコントラクトを呼び出すことができるようになります。以下の図と組み合わせると、要約すると、EOA は、信頼するコントラクト (Invoker と呼ばれる) に署名されたメッセージ (トランザクション) を送信できます。この Invoker コントラクトは、AUTH および AUTHCALL オペレーション コードを使用して、この EOA を置き換え、このトランザクションを送信できます。貿易。
EIP-4337: トランザクション メモリ プールを使用してアカウント抽象化を実装する--2021-09-29
私はこれに関して、そのメカニズムを詳しく分析した多くの記事をすでに書いています。さらに読むことができます。
https://research.web3 caff.com/zh/archives/3212、
イーサリアムアカウント要約ERC 4337の見直し計画の解釈（その1）
イーサリアム アカウントの要約 10,000 ワードの調査レポート: 10 件の関連 EIP 提案の解体と、毎日数千万人のアクティブ ユーザーのボトルネックを打破する 7 年間の道のり
つまり、彼の設計は MEV からインスピレーションを得たものであり、その核となる価値はコンセンサス層プロトコルの変更を完全に回避できることです。
eip 4337 は、新しいトランザクション オブジェクト UserOperation を提案します。ユーザーはこのオブジェクトをメモリ プールに送信し、バンドラーはマイナー ディメンションからコントラクトをバッチでパッケージ化して配信し、基本的なトランザクションとアカウントの操作をコントラクト レベルにプルします。実行のために。
EIP-5189: エンドーサーを通じて抽象アカウントを操作する — 2022-06-29
これは、EIP 4337 のロジックの最適化と見なすことができます。悪意のある Bundler に直面して、DoS ブロック攻撃を防ぐために、金銭的ペナルティを承認するメカニズムを確立します。
3.3 AA をサポートするためのその他の提案
EIP-2718: 新しいトランザクション タイプの包装封筒--2020-06-13
これは、将来の新しいトランザクション タイプのエンベロープとして新しいトランザクション タイプを定義する最終的な提案です。最終的な効果は、新しいトランザクション タイプが導入されると、トランザクションのタイプを区別するために特定のエンコーディングが使用されるため、下位互換性のみが必要になり、前方互換性は必要なくなります。最も一般的な例は EIP 1559 です。これは、トランザクション手数料を区別し、元の従来のトランザクション タイプに影響を与えることなく、新しいトランザクション タイプのエンコーディングを使用します。
EIP-3607: EOA アドレスを展開不可能な契約にする --2021-06-10
これは、コントラクト展開アドレスと EOA アドレス間の競合を防ぐための、AA パス上の補足的なソリューションです。彼は、システムが既に EOA アドレスであるアドレスにコードを展開できないようにコントラクト生成方法を制御します。結局のところ、このリスクは実際には非常に小さいです。イーサリアムのアドレスは 160 ビット長なので、秘密鍵を使用して指定されたコントラクト アドレスの秘密鍵と衝突する方法もありますが、完全に計算すると、それでも 1 年かかります。ビットコインの計算能力。
3.4 アカウント抽象化の開発プロセスを理解するにはどうすればよいですか?
まず、CA に変換する価値を理解する必要があります
基本的に、これは EIP-4337 の実際の効果であり、彼は達成できます
ただし、EIP-4337 の主要な欠点は、人間の動機の原則に違反していることです。
改善されたように見えますが、多くの Dapps は互換性がないため、CA アドレスを使用することに消極的であり、CA を使用してもトランザクションコストが高くなります (通常の転送シナリオでもトランザクション手数料がかかります)。 double)、また Dapp 自体の互換性に依存しすぎます。
したがって、イーサリアムメインネットではこれまでのところ普及していません。
ユーザーにとってコストは最も重要な基準であり、コストを削減する必要があります。
しかし、本当に GAS を削減するには、イーサリアム自体がソフト フォークのアップグレードを実行し、GAS の計算を変更するか、オペコードやその他のモジュールの GAS 消費を変更する必要があります。ただし、ソフト フォークが必要なため、EIP-7702 を直接検討してみてはいかがでしょうか。
4. EIP-7702の総合解析
4.1 EIP-7702とは
新しいトランザクション タイプが特徴で、EOA は単一トランザクションでスマート コントラクトの機能を一時的に持つことができるため、ビジネスにおけるバッチ トランザクション、ガスフリー トランザクション、カスタム パーミッション管理などを導入することなくサポートできます。新しい EVM opCode (前方互換性に影響します)。
これにより、ユーザーはスマート コントラクトを展開せずに AA のほとんどの機能を取得できるようになり、ユーザーに代わってトランザクションを開始する機能をサードパーティに提供することもできます。ユーザーは秘密キーを提供する必要はなく、認証情報に署名するだけで済みます。
4.2 データ構造
新しいトランザクション タイプ 0x 04 を定義します。その TransactionPayload は、次のコンテンツの RLP エンコードされたシリアル化結果です。
重要なことは、署名者が EOA に実行したいコードを保存するために authorization_list オブジェクトが追加されるということです。これは、ユーザーがトランザクションに署名するときに、実行されるコントラクト コードにも署名します。これは 2 次元のリストとして存在します。複数の操作情報をバッチで保存できることを示し、バッチ操作を実行します。
4.3 トランザクションのライフサイクル
4.3.1 検証フェーズ
トランザクションの実行開始時に、authorization_list の [chain_id, address, nonce, y_parity, r, s] タプルごとに次のようになります。
ecrecover を使用して、署名 r および s から署名者のアドレスを復元します (これはイーサリアム自体のメカニズムであるため、この EIP は署名アルゴリズムを変更しないことに注意してください)。 authority = ecrecover(keccak(MAGIC || rlp([chain_id, address, nonce])), y_parity, r, s] (送信元アドレスを取得するための以前の署名の復号と同様に、ここで取得されるのはローカル署名ですこのリストのアドレス)
チェーン ID を確認します (アンチフォークされたチェーン リプレイ)。
権限署名者のコードが空であるか、または委任されているかどうかを確認します (トランザクションが有効な 7702 トランザクションであるかどうかを確認し、後でトランザクションを実行するために委任メカニズムが使用されるかどうかを確認します)。
権限署名者の nonce を検証します (権限署名の再実行を防ぐため)。
権限署名者のコードを 0x ef 0100 アドレスに設定します (EIP 3607 衝突防止ポリシーをバイパスするために使用されます)
権限署名者の nonce を増やします (部分的な署名の再生を防ぐため)。
訪問先アドレスリストに権限署名者アカウントを追加します (クエリストレージのガス料金を削減するためにホットアドレスを転送します)
4.3.2 実行操作フェーズ
実行する契約コードと操作指示はどこにありますか?
「新しい」バージョンでは、コードのデプロイメントに関する動作のみが変更されます。
アカウント コードをcontract_codeに設定する代わりに、authorization_listからコード アドレスを取得し、そのコードをアカウント コードとして設定します。
したがって、認証コードを実行する必要がある場合、コードは authorization_list のアドレス フィールドで指定されたアドレスからロードされ、署名者のアカウントのコンテキストで実行されます。
これは、ユーザーのコントラクト コードがトランザクションに直接含まれるのではなく、実際にはチェーン上の特定のアドレスに保存されることを意味します。
操作命令と関連パラメータは、トランザクション ペイロードのデータ フィールドに保存されます。
4.4 EIP-7702 の価値は何ですか?
これにより、Web3 ウォレットのリンク全体が変更され、EOA によって開始される通常のトランザクションでもバッチ転送などのコントラクトと同様のさまざまなロジックを実行できるため、ユーザー エクスペリエンスも劇的に変化します。 CeFi シナリオは、トランザクションの識別と出金回収手数料に影響を及ぼします。その出現により、次のような以前の多くの固定概念が打ち破られました。
口座残高はその口座からの取引によってのみ減少できるという不変条件を破ります。
トランザクションの実行開始後に EOA nonce が 1 ずつ増加するという不変条件を破ります (同時に複数の nonce が増加する可能性があります)。
tx.origin と msg.sender の比較の保護ロジックが壊れており、過去の多くの契約が危険にさらされています。
EOA 自体がイベントを発行できないという現状を打破するため、一部のオンチェーン イベントの識別と監視に注意を払う必要があるかもしれません。
EOA アドレスが ERC 20、721、1155 およびその他のアセットの受け入れに成功する必要があるという現状を打破します (コールバック メカニズムが原因で失敗する可能性があります)。
4.5 EIP-7702 と EIP-4337 の比較
1. EIP-7702のメリット
エントリポイント モジュールを通過する必要がないため、ガスが少なくなり、オンチェーン操作が軽減されます。
ユーザーの移行コストが低くなり、対象としてオンチェーンコントラクトを事前に展開する必要がありません。
Eip 4337 と比較すると、コード委任の実行もあり、次の 2 つの方法もあります。
完全な代表団
完全委任とは、操作に対するすべてのアクセス許可を特定のアドレスに委任することを指します。たとえば、ユーザーはすべての ERC-20 トークンの管理権限をスマート コントラクト アドレスに委任し、このスマート コントラクトがユーザーに代わって関連するすべての操作を実行できるようにすることができます。
保護された委任
保護された委任とは、委任操作の安全性と制御性を確保するために、委任プロセス中にいくつかの制限と保護措置を追加することを指します。
たとえば、ユーザーは ERC-20 トークンの一部のみの管理をスマート コントラクトに委任したり、一部の制限 (1 日の最大支出額を総残高の 1% にするなど) を設定したりできます。
2. EIP-7702の欠点
その主な欠点は、これがソフト フォーク アップグレードであり、推進するには全員の合意が必要であること、および変更が大きく、チェーンの生態系に広範な影響を与えることです。次のような課題がありますが、これらの課題は市場機会でもあります。
自由度は非常に高く、セキュリティ保護を提供するためにユーザーはより信頼性の高いウォレットを必要とします。
元の構造は大きく変化しており、さまざまなトランザクション タイプによって区別されていますが、多くのインフラストラクチャ、特にチェーン上の不変コントラクトを直接適用することはできません。
EOA アドレスには契約機能が提供されますが、対応するストレージ スペースを保持することはできません。
通話データの部分が大幅に増加するため、別のトランザクションのコストは若干高くなります。通話の推定総コストは、16 (ガス) * 15 (バイト) = 240 (ガス) の通話データ コストに EIP のコストを加えたものになります。 3860 2 * 15 = 30 に、およそのランタイム コスト 150 を加えます。そのため、何もしなくてもアカウントを準備するだけでガスが500増加します。
「受信者が受信機能を持たずにコードに署名した場合、送信者はアセットを送信しようとしたときに DoS に直面する可能性があります。」実際の問題は、EOA A が署名すべきではないもの、つまり間違った実装設定 (receive() がない) で再生可能なファイルに署名したことです。
たとえば、ERC-20 トークンを転送する場合、受信側アカウントにコードがある場合、トークン コントラクトは受信側アカウントに対して onERC 20 Received を呼び出します。 onERC 20 Received が元に戻るか、間違った値を返した場合、トークン転送は元に戻ります。
また、EOA がイベントを発行できる場合、何か問題はありますか?一部のインフラストラクチャには注意が必要な場合があります。
これらは、現在の EIP 7702 提案内容と対応する公式フォーラムの議論に基づいて Shishijun によって要約された欠点の一部にすぎません。最終的には、最終的な実装コードに基づいて完全に分析する必要があります。参考文献は以下の通りです。
https://eips.ethereum.org/EIPS/eip-7702
https://ethereum-magicians.org/t/eip-set-eoa-account-code-for-one-transaction/19923
5. 全文要約
この記事は非常に長いように見えますが、実際にはテキストの内容は 6,000 ワードを超えるだけです。この記事に含まれる以前の EIP 解釈の多くは記事内のリンクから参照できるため、ここでは戻りません。
現時点では、アカウント抽象化は実際にすべてを修正する 6 番目のモジュールにのみ配置できます。つまり、EIP 7702 の進歩が大幅に加速された今、システム セキュリティにさらなる課題がもたらされることになります。結局のところ、イーサリアムの合併やコンセンサスアルゴリズムの変更などの破壊的な出来事が起こる可能性があるため、新しいトランザクションタイプはどうなるでしょうか？
しかし、今回は転覆が多すぎて、複数のチェーン上の不可能な隠されたルールを破り、ほとんどの Dapps のアプリケーションロジックも破っています。しかし、ユーザーのコストが低いという核心点はしっかりと占めています。 ！これを EIP 4337 のほぼ 2 倍のトランザクション コストと比較してください。
ユーザー自身はまだ EOA アドレスを持っており、必要な場合にのみ CA ロジックを駆動して使用するため、保持コストは低くなります。操作を実行する前にチェーン上の CA ID を変換する必要はありません。つまり、ユーザーは登録する必要がありません。
ユーザーは、EOA を使用して、源泉徴収の承認と源泉徴収の実行を 1 つで行うなど、複数のトランザクションを並行して実行することができます。これにより、Dapps、特に取引所などのオンチェーンのエンタープライズレベルの管理を必要とする Dapps のトランザクションコストが削減されます。は、破壊的な最適化を行い、バッチ集約が本来のエコロジーで実現されると、基本的な交換コストを瞬時に半分以下に削減でき、最終的にはユーザーに利益をもたらすことができます。
したがって、大きく変わりましたが、コストの観点から、今回はユーザーが EIP 7702 の側に立つ必要があるため、研究してすべての Dapps に適応する価値があります。
