Vitalik の新しい EIP-7702 提案を 1 つの記事で読んでください: アカウント抽象化の究極の処方箋?
原作者: ジャロッド・ワッツ
オリジナル編集: Frank、Foresight News
Vitalik Buterin は最近、イーサリアムの歴史の中で最も影響力のある変更の 1 つである EIP-7702 提案を提案しました。この記事では、新しい提案がどのように機能するか、そしてそれを実装するために知っておくべきことをすべて紹介します。
まず、新しい EIP-7702 提案は驚くほど短いため、実際にどのように機能するかについて混乱する人もいます。7702 を理解するには、まずその中で言及されている他の 3 つの提案を理解する必要があります。
EIP-4337
EIP-3074
EIP-5003
これらすべての提案の共通の目標である「アカウントの抽象化」から始めましょう。イーサリアムの EOA (「通常の」アカウント) はひどいもので、リスクがあり、機能が非常に制限されていますが、アカウントの抽象化により、ユーザーは追加するアカウントとしてスマート コントラクトを使用できます。この問題を解決するために、より多くの機能とセキュリティが必要です。
EIP-4337
2023 年 3 月にメインネットで公開された EIP-4337 により、スマート コントラクトをアカウントのように作成できるようになり、トランザクションを検証して実行できるようになり、多くのユーザー エクスペリエンス (UX) が向上します。
EIP-4337 はリリース以来、主に Polygon を中心に広く採用されており、Base では過去数か月間で活動が増加しています。
EIP-4337 に関連する最新のイノベーションは、Coinbase エコシステムと Coinbase スマート ウォレットから生まれました。これは生体認証技術に基づいており、優れたユーザー エクスペリエンスを備えています。私は先週末の ETH グローバル シドニーでこれを実証するために、別の小さなデモを作成しました。
それでは、EIP-4337 の何が問題なのでしょうか?なぜ今日、別のアカウント要約提案を行う必要があるのでしょうか?なぜなら、EOA は依然として最も広く使用されているアカウント タイプだからです。
さらに、EIP-4337 のスマート コントラクト アカウントのほとんどは、単一の EOA 署名者によって制御されます。サンプル コードは次のとおりです。
ユーザーの EOA をスマート コントラクト アカウントに「変換」する方法がないため、この奇妙な中間段階のソリューションが存在します。主に、Web3 アプリケーションでスマート コントラクト アカウントを接続するためのネイティブ サポートが欠如しているため、今日のほとんどの人は依然としてプラグを使用しています。 -MetaMask などのウォレットでは EOA を使用します。
EIP-3074
これにより、次の提案である EIP-3074 が導き出されます。
実際、この提案は EIP-4337 よりも前に提案されましたが、まだメイン ネットワークに統合されていません。EIP-3074 は EOA にさらなる権限を与え、EOA の制御をスマート コントラクトに委任できるようにしようとしています。
この提案では次の概要が説明されており、2 つの新しいオペコードが追加されています。
AUTH: EOA は AUTH を呼び出して、特定のスマート コントラクトが EOA に代わって操作を実行することを承認できます。
AUTHCALL: 認可されたスマート コントラクトは AUTHCALL を使用して EOA のトランザクションを実行できます。
これにより、各ユーザーが新しいスマート コントラクトを展開する必要がなく、EIP-4337 と同じユースケースの多くが可能になります。主な違いは、トランザクションがユーザー、ETH、NFT、トークンなどのアカウント履歴のない新しい契約ではなく、ユーザーの EOA から行われることです。
EIP-3074 に対する一般的な反応は、「誰かが悪意のある契約を締結し、ユーザーがその人に委任したらどうなるのですか?」です。結局のところ、悪意のある契約に委任すると、ユーザーのウォレット内のすべての暗号資産が流出する可能性があります。
この問題の解決策は、ウォレット サービス プロバイダーがユーザーにコントラクトを承認することさえ許可せず、ユーザーが承認を委任できるスマート コントラクトのホワイトリスト リストを保持し、このリスト外のコントラクトはユーザーに表示されないことです。
EIP-3074 委任の重要な点は、委任が永続的ではないということです。「EOA の単一トランザクションにより nonce が増加し、それによって未完了の認可が無効になる」ということです。
基本的に、ユーザーが新しい取引を行うと、その注文は無効になります。
EIP-5003
私たちは、EOA にこれ以上の権限を与えたくありません。結局のところ、これらの提案の目標はユーザーを EOA からスマート コントラクト アカウントに移行することですが、なぜ EOA に機能を追加するのでしょうか?
これは、次の提案である EIP-5003 にうまくつながります。 EIP-5003 は別のオペコード「AUTHUSURP」を追加し、EIP-3074 の許可されたアドレスにコードを展開します。
EIP-3074 と EIP-5003 の違いは次のとおりです。
EIP-3074 はスマート コントラクトへの一時的な委任であり、取り消すことができます。
EIP-5003 は EOA からの永続的な移行、および EOA からスマート コントラクト アカウントへの「変換」です。
EIP-3074 + EIP-5003 の大きな問題は、EIP-4337 による現在のアカウント抽象化スキームとの互換性があまり高くないことです。そのため、イーサリアム コミュニティの一部は、「2 つの別々のコード エコシステムが作成される」ことを懸念しています。
EIP-7702
今日の Vitalik Buterin の提案は次のとおりです。EIP-7702 - 彼は、EIP-3074 を修正して、より合理化され、EIP-4337 との互換性が高まるようにすることを提案しています。これにより、2 つの別々のアカウント抽象化エコシステムができてしまうことはありませんが、 EIP-5003 は永続的な移行の次のステップです。
EIP-7702 は、contract_code フィールドと署名フィールドの両方を受け入れる新しいトランザクション タイプを提案しており、トランザクションの実行を開始するときに、署名者のアカウントの契約コードを Contract_code に設定します。トランザクションの終了時に、ティッカーは空にリセットされます。
これは、EOA のスマートコントラクトに対する一時的な委任機能を実装する EIP-3074 と同じです。ただし、EIP-7702 は新しいオペコード (ハード フォークが必要) を導入せず、代わりに呼び出される関数を定義します。
AUTH -> 「verify」を呼び出します（検証）
AUTHCALL -> 「実行」を呼び出します
具体的には、次のとおりです。
アカウント契約コードが空かどうかを確認してください。
空の場合は、指定されたコントラクト コードに設定されます。
提供されたスマート コントラクトがトランザクションを処理する方法に従ってトランザクションを実行します。
アカウント契約コード設定を空に戻します。
「コントラクトコード」とは文字通り、スマートコントラクトのコードが「コントラクトコード」に格納されることを意味します。 EOA 自体は契約ではないため、このフィールドは通常は空です。ただし、EIP-7702 の賢い点は、トランザクションの実行中にこのフィールドにスマート コントラクト コードが一時的に入力されることです。
これは、この特定のトランザクションを実行するための EOA に新しい動作を (ティッカーの形式で) 与える方法です。次のステップでは、これを永続的な動作変更にします。「取引終了後にティッカーを設定しない」を選択するだけです。 null 」。
この提案の最も優れた点の 1 つは、これまでに EIP-4337 用に構築されたすべてのアカウント抽象化作業と高い互換性があることです。「ユーザーが署名する必要がある契約コードは、実際には既存の EIP-4337 ウォレット コードであり得る」ということです。
この変更が有効になると、ユーザーの既存の EOA は任意のスマート コントラクト コードを実行できるようになります。 EIP を追加すると、EOA を永続的にアップグレードして特定のコードを実行することもできます。
時間が経つにつれて、これは私たち全員が Web3 アプリケーションを操作する方法に革命を起こす可能性があります。
