【ERC4337 その1】ERC4337について

2023-07-14Web3.0, ブロックチェーン

お疲れさまです。
次世代ビジネス推進部Web3開発Gの荻原です。

今回は「Ethereum developer communityにとって長年の夢」であったとEthereumの考案者Vitalikにも言われているAccount Abstractionという概念と、それをできる限り実現したERC4337について紹介します。

第1回は概要の説明、第2回は実際に実装して使ってみるところまでを紹介します。

1. Account Abstractionについて

現状Ethereumではtokenを転送する際に、tokenを所有しているEOAを起点としてトランザクションが発行され、トランザクションの正当性を証明するための署名はそのEOAの秘密鍵を用いて行われます。
署名の検証には、secp256k1という特定の楕円曲線を用いて、ECDSAという特定の公開鍵暗号方式によって秘密鍵から導出された公開鍵が用いられます。
公開鍵暗号方式では秘密鍵から公開鍵の導出は可能ですが、公開鍵から秘密鍵を知ることは現在現実的には不可能と言われています。

しかし、秘密鍵にはいくつかのリスクがあります。
例えば、秘密鍵の盗難や紛失です。1つの秘密鍵を失うだけでそのアカウントが保有している資産をすべて失うことになります。
また、「公開鍵から秘密鍵を知ることは現在現実的には不可能と言われています」が、ECDSAは量子コンピュータによって将来的に破られてしまうということも言われています。

そこで、スマートコントラクトをトランザクションの起点にすることで、署名について自由にプログラムすることができるようになりこのようなリスクを低減することができます。
様々な署名方式を用いることができ、秘密鍵を複数使用したり、定期的に署名者を変更することも可能です。

このような背景からEOAから脱却することを目指した概念に、Vitalikによって提唱されたAccount Abstractionがあります。

しかし、Account Abstractionを実現するためにはEthereumの仕組みの根幹から変える必要があり、現実的に難しいです。
そこで、できるだけAccount Abstractionに近づけられるような様々な提案がこれまでされてきました。その中で最も新しいものにERC4337というものがあります。

2. ERC4337について

ERC4337では部分的にAccount Abstractionを実現しています。

まずはERC4337のトランザクション実行の流れを説明します。

従来のトランザクションは発行する際にnonceやcalldata、ガス代関連の値等をまとめて、JSON-RPC APIの eth_sendTransactionを呼び出して渡します。ERC4337ではまずUserOperationという以下の形式のデータを作成します。

UserOperation: {

sender: '0x',

nonce: '0x',

initCode: '0x',

callData: '0x',

callGasLimit: '0x',

verificationGasLimit: '0x',

preVerificationGas: '0x',

maxFeePerGas: '0x',

maxPriorityFeePerGas: '0x',

paymasterAndData: '0x',

signature: ''

}

sender：実行したいコントラクトアドレスです。
nonce：意味としては通常のNonceと同様ですが、Entry Pointが保持しているsenderごとの値です。
以下の形で保持されています。（参考）

nonceSequenceNumber[msg.sender][key]

initCode：ContractFactoryでcontractをdeployする際に使用します。<Contract Factory address><function名のhash値4バイト><引数32バイトずつ>という形式です。
callData：実行したいメソッドの内容です。<function名のhash値4バイト><引数32バイトずつ>という形式です。
callGasLimit：メインのコントラクト（callData）実行時のGas Limitです。
verificationGasLimit：UserOperationの検証時のGas Limitです。
preVerificationGas：トランザクション実行前に実際にガス代が支払われることをBundlerが検証する際に使用されるGasです。
maxFeePerGas：EIP1559のmaxFeePerGasです。
maxPriorityFeePerGas：EIP1559のmaxPriorityFeePerGasです。
paymasterAndData：Paymasterを使う際に使用します。
signature：署名データです。コントラクトの実装に合わせて署名することになります。

このUserOperationをBundlerのJSON-RPC API eth_sendUserOperationに渡します。そしてMempoolという場所に置かれると、いくつかのUserOperationがまとめられEOAを起点としてトランザクションが発行されます。
そして、EntryPointというスマートコントラクトを通じて、UserOperationに含まれる署名の検証やコントラクトメソッドの実行がされます。

ERC4337を利用したトランザクション実行の流れをざっくりまとめると次のようになります。
1. UserOperationを作成する
2. BundlerにUserOperationを送信する
3. EntryPointから署名の検証やトランザクションが実行される

ガス代についてですが、通常はsenderからEntryPointに支払われます（ガス代の流れについては次回、実行した後Polygonscanで確認します）が、Paymasterというものを使った仕組みもありsender以外から支払いをすることも可能です。

以上のように、ERC4337はBundler以外についてAccount Abstractionが実現されています。

3. ERC4337関連で利用できるもの

Stackup
BundlerのSaaSです。チュートリアルから簡単にERC4337を試すことができます。
Stackup GitHub
Goで実装されたBundlerのコードや上記のチュートリアルで使用しているコード等が公開されています。userop.jpはUserOpetationを作成したりBundlerに送信する際に便利なSDKです。
account-abstraction GitHub
EntryPointや上記のチュートリアルで利用するコントラクトが実装されています。

第2回ではここで紹介したものを使います。

さらに詳しくERC4337やAccount Abstractionについて知りたいという方には、日本語記事では以下をおすすめします。

AA（Account Abstraction）の先にある、コントラクトウォレット中心の世界
ERC4337以外にもAccount Abstractionに近づけようとしたEIPがいくつか紹介されています。
Account Abstractionの誤解と真実
Account Abstractionにおける秘密鍵の考え方が深掘って解説されています。