ヴィタリックの最新提案EIP-7702の説明：EIP-3074の代替案

著者：Vitalik, Etherの創設者; 翻訳：xiaozou@Golden Finance

1, 概要

同様のEIP-3074機能を提供する目的で、contract_codeフィールドと署名を追加し、署名アカウント（必ずしもtxt .originと同じではない）をそのトランザクションの期間中スマートコントラクトウォレットに変換する新しいトランザクションタイプを追加する。同様の機能を提供することを目的としています。

2、動機

アプリケーションの使いやすさを向上させ、場合によってはセキュリティ強化をサポートするために、EOAに短期的な機能強化を追加することは、多くの人にとって大きな関心事です。興味がある。

• バッチ処理：同じユーザーが1つのアトミック・トランザクションで複数のアクションを実行できるようにする。一般的な例としては、ERC-20が承認され、再度使用されることが挙げられます。これは、2つのトランザクションを必要とする今日の分散型取引所では一般的なワークフローです。バッチ処理のハイレベルなユースケースは、時折依存関係も伴います：最初の操作の出力は2番目の操作の入力の一部です。

• スポンサーシップ：アカウントXはアカウントYに代わって取引手数料を支払う。アカウントXは他のERC-20を通じてこのサービスの料金を支払うこともできるし、無料でユーザーの取引を含むアプリ運営者になることもできる。

• 特権の劣化：ユーザーはサブキーに署名し、アカウントのグローバルアクセスよりもはるかに弱い特定の権限を与えることができます。例えば、ETHの代わりにERC-20トークンで支払うとか、1日あたり総残高の1％を使うとか、特定のアプリケーションとだけやり取りするといった権限です。

EIP-3074はこれらのユースケースの課題をすべて解決しますが、将来の互換性については懸念があります。: disc;">

このEIPの目標は、これら2つの問題なしにEIP-3074のすべてのユースケースを可能にすることです。

3、仕様

この文書のキーワード「MUST」、"、"must not"、"required"、"shall"、"shall not"、"should"、"should not"、"recommended"、"MAY"、および "OPTIONAL "は、RFC 2119に記述されている。

パラメータ:

• 次のようになります。FORK_BLKNUM = TBD

• TX_TYPE = TBD

• MAGIC = TBD

• MAGIC = TBD

• PER_CONTRACT_CODE_BASE_COST = 5000

FORK_BLOCK_NUMBERで始まる、新しいEIP-が導入されました。TransactionType = TX_TYPE(TBD)の2718トランザクション。

このトランザクションのEIP-2718 TransactionPayloadは次のとおりである：

rlp([chain_id, nonce, max_priority_feeこのトランザクションは、

rlp([chain_id、nonce、max_priority_fee、max_per_gas、gas_limit、destination、data、access_list、[[contract_code、y_parity、r、s], ...]

新しいトランザクションの固有コストはEIP-2930から継承されており、以下の通りである。+ 4 * ゼロ calldata バイト + 1900 * アクセスリストストレージキーカウント + 2400 * アクセスリストアドレスカウント

さらに、各contract_codeに16 * 非ゼロ calldataバイトを追加します。16 * 非ゼロ calldata バイト + 4 * ゼロ calldata バイト、さらにPER_CONTRACT_CODE_BASE_COSTにcontract_code配列の長さを掛けたコード。: disc;">

トランザクションの終了時に、各シグナーのcontract_codeをnullにリセットする。

どのcontract_code署名者とトランザクションのtxt .originは異なっていてもよいことに注意。

4、基礎

(1)EIP-3074。Strong>ユースケースの変換

この設計では、大きな労力をかけずに既存のEIP-3074ワークフローを変換することが可能です。具体的には、AUTHとAUTHCALLは、このEOAへの呼び出しに置き換えられる。1つのアプローチは、contract_codeがユーザーウォレットになり（ガスを節約するためにDELEGATECALLフォワーダーになる可能性がある）、verifyとexecuteの2つの関数を公開することです。style-type: disc;">

したがって、「既存のEIP-3074ワークフロー」からこの新しいシナリオのワークフローに変換するのは非常に簡単です。

(2)将来のアカウント抽象化との前方互換性

このEIPは、アカウント抽象化との将来の前方互換性が非常に高くなるように設計されており、過度に保存されることはありません。ERC-4337やRIP-7560の詳細については、こちらをご覧ください。

詳細は以下の通りです：

• ユーザーが必要とする契約コード。ユーザーが署名する必要がある契約コードは、既存のERC-4337ウォレットコードにすることができます。

• 使用される「コード経路」は、すべてではないかもしれませんが、多くの場合、純粋なスマート・コントラクト・ウォレット空間で「機能」し続けるものです。"純粋なスマート・コントラクト・ウォレット空間における多くの場合（おそらくすべてではないが）。

• そのため、「2つの別々のコードエコシステムを作成する」という問題を回避できます。このソリューションのもとで組み合わせる必要のあるワークフローもあるかもしれませんし、Account Abstraction Endpointのもとで、さまざまな「よりネイティブな」環境でよりうまくいくかもしれませんが、それは比較的小さな部分です。

• オペコードを追加する必要はなく、EOA後の世界では役に立ちません。

• これは、既存のEntryPointと互換性のある方法で、EOAを一時的にERC-4337トランザクションパッケージに含まれるコントラクトに変換することを可能にします。

• 一旦デプロイされると、EIP-5003は「1行のコード」になります：トランザクションの終了時にコードをnullに設定しないフラグを追加するだけです。

5, 後方互換性

EIPは、そのアカウントから発信されるトランザクションによってのみ減少させることができるアカウント残高を持つという型を破ります。これは、メモリプールの設計やインクルードリストのような他のEIPに影響を与えます。

6, セキュリティ上の懸念

EIP-に関するセキュリティ上の懸念の多くは、EIP-3074に関するものです。3074 セキュリティに関する懸念の多くは一般的なものです。特に、ユーザー・ウォレットはcontract_codeに署名する際に特に注意する必要があります。