現在、Acccount Abstraction（以下 AA）やそれを実現するための提案 ERC-4337 が注目を集めています。これは、既存のコンセンサス・エンジンを変えることなく、Ethereum のユーザビリティを向上させるものです。今回のエンジニアブログでは、これらの基本的な概念や大まかな提案の内容について紹介します。
目次
Account Abstraction（AA）とは？
現在の EVM の実装には 2 つのアカウントの概念が存在します。Externally Owned Account（EOA）とスマートコントラクトアカウントです。EOA は secp256k1 の楕円曲線暗号を秘密鍵と対応して存在するアカウントで、そのアドレスは対応する公開鍵から導出されます。一方、スマートコントラクトアカウントは EVM のメモリ上に存在するスマートコントラクトに対応するアカウントです。どちらのアカウントもネイティブ・トークンの残高を持つことはできますが、EVM の状態を変更するトランザクションを開始できるのは、EOA のみという点で両者は異なります。逆に、スマートコントラクトは自発的にトランザクションを開始することはできません。また、スマートコントラクトのスクリプトを実行は EOA が起点となるトランザクションである必要があります。
Account Abstraction は、このような 2 つのアカウントの概念を抽象化し、新たに一つのアカウントを抽象化するために提案されました。2023年12月20日現在、ERC-4337 のドラフトにて、AA の目標について、以下のように述べられています。
Achieve the key goal of account abstraction: allow users to use smart contract wallets containing arbitrary verification logic instead of EOAs as their primary account. Completely remove any need at all for users to also have EOAs (as status quo SC wallets and EIP-3074 both require)
つまり、AA ないし ERC-4337 では、ユーザが、EOA に変わる任意の検証ロジックを備えた新たなウォレットを、EOA を持っていなくともスマートコントラクトの形で持てるように実装することを目指しているわけです。
ERC-4337 の特徴
それでは具体的な実装提案の一つである ERC-4337 は、どのような特徴を持っているのでしょうか？
ERC-4337 のドラフトでは、以下のようなことが挙げられています。
- コンセンサスレイヤのプロトコルに変更を加えることなく AA を導入できる
- UserOperation の真正性の検証に利用できる形式が柔軟に
- 非中央集権型
１つ目の特徴について、これはハードフォークが発生しないことを意味します。ハードフォークのハードルはかなり高いですが、それに比べると ERC-4337 は簡単に導入できる、ということです。
２つ目の特徴について、 UserOperation は、AA でのアカウントに関するトランザクションだと認識すると良いでしょう。この真正性の検証ロジックが柔軟に行えることは、トランザクション発行時に secp256k1 の楕円曲線暗号のみしか使えなかった、という制約がなくなることを意味します。つまり、他の曲線での楕円曲線暗号や、BLS 署名、更には外部サービスが提供する JWT までもがアカウントに対する操作データの真正性の検証に使えるようになり得るのです。
３つ目の特徴について、ERC-4337 には bundler や paymaster など、プロトコル上ユーザが依存せざるを得ない構成要素が複数存在します。「非中央集権型」というのは、これらの構成要素は自分で実装し、または実行できるのですが、その際にどの bundler や paymaster などであっても AA のプロセスに参加できる、ということです。また、ERC-4337 で提案される AA のプロトコルには評価機構が存在しており、ドラフトではbundler や paymaster への無条件の信頼を回避できるとしています。
ERC-4337 の構成要素
次に、諸々の実行フローに触れる前に、それらを構成する要素を説明します。
UserOperation
UserOperation（以後、userOp とします）について説明します。 userOp はエンドユーザによって署名され、 Bundler と呼ばれる特殊なノードに送られるデータです。これは、通常のトランザクション構造に幾つか専用のフィールドを加えたもので、エンドユーザが AA でのアカウントに関する EVM 上の状態変更を要求する際に発行されます。具体的な構造体の模擬コードを、以下に示します。
struct UserOperation {
address sender;
uint256 nonce;
bytes initCode;
bytes callData;
uint256 callGasLimit;
uint256 verificationGasLimit;
uint256 preVerificationGas;
uint256 maxFeePerGas;
uint256 maxPriorityFeePerGas;
bytes paymasterAndData;
bytes signature;
}このように、構造自体は通常のトランザクションに非常によく似ていることがわかります。もちろん、ここでの signature に格納するためのデータ生成に用いるアルゴリズムは仕様として規定されていません。これは、後述する Account コントラクトの実装依存となります。注意すべきは、callData でアクセスできる資源には制限がかかっている点には注意が必要です。具体的には、後述する bundler によるシミュレーション時と実際の実行時で値が変わる可能性があるような資源には読み込みも書き換えもできません。
Account コントラクト
Account コントラクトは EVM 上のスマートコントラクトで、Wallet コントラクトとも呼ばれます。このコントラクトのアドレスはオペコード CREATE2 によって決定論的に得られることが望ましいとされています。また、userOp の送信主がコントロール権を持つことを検証するメソッド validateUserOp を持つことが期待されます。裏を返せば、検証ロジックに関する柔軟性はこれに起因しており、validateUserOp の定義次第で、RSA や BSA、JOSE や（通常はあり得ないが）無条件に認めるなど、様々な検証ロジックが組めるわけです。また、userOp.callData を解釈するための関数が存在することが望ましいとされています。Account コントラクトの新規作成については今回は割愛しますが、キーワードとして、Account Factory アカウントを用いることもできます。
Bundler
Bundler とは、Account Abstraction（具体的には ERC-4337）を実装した特殊な EVM クライアントです。エンドユーザが作成した userOp はここに送られます。Bundler では送られてきた userOp を正常に実行できることをシミュレートし、問題なければ一定のチャンクで EntryPoint コントラクトの関数を呼び出して処理を実行します。シミュレートに失敗した場合は、当該 userOp は破棄されます。
EntryPoint コントラクト
最後に、EntryPoint コントラクトです。これは EVM 上のスマートコントラクトで、bundler から送られてきた userOp を実際に実行する役割を担います。また、コントラクトは、userOp を verification loop と execution loop に分けて実行します。verification loop では、以下のことを確認します。
- Account が存在するか？
- 十分な Gas 代が預けられたか？
- userOp は有効か？
これらの確認が問題ないようであれば、EntryPoint コントラクトは execution loop で userOp を userOp.calldata に基づき実行します。当然、calldata をどのように解釈するかは account の実装依存です。また、calldata の解釈を担う execute 関数（名前はなんでも良い）が account コントラクトにあることが期待されます。
ERC-4337 における UserOperation の実行フロー
最後に、UserOperation が実行されるまでの過程について図でまとめましたので、紹介します。諸事情により、英語での表現となっていますが、お許しください。
基本のフロー
Paymaster を利用する場合の実行フロー
AA には Paymaster と呼ばれる概念も存在します。これはご覧の通り、EVM 上のコントラクトで、エンドユーザは Paymaster にトランザクションの Gas 代を支払ってもらうことができます。
まとめ
今回は、AA の目的と、その具体的な提案となる ERC-4337 の基本的な概念に関して解説をしました。AA には他にも signature aggregation と呼ばれる、署名を一まとめにして検証することで、verification loop の実行コストを下げるようなことも提案されています。一方、今回紹介した ERC-4337 は未だドラフトの段階で、今後大きく変わることにも注意が必要です。Bundler の実装については Alchemy や Stackup がクラウドとして提供しているほか、リファレンス実装として GitHub 上で公開されているものもあります。気になる方はぜひ確認してみてください。
