アカウントの抽象化は、ユーザーや開発者のエクスペリエンスを全体的に向上させることを目指しています。オンチェーンのエクスペリエンスをユーザーにとってよりアクセスしやすく楽しいものにするだけでなく、開発者がイーサリアム上でより強力なことを行い、ユーザーにさらに意味のある方法でサービスを提供できるようにもしています。

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

1. EOAの機能強化/プログラマビリティ:これには、EOA(外部所有アカウント)が有効性ルールの実行ロジック部分を再定義できるようにするプロトコルレベルの変更が含まれます。開発コミュニティでよく知られているように、EOAは通常、エンドユーザーに関連付けられたアカウントです。したがって、このアプローチに該当するソリューションでは、エンドユーザーアカウントは、現在の管理方法と比較して、承認できるアクションの種類をより詳細に制御できるようになります。
2. EOAの変換/移行：このアプローチは、EOA（外部所有者アカウント）をCA（コントラクトアカウント）に完全に変換することを目指す提案を含んでいます。このアプローチの主要なアイデアは、コントラクトアカウントがすでにスマートアカウントが提供するほとんどの利点を提供しているため、もはや複雑にする必要はないということです。誰もが単にスマートコントラクトウォレットを介してコントラクトアカウントを主要なアカウントとして使用すればよいということです。

このアプローチには、資産を移動せずにEOAからCAに移行することを可能にするメカニズムが備わっています。EIP 7377とEIP 5003（EIP 3074と併せて考えると）。

1. スマートアカウント：この提案グループには、EOAとCAの両方が「スマートアカウント」として振る舞えるようにするためのデザインが含まれており、それによって彼らは完全に自分の有効性ルールを再定義できます。

スマートアカウントの作成とアカウントの抽象化のプロトコルレベルでの確立について、以前にさまざまな提案が行われてきました；EIP-86そしてEIP-2938これらはよく引用されるもののいくつかです。しかし、この設計によって導入されるとされる複雑さと、イーサリアムがそのような複雑さに対して準備ができていないという多数派の意見により、多くの反対意見がありました。

The Merge後のVitalikの復活に続いて、ERC-4337スマートアカウント標準のオプトインバージョンとして提案され、MEV（最大抽出可能価値）のためのPBS（提案者-ビルダー分離）インフラストラクチャと類似しています。したがって、スマートアカウントの利点にアクセスしたいユーザーは、単純にERC-4337パイプラインを使用して、そのアカウントのロジックと取引の妥当性ルールを再定義することができます。これはUserOperation（またはUserOps）と呼ばれる構造体になります。

ERC 4337は、プロトコル外のエンシュラインされたスマートアカウントの代替として、現代のイーサリアムにスマートアカウントの利点をもたらしますが、複雑さをエンシュラインすることなく、そのままの複雑さを克服するためのものです。ただし、現在の状態ではインフラストラクチャが最適であるわけではなく、その複雑さはまだ重大な障害点です。

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

このレポートでは、EOAのプログラム可能性を探求し、このラインに沿ったさまざまなEIPを評価し、そのメリットと欠点について議論します。このシリーズのパート2と3では、イーサリアム内で探求されているアカウントの抽象化の残りの2つのアプローチのクラスをカバーします。

イーサリアムのアカウントとトランザクションに関する入門書

抽象化できるものを探すためには、経常勘定設計の(ある程度)全体像を把握する必要があります。このセクションは、主にイーサリアムのアカウントが実際に何であるか、そしてそれらのトランザクションがどのように検証され、実行されるかについての一種の改訂として機能します。

Ethereum accountsは、ether（ETH）のバランスとEthereumブロックチェーンでトランザクションを送信する能力を持つエンティティです。これらは、アカウントの保有物やトランザクションを指すユニークなポインターとして機能する42文字の16進数「アドレス」として表されます。

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

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

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

1. 暗号鍵ペアとして初期化された外部所有アカウント（EOA）:

• 暗号化可能で証明可能な64桁の16進数文字列であるプライベートキー、およびその補完的な対応物
• ECDSA（楕円曲線デジタル署名アルゴリズム）を使用して、秘密鍵から派生した公開鍵。

EOAは空のcodeHashとstorageHashフィールドを持ち、プライベートキーを所有する人によってのみ制御されることができます。アカウントのアドレスは、アカウントの公開キーのkeccak-256ハッシュの最後の20文字に「0x」を付けたものから取得できます。

1. 契約アカウント（CAs）- これは既存のEOAによってのみ作成されることができます。 EOAがEVM上で実行可能なコードコンテンツを展開することによって初期化されます。このコードコンテンツ（codeHashとして保存されます）はEVMにおいて確立され、アカウントを制御し、そのロジックと相互作用を定義することが責任を持ちます。

彼らの取引は完全にプルベースであり、展開されたコードのロジックに基づいています。

これらのアカウントは、コード内容によってのみ制御されるため、秘密鍵は必要ありません。ただし、公開鍵は持っています。したがって、契約アカウントのコード内容を更新/変更できる能力を持つエージェントは、その残高にアクセスすることができます。

CAのアドレスは、作成者のアドレスと契約の展開ポイントまでのnonceから派生します。

トランザクション

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

それでは、これらの「取引」とは何ですか？

取引は、アカウントから送信される操作で、ネットワークの「状態」に変更を引き起こします。それらはアカウントからの暗号化された署名付きの命令であり、実行されるとネットワーク全体の状態が更新されます。

無許可性は逆効果のインセンティブを伴いますが、これらに対処するためには、厳格なガイドライン（または有効性ルール）を定義する必要があります。

このコンテキストでは、トランザクションは特定の妥当性ルールに従って有効で実行可能でなければなりません。これらの妥当性ルールのほとんどは、トランザクションを送信するアカウントに配置された制約を介して実装され、アカウントの種類によって異なります。

アカウントとトランザクションの妥当性

イーサリアムでは、EOAはユーザビリティが向上しており、エンドユーザー向けに設計されています。特定の方法でトランザクションを送信し、完全に自律的に操作する能力を持っています。また、ローカルで作成することもできますが、より一般的な方法はMetaMask、Rainbow、Rabbyなどのウォレットプロバイダーの使用です。

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

より高度な説明は、EOAは残高しか保持できず、CAは残高と、この残高をどのように使うかを規定するロジックを保持できることです。

これらの特性は、アカウントの取引が従う必要があるルールを定義する次の論理パラメータによるものです。

1. 認証ロジック - アカウントが残高と/またはロジックを変更する際にネットワークに自分の身元を証明する方法を定義するために使用されます。
2. 認可ロジック-アカウントのアクセスポリシー、つまり、誰がアカウントの残高および/またはロジックにアクセスし、変更を加えることができるかを定義するために使用されます。
3. Nonceロジック - アカウントからのトランザクションが実行される順序を定義します。
4. ガス支払いロジック-トランザクションのガス手数料を解決する責任を持つ当事者を定義するために使用されます。
5. 実行ロジック-アカウントが送信できるトランザクションの形式、またはトランザクションの実行方法を定義するために使用されます。

これらのパラメータは、EOA向けに厳格に設計されています。

• 認証と承認は、ECDSAベースの秘密鍵によって提供されます。つまり、ユーザーは、彼らのEOAからトランザクションを送信したい場合は、そのアカウントにアクセスするために秘密鍵を使用し、そのバランスに変更を加える権利を持っていることを証明しなければなりません。
• nonceロジックは、ユニークなnonceごとに1つのトランザクションのみをアカウントごとに順次実行できるようにする順次カウンター方式を実装しています。
• ガス支払いロジックは、取引のガス手数料は送信元のアカウントによって清算されなければならないことを指定しています。
• 実行ロジックでは、EOAは以下のトランザクション形式のみを送信できることが指定されています:

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

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

一方、CAsにはこれらのパラメータについての柔軟性があります:

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

1. アカウントのスマートコントラクトのロジックと不変条件に依存する、CAsコンテンツコード（またはスマートコントラクト）を「呼び出す」能力。
2. CAsのコンテンツコードを変更できる能力は、主にコンテンツコードがアップグレード可能かどうかに依存します。

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

• 彼らの取引の順序付けは緩くノンスに基づいています。CA自体は、できるだけ多くの異なる呼び出し元に対して多くの取引を送信することができますが、各呼び出し元は自分自身の能力に基づいて制限されています。
• ガス料金は通常、CAのロジックの呼び出し元によって処理されます。
• CAsの実行ロジックは多様で、マルチコールトランザクションやアトミックトランザクションなどのUXの改善を可能にします。

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

EOAは完全な自律性を持ちますが、限定的なプログラム可能性があります。彼らはいつでもトランザクションを承認および送信することができますが、これらのトランザクションは厳格な形式に従わなければなりません。CAは完全なプログラム可能性を持っています（EVMの設計によってのみ制限されます）が、限定的な自律性を持っています。彼らのトランザクションは厳格な形式に従う必要はありませんが、彼らのロジックが最初に呼び出されるためにのみ送信されることができます。

以下のサブセクションでは、これらの設計選択肢の影響について研究し、このシリーズの各議論されたEIPの提案を完全に理解するために学びます。

イーサリアムのアカウントのジレンマ

今、私たちは異なるアカウントの機能についてかなり簡潔な知識を持っているので、イーサリアム上のユーザーと開発者の経験にとっての彼らのセリングポイントや問題を簡単に特定できます。

以前にも述べたように、EOAはエンドユーザーをターゲットとしたファーストクラスのアカウントとして設計されています。アプリケーションはこれらと簡単にやり取りするように設計されており、ほとんど複雑さはなく、もちろん作成にはコストがかかりません。しかし、そのシンプルさは厳密に決定論的に設計されているため、新しさの重要な部分を失っています。

それらに関する懸念の一部は:

1. 量子攻撃への脆弱性 – 彼らのキーペアによって使用されているECDSA署名スキームは、量子耐性ではなく、産業用の量子システムが5年から10年の楽観的なスケジュールで達成される見込みであるため、これはECDSAスキームに重大な脅威をもたらし、その暗号的証拠とセキュリティに重大に依存しているEthereumおよびそのアプリケーションにとって重大な脅威となります。
2. 表現の不足−EOAの有効性ルールの厳格な形式は、トランザクションの原子性やバッチ処理、トランザクションの委任などの機能を利用してユーザーがより簡潔にトランザクションを表現する能力を排除しています。
3. 自己持続性-誰もが取引の途中で「ガスが切れた」という経験をしたことがあるでしょう。これは、EOAがトランザクションのガスを自分で解決する必要があるためであり、イーサ（ETH）が唯一の受け入れ可能なガス通貨でなければ、あまり問題ではないでしょう。これはアカウントベースのステートマシン（およびUTXOベースのステートマシン）に共通の問題ですが、Ethereumは常に異なることを意図していました。

誰もがいつもETHを保持することを望んだりできるわけではありません（価格の動きを見てください）、ですので、実現可能な解決策は複数のガス通貨を許可するかです（難しすぎて、「通貨」のセクションで説明されているように不変条件を多数壊してしまいます）ここまたは、トランザクションの起点でない別のアカウントによってガス料金を支払うことを許可するために、アカウントの抽象化を使用することがあります。

アカウントスペクトルの反対側にあるCAは、開発者やより技術的なユーザーベースをターゲットにしています。彼らはスマートコントラクトのための手段として機能し（つまり、スマートコントラクトをその中に含まれるロジックやコードの内容と見なします）、EVMによって可能にされる新しいトランザクション形式を実装することができます。

しかし、これらの機能にもかかわらず、それらは自律性を持たないため、称賛される二等アカウントです。彼らの欠点のいくつかは次の通りです:

1. 完全な自律の欠如 – CAsは取引を開始することはできません。彼らは特定の方法で呼び出された応答としてのみ取引を送信することができます。
2. ロジックのヒューマンエラーに対する感受性 – 硬直性の欠如は、しばしば不変条件やその他のロジックの誤った定義につながり、スマートコントラクトの悪用やハッキングによる数十億ドルの損失につながっています。ただし、これはほとんどまったく別のトピックであり、ここでの範囲を超えています。

このサブセクションで定義された問題につながる設計の選択肢を見直した後、提案された解決策を評価することができます。

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

アカウントの抽象化の概念（少なくともスマートアカウントを介して）は、常にEthereumのロードマップの重要な部分でした。実装に関連する複雑さがEthereumのローンチをさらに遅らせる可能性があるという伝説があり、異なる機能を提供する異なるアカウントを使用した現在のデザインのために廃止されました。Ethereumの焦点がThe Mergeに移ったことにより、再び遅れ、次の主要なアップグレードであるPectraのネットワークの主要な部分として再浮上しています。しかし、その複雑さはまだ埋め込まれることを阻害する重要な欠点と見なされており、特にEthereumがロールアップに焦点を当てるロードマップに切り替えたことを考慮すると、その影響は大きいです。

要件は今や二つに分かれています:

1. アカウントの基準はより表現豊かでなければなりませんが、自律性を失わないようにします。 EOAとCAの基準との間の隔たりを埋める新しい標準。
2. 新しいスタンダードは、EOAとCAのギャップを埋めながら、イーサリアムとそのL2エコシステム全体で完全に互換性がある必要があります。

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

アカウントの抽象化は、EOAとCAの最良の特徴を組み合わせて、新しいアカウント標準であるスマートアカウントを作成することを目指しています。スマートアカウントでは、任意のアカウントの有効性ルールを検証ロジックと実行ロジックに全体または一部分離することができます。つまり、アカウントは契約アカウントと同様にEVMに許可された範囲内で独自の有効性ルールを定義することができ、同時に完全に自律的な外部所有アカウントのままです。

スマートアカウントとスマートコントラクトウォレットの違いについては、しばしば混乱がありますので、以下でこれらの違いを明確に説明しましょう。

• スマートアカウントは、プログラマビリティと自律性を同等に提供するように概念化されたイーサリアムアカウントです。この考え方は、EOAとCAの両方が、ネットワークが課す有効性ルールを、適切と思われるオーダーメイドの有効性ルールに置き換えることができる何らかのメカニズム(ERC 4337など)を利用するだけで、スマートアカウントになることができるというものです。
• 一方、スマートコントラクトウォレットは、契約アカウントへのインターフェースとして機能する単なるウォレットプロバイダーです（そう、ウォレットはアカウントではありません）。

スマートコントラクトウォレットの商業化により、より広範な市場でCAsの採用が容易になり、技術的には少ないユーザーもその提供する機能を利用することができるようになりました。しかし、それらはまだCAsに関連する落とし穴に直面しています。

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

• 認証
• 認証
• Nonceロジック
• ガス支払いのロジック
• 実行ロジック

最初の4つのパラメータの値は、トランザクションの実行が開始される前に行われるチェックである、アカウントの検証ロジックとして総称されることがあります。

最後のパラメータは、トランザクションの実行方法を定義します。

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

プログラマブルEOAs

イーサリアムの最大の魅力は、若いながらも活気あるDeFiエコシステムであり、その中には主要な流動性の吸収源となるさまざまな分散型アプリケーションがあります。これらのDAppのほとんどはEOAに対応するように最適化されているため、CAやスマートアカウントとのインターフェースは困難です。スマートコントラクトウォレットはこの場合CAを支援しますが、それには独自の制限とまったく異なるUXがあります。

スマートアカウントの標準に慣れるまで、DAppsとウォレットプロバイダーの両方が探索されている暫定的な解決策は、EOAに一時的な拡張機能を提供することです。これにより、制約された制約や実行ロジックを克服できます。

以下、私たちは行動可能な経路を提供する3つの主要なEIPの仕様について説明します。EIP 5806、野心的なEIP 3074そして最後に勝利へEIP 7702.

EIP-5806によるプログラム可能性

この提案は、EOA（外部所有アカウント）の標準にさらなる機能をもたらすため、コントラクトアカウントのロジック（スマートコントラクト）へのデリゲートコールを実行できるようにすることを目指しています。これにより、スマートコントラクトは呼び出し元EOAのコンテキストで実行され、つまり、EOAはバリデーションロジックを制御し続ける一方で、実行ロジックは対応するCAのロジックによって処理されます。

さらに進む前に、イーサリアムの進化の記憶の道をたどってみましょうEIP-7.

EIP-7は、0xf4/DELEgateCALLオペコードの作成を提案し、これはプライマリアカウントにメッセージコールを送信し、セカンダリアカウントのロジックを使用しながら、プライマリアカウントの[sender]および[value]フィールドの値を維持します。

言い換えると、プライマリアカウントは、メッセージ呼び出しで指定された期間中、セカンダリアカウントのロジックを「継承」（または好むなら借用）し、その結果、後者のロジックが前者の文脈で実行されます。

このオペコードは、dApp 開発者がアプリケーションのロジックを複数のスマートコントラクトに分割しながら、相互依存関係を維持できるようにすることで、コードサイズの障壁やガスの障壁を簡単に迂回できるようにしました。

EIP-5806の要約

OK、したがって、どのデリゲートコールがCA同士が相互依存できるようにするのでしょうか？EIP-5806は、EIP-7をインスピレーションにして、デリゲートコール機能をEOAにも拡張することを提案します。つまり、EOAもCAと相互依存できるようにしましょう。なぜなら、そうした方がいいからです。

仕様

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: 1つの5806タイプのトランザクションが消費できる最大ガス量。
• 宛先：トランザクションの受信者
• データ：実行可能なコードの内容
• access_list：EIP-5806トランザクションを条件付きで実行する権限を持つエージェント。
• signature_y_parity、signature_r、およびsignature_s：メッセージ上のsecp256k1署名を表す3つの値 — 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はCAと同等ではありません。そのため、不変条件の破損を防ぐために、EOAがデリゲートコールを利用する方法には特定の制限が定義される必要があります。

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

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

潜在的な適用/ユースケース

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

• 取引の条件付き実行
• トランザクションのバッチ処理
• マルチコールトランザクション（例：承認および呼び出し）

批判

EIP-5806によって提案された変更は、必要な機能を可能にする一方で、特に斬新ではありません。その存在は、既に機能しているEIP-7に基づいています。これにより、多くの潜在的な受け入れの障壁を回避することができます。

初期の段階での主な懸念の1つは、EOAがストレージにアクセスして変更するという潜在的なリスクでした。これは、CAが現在行っているのと同様に、ネットワークに絶対的に定められた不変条件の多くを破壊します。そのため、前のサブセクションで言及された制限を導入することで対処されました。

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

EIP-3074によるプログラマビリティ

EIP-3074は、EOAが特殊なコントラクトアカウントであるインボーカーに対して、その検証ロジックの大部分を委任することを提案しています。これにより、特定のトランザクション形式に対して、インボーカーの認証ロジックが彼らの上に重ねられます。

これにより、アクセスポリシーをインボーカーコントラクトに署名することで、そのコントラクトがEOAのアクセスポリシーを定義する責任を負うことによってこれを達成します。

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

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

これらの2つのオペコードにより、EOAは事前に設定されたCAに制御を委任し、それを通じて1つとして行動することができ、契約を展開し、それに関連するコストと外部性を負担する必要がありません。

仕様

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

各オペコードの複雑さに取り組む前に、これらがEIP-3074トランザクションに関係するエンティティであることに注意してください。

• [authority]: 通常は契約アカウントである第2のアカウントへのアクセス/制御を委任する主署名アカウント（EOA）です。
• [authorized]: [AUTHCALL] 命令が実行のために渡されるアカウント。言い換えれば、これは [AUTHCALL] のロジックが [authority] に代わって [invoker] によって定義された制約を使用して実行されるアカウントです。
• [invoker]: 主に、[認可された]アカウントと[AUTHCALL]のロジックとの相互作用を管理するための副次的な契約で、特に後者の契約コードの主要なロジックがガスのスポンサーシップである場合に適用されます。

呼び出し元コントラクトは、[authority] から [COMMIT] 値を持つ [AUTH] メッセージを受信します。この値は、アカウントが [authorized] による [AUTHCALL] 命令の実行に課したい制限を定義します。

したがって、呼び出し元は、[authorized]アカウントで定義された[contract_code]が悪意がなく、主要な署名アカウントによって設定された不変条件を満たす能力を持っていることを確認する責任があります。[COMMIT]値。

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

1. authority: 署名を生成する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. [メモリ(オフセット+65 : オフセット+97)] – [コミット]

変数[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. 現在の割り当て範囲（97ユニット）を超えてメモリが拡張される場合に、[RETURN]オペコードと同様に計算され、適用されるメモリ拡張手数料
3. ウォームな[authority]の場合には100ユニットの固定コストが発生し、コールドな場合には2600ユニットのコストが発生します。これは、状態アクセスオペコードの誤った価格設定による攻撃を防ぐためです。

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

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

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

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

1. [authorized]の値をチェックします。未設定の場合、実行は無効と見なされ、フレームはすぐに終了します。これにより、予期しない障害による不当な料金を防ぐのに役立ちます。
2. [authorized]の意図した動作のガスコストをチェックします。
3. [gas] オペランドの EIP-150 準拠値をチェックします。
4. [当局]の残高にある総ガスコスト-[値]-の可用性をチェックします。
5. 実行は、[権限] の口座から[value]を差し引いた後に行われます。[value]が彼らの残高を超える場合、実行は無効になります。

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

• 呼び出しのための固定費用 [warm_storage_read]
• メモリ拡張のコストは[memory_expansion_fee]で、これは[CALL]オプコードのガスコストと同様に計算されます
• ダイナミックなコスト [dynamic_gas]
• サブコールの実行コスト [subcall_gas]

[AUTHCALL]から返されるデータは次のようにアクセスされます:

• [RETURNDATASIZE] – which pushes the size of the return data buffer onto the output stack
• [RETURNDATACOPY] - リターンデータバッファからデータをメモリにコピーするものです。

すべてをまとめると、テクニカルな言葉をあまり使わずに言えば、イーサリアムのトランザクションでは通常2つの値が指定されます。

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

以前に言及したように、EOAでは、認証は実行と密接に結びついています、つまり、(tx.origin == msg.sender)です。この単純な不変条件は、このレポートの「アカウントとトランザクションの正当性」のサブセクションで説明した多くの問題を引き起こします。

[AUTH]メッセージは、[authority]からのメッセージによって、tx.origin関数を[authorized]にオフセットすることができますが、msg.senderのままです。また、[COMMIT]値を使用してこの特権に制限を定義することもできます。

[AUTHCALL]は、[authorized]が[invoker]を介して契約のロジックにアクセスできるようにし、アクセスする契約が安全であることを保証します。つまり、[AUTHCALL]ごとに、[authorized]は[COMMIT]用の特定の[invoker]を指定する必要があります。

潜在的な適用/使用事例

EIP 3074は、主にEOAが承認ロジックを別のアカウントに委任できるようにすることが主な役割ですが、そのオープンな設計により、さまざまなコンテキストでさらに多くの機能が可能になります。

EOAの全検証ロジックは、必要に応じてインボーカーにさまざまな制約/革新を適用することによって抽象化できます。ターゲットロジックに基づく可能性のある設計の一部は次のとおりです。

• Nonceロジック：EIP-3074では、EOAのNonceは[AUTH]メッセージを送信した後も変更されず、一方、[AUTHCALL]ごとに対応するインボーカーに依存します。これにより、EOAのNonce並列処理が可能になり、希望するだけで複数の重複しない[AUTHCALL]を送信できるようになります。
• ガス支払いロジック：指定された通りEIPでは、インボーカーを設計して、ガスのスポンサーシップを許可することができます。したがって、ユーザーの[COMMIT]のガス料金は、トランザクションの発信元または個人用またはサービスベースのリレー（ガススポンサーシップサービス）のいずれかのサポートアカウントから差し引かれる可能性があります。

また、実行ロジックは直感的に抽象化されています。つまり、すべての呼び出し元（つまりCA）が、今ではEOAの代理で取引リクエストを実行する責任があります。

批判

• Invoker Centralisation

引用その著者の1人は、「ウォレットが任意の呼び出し元に署名機能を公開することは期待していない」と述べています。 3074イニシアチブによって提示される最大の問題は、その上にイノベーションが非常に簡単に許可された取引フローと独自の取引フローになることです。まるで現在のEthereumのMEVとPBS市場の現在のイテレーションのように。

デフォルトでは、インボーカーコントラクトは、現在可能な攻撃よりも悪化する可能性があるため、非常に厳格に監査する必要があります。これにより、影響力のある人物によって開発されたわずかな数のインボーカーコントラクトだけが、ウォレット開発者のデフォルトとして採用される生態系になるでしょう。したがって、ユーザーのセキュリティのリスクを冒しながら、常に監査を行い、インボーカーコントラクトをサポートするハードな分散型の道を選択するか、より確実なユーザーセキュリティを保証し、契約の安全性に対する監視を減らす確立された信頼できるソースからインボーカーコントラクトを採用するかのトレードオフに帰着します。

このポイントの別の側面は、機能的で安全なインボーカーを設計し、監査し、マーケティングするために関連付けられたコスト関数です。小規模チームはほとんど常に、特にマーケティングの面で、すでに一定の評判を持つ大手組織によって上回られるでしょう。たとえ彼らの製品がより良いとしても。

• 互換性の問題

EIP-3074 は、呼び出し側を介して導入された承認スキームよりも有効であると見なされるため、ECDSA 署名スキームを定着させます。量子抵抗は今のところ決定的な問題ではなく、ECDSAが壊れやすい未来ではもっと深刻な危機に瀕しているという議論もありますが。イーサリアムのやや明言されていない目標は、常にそのような問題の先を行くことです。UXのわずかな改善のために量子抵抗と検閲耐性を犠牲にすることは、近い将来、最善の選択ではないかもしれません。

フォワード互換性の議論のもう1つのポイントは、3074の利点がまだ評価されている間に、プロトコルの変更を必要としないERC-4337（現在は大きな市場があります）があるため、それにも互換性を持たなければならないことです。それを避けるために、エコシステムの区画化を避けるためにも、それにも対応する必要があります。

ネイティブなアカウントの抽象化ロードマップを使用しても、[AUTH]および[AUTHCALL]オペコードは最終的にEVMで廃止され、わずかなUXの改善を提供するためにイーサリアムに多くの技術的負債をもたらします。

• ECDSAスキームの不可逆性

[AUTH]メッセージを送信し、コントロールを委任した後、EOAは通常の秘密鍵認証方式を避けることが期待されます。なぜなら、「通常の」トランザクションを送信すると、委任した認可がすべての呼び出し元に取り消されるからです。

したがって、ECDSAスキームは、関連する契約が有効にする他のいかなる認証スキームよりも厳格に優れているため、秘密鍵の紛失はアカウントの資産の完全な損失をもたらすことになります。

EIP-7702によるプログラマビリティ

この提案は、元々EIP 3074のややミニマリスティックなバリエーションとして設定されていました。意味もそれに対するアップデートであるとされ、特に既に繁栄している4337エコシステムおよびネイティブアカウント抽象化提案（RIP 7560）との非互換性に関する懸念を解消するためにEIP 3074の潜在的な非効率性に対処するために生まれました。

そのアプローチは、新しいEIP 2718に準拠したトランザクションタイプである[SET_CODE_TX_TYPE]の追加です。これにより、特定のトランザクションに対してEOAがスマートアカウントとして振る舞うことができます。

この設計により、EIP 5806と同じ機能とさらにいくつかの機能が可能になりますが、ネイティブのアカウントの抽象化のロードマップと既存の取り組みとの互換性は維持されます。

仕様

EIP-7702は、[SET_CODE_TX_TYPE] 2718準拠のトランザクションを介して、EOAが契約のコード内容を「インポート」することを許可します。フォーマットは次のとおりです:

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]: which is the EOA/primary signing account
• [address]: これはデリゲート可能なコードを含むアカウントのアドレスです。

【権限】が[アドレス]を指定するSET_CODE_TX_TYPEに署名すると、委任指示子が作成されます。これは「ポインタプログラム」であり、[権限]のアクションによるすべてのコード取得要求がいつでも[アドレス]の観察可能なコードに結合されるようにします。

各 [chain_id、address、nonce、y_parity、r、s] のタプルに対して、7702型トランザクションの論理フローは次のとおりです:

1. 提供されたハッシュから[権限]の署名を検証する方法: 権限 = ecrecover(keccak(MAGIC || rlp([chain_id, address, nonce])), y_parity, r, s)
2. クロスチェーンリプレイ攻撃の防止と他の攻撃ベクトルチェーンのIDの検証によって。
3. [authority]がすでにコードコンテンツを持っているかどうかをチェックしています。
4. タプルに含まれるnonceと[authority]のnonceが等しいことを確認するノンスチェック。
5. もし取引が[権限]の最初のSET_CODE_TX_TYPE取引である場合、PER_EMPTY_ACCOUNT_COST手数料が請求されます。この手数料の値よりも残高が少ない場合、操作は中止されます。
6. デリゲーション指定が行われ、[authority]のコードが[address]のポインタに設定されます。
7. 署名者のノンス–[authority]–が1つ増加されます。
8. [権限]は、アクセスされたアドレスのリストに追加されます。これは（単純化された表現ですが）、そのスコープの逆転がそれら（アドレス）を前の状態に戻すように作成されたアドレスのセットです。これは、EIP-2929再利用可能な値のキャッシングを有効にし、不要な料金を防止するために。

ふぅ！ すべてを結びつけるために、このEIPによってEOAは、コントラクトのコードへのポインタを設定するトランザクションを送信できるようになり、それによってEOAは後続のトランザクションで独自のロジックを実装できるようになります。この方法によって、EIP 5806よりも厳密に強力です。なぜなら、EOAは実際にはコードの内容を望むだけの時間を持つことができるからです（EIP 5806では単にEOAがデリゲートコールを送信できるようにするだけです）。

潜在的な適用/使用事例

• 実行の抽象化

EOAが実行したいロジックを積極的に受け入れるため、もはや抽象化ではないと主張できるかもしれませんが、それでもそのロジックの「主要な所有者」ではありません。また、直接ロジックを含んでいるわけではなく、計算の複雑さを減らすためにロジックへのポインターを指定するだけです。したがって、実行抽象化に進みます！

• ガススポンサーシップ

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

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

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

これにより、特定のdAPPが特定の条件下でアカウントの残高にのみアクセスできるようにするサブキーの存在が可能になります。「特権のエスカレーション」を実現するために使用されます。たとえば、ERC-20トークンを消費する権限を持つがETHを消費する権限は持たない、または1日に総残高の1%までしか消費できない権限、または特定のアプリケーションとのみやりとりできる権限などが考えられます。

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

非制限的な性質のため、EIP-7702トランザクションは、手数料市場論理（例：EIP-1559およびEIP-4844）などの制限的なパラメーターなしに、CREATE2オプコードにアクセスしてバイトコードをアドレスに展開することを許可する可能性があります。これにより、同じバイトコードを持つ複数のステートマシン上で復元および使用されるアドレスが可能になり、各チェーン上のそのアカウントが他のコンテキスト変数パラメータを定義する責任を負います。

批判

• 後方互換性の欠如

EIP-7702はまだ非常に最近のものですが、その依存関係や潜在的な欠点のために多くのプロトタイピングとテストがすでに行われていますが、その最小限のモデルは異なるコンテキストで多くの柔軟性、そして有用性を保証しています。しかし、これはあまりにも多くの不変条件を破り、直ちに後方互換性がありません。

そのロジックの一部には:

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

ほとんどのユーザーは、アカウントの実際の内容に詳しくない（アカウントとアドレスの違いさえわかっていないこともあります！）ため、アドレスの衝突を許すことは、EOAがCAを装ってユーザーの資金を引き付け、最終的にはすべてを盗むという長ったらしい試みが可能になるということを意味します。EIP-3607は、コードを含むアカウントが自分自身の認証ロジックを使用して残高を使うことができないようにすることで、これに対処しました。しかし、EIP 7702は、一部のプログラマビリティを得た後もEOAが自律的であり続けるようにするために、この不変条件を破っています。

• EIP-3074に似ています

アカウントのアドレスを署名することは、基本的にはinvokersを使った3074のスキームのようなものです。異なるチェーン上でアドレスが異なるコードコンテンツを持つ可能性があるため、クロスチェーンのコードコンテンツの一貫性に厳密な保証を提供しません。これは、あるチェーン上で同じロジックを含むコードコンテンツを持つアドレスが、別のチェーン上では悪意のあるものになる可能性があることを意味し、これはユーザー資金の損失につながる可能性があります。

結論

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

EOAが任意の方法でコードを実行できるようにすると、アカウントの機能が大幅に拡張されますが、この新しい表現可能性には、重大なリスクと盲点が伴います。これらのトレードオフを解決することは、イーサリアムユーザーに無競争のUXメリットをもたらすアップグレードを提供するために重要です。

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

EIP-7702は、現在、EOAにEVMプログラミング性をもたらす機構の模範とされており、PectraアップグレードのEIP 3074のスロットに代わるとして指定されています。 3074のメカニズムのオープンな設計を継承しながら、攻撃面/リスクを大幅に低減しています。 さらに、特定のオペコードクラスに制限を避けることで、3074の制限を回避することにより、より多くのことが可能になります。

提案のデザインにはまだいくつかの改良が行われていますが、特にVitalikが直接支持しているため、開発者から多くの支持と支援を既に得ています。

コミュニティ内では、アカウントの抽象化へのこのアプローチがスマートアカウントよりも優れていると主張されています。このコメントでは、この方法は変更が少なく、複雑ではないことを強調しており、EOAが既に確立されていると述べています。しかし、イーサリアムネットワークのあらゆるレベルでの将来のセキュリティのマイルストーンである量子耐性を忘れてはなりません。現在のアカウントモデルのコアでは、EOAの承認にはECDSAベースの署名スキームが使用されているため、この量子安全性は実現不可能です。

したがって、EOAのプログラマビリティは、宛先ではなく、スマートアカウントへのパスに沿ったステップと見なされるべきです。EOAを強化し、ユーザーエクスペリエンスと開発者エクスペリエンスを向上させると同時に、スマートアカウントの最終的なアカウント抽象化目標との互換性を維持します。

次のレポートでは、アカウントの抽象化のロードマップにどのように適合するかを見るために、次のようにEOA移行スキームに入る予定です。お楽しみに！

免責事項：

1. この記事は[から転載されました2077.xyz], All copyrights belong to the original author [zhev]. この転載に異議がある場合は、お問い合わせください。ゲートラーンチームが対応します。
2. 責任免除事項：本記事に表明された見解や意見は、著者個人のものであり、投資アドバイスを意図するものではありません。
3. 他の言語への記事の翻訳は、gate Learnチームによって行われます。特記されていない限り、翻訳された記事のコピー、配布、または盗用は禁止されています。