Vitalik Buterinは最近、Ethereumの歴史の中で最も影響力のある変更の1つになり得るEIP-7702を提案しました。この記事では、この新しい提案の仕組みとその実装を理解するために必要なすべてを紹介します。

まず、EIP-7702提案は驚くほど簡潔であり、その動作について一部の人々が疑問を抱いています。EIP-7702を理解するには、それに言及されている他の3つの提案を見る必要があります。

1. EIP-4337

2. EIP-3074

3. EIP-5003

これらの提案の共通目標から始めましょう：「アカウント抽象化」。イーサリアムでは、EOA（「通常」のアカウント）には重大な欠点があり、非常にリスクが高く機能が非常に限られています。アカウントの抽象化により、ユーザーはスマートコントラクトをアカウントとして使用でき、これらの問題に対処するためにより多くの機能とセキュリティが追加されます。

EIP-4337

EIP-4337は2023年3月にメインネットで稼働しました。これにより、スマートコントラクトをアカウントのように記述して取引を検証および実行できるようになり、多くのユーザーエクスペリエンス（UX）が向上しました。

リリース以来、EIP-4337は、主にPolygonによる広範な採用を見ており、最近数ヶ月間でBaseからの活動が増加しています。

EIP-4337に関連する最新のイノベーションは、CoinbaseエコシステムとCoinbaseスマートウォレットからもたらされています。このウォレットは生体認証技術に基づいており、優れたユーザーエクスペリエンスを提供しています。先週末、私はETH Global Sydneyでこのデモをさらに製作し、紹介しました。

EIP-4337にはどのような問題がありますか？なぜ今日別のアカウント抽象化提案があるのですか？なぜなら、EOAは今でも圧倒的に最も広く使用されているアカウントタイプだからです。

さらに、EIP-4337のスマートコントラクトアカウントのほとんどは、単一のEOAサイン者によって制御されています。以下はコードスニペットの例です。

ユーザーのEOAをスマートコントラクトアカウントに「変換」することはできないため、この奇妙な中間解決策が存在しています。これは、Web3アプリケーションでスマートコントラクトアカウントを接続するためのネイティブサポートの不足に主に起因しています。現在、ほとんどの人々は、MetaMaskのようなプラグインウォレットを介してEOAを使用しています。

EIP-3074

これで次の提案、EIP-3074 に移ります。

実際、この提案はEIP-4337より前に導入されましたが、まだメインネットにマージされていません。EIP-3074は、EOAがスマートコントラクトにそのEOAの制御権を委任することを可能にしようとしています。

提案では、2つの新しいオペコードの追加が概説されています:

1. AUTH：EOAは、指定されたスマートコントラクトが自分の代わりに行動することを許可するために、AUTHを呼び出すことができます。
2. AUTHCALL: 承認されたスマートコントラクトは、EOAを代表して取引を実行するためにAUTHCALLを使用できます。

これは、EIP-4337と同様のユースケースの多くを達成しますが、各ユーザーに新しいスマートコントラクトを展開することなく行われます。主な違いは、取引がユーザーのEOAから発信される点で、新しいコントラクトからではなく、ユーザーのアカウント履歴、ETH、NFT、トークンなどが欠如しています。

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種類のアカウント抽象化によって「2つの別々のコードエコシステムが作成される可能性がある」と懸念しています。

EIP-7702

これにより、Vitalik Buterinの提案が本日行われました：EIP-7702。彼はEIP-3074を改変し、EIP-4337との互換性を高め、2つの別々のアカウント抽象化エコシステムができないように提案しています。EIP-5003はその後、恒久的な移行のための次のステップと見なされています。

EIP-7702は、contract_codeとsignatureフィールドの両方を受け入れる新しいトランザクションタイプを導入しています。 トランザクションの実行時には、サイン者のアカウントの契約コードをcontract_codeに設定します。 トランザクションの終了時には、コードを空にリセットします。

EIP-3074に類似して、これはEOAをスマートコントラクトに一時的に委任することを実現します。ただし、EIP-7702は新しいオペコードを導入しません（これにはハードフォークが必要です）、代わりに呼び出すべき関数を定義します。

AUTH -> calls “verify”

AUTHCALL -> calls “execute”

具体的には、それは：

あなたのアカウントの契約コードが空であるかどうかをチェックします。

空の場合、提供された契約コードに設定します。

提供されたスマートコントラクトが取引をどのように処理するかに従って取引を実行します。

アカウントの契約コードを空に戻します。

「契約コード」とは文字通り、スマート契約のコードが格納されている場所です。 EOAそのものが契約ではないため、通常、このフィールドは空です。 ただし、EIP-7702の素晴らしさは、トランザクション実行中に一時的にこのフィールドにスマート契約コードを一部挿入することです。

これは、あなたのEOAがこの特定のトランザクションを実行するための新しい動作（コード形式で）を提供する方法です。次のステップは、単に「トランザクション終了後にコードを空に設定しない」を選択することで、それを恒久的な行動変化にすることです。

この提案の最大の利点の1つは、これまでにEIP-4337のために行われたすべてのアカウント抽象化作業と非常に高い互換性があることです。ユーザーが署名する必要がある契約コードは実際には既存のEIP-4337ウォレットコードである可能性があります。

この変更が有効になると、ユーザーの既存のEOAは任意のスマートコントラクトコードを実行できます。さらに、追加のEIPを通じて、EOAを特定のコードを実行するように永続的にアップグレードすることも可能です。

時間の経過とともに、これは私たち全員がWeb3アプリケーションとやり取りする方法を根本的に変える可能性があります。

ステートメント:

1. この記事は[から転載されましたパニュース], 元のタイトル「EIP-7702提案の探索：ビタリックの口座抽象化問題への究極の処方箋？」、著作権は元の著者[Foresight News]に帰属します。転載に異議がある場合は、お問い合わせください。Gate Learn チーム, チームは関連手続きに従ってできるだけ早く対応いたします。

2. 免責事項：この記事に表現されている見解や意見は、著者個人の見解を表しており、投資アドバイスを構成するものではありません。

3. 他の言語版はGate Learnチームによって翻訳されており、記事には言及されていませんGate, 翻訳された記事の複製、配布、または盗用はできません。