当時は終わりが見えませんでしたが、現在ではEIP7702のコアロジックの1つとなり、特別なトランザクション構造と組み合わせたEIP7702の各トランザクションには、一定のコードを伴うことができ、これによりEOAアドレスはこのトランザクションで契約機能を持つことができるようになります。
これは、この記事で後述するメカニズムの中核となるEIPです。VitalikはEIP-3074(2024-05-07)の代替としてEIP-7702を発表しました。その結果、EIP-3074は破棄され、EIP-7702が来るべきETHプラハ/エレクトラ(ペクトラ)のハードフォークに含まれることが確認されました。
EVMに2つの新しいOpCodeを追加します AUTH
と AUTHCALL
。EOAは、他のコントラクトを呼び出すために、EOAのIDの代わりに、これら2つのオペコードを通してコントラクトを認可できる。下の図と合わせて考えると、要約すると、EOAは署名されたメッセージ(トランザクション)を信頼されたコントラクト(インヴォーカー
と呼ばれる)に送ることができ、そのコントラクトはインヴォーカー
コントラクトを使って他のコントラクトを呼び出すことができます。>コントラクトは、 AUTH
と AUTHCALL
オペコードを使用して、このEOAの代わりにこのトランザクションを送信することができます。
EIP-4337:トランザクション・メモリ・プールによるアカウント抽象化 - 2021-09-29
要約すると、彼はMEVにインスパイアされて設計しました。コンセンサス層のプロトコル変更を完全に回避する能力である。
eip4337氏は新しいトランザクションオブジェクトであるUserOperation
を提案しており、ユーザーはこれをメモリのプールに送り、bundlers
がバッチパッケージ化して採掘者次元のコントラクトを配信してトランザクションを実行する。これにより、基本的なトランザクションとアカウント操作がコントラクトレベルに引き下げられ、実行される。
EIP-5189:エンドーサーによって操作される抽象アカウント-2022-06-29
これは、EIP4337のロジックを最適化したようなものです。EIP4337 のロジックは、悪意のある Bundler
に直面したときに、ペナルティのエンドーサーに資金を提供するメカニズムを作成することで、Dos ブロッキング攻撃を防ぐことです。
3.3 AA サポートのためのその他の提案
EIP-2718: 新しいトランザクションタイプのためのパッケージ化されたエンベロープ - 2020-.06-13
これはむしろ、将来の追加のためのエンベロープとして使用される新しいトランザクションタイプを定義する、すでにFinalとなっている提案です。
その正味の効果は、新しいトランザクションタイプが導入されるとき、それがどのトランザクションであるかを区別するために特定のエンコーディングが使用され、前方互換性ではなく後方互換性のみを可能にするということである。この最も一般的な例はEIP1559であり、これは取引手数料を区別し、元のレガシートランザクションタイプに影響を与えることなく、新しいトランザクションタイプのエンコーディングを使用する。
EIP-3607: MakeEOA
Address Non-Deployable Contracts - 2021-06-10
これは、契約展開アドレスがEOAアドレスと競合する問題を防ぐための、AAパス上の補完的なソリューションです。システムがすでにEOAアドレスであるアドレスにコードをデプロイできないように、コントラクト生成方法を制御します。結局のところ、イーサネットアドレスは160ビット長であり、与えられた契約アドレスの秘密鍵と秘密鍵を衝突させる方法はあるものの、ビットコインの計算能力がフルに発揮されるのはまだ1年先と見積もられている。
3.4アカウント抽象化の開発履歴を理解するには?
最初に理解すべきことは、CAに切り替えることの価値です
基本的にEIP-4337が実際に行っていることは、彼が実現できることです
しかし、EIP-4337の中心的な欠点は、それが人間の動機の原則に反するということである。
彼は良く見えるが、市場発展の死角のようなものに巻き込まれ、Dappsはまだ互換性のないものが多く、ユーザーはCAアドレスを使うことに満足しないだろうし、CAを使っても取引コストが高く(一般的な送金シナリオでは、取引コストも2倍になる)、Dapp自体の互換性にも依存しすぎる。
そのため、メインのイーサネットワークではこれまで人気がなかったのです。
コストはユーザーにとって最も重要な指標であり、削減されなければなりません。
しかし、本当にGASを削減するためには、Ether自身がソフトフォークアップグレードを行うか、GAS計算を修正するか、オペコードのGAS消費などのモジュールを修正しなければなりませんが、ソフトフォークしなければならないのですから、EIP-7702を検討すればよいのではないでしょうか?h3>
EOAが一時的に単一のトランザクションでスマートコントラクト機能を持つことを可能にする新しいトランザクションタイプによって差別化されており、新しいEVM opCodeを導入する必要なく(前方互換性に影響する)、バッチトランザクション、ガスフリートランザクション、カスタム権利管理などのビジネスをサポートします。
スマートコントラクトをデプロイすることなく、ユーザーにAA機能のほとんどにアクセスさせることができ、第三者がユーザーに代わってトランザクションを開始する機能さえ提供することができます。
4.2データ構造
彼は新しいトランザクションタイプ0x04を定義し、そのTransactionPayloadは以下の通りである。内容のRLPエンコードされた直列化結果
重要なことは、新しいauthorization_listオブジェクトが存在することである。このオブジェクトは、署名者が自分のEOAで実行されることを望むコードを格納し、ユーザーは実行される契約のコードとともにトランザクションに署名する。彼は2次元リストとして存在し、複数の操作に関する情報を一括して保存し、一括して操作を実行することが可能であることを示している。
4.3 トランザクションのライフサイクル
4.3.1 検証フェーズ
トランザクションの実行開始時に、authorisation_listの各[chain_id, address, nonce, y_parity, r, s]
タプルについて:
ecrecoverを使って署名r, sから署名者のアドレスを復元する(これはEther自体のメカニズムなので、このEIPは署名アルゴリズムを変更しないことに注意)。authority = ecrecover(keccak(MAGIC || rlp([chain_id, address, nonce])), y_parity, r, s]
(FROMアドレスを導出するための以前の署名の復号と同様で、ここではこのリストのローカル署名のアドレスである))
チェーンIDを検証する(フォークチェーンのリプレイを防ぐため)。
authority
署名者のコードが空であるか、委任されていることを検証する(トランザクションが有効な7702トランザクションであることを検証し、エージェントに代わってトランザクションを実行する委任メカニズムによってフォローアップされる)。
authority
署名者のnonceを検証する(authority
の署名のリプレイを防ぐ)。li>
authority
署名者の nonce を追加する (ローカル署名のリプレイを防ぐ)。
訪問したアドレスのリストにauthority
署名者アカウントを追加する(アドレスのヒートを上げ、店舗への問い合わせのガス代を減らす)
Authority 署名者アカウントを追加する。: left;">4.3.2操作フェーズを実行する
実行する契約コードと操作指示はどこにあるのか?
「新しい」バージョンは、コード展開の点で動作を変更するだけです。
口座コードをcontract_code
に設定することはなくなり、代わりにauthorisation_list
からaddress
というコードを取得し、そのコードを口座コードとして設定します。そのコードを口座コードとして設定する。
そのため、認証コードを実行する必要がある場合、コードはauthorization_list
のaddress
フィールドで指定されたアドレスからロードされ、署名者のアカウントのコンテキストで実行されます。
これは、ユーザーの契約コードが、トランザクションに直接含まれるのではなく、チェーン上の特定のアドレスに実際に保存されることを意味します。
そして、アクション命令と関連パラメータは、トランザクションロードのdata
フィールドに格納されます。
4.4EIP-7702の値とは?
EOAによって開始される通常のトランザクションも、バッチ転送のようなさまざまなロジックを実行するために同様に契約できるため、Web3ウォレットのチェーン全体に変化をもたらし、その結果、ユーザーエクスペリエンスが劇的に変化します。
口座残高はその口座で発生した取引によってのみ減少させることができるというルールを破ることになります。口座の残高は、その口座を起点とする取引によってのみ減らすことができるという規則を破ること。
取引実行の開始後にEOA nonceが1ずつ増加するという不変則を破る(同時に1以上増加する可能性がある)。
tx.originとmsg.senderの2つの比較の保護ロジックを破り、多くの過去の契約が危険にさらされます。
EOA自身がイベントを発信できないという現状を打破し、オンチェーンのイベント認識リスナーのいくつかに注意を払う必要があるかもしれません。
ERC20、721、1155などのアセットを受け入れるEOAアドレスは成功するに決まっているという現状を打破する(コールバック機構のために失敗する可能性もある)
EOAアドレスは、ERC20、721、1155などのアセットを受け入れるEOAアドレスは成功するに決まっているという現状を打破する。strong>4.5EIP-7702とEIP-4337の比較
1.EIP-7702の利点
エントリーポイントモジュールを経由する必要がないため、ガスは少なくなり、オンチェーンオペレーションを減らすことができます。
ユーザーの移行コストが下がる、オンチェーン契約を本体として先に展開する必要がない
Eip4337と比較すると、同じコードの実行委譲があり、やはり2つの方法で行われます:
完全な委任
完全な委任とは、操作への完全なアクセスを特定のアドレスに委任することを意味します。例えば、ユーザーはすべてのERC-20トークンの管理をスマートコントラクトのアドレスに委任することができ、これによりスマートコントラクトはユーザーに代わってすべての関連操作を実行することができます。
保護された委任
保護された委任とは、委任された操作の安全性を確保するために制限と保護を追加して委任するプロセスを指します。保護された委任とは、委任された操作の安全性と制御性を確保するために、制限や保護を加えて委任することを指します。
例えば、ユーザーはERC-20トークンの一部だけを単一のスマートコントラクトに委任したり、いくつかの制限(例えば、1日あたり総残高の1%までしか使用できない)を設定したりすることができます。
2.EIP-7702の欠点
EIP-7702の中核的な欠点は、ソフトフォークアップグレードに属し、全員のコンセンサスによって推進される必要があり、変更が巨大で、チェーン上のエコシステムに広範すぎる影響を与えることです。14紳士ダウンの予備評価では、次のような課題がありますが、課題は市場機会でもあります:
自由度が非常に高く、監査されるのが難しく、ユーザーはセキュリティ保護の保護を引き受けるために信頼できるウォレットをより必要とするでしょう。
自由度が極めて高く、監査されにくいため、ユーザーはセキュリティ保護を担う信頼性の高いウォレットをより求めるようになる。
元のアーキテクチャへの変更はあまりにも大幅で、異なるトランザクションタイプを使用して区別していたものの、インフラの多く、特にオンチェーンの不変コントラクトはそのまま適応することができませんでした。
コントラクト機能はEOAアドレスに提供されますが、対応するストレージスペースを保持することはできません。
別個のトランザクションのコストは、calldata 部分で大幅な増加があるため、わずかに高くなり、呼び出しの推定総コストは、16 (gas) * 15 (bytes) = 240
(gas) calldata コスト、プラスEIP-3860のコストは2 * 15 = 30
、それにおおよそのランタイム・コストは150
となる。つまり、何もしないアカウントを準備するだけでも、500ギガを追加することになります。
「受信者が受信機能を持たないコードに署名した場合、送信者はアセットを送信しようとすると DoS に直面する可能性があります。問題は、EOA A が署名すべきでないものに署名していること、つまり間違った実装セット (receive()
がない) を持つ再生可能ファイルに署名していることです。
オンチェーンフラッシュのロジックには一貫性がありません。たとえば、ERC-20 トークンを転送する場合、トークン契約は、受信者アカウントにコードがあれば、onERC20Received
を呼び出します。onERC20Received
が戻ったり、間違った値を返したりすると、トークンの転送は元に戻ります。
また、EOAがイベントを送信できる場合、何か問題はありますか?いくつかのインフラには注意が必要かもしれません。
これらは、現在のEIP7702提案と対応する公式フォーラムの議論に基づいてXIVがまとめた欠点の一部に過ぎず、最終的には最終的な実装コードに基づいて分析する必要があります。
以下を参照してください:
5、完全な要約
この記事は長いように見えますが、実際にはテキストコンテンツは6しかありません。
この記事は長いように見えるが、実際には、テキストの内容はわずか6kワードであり、中間は、以前のEIPの解釈の多くを含む、テキストのリンクで展開することができ、私はトレースに入ることはありません。
現時点では、アカウントの抽象化は、確かに、唯一のEIP7702の進歩の今日の実質的な加速の実装では最後、つまり、すべてを修復するために、第六モジュールに配置することができ、より多くの、またはシステムのセキュリティの課題は、それは期待することができ、彼は最終的に達成される、結局のところ、イーサリアムの合併、コンセンサスアルゴリズムの変更は、そのような破壊的なイベントが再び起こることができるように、EIP7702の目的にも使用することができます。破壊的なイベントが発生する可能性があり、地区内のトランザクションの新しいタイプについて話します。
しかし、今回はあまりにも多くの破壊的なコンテンツがあり、不可能な裏技の複数のチェーンを壊すだけでなく、ほとんどのDappのアプリケーションロジックを壊すが、彼は死んだ最もコアなポイントを占めている、つまり、ユーザーのコストが低くなります!EIP4337の2倍近い取引コストに対して。
ユーザー自身はEOAアドレスのままであり、必要なときだけCAロジックを動かして使うので、所有コストは低い。操作を行う前にオンチェーン CA ID から変換する必要がないため、ユーザが登録する必要がない。
ユーザーは、EOAを使用して、認可された源泉徴収と源泉徴収の2つの実行を1つにするなど、複数のトランザクションを並行して行うことが簡単にできるため、ユーザートランザクション自体のコストが低く、Dappにとって、特に取引所などのプロジェクト側の企業管理の連鎖を行う必要があるため、一旦バッチインピュテーションを行うことが破壊的な最適化になります。一括集計が実現すれば、基本的な交換コストは瞬時に半分以下になり、最終的にはユーザーにも利益をもたらすことができる。
だから、彼は多くを変更したが、この次元のコストを占めるが、それはすべてのDAPPが勉強して適応する価値がある、この時間は、ユーザーがEIP7702の側に立ってバインドされているため。