原文の編集: The Way of DeFi
原文の編集: The Way of DeFi
アカウントの抽象化により、スマート コントラクト ロジックを使用して、トランザクションの効果だけでなく、手数料の支払いや検証ロジックも指定できるようになります。これにより、マルチ署名およびスマート リカバリ ウォレット、ウォレットを変更せずにキーを変更できる機能、量子セキュリティなど、多くの重要なセキュリティ上の利点がもたらされます。
アカウント抽象化に対する多くのアプローチが提案され、さまざまな程度で実装されています。EIP-86、EIP-2938、および 2 年前のこの文書を参照してください。現在、開発者がマージとシャーディングに集中したいため、これらの EIP の開発は停滞していますが、コンセンサス変更を必要としない代替案である ERC-4337 は大きな進歩を遂げています。
ERC-4337 は、追加のプロトコル手段を通じて EIP-2938 と同じことを達成しようとします。ユーザーは、ユーザー オペレーションと呼ばれるオフチェーン メッセージを送信する必要があります。メッセージは、ブロック プロポーザーまたはブロック プロポーザー用のバンドルを生成するビルダーによってバッチで収集され、単一のトランザクションにパッケージ化されます。提案者または構築者は、料金を支払う操作のみを確実に受け入れるように操作をフィルタリングする責任があります。ユーザー アクション用に別のメモリプールがあり、このプールに接続するノードは ERC-4337 固有の検証を実行して、ユーザー アクションが転送される前に支払いが行われていることを確認します。
ERC-4337 は純粋に自主的な ERC として多くのことを行うことができます。ただし、いくつかの重要な領域において、真のプロトコル内ソリューションよりも弱いです。
既存のユーザーは、すべての資産とアクティビティを新しいアカウントに移動しないとアップグレードできません。
追加のガスオーバーヘッド(基本的な UserOperation ユーザー操作は約 42k、基本トランザクションは約 21k)。
トランザクションをターゲットにしてユーザーの操作を見逃す、プロトコル内の検閲耐性技術 (例: crLists) によるメリットが少ない
最良の結果を達成するための現実的な方法は、まず短期的に ERC-4337 を強力にサポートし、その後、その弱点を補うために時間をかけて EIP を追加することです。これは必ずしも全員が ERC-4337 に準拠することを明確に約束する必要はありません。代わりに、プロトコル内サポートをより汎用的に設計し、ERC-4337 とその代替案および改良点をサポートすることができます。
副題
EOA ウォレットをスマート コントラクト ウォレットに変換する
既存の EOA ウォレットを ERC-4337 ウォレットにアップグレードするには、EOA がコントラクト コードを設定する操作を実行できるようにする EIP を作成します。 EOA がこれを達成すると、移行は元に戻すことはできません。それ以降、アカウントはスマート コントラクト ウォレットとしてのみ使用されます。幸いなことに、ERC-4337 アカウントは DELEGATECALL プロキシであるため、必要に応じてウォレットを後で他の ERC 互換スマート コントラクトに変換できます。
このアップグレード プロセスを実装する方法については、いくつかの提案があります。
1.「コード交換」トランザクションタイプ
これはまだ正式な EIP として導入されていませんが、方法は簡単です。新しい EIP-2718 トランザクション タイプを追加し、account_code を calldata に置き換えるだけです。
2、AUTH_USURP (EIP-5003)
EIP-5003 は EIP-3074 (AUTH および AUTHCALL) に対する拡張案であり、新しい AUTHISURP オペコードが導入されています。 EIP-3074 メカニズムを使用して、EOA アドレス A が別のアドレス B にその代理として動作することを許可した場合、AUTHUSURP は B が A のコードを設定できるようにします。
副題
強制変換
長期的には、プロトコルを簡素化し、契約を唯一のアカウントタイプにしてプロトコルから ECDSA を削除するために、強制的な変換を実行する必要があるかもしれません。考えられるアプローチの 1 つは、特定のブロックから開始して、コードのないアカウントが特定の標準化された「ERC-4337 EOA ウォレット」コードを持つアカウントとして扱われるオーバーライド ルールを追加することです。
質問
質問
契約中の ECRECOVER 検証:一部のスマート コントラクトは、ECRECOVER の署名を特定のアカウントに提供すると、そのアカウントを所有しているという前提に基づいています。 EOA が契約に変換され、その検証キーが変更された場合でも、元のキーはこれらの特定のコンテキストでアカウントを「表す」ことができます。これは、アカウントにコードがある場合、ECRECOVER の代わりに EIP-1271 検証を使用するように変更するようすべてのプロジェクトに奨励し始めることで実現できます。
まだ検出されていないアカウント:強制変換に関する課題の 1 つは、資産 (ETH ではなく ERC20、ERC721 など) を所有しているものの、トランザクションを送受信していないアカウントであるため、プロトコルはこれらのアカウントを確実に検出できないことです。プロトコルは、そのようなアカウントをデフォルトのウォレットに永続的に変換する機能を保持するか、変換されていないアカウントが焼き付けられるまでの期限 (例: 導入後 4 年) を設ける必要があります。
EOA は非譲渡性のみをチェックします。副題
ガスコストの削減
ERC-4337 ウォレットは、以下の理由により、より高いガスコストに直面しています (基本的な通常のトランザクションの 21,000 ガスと比較して、ERC-4337 の基本的な操作では約 42,000 ガス)。
1. ストレージの読み取り/書き込みコストを個別に支払う必要があります。EOA の場合、これらのコストは 21000 ガスの 1 回の支払いにまとめられます。
(1) pubkey+nonce (~5000) を含むストレージ スロットを編集します。
(2) ユーザー操作呼び出しデータコスト (約 4500、圧縮により約 2500 に削減可能)。
（3）ECRECOVER (~3000)；
(4) ウォレット自体への初回アクセス (~2600)
(5) 受取人口座への初回アクセス(~2600)
(6) ETHを受取人の口座に送金(~9000)
(7) 料金を支払うためにストレージを編集 (~5000)
(8) エージェントを含むストレージ スロット (~2100) にアクセスし、次にエージェント自体 (~2600) にアクセスします。
2. 上記のストレージ読み取り/書き込みコストに加えて、コントラクトでは「ビジネス ロジック」(UserOperation のアンパック、ハッシュ、変数のシャッフルなど) を実行する必要もあります。
3. ログ料金を支払うためにガスを消費する必要があります (EOA はログを公開しません)。
4. 1 回限りの契約作成コスト (約 32,000 ガス、プロキシ内のコード バイトごとに 200 ガス、およびプロキシ アドレスの設定に 20,000 ガス)
これらの問題の多くは、Verkle ツリー監視ガス コスト EIP と書き込みガス コスト改革 EIP で自動的に解決され、大規模なストレージ コストがより無駄のないシステムに置き換えられます。たとえば、公開鍵とナンスはスロット 0 ～ 63 に保存できるため、アクセスコストが 1000 未満に削減されます。対象アカウントと受信アカウントに初めてアクセスする必要があるのは 1 回だけであるため、ユーザーは ETH の送金と手数料の支払いの際に支払う費用が少なくなります。
簡素化に役立つ EIP は他にもあります。例えば：
スマート コントラクト ロジックによるスロット 0 の自発的 ERC の使用を無効にすると、スロット 0 をストレージ プロキシとして使用できるようになり、ガス コストが安くなるというメリットが得られます。
「コード アドレス」フィールドを使用すると、プロキシ処理が容易になり、ガスの消費量が少なくなります。
「迅速な圧縮」プリコンパイルにより、すべてのゼロ バイトに対する calldata ガス コストを支払うことなく、ABI オブジェクトを簡単に使用できるようになります。
副題
crLists
crLists は完全なプロトコル提案者/ビルダー分離スキームが有効になっている場合にのみ実際に適用できるため、これは長期的な問題です。課題は、プロトコルが余地のある次のブロックにそれらを強制的に含めることができるように、提案者が含めるのに「価値がある」ユーザーアクション (つまり、十分な料金を支払う) を識別できるようにしたいことです。
これには、「検証」と「実行」の概念をプロトコルで明示する必要があります。ユーザーアクションの場合、アクションを検証するための定義された方法と、アクションを実行するための定義された方法が必要です。つまり、アクションが検証された場合、検証中に読み取り状態が変更されない限り、アクションを実行しようとすると料金が保証されます。 。これらの操作は、ABI メソッドを埋め込むことによって、または EOF EIP が実装されている場合は専用の EOF セクションを追加することによって実装できます。
幸いなことに、これには ERC-4337 を最終標準として扱う必要はなく、代わりに、ERC-4337 によってサポートされる弱い概念が組み込まれており、他の大きく異なる ERC によって簡単にサポートできます。
その理由は、ERC-4337 と EIP-2938 の複雑さは、より強力な DoS 耐性の問題の解決に大きく関係しているためです。これにより、Mempool Transactional の安価なガベージが可能になるため、1 つの操作で何百もの他の操作をキャンセルすることはできません。攻撃。これには、アカウント認証がアクセスできるものに制限を課す必要があります。ここでは、もっと単純なことを行うことができます。検証中にどの状態オブジェクトに触れたかを記録するだけで、それらの状態オブジェクトのいずれかが編集されたかどうかを含める必要はありません。
これにより、個々のアカウントが検閲への耐性と柔軟性の間で独自のトレードオフを選択できるようになります。極端な場合、アカウントは希望に応じて Uniswap 経由で検証中に手数料を支払うことができますが、誰でも Uniswap の状態に影響を与えるトランザクションを送信できるため、そのようなアカウントには事実上検閲耐性の保証がありません。
crList 設計の概要は次のとおりです。
プロポーザルには、含める操作のリストを指定する crList と、各操作が読み取る状態オブジェクト (キー、値) ペアのリストを含めることができます。 crList を受け入れるビルダー (または他の人) は、すべての操作が検証チェックに合格することを確認する必要があります。
ブロックに十分なガスが残っていない場合、または実行時の現在の状態が操作によって読み取られた状態オブジェクトの 1 つを編集した場合を除き、ブロックは crList 内のすべての操作を実行する必要があります。
ERC-4337 の残りの複雑さは、メモリプールのセキュリティにのみ使用されます。原則として、すべてが同じ検証および施行基準に準拠している限り、さまざまな方法でこの目標を達成する複数の競合する ERC が存在する可能性があります。
副題
可能なロードマップ
短期
ERC-4337 を本格的に稼働させます。理想的には、ロールアップを容易にするために署名集約機能を使用してこれを拡張できます。
ERC-4337と連携する使いやすいブラウザウォレットが必要です。
ERC-4337 を L2 フレンドリーにするために、署名の集約と圧縮の実装を検討してください。
ガスコストの問題が少なくなる L2 プロトコルでの ERC-4337 エコロジーをガイドします。
中期
Verkle ツリーを実装し、EIP を追加してガスコストを削減します。
オプションの EOA から ERC-4337 への変換を追加します。
PBS の起動と同時に、またはその直後に crList ロジックを追加します。
長さ
副題
可能な代替案
ERC-4337 と同等のアカウントとトランザクションをプロトコル層に含む EIP を作成し、L2 での導入を推進することを検討してください。
補助ブロックを介して機能する検閲耐性のあるソリューションを使用して、ユーザーのアクションをイーサリアム プロトコルで読み取れるようにする必要性を排除します。
