イーサリアム技術解説:ウォレットのUXを向上させる、Account Abstractionとその近況(第3回)

今回は前回に引き続き、Account Abstraction(AA)について解説します。前回は現在主流となっている3つのAA関連規格のうち、EIP-3074とERC-4337について解説しました。ERC-4337については2023年3月に実装済み、EIP-3074についても2025年Q1に実施予定の「Pectra」アップグレードで実装される予定でしたが、急遽実装がキャンセルされることになりました。

EIP-3074の実装はなぜキャンセルされたのか、今回はAA関連規格を取り巻く議論とEIP-7702について見ていきたいと思います。

EIP-3074の実装がキャンセルされた背景には、すでに実装されているERC-4337との互換性がないということ、今後のAA関連規格との前方互換性を持たせにくいということが挙げられます。

EIP-3074による既存ウォレットアドレスのAA化は、AUTHとAUTHCALLという2つのオペコードを追加することで実現されるものでした。しかし、これはすでに実装済みのERC-4337とは異なる手法であるため、既存のウォレットアドレス向けのAA(EIP-3074)とスマートコントラクトベースのウォレット向けのAA(ERC-4337)でまったく別の仕組みになってしまうことが懸念されるようになりました。

また、今後のAA関連規格においてもAUTHやAUTHCALLを使うようなものが実装されることは考えにくく、EIP-3074でしか使われないオペコードが残り続けることを是としない開発者が少なからず出てくるようになりました。

こうした議論が巻き起こる中で、ERC-4337と互換性を持ち、オペコードの追加を必要とせずに既存ウォレットアドレスのAA化を実現する規格として、EIP-7702というものが提案されました。EIP-7702の仕組みは以下のようなものです。

まず、「SET_CODE_TX_TYPE」という新たなトランザクションタイプをEthereumに導入します。このトランザクションタイプの中には、一時的に使用したいスマートコントラクトのアドレスを指定する部分(以下タプルと呼称)が含まれています。

SET_CODE_TX_TYPEが実行されると、タプルへの署名を行ったウォレットアドレスが、一時的に指定したスマートコントラクトとして見なされるようになります。SET_CODE_TX_TYPEの実行が完了すると、タプルに入っていた情報は空になり、元のウォレットアドレスに戻ります。

これが大まかなEIP-7702の仕組みです。一見するとAAとは関係がないようにも思えますが、スマートコントラクトベースのウォレットアドレスをタプルで指定しておくことで、ERC-4337によるAAを既存のウォレットアドレスから利用することができるようになります。

また、タプルへの署名を行うウォレットアドレスと、SET_CODE_TX_TYPEを実行するウォレットアドレスは異なっていても問題ないという特徴を持っています。このため、ガス代を払うことなく既存のウォレットアドレスからAAを利用することができるようになります

EIP-7702は、AAの仕組み自体はERC-4337のものをそのまま利用しているため、AA周りのエコシステムが1つにまとまるというメリットがあります。また、チェーンの基幹的な部分であるオペコードではなく、トランザクションタイプの追加によって既存ウォレットアドレスのAA化を実現することができるため、前方互換性を持たせやすいといったメリットがあります。

このように、EIP-7702はEIP-3074の懸念点をすべて解消するようなものでした。EIP-7702が提案されたことを背景として、EIP-3074の実装予定はキャンセルされることになり、代わりとしてEIP-7702がPectraアップグレードにて実装されることが決定されました。

次回はいよいよAAに関する解説の最終回として、これまでのまとめと、今後の実装が期待されているネイティブAA規格「RIP-7560」について見ていきたいと思います。

「MCB Web3カタログ」でウォレット関連のサービス一覧を確認する

ニュースレターを無料購読していただくと、毎週月曜日の17:00にイーサリアム技術解説シリーズを含む最新のニュースレターをお届けいたします。

Comments are closed.