Ethereum アカウント抽象化ロードマップ I: EIP-3074、EIP-5806、および EIP-7702

Deneb アップグレードを通じて Ethereum に導入された重要な変更を観察し、次のハードフォークである Pectra で何が導入されるかを検討し始めました。今後の議論を形作るために、Ethereum とそのロールアップ エコシステムを取り巻くアカウント抽象化の現状を説明し、明確な前進の道筋を描くことを目指しています。

このレポートでは、Ethereum の現在のアカウント モデルの概要、特にトランザクションの有効性への影響、アカウントの抽象化が具体的に何を意味するのか、そしてそれについて推論するためのフレームワークについて説明します。次に、EIP 5086、3074、および 7702 の評価による EOA プログラマビリティ アプローチに焦点を当て、これらすべてが Ethereum でのトランザクションの将来にどのような影響を与える可能性があるかを結論として述べます。

アカウント抽象化とは何か、何でないかは多くの混乱がありますが、このシリーズ全体を通して、アカウントの有効性ルールの一部を再定義できるメカニズムはすべてアカウント抽象化のメカニズムであると考えています。さらに、これらのメカニズムのほとんどは漠然と似ていて重複しているため、これらのメカニズムの分類を示します。

Ethereum におけるアカウント抽象化の概要

アカウントの抽象化は、Ethereum エコシステム全体にわたってユーザーと開発者のエクスペリエンスを向上させることを目指しています。オンチェーン エクスペリエンスをユーザーにとってよりアクセスしやすく楽しいものにするとともに、開発者が Ethereum 上でより強力な機能を実現し、より有意義な方法でユーザーにサービスを提供できるようにもなります。

アカウント抽象化へのアプローチの分類は次のとおりです。

1. EOA の強化/プログラマビリティ: これには、EOA (外部所有アカウント) が妥当性ルールの実行ロジック部分を再定義できるようにするプロトコル レベルの変更が含まれます。開発コミュニティではよく知られているように、EOA は通常、エンド ユーザーに関連付けられたアカウントです。したがって、このアプローチに含まれるソリューションは、エンド ユーザー アカウントが承認できるアクションの種類を、現在の管理方法よりも詳細に制御できるようにします。

2. EOA 変換/移行: このアプローチには、EOA を CA (コントラクト アカウント) に完全に変換するという提案が含まれます。このアプローチの重要な考え方は、コントラクト アカウントは既にスマート アカウントが提供するメリットのほとんどを提供しているため、これ以上複雑にする必要はないということです。つまり、誰もがコントラクト アカウントをメイン アカウントとして使用すればよいのです (スマート コントラクト ウォレット経由)。

このアプローチには、 EIP 7377やEIP 5003 (EIP 3074 と併せて考慮した場合) などの資産を移動することなく EOA を CA に移行できるメカニズムが備わっています。

3. スマート アカウント: このグループの提案には、EOA と CA の両方が、有効性ルールを完全に再定義できるようにすることで「スマート アカウント」として動作できるようにする設計が含まれます。

これまで、スマート アカウントの作成とプロトコル レベルでのアカウント抽象化の導入に関するさまざまな提案がなされてきました。EIP -86とEIP-2938は、最もよく引用される提案の一部です。ただし、この設計によってもたらされる複雑さが認識され、Ethereum はそのような複雑さに対応できないという大多数の意見により、多くの反発がありました。

The Merge 後の Vitalik によるこのトピックの復活に続き、 ERC-4337 は、MEV (Maximal Extractable Value) の PBS (Proposer-Builder Separation) インフラストラクチャに似た、スマート アカウント標準のオプトイン バージョンとして提案されました。したがって、スマート アカウントのメリットを利用したいユーザーは、ERC-4337 パイプラインを使用して、 UserOperation (略してUserOps ) と呼ばれる構造でアカウントのロジックとトランザクションの有効性ルールを再定義するだけで済みます。

ERC 4337 は、既存のスマート アカウントのプロトコル外の代替として機能することで、複雑さを一切残すことなく、スマート アカウントの利点を現在の Ethereum にもたらします。ただし、これはインフラストラクチャが現状で最適であることを意味するものではなく、その複雑さは依然として大きな障害点となっています。

この複雑さに対処するため、 RIP 7560 は、Ethereum とその L2 全体にわたる ERC 4337 インフラストラクチャの定式化バージョンとして起草されました。これにより、新しい一連のルールを定義する必要がなくなり、ネットワークのシビル耐性スキームを継承するようになりました (ERC 4337 がERC 7562で行っているように)。

このレポートでは、EOA のプログラマビリティの調査、この方向のソリューションを説明するさまざまな EIP の評価、およびそれらのメリットとデメリットについて重点的に説明します。このシリーズのパート 2 と 3 では、Ethereum 内で調査されているアカウント抽象化へのアプローチの残り 2 つのクラスについて説明します。

イーサリアムのアカウントとトランザクションの入門

抽象化できるものを探すには、現在のアカウント設計の (ある程度の) 全体像が必要です。このセクションでは、Ethereum 上のアカウントが実際にどのようなものであるか、およびそのトランザクションがどのように検証され実行されるかについて、ある種の復習として主に説明します。

Ethereum アカウントは、イーサ (ETH) 残高を持ち、Ethereum ブロックチェーン上でトランザクションを送信する機能を持つエンティティです。これらは 42 文字の 16 進数の「アドレス」として表され、アカウントの保有とトランザクションへの一意のポインタとして機能します。

アドレスはブロックチェーンの状態トライへのキーとして機能します。このトライのリーフノードは、4 つのフィールドに分解できるアカウント データ構造です。

1. nonce : アカウントによって開始された送信トランザクションの数を示すために使用される線形カウンター。リプレイ攻撃を防ぐ上でも重要です。
2. balance : アカウントが所有するイーサ (ETH) の wei 建ての量。
3. codeHash : アカウントに含まれる EVM 実行可能コードのハッシュ。EVM (Ethereum Virtual Machine) は、単純な「送信」トランザクションを超えた複雑な状態遷移を処理する Ethereum のカスタム実行環境です。アカウントのコード コンテンツは、EVM を通じて Ethereum ブロックチェーン上で特定の形式の状態遷移を実行するように不変にプログラムされています。
4. storageHash : アカウントのストレージ ルートのハッシュ。アカウントのストレージ コンテンツを、マークル パトリシア トライのルート ノードの 256 ビット ハッシュとして表すために使用されます。簡単に言えば、アカウントのコード コンテンツに関連する状態変数データのハッシュです。

これら 4 つのフィールドの内容は、アカウントの種類を定義するために使用され、最終的にはその機能の範囲を定義します。したがって、Ethereum アカウントには次の 2 つの種類があります。

1. 外部所有アカウント (EOA) — 暗号化キー ペアとして初期化されます。

• 暗号化可能でランダムであることが証明できる 64 桁の 16 進文字である秘密鍵とその補完的な対応物。
• ECDSA (楕円曲線デジタル署名アルゴリズム) を使用して秘密鍵から派生した公開鍵。

EOA には空の codeHash フィールドと storageHash フィールドがあり、秘密鍵を所有するユーザーのみが制御できます。EOA のアドレスは、アカウントの公開鍵の keccak-256 ハッシュの最後の 20 文字に「0x」をプレフィックスとして追加することで、対応する公開鍵から取得できます。

2. 既存の EOA によってのみ作成できるコントラクト アカウント(CA)。これらは、EOA が EVM に実行可能コード コンテンツを展開することによって初期化されます。このコード コンテンツ (codeHash として保存) は EVM に格納され、ロジックと相互作用を定義することでアカウントを制御する役割を担います。

コントラクト アカウントからのトランザクションは、デプロイされたコードのロジックに基づいて完全にプルベースで行われます。これらのアカウントはコード コンテンツによってのみ制御できるため、秘密鍵は必要なく、公開鍵のみを持ちます。したがって、コントラクト アカウントのコード コンテンツを更新/変更できるエージェントであれば誰でも、その残高にアクセスできます。コントラクト アカウントのアドレスは、コントラクトのデプロイ時点までの、作成者のアドレスと nonce から派生します。

取引

先日、アカウントはイーサリアム上でトランザクションを送信する機能を持つエンティティであると説明しました。したがって、アカウントの主な目的はトランザクションの送受信であり、ブロックチェーンはトランザクションの履歴を記録する台帳として機能し、ブロックチェーン プロトコル仕様で説明されているルールに基づいてトランザクションがアカウント フィールドをどのように変更するかを記述することがわかります。

では、これらの「取引」とは何でしょうか?

トランザクションはアカウントから送信される操作であり、ネットワークの「状態」を変更します。トランザクションはアカウントからの暗号署名された命令であり、実行されるとネットワーク全体の状態が更新されます。

許可なしの場合には、逆効果のインセンティブというコストが伴います。これに対処するには、そのような環境でのやり取りに対して厳格なガイドライン (または有効性ルール) を定義する必要があります。このコンテキストでは、トランザクションが有効とみなされ実行されるためには、トランザクションは特定の有効性ルールに従う必要があります。これらの有効性ルールのほとんどは、トランザクションを送信するアカウントに課される制約を通じて実装され、アカウントの種類によって異なります。

アカウントと取引の有効性

Ethereum では、EOA はエンドユーザー向けであるため、使いやすさが最適化されています。特定の方法でトランザクションを送信し、完全に自律的に動作する機能があります。EOA はローカルで作成することもできますが、より一般的な方法は MetaMask、Rainbow、Rabby などのウォレット プロバイダーを使用することです。

一方、コントラクト アカウントは、「呼び出された」ことに応じて、ロジックによって許可されたトランザクションのみを送信できます。また、コントラクト アカウントは、状態ストレージの支払いに十分な残高を持つ EOA によってのみ作成できます。

より高レベルで説明すると、EOA は残高のみを保持できますが、CA は残高と、この残高をどのように使用できるかを指示するロジックの両方を保持できます。これらのプロパティは、アカウントのトランザクションが従う必要があるルールを定義する次のロジック パラメータによるものです。

1. 認証ロジック- アカウントが残高やロジックを変更する際にネットワークに対して ID を証明する方法を定義するために使用されます。
2. 承認ロジック- アカウントのアクセス ポリシー (つまり、アカウントの残高やロジックにアクセスして変更できるユーザー) を定義するために使用されます。
3. ノンス ロジック- アカウントからのトランザクションが実行される順序を定義します。
4. ガス支払いロジック- トランザクションのガス料金の決済を担当する当事者を定義するために使用されます。
5. 実行ロジック- アカウントが送信できるトランザクションの形式、またはトランザクションの実行方法を定義するために使用されます。

これらのパラメータは、EOA に対して厳格に設計されているため、次のようになります。

• 認証と承認は ECDSA ベースの秘密鍵によって提供されます。つまり、EOA からトランザクションを送信するユーザーは、秘密鍵を使用してアカウントにアクセスし、残高を変更する権限があることを証明する必要があります。
• nonce ロジックは、シーケンシャル カウンター スキームを実装します。これにより、アカウントごとに、一意の nonce ごとに 1 つのトランザクションのみが順次実行されます。
• ガス支払いロジックでは、トランザクションのガス料金は送信者/発信元アカウントによって決済される必要があることを指定します。
• 実行ロジックでは、EOA が次のトランザクション フォームのみを送信できることを指定します。

1. 2 つの EOA 間の定期的な転送。
2. 契約の展開。
3. デプロイされたコントラクト アカウントのロジックを対象とするコントラクト呼び出し。

より一般的には、EOA の実行ロジックにより、有効な署名ごとに 1 つのトランザクションに制限されます。

一方、CA では次のパラメータに関してより柔軟性があります。

• トランザクションは本質的に結果的/プルベースであるため、認証は必要ありません。
• CA の承認には 2 つの形式があります。

1. アカウントのスマート コントラクトのロジックとその不変条件に応じて、CA のコンテンツ コードを「呼び出す」(またはそのスマート コントラクトを実行する) 機能。
2. CA コンテンツ コードを変更する機能。これは主に、コンテンツ コードがアップグレード可能かどうかによって決まります。

実際のほとんどのケースでは、この場合に使用されるロジックは、CA のロジックの変更を有効にするために、特定のアカウント (通常は EOA) から N 個のうち M 個の有効な署名 (M < N) が必要であると規定するマルチ署名スキームです。

• トランザクションの順序付けは、緩やかに nonce ベースです。CA 自体は、可能な限り多くのさまざまな呼び出し元にトランザクションを送信できますが、各呼び出し元は自身の機能に基づいて制限されます。
• ガスの支払いは通常、CA ロジックの呼び出し元によって処理されます。
• CA の実行ロジックはより多様化しており、マルチコール トランザクションやアトミック トランザクションなどの UX 改善が可能になります。

これらの機能を評価すると、各タイプのアカウントは自律性とプログラム可能性の間でトレードオフを持つように設計されていることがわかります。

EOA は完全な自律性を持っていますが、プログラム可能性は限られています。いつでもトランザクションを承認して送信できますが、これらのトランザクションが有効と見なされるには、厳格な形式に従う必要があります。コントラクト アカウントは完全なプログラム可能性 (EVM の設計によってのみ制限されます) を持っていますが、自律性は限られています。そのトランザクションは厳格な形式に従う必要はありませんが、ロジックが最初に呼び出されるため、送信のみ可能です。

次のサブセクションでは、このシリーズ全体で説明した各 EIP の命題を完全に理解するために、これらの設計上の選択の意味を検討します。

イーサリアムのアカウント問題

さまざまなアカウントの機能についてある程度簡潔に理解できたので、それぞれのセールスポイントと、Ethereum のユーザーと開発者の両方のエクスペリエンスに与える問題を簡単に特定できます。前述したように、EOA はエンドユーザーを対象としたファーストクラスのアカウントとして設計されています。アプリケーションは EOA と簡単にやり取りできるように設計されており、複雑さはほとんどなく、もちろん作成コストもかかりません。ただし、厳密に決定論的に設計されているため、そのシンプルさは目新しさの大幅な喪失を伴います。

彼らを取り巻く懸念のいくつかは次のとおりです。

1. 量子攻撃に対する脆弱性– キーペアで使用される ECDSA 署名方式は量子耐性がなく、産業用量子システムが実現するまでのタイムラインが 5 ～ 10 年と楽観的に見積もられているため、暗号証明とセキュリティのために ECDSA 方式に大きく依存している Ethereum とそのアプリケーションにとって、これは大きな脅威となります。
2. 表現の欠如– EOA の有効性ルールの厳格な形式により、ユーザーはトランザクションの原子性やバッチ処理、トランザクションの委任などの機能を使用して、トランザクションをより簡潔に表現することができません。
3. 自己持続性– トランザクションの途中で「ガスがなくなった」という瞬間を誰もが経験したことがあるでしょう。これは、EOA がトランザクションのガスを自分で決済する必要があるためです。これは、イーサ (ETH) が唯一の許容ガス通貨でなければ、それほど難しいことではありません。これはアカウントベースのステートマシン (および UTXO ベースのステートマシン) の一般的な問題ですが、Ethereum は常に異なることを意図していました。

誰もが常に ETH を保有したい（または保有できる）わけではありません（つまり、価格変動を見てください）。そのため、実行可能な解決策としては、複数のガス通貨を許可する（これは難しすぎるため、ここの「通貨」セクションで説明されているように、多くの不変条件が破られます）か、ガスの支払いをトランザクションの発信元ではない別のアカウントで決済できるようにするかのいずれかになります。

アカウント スペクトルのもう一方の端では、CA は開発者やより技術的なユーザー ベースを対象としています。CA はスマート コントラクトの媒体として機能し (つまり、スマート コントラクトはそこに含まれるロジックまたはコード コンテンツであると考えられます)、EVM によって有効化される新しいトランザクション形式を実装できます。

しかし、これらすべての機能にもかかわらず、自律性がないため、これらは二流のアカウントに過ぎません。その欠点のいくつかは次のとおりです。

1. 完全な自律性の欠如- CA はトランザクションを開始できず、非常に特殊な方法で呼び出された場合に応答してトランザクションを送信することしかできません。
2. ロジックにおけるヒューマンエラーの脆弱性– 厳密性の欠如により、不変条件やその他のロジックの誤った定義につながることが多く、スマート コントラクトの悪用やハッキングにより数十億ドルの損失が発生しています。ただし、これはほぼ完全に異なるトピックであり、ここでは取り上げません。

このサブセクションで定義された問題につながる設計上の選択を確認した後、提案されたソリューションの評価に進むことができます。

アカウント抽象化のタイムライン

抽象化できるものを探すには、現在のアカウント設計の (ある程度の) 全体像が必要です。このセクションでは、Ethereum 上のアカウントが実際にどのようなものであるか、およびそのトランザクションがどのように検証され実行されるかについて、ある種の復習として主に説明します。

アカウント抽象化の概念 (少なくともスマート アカウント経由) は、常に Ethereum のロードマップの不可欠な部分でした。その実装を取り巻く複雑さが Ethereum のローンチをさらに遅らせる恐れがあったため、現在の設計では廃止され、異なるアカウントが異なる機能を提供するようになりました。これは Ethereum が The Merge に注力したために再び遅れましたが、現在はネットワークの次のメジャー アップグレードである Pectra の主要部分として再浮上しています。ただし、その複雑さは依然として大きな欠点と見なされており、特に Ethereum がロールアップ中心のロードマップに方向転換したため、その定着を妨げています。

要件は現在 2 つあります。

1. アカウント標準は、自律性を失うことなく、より表現力豊かにする必要があります。EOA 標準と CA 標準の間の隔たりを埋める新しい標準です。
2. 新しい標準は、Ethereum とその L2 エコシステム全体で完全な互換性を維持しながら、EOA と CA 間のギャップを埋める必要があります。

直感的に、この概念はチェーンの抽象化と相互運用性の文脈でより大きな役割を果たします。ただし、このレポート全体の範囲は、アカウントの抽象化自体を実現するために講じられた技術的な取り組みに限定されています。

アカウント抽象化の目的は、EOA と CA の最良の機能を新しいアカウント標準であるスマート アカウントに統合することです。スマート アカウントでは、アカウントの有効性ルールを検証ロジックと実行ロジックに完全にまたは部分的に分離できます。これにより、アカウントは、EVM で許可されているように、契約アカウントと同様に独自の有効性ルールを定義できると同時に、外部所有のアカウントと同様に完全に自律的になります。

スマート アカウントとスマート コントラクト ウォレットの違いについては混乱が生じることが多いため、以下でその違いを明確に説明しましょう。

• スマート アカウントは、プログラム可能性と自律性を同等に提供するように概念化された Ethereum アカウントです。EOA と CA はどちらも、ネットワークによって課せられた有効性ルールを必要に応じてカスタムの有効性ルールに置き換えることができるメカニズム (ERC 4337 など) を利用するだけで、スマート アカウントになることができます。
• 一方、スマート コントラクト ウォレットは、コントラクト アカウントへのインターフェイスとして機能する単なるウォレット プロバイダーです (そうです、ウォレットはアカウントではありません)。

スマート コントラクト ウォレットの商用化により、より広範な市場で CA の採用が容易になり、技術に詳しくないユーザーでも CA が提供する機能を活用できるようになりました。しかし、CA に関連する落とし穴は依然として存在します。

会話に戻りますが、アカウントのトランザクションの有効性ルールを定義するために使用されるパラメータについては以前に説明しました。

• 認証
• 承認
• ノンスロジック
• ガス支払いロジック
• 実行ロジック

最初の 4 つのパラメータの値は、総称してアカウントの検証ロジックと呼ばれ、トランザクションの実行が開始される前に行われるチェックです。最後のパラメータは、トランザクションの実行をどのように進めるかを定義します。

はじめに、さまざまな提案された設計を分類する形で、現在の AA ランドスケープの概要を説明しました。ここでは、Ethereum のアカウント ジレンマに対する最初のクラスのソリューションである EOA プログラマビリティに焦点を当てます。

プログラム可能なEOA

Ethereum の最大の魅力は、その主要な流動性シンクであるさまざまな分散型アプリケーションを特徴とする、まだ若いが活気のある DeFi エコシステムです。これらの DApp のほとんどは EOA を提供するために最適化されているため、コントラクト アカウント、さらにはスマート アカウントとのインターフェイスが困難です。この場合、スマート コントラクト ウォレットはコントラクト アカウントに役立ちますが、独自の制限があり、UX もまったく異なります。

DApp とウォレット プロバイダーの両方がスマート アカウント標準に慣れるまでの暫定的な解決策として、EOA に一時的な機能強化を提供して、検証や実行ロジックなど、課せられた制限のほとんどを克服できるようにすることが検討されています。以下では、EOA のプログラミング可能性への実用的なルートを提供する 3 つの主要な EIP の仕様について説明します。あまり知られていないEIP 5806から、野心的なEIP 3074 、そして最終的に勝利を収めたEIP 7702までです。

EIP-5806によるプログラミング

この提案は、コントラクト アカウントのロジック (スマート コントラクト) へのデリゲート呼び出しを許可することで、EOA 標準にさらに多くの機能をもたらすことを目指しています。これにより、スマート コントラクトは呼び出し元の EOA のコンテキストで効果的に実行されます。つまり、EOA は検証ロジックを制御したまま、実行ロジックは対応するコントラクト アカウントのロジックによって処理されます。

先に進む前に、Ethereum の進化の記憶を辿ってEIP-7まで行きましょう。EIP-7 は、 0xf4/DELEGATECALLオペコードの作成を提案しました。これは、プライマリ アカウントの [送信者] および [値] フィールドの値を維持しながら、セカンダリ アカウントのロジックを使用してプライマリ アカウントにメッセージ呼び出しを送信するために使用されます。言い換えると、プライマリ アカウントは、メッセージ呼び出しで指定された期間、セカンダリ アカウントのロジックを「継承」(または借用) し、後者のロジックが前者のコンテキストで実行されるようにします。

このオペコードにより、dapp 開発者は相互依存性を維持しながらアプリケーションのロジックを複数のスマート コントラクトに分割できるようになり、コード サイズの障壁やガス障壁を簡単に回避できるようになりました。EIP-5806 は、コントラクト アカウントの相互依存性を許可する以外に、DELEGATECALL オペコードの新しい用途を見つけます。具体的には、EIP-5806 は EIP-7 を参考にして、デリゲート呼び出し機能を EOA にも拡張することを提案しています。つまり、EOA がコントラクト アカウントと相互依存性を持つようにしましょう。そうしない理由はありません。

EIP-5806仕様

EIP 5806 では、次のようにパッケージ化された新しいEIP-2718 準拠のトランザクション タイプが導入されています。

 rlp([chainID, nonce, max_priority_fee_per_gas, max_fee_per_gas, gas_limit, destination, data, access_list, signature_y_parity, signature_r, signature_s]).

これらのトランザクションは、受信者のアドレスを表す [to] フィールドが 20 バイトの入力としてのみアドレスを受け入れるように設計されており、送信者がCREATEオペコードを使用できなくなります。

RLP スキームの各コンポーネントの背後にある動機は次のとおりです。

• chainID : 現在のチェーンの EIP-115 準拠の識別子 (32 バイトにパディング)。この値はリプレイ攻撃保護を提供し、元のチェーン上のトランザクションが、同様の履歴を持ち経済的なセキュリティが低い代替 EVM チェーンに簡単に複製されないようにします。
• nonce : 各トランザクションの一意の識別子。リプレイ攻撃からの保護も提供します。
• max_priority_fee_per_gas と max_fee_per_gas : EIP-5806 トランザクションがそれぞれ順序付けと包含に対して支払うガス料金の値。
• gas_limit : 単一の 5806 タイプのトランザクションが消費できるガスの最大量。
• 宛先: トランザクションの受信者
• データ: 実行可能コードの内容
• access_list : EIP-5806 トランザクションを実行することを条件付きで承認されたエージェント。
• signature_y_parity、signature_r、および signature_s : これら 3 つの値は、メッセージに対する secp256k1 署名を表します — keccak256 (TX_TYPE || rlp ([chainID, nonce, max_priority_fee_per_gas, max_fee_per_gas, gas_limit, destination, data, access_list])).

EIP-5806 トランザクションを EIP-2718 エンベロープにパッキングすると、下位互換性が大幅に向上しますが、EOA はコントラクト アカウントと同等ではありません。そのため、不変の破損を防ぐために、EOA がデリゲート呼び出しを利用する方法に特定の制限を定義する必要があります。

これらの制限は次のオペコードを対象としています。

• SSTORE/0x55 : このオペコードにより、アカウントはストレージに値を保存できます。これは、EOA がデリゲート呼び出しを使用してストレージを設定/アクセスするのを防ぐために EIP-5806 トランザクションで制限されており、アカウントの移行によって将来発生する可能性のある潜在的な問題を防止します。
• CREATE/0xF0 、 CREATE2/0xF5 、およびSELFDESTRUCT/0xFF : これらのオペコードにより、呼び出し元は広範囲に新しいアカウントを作成できます。これらへのアクセスは、EIP-5806 トランザクションの実行中に、別の実行フレーム (この場合はコントラクトの作成/破棄) で EOA の nonce が変更されるのを防ぐために制限されています。これにより、トランザクションが連続した nonce を運ぶという期待が無効になるのを防ぎます。

EIP-5806の潜在的用途

EIP-5806 の主な適用範囲は、EOA の実行抽象化です。EOA が単純なロジックの呼び出しを超えてスマート コントラクトと信頼性なく対話できるようにすることで、次のような機能が実現します。

• トランザクションの条件付き実行
• トランザクションのバッチ処理
• マルチコールトランザクション（承認と通話など）

EIP-5806に対する批判

EIP-5806 で提案された変更は、必要な機能を有効にする一方で、特に目新しいものではありません。その存在は、主にすでに機能している EIP-7 を前提としています。これにより、承認の際の多くの潜在的なハードルを回避できます。

初期に表明された大きな懸念の 1 つは、現在の CA と同様に、EOA がストレージにアクセスして変更できるようにすると潜在的なリスクが生じるというものでした。これは、EOA のトランザクション方法に関するネットワークに定められた多くの不変条件を破るため、前のサブセクションで説明した制限を導入することで対処されました。

2 つ目の批判 (これは両刃の剣です) は、EIP-5806 のシンプルさです。EIP-5806 では実行の抽象化のみが可能で、それ以外はあまり何もできないため、EIP-5806 を受け入れることによるメリットはコストに見合わないのではないかという意見もあります。EIP-5806 をオプトインする EOA の場合、その他のすべての有効性制限はネットワーク定義のままです。これは、次のサブセクションで説明する他のやや類似した EIP とは対照的です。

EIP-3074によるプログラミング

EIP-3074 は、特定の形式のトランザクションに対して、EOA の承認ロジックにインボーカーと呼ばれる特殊な契約アカウントの承認ロジックを重ね合わせることで、EOA が検証ロジックの大部分をインボーカーと呼ばれる特殊な契約アカウントに委任できるようにすることを提案しています。これは、インボーカーのアクセス ポリシーをインボーカー コントラクトに署名することで実現され、インボーカー コントラクトは EOA のアクセス ポリシーの定義を担当します。

この EIP では、EVM に 2 つの新しいオペコードを追加することを提案しています。

• [AUTH]は、コンテキスト変数 [authorized] アカウントを、後者の ECDSA 署名に基づいて、2 番目の [authority] アカウントに代わって動作するように設定します。
• [AUTHCALL]は、[authorized] アカウントから [authority] アカウントへの呼び出しを送信/実装します。

これら 2 つのオペコードにより、EOA は事前に確立された CA に制御を委任し、契約を展開してそれに関連するコストや外部要因を負担することなく、その CA を介して 1 つの CA として動作することができます。

EIP-3074仕様

EIP-3074 では、トランザクションが[MAGIC]署名形式を使用して、他のトランザクション署名形式との衝突を防ぐことができます。 [AUTHCALL]指示が渡されるアクティブ アカウントは、[authorized] という名前のコンテキスト変数フィールドとして定義されます。これは単一のトランザクションを通じてのみ存続し、新しい[AUTHCALL]ごとに再定義する必要があります。

各オペコードの複雑さについて説明する前に、EIP-3074 トランザクションに関係するエンティティは次のとおりです。

• [権限] : アクセス/制御を 2 番目のアカウント (通常は契約アカウント) に委任するプライマリ署名アカウント (EOA)。
• [authorized] : [AUTHCALL]命令が実行のために渡されるアカウント。つまり、[invoker] によって定義された制約を使用して、[authority] に代わって[AUTHCALL]のロジックが実行されるアカウントです。
• [invoker] : [authorized] アカウントと[AUTHCALL]のロジック間のやりとりを管理することを目的とした補助契約。特に後者の契約コードの主なロジックがガススポンサーシップである場合に使用されます。

呼び出し側コントラクトは、[authority] から [COMMIT] 値を持つ[AUTH]メッセージを受信します。この値は、アカウントが [authorized] による[AUTHCALL]命令の実行に対して課す制限を定義します。したがって、呼び出し側は、[authorized] アカウントで定義されている [ contract_code ] が悪意のあるものではなく、プライマリ署名アカウントによって [COMMIT] 値に設定された不変条件を満たす能力があることを確認する責任があります。

[AUTH]オペコードには 3 つのスタック要素入力があります。簡単に言えば、1 つの出力を計算する 3 つの入力によって定義されます。これらの入力は次のとおりです。

1. 機関: 署名を生成するEOAのアドレス
2. オフセット
3. 長さ

最後の 2 つの入力は、0 から 97 までの変更可能なメモリの範囲を記述するために使用されます。

1. [memory(offset : offset+1)] – [yParity]
2. [memory(offset+1 : offset+33] – [r]
3. [memory(offset+33 : offset+65)] – [s]
4. [memory(offset+65 : offset+97)] – [COMMIT]

変数 [yParity]、[r]、[s] は、メッセージ上の secp256k1 曲線上の ECDSA 署名 [magic] としてまとめて解釈されます。

[keccak256 (MAGIC || chainID || nonce || invoker address || COMMIT)]

どこ：

• [MAGIC]は、変数の組み合わせから生成される ECDSA 署名です。
• [chainID]は、同様の履歴を持ち経済的なセキュリティが低い代替 EVM チェーンにリプレイ攻撃保護を提供するために使用される、現在のチェーンの EIP 115 準拠の識別子です。
• [nonce]はトランザクション署名者のアドレスの現在の nonce で、左側が 32 バイトにパディングされます。
• [invokerAddress]は、 [AUTH]の実行ロジックを含むコントラクトのアドレスです。
• [COMMIT] は、呼び出し元の前処理ロジックで追加のトランザクション有効条件を指定するために使用される 32 バイトの値です。

計算された署名が有効で、署名者のアドレスが [authority] と等しい場合、[authorized] フィールドは [authority] によって提供された値に更新されます。これらの要件のいずれかが満たされない場合、[authorized] フィールドは以前の状態のまま、または未設定の値として変更されません。

このオペコードのガスコストは、次の合計として計算されます。

1. [ecrecover] プリコンパイルの固定料金と、keccak256 ハッシュと追加ロジックの追加料金は 3100 ユニット相当です。

2. [RETURN] オペコードと同様に計算され、現在の割り当ての指定範囲（97 単位）を超えてメモリが拡張されたときに適用されるメモリ拡張料金。

3. 状態にアクセスするオペコードの価格設定ミスによる攻撃を防ぐために、ウォーム [権限] には 100 単位、コールド [権限] には 2600 単位の固定コストが発生します。

   
   

   ( AUTHメモリを変更しないように実装されており、[authority] の値を引数として取るため、提供された署名からその値を簡単に検証できます。)

[AUTHCALL]オペコードには、単一のスタック要素出力を計算するために使用される 7 つのスタック要素入力があります。

これは[CALL]オペコードと同じロジックを持ちます。つまり、アカウントにメッセージ呼び出しを送信し、そのコントラクト内の特定のロジックをトリガーするために使用されます。ロジックの唯一の違いは、 [AUTHCALL]実行を続行する前に [CALLER] の値を設定するように設計されていることです。

したがって、 [AUTHCALL]は [authority] によって使用され、次のように論理チェックが進行して [authorized] のコンテキスト固有の動作をトリガーします。

1. [authorized] の値を確認します。設定されていない場合、実行は無効とみなされ、フレームはすぐに終了します。これにより、前例のない失敗による不当な請求を防ぐことができます。
2. [authorized] の意図した動作のガスコストをチェックします。
3. [gas] オペランドの EIP-150 準拠値をチェックします。
4. [authority] の残高にある合計ガスコスト –[value]– が利用可能かどうかを確認します。
5. [authority] のアカウントの残高から [value] を差し引いた後に実行が行われます。[value] が残高より大きい場合、実行は無効になります。

[AUTHCALL]のガスコストは、次の合計として計算されます。

• [warm_storage_read]を呼び出すための固定コスト
• メモリ拡張コスト[memory_expansion_fee]は、 [CALL]オペコードのガスコストと同様に計算されます。
• 動的コスト[dynamic_gas]
• サブコールの実行コスト[subcall_gas]

[AUTHCALL]から返されるデータには、次の方法でアクセスします。

• [RETURNDATASIZE] – 戻りデータバッファのサイズを出力スタックにプッシュします。
• [RETURNDATACOPY] – 戻りデータ バッファーからメモリにデータをコピーします。

技術的な用語をあまり使わずにまとめると、Ethereum トランザクションでは通常、次の 2 つの値が指定されます。

1. tx.origin – トランザクションの承認を提供します。
2. msg.sender – トランザクションが実際に発生する場所。

前述のように、EOA では、承認は実行と密接に結びついています (つまり、( tx.origin == msg.sender ))。この単純な不変条件により、このレポートの「アカウントとトランザクションの有効性」サブセクションで説明したほとんどの問題が発生します。

[authority] からの[AUTH]メッセージにより、 msg.sender のままで tx.origin 関数を [authorized] にオフセットできます。また、[COMMIT] 値を使用してこの権限に制限を定義することもできます。 [AUTHCALL]により、[authorized] は [invoker] を仲介として使用して、アクセスするコントラクトが無害であることを確認しながら、コントラクトのロジックにアクセスできます。つまり、すべての[AUTHCALL]に対して、[authorized] は [COMMIT] に特定の [invoker] を指定します。

EIP-3074の潜在的用途

EIP 3074 は主に、EOA が認証ロジックを別のアカウントに委任できるようにすることを担当していますが、そのオープン設計により、さまざまなコンテキストでさらに多くのことが可能になります。EOA の検証ロジック全体は、必要に応じて呼び出し側にさまざまな制約/革新を適用することで抽象化できます。ターゲット ロジックに基づく可能な設計には、次のものがあります。

• ノンス ロジック: EIP-3074 では、 [AUTH]メッセージを送信した後も EOA のノンスがそのまま残りますが、一方で[AUTHCALL]ごとのノンスは、どの呼び出し元と対話しているかによって異なります。このようにして、EOA のノンスの並列処理が可能になり、EOA は必要に応じて複数の重複しない[AUTHCALL]を送信できます。
• ガス支払いロジック: EIP で指定されているように、インボーカーはガス スポンサーシップを許可するように設計できます。そのため、ユーザーの [COMMIT] のガス料金は、トランザクションの発信元から差し引くか、個人アカウントまたはサービスベースのリレー (ガス スポンサーシップ サービス) などのサポート アカウントから差し引くことができます。また、実行ロジックは直感的に抽象化されています。結局のところ、インボーカー (CA) は EOA に代わってトランザクション リクエストを実行する責任を負います。

EIP-3074に対する批判

呼び出し側の集中化

著者の一人の言葉を引用すると、「ウォレットが任意の呼び出し元に署名する機能を公開することは期待していません... 」。おそらく、3074 イニシアチブが抱える最大の問題は、その上でのイノベーションが、イーサリアムの MEV (最大抽出可能値) および PBS (提案者とビルダーの分離) 市場の現在のイテレーションのように、許可された独自の取引フローに非常に簡単に傾くことです。

デフォルトでは、現在可能な攻撃よりもさらに悪質な攻撃を防ぐために、インボーカー コントラクトを徹底的に監査する必要があります。これにより、影響力のある人物によって開発された少数のインボーカー コントラクトのみがウォレット開発者のデフォルトとして採用されるエコシステムが必然的に生まれます。したがって、これは次のトレードオフに帰着します。

• ユーザーのセキュリティを危険にさらしながら、呼び出し側の契約を継続的に監査しサポートするという困難な分散型の道を進む
• 確立された評判の良いソースからの呼び出し側契約を採用することで、ユーザーのセキュリティがより確実に保証され、契約の安全性に対する監視が少なくなります。

この点のもう 1 つの側面は、機能的で安全なインボーカーの設計、監査、マーケティングに関連するコスト関数です。小規模なチームは、製品が優れていても、すでにある程度の評判を確立している大規模な組織 (特にマーケティングの面) にほぼ必ず負けてしまいます。

前方互換性の問題

EIP-3074 は、ECDSA 署名スキームを定着させます。これは、呼び出し側によって導入された認証スキームよりも有効であると考えられているためです。量子耐性は現時点では決定的な問題ではない (そして、ECDSA が改ざんされる可能性がある将来には、さらに深刻な問題が発生する) という議論もありますが、Ethereum のやや暗黙の目標は、常にそのような問題に先んじることです。量子耐性と検閲耐性を犠牲にして UX をわずかに改善することは、近い将来には最善の選択ではないかもしれません。

前方互換性に関する議論のもう 1 つのポイントは、3074 の利点がまだ評価されている一方で、ERC-4337 (プロトコルの変更を必要としない) が現在大きな市場を持っているため、エコシステムの区分化を避けるために、ERC-4337 との互換性も確保する必要があるということです。ネイティブ アカウント抽象化ロードマップがあっても、 [AUTH]および[AUTHCALL]オペコードは EVM で最終的に廃止され、わずかな UX 改善を実現するために、Ethereum に多大な技術的負債をもたらすことになります。

ECDSA スキームの取消不能

[AUTH]メッセージを送信して制御を委任した後、EOA は通常の秘密鍵認証スキームを回避することが期待されます。これは、「通常の」トランザクションを送信すると、すべての呼び出し元に委任された認証が取り消されるためです。したがって、ECDSA スキームは、関連する契約によって有効になる可能性のある他のどの認証スキームよりも厳密に優先されます。つまり、秘密鍵が失われると、アカウントの資産が完全に失われることになります。

EIP-7702によるプログラミング

この提案は当初、EIP 3074 のややミニマルなバリエーションとして始まり、EIP 3074 のアップデートとなることも意図されていました。この提案は、EIP 3074 の非効率性、特にすでに繁栄している 4337 エコシステムやネイティブ アカウント抽象化提案である RIP 7560 との非互換性に関する懸念に対処するために生まれました。

そのアプローチは、新しい EIP 2718 準拠のトランザクション タイプ[SET_CODE_TX_TYPE]を追加することです。これにより、EOA は指定されたトランザクションのスマート アカウントとして動作できるようになります。この設計により、ネイティブ アカウント抽象化ロードマップおよび既存のイニシアチブとの互換性を維持しながら、EIP 5806 と同じ機能とそれ以上の機能が有効になります。

EIP-7702仕様

EIP-7702 では、EOA が[SET_CODE_TX_TYPE] 2718 準拠のトランザクション形式を通じて契約のコード コンテンツを「インポート」できます。

 rlp([chain_id, nonce, max_priority_fee_per_gas, max_fee_per_gas, gas_limit, destination, value, data, access_list, authorization_list, signature_y_parity, signature_r, signature_s])

このペイロードは、EIP 5806 のペイロードと完全に似ていますが、「承認リスト」が導入されている点が異なります。このリストは、次の形式の値の順序付けられたシーケンスです。

[[chain_id, address, nonce, y_parity, r, s], ...]

各タプルは [address] の値を定義します。

先に進む前に、 SET_CODE_TX_TYPEに関係する当事者は次のとおりです。

• [authority] : EOA/プライマリ署名アカウント
• [アドレス] : 委任可能なコードを含むアカウントのアドレスです。

[authority] が [address] を指定してSET_CODE_TX_TYPEに署名すると、委任指定子が作成されます。これは「ポインタ プログラム」であり、これにより [authority] のアクションによるすべてのコード取得要求がいつでも [address] の観測可能なコードに送信されます。

各[chain_id, address, nonce, y_parity, r, s]タプルについて、7702 タイプのトランザクションのロジック フローは次のようになります。

1. 提供されたハッシュから [authority] の署名を検証するには、 authority = ecrecover(keccak(MAGIC || rlp([chain_id, address, nonce])), y_parity, r, s]を使用します。
2. チェーンの ID を検証することで、クロスチェーン リプレイ攻撃やその他の攻撃ベクトルを防止します。
3. [authority] にすでにコード コンテンツがあるかどうかを確認しています。
4. [authority] の nonce がタプルに含まれる nonce と等しいことを確認するための nonce チェック。
5. トランザクションが [authority] の最初のSET_CODE_TX_TYPEトランザクションである場合、 PER_EMPTY_ACCOUNT_COST手数料が課金されます。残高がこの手数料の値より少ない場合、操作は中止されます。
6. 委任指定が行われ、[権限]のコードが[アドレス]のポインタに設定されます。
7. 署名者（[authority]）の nonce が 1 増加します。
8. [authority] は、アクセスされたアドレスのリストに追加されます。これは、(簡略化して言えば) トランザクションのスコープが元に戻されると、元に戻されたスコープに入る前の状態に戻るように作成されたアドレスのセットです。これは、再利用可能な値のキャッシュを可能にし、不要な課金を防ぐために、 EIP-2929で定義されているとおりです。

ふぅ！ まとめると、この EIP により、EOA は、契約のコードへのポインターを設定するトランザクションを送信できるようになり、後続のトランザクションでこのロジックを独自のものとして実装できるようになります。このように、この EIP は、EOA が実際にコード コンテンツを必要なだけ保持できるため、EIP 5806 よりも強力です (EIP 5806 では、EOA がデリゲート呼び出しを送信することしかできません)。

EIP-7702の潜在的用途

実行の抽象化

EOA は実行したいロジックを積極的に取り込むため、もはや抽象化ではないと主張することもできますが、それでも EOA はロジックの「主たる所有者」ではありません。また、ロジックを直接含むわけではなく、ロジックへのポインターを指定するだけです (計算の複雑さを軽減するため)。そのため、実行抽象化を採用します。

ガススポンサーシップ

require(msg.sender == tx.origin)不変条件は破られ、自己スポンサーシップが許可されますが、EIP ではスポンサー付きトランザクション リレイラーの統合が依然として許可されています。ただし、注意点として、このようなリレイラーには、グリーフィング攻撃を防ぐために、レピュテーション ベースまたはステーク ベースのシステムが必要です。

条件付きアクセスポリシー

EOA はアカウントのコードの特定の部分のみを指すことができるため、その部分のロジックのみがそのコンテキストで実行可能になります。

これにより、「権限のエスカレーション解除」を可能にするサブキーの存在も可能になり、特定の dapp は特定の条件下でのみアカウントの残高にアクセスできるようになります。たとえば、ERC-20 トークンは使用できるが ETH は使用できない、1 日あたり合計残高の最大 1% まで使用できる、特定のアプリケーションのみとやり取りできるなどの権限を想像できます。

クロスチェーンスマートコントラクトの展開

EIP-7702 トランザクションは非制限的な性質を持つため、ユーザーは CREATE2 オペコードにアクセスし、それを使用して、手数料市場ロジック (EIP-1559 や EIP-4844 など) などの他の制限パラメータなしで、アドレスにバイトコードを展開できます。これにより、同じバイトコードを使用して、複数のステート マシン間でアドレスを回復して使用できるようになります。各チェーンのアカウントは、他のコンテキスト変数パラメータを定義する責任を負います。

EIP-7702に対する批判

下位互換性の欠如

EIP-7702 はまだごく最近のものですが、すでに多くのプロトタイプ作成と依存関係や潜在的な欠点のテストが行われています。また、その最小限のモデルにより、さまざまなコンテキストで高い柔軟性と実用性が保証されています。ただし、不変条件があまりにも多く破られており、すぐには下位互換性がありません。EIP-7702 のロジックには次のものが含まれます。

1. トランザクション中の EOA nonce の変更: EIP-7702 は、一貫性を確保するために、オペコードを制限しません。つまり、EOA は、EIP-7702 トランザクションの実行中にCREATE 、 CREATE2 、 SSTOREなどのオペコードを実装でき、異なるコンテキストで nonce を増やすことができます。
2. ゼロ以外のcodeHash値を持つアカウントがトランザクションの発信者になることを許可する: EIP-3607 は、EOA と CA 間の「アドレス衝突」の潜在的な影響を減らすために実装されました。アドレス衝突は、EOA のアドレスの 160 ビット値が CA のアドレスの値と完全に等しい場合に発生します。

ほとんどのユーザーはアカウントの実際の内容に精通していません (アカウントとアドレスの違いさえも)。そのため、アドレスの衝突を許可すると、EOA が契約アカウントを装い、長々とユーザーの資金を引き寄せ、最終的にすべてを盗む可能性があります。EIP-3607 では、コードを含むアカウントが独自の承認ロジックを使用して残高を消費できないように規定することで、この問題に対処しました。ただし、EIP 7702 では、EOA がある程度プログラム可能になった後でも自律性を維持できるように、この不変条件が破られています。

EIP-3074との類似点

コード コンテンツではなくアカウントのアドレスに署名することは、基本的に 3074 の呼び出し元を使用したスキームと同じです。アドレスは異なるチェーンで異なるコード コンテンツを取る可能性があるため、チェーン間のコード コンテンツの一貫性について厳密な保証は提供されません。つまり、あるチェーンで同じロジックを含むコード コンテンツを持つアドレスが、別のチェーンでは略奪的または完全に悪意のあるものである可能性があり、ユーザーの資金が失われる可能性があります。

結論

現在の EOA は、EVM が提供するプログラミング機能をユーザーが利用できないため、非常に制限されています。アカウントをアップグレードするにはさまざまな方法がありますが、このレポートの冒頭で概説したように、選択したソリューションは安全でセキュアな自己管理の原則を維持する必要があります。さらに、EOA のアップグレードは、ユーザー エクスペリエンスとアプリケーション開発者の両方に大きな影響を与える可能性があるため、すべての関係者の意見を考慮する必要があります。

EOA が任意の方法でコードを実行できるようにすると、アカウントの機能が大幅に拡張されますが、この新しい表現力には重大なリスクと潜在的な不意打ちが伴います。これらのトレードオフを解決することは、Ethereum ユーザーに文句なしの UX メリットをもたらすアップグレードを提供するために不可欠です。

イーサリアムのオープンな議論の文化は、あらゆる設計のほぼすべての意味が専門家によって徹底的に分析されるため、このようなイノベーションの素晴らしいテストの場となります。この包括的な検討は、敵対者による不正行為のリスクを軽減するのに役立つはずです。

EIP-7702 は現在、EOA に EVM のプログラム可能性をもたらすことを目指すメカニズムの代表的存在であり、Pectra アップグレードの EIP 3074 のスロットの代替として位置付けられています。3074 のメカニズムのオープン設計を継承しながら、攻撃対象領域とリスクを大幅に低減しています。また、3074 の特定のクラスのオペコードに対する制限を回避することで、さらに多くのことが可能になります。

提案の設計にはまだ改良が加えられていますが、特に Vitalik が直接支援しているため、すでに開発者から多くの好意とサポートを得ています。コミュニティ内では、アカウント抽象化に対するこのアプローチはスマート アカウントよりも優れている可能性があるという主張があります。この解説では、この方法では変更が少なくて済み、それほど複雑ではないこと、および EOA がすでに制定されていることを強調しています。

しかし、イーサリアム ネットワークのあらゆるレベルでの量子耐性という将来のセキュリティのマイルストーンを忘れてはなりません。EOA 認証に ECDSA ベースの署名スキームを使用しているため、この量子安全性は現在のアカウント モデル コアでは実現不可能です。

したがって、EOA のプログラマビリティは、スマート アカウントへの道の途中のステップであり、目的地ではありません。EOA を強化し、ユーザーと開発者のエクスペリエンスを向上させながら、スマート アカウントの究極のアカウント抽象化の目標との互換性を維持します。

次回のレポートでは、EOA 移行スキームを詳しく調べて、アカウント抽象化ロードマップにどの程度適合するかを確認します。お楽しみに!