今回は「ERC4337」について簡単にまとめていきます。
以下で作成したスライドをもとに説明していきます。
まずは簡単に「AccountAbstraction」についてまとめていきます。
Ethereumにおいて大きく分けるとアカウントは以下の2つがあります。
EOAアカウント
コントラクトアカウント
EOAアカウントという言葉は聞き慣れないかもしれないですが、皆さんがよく使用されているMetamaskなどのウォレットがそれです。
EOAアカウントの特徴としては以下の2つがあります。
秘密鍵を所有している。
トランザクションを起こすことができる。
Metamaskを作成するときに12個のワードなどからなるシードフレーズが生成されたはずです。
そのシードフレーズから作られたものが秘密鍵であり、「誰にも見せちゃダメだよ」とよく注意されるものです。
その秘密鍵があることでトランザクションを起こすことができます。
一方、コントラクトアカウントとは、スマートコントラクトのことです。
Solidityなどのプログラミング言語を書くことで作ることができるやつです。
コントラクトアカウントの特徴としては以下の2つがあります。
秘密鍵がない。
コードがわちゃわちゃ書かれている。
EOAアカウントと異なり、コントラクトアカウントには秘密鍵がありません。
そのためトランザクションを起こすことができません。
その代わりコードが書かれているので、色々複雑なことができるようになっています。
「AccountAbstraction」の悲願としては、ざっくりいうと「コントラクトアカウントからトランザクションを起こせるにする」ことです。
もう少し詳しくまとめると以下の2つが「AccountAbstraction」の特徴となります。
EOAとコントラクトアカウントの差をなくす。
よりセキュアなトランザクション検証処理の実装。
他にも特徴があるのですが、それはこの記事の最後の方に回そうと思います。
また、以下の記事をがっつり参考にさせていただいています。
これはアカウントというものを抽象化して、現在EOAアカウントにできていることをコントラクトアカウントでもできるようにすることを指しています。
先ほど述べたように、トランザクションを起こすことを目指しています。
現在のEOAアカウントでは秘密鍵を所有しているため、秘密鍵の流出やハッキング、秘密鍵を忘れたことによる実質の資産凍結など様々問題があります。
これを解決する手段として「AccountAbstraction」があります。
具体的なことについてはこれからの章で解説していきます。
ただ、現在のEthereumで「AccountAbstraction」を実装するにはコンセンサスレイヤーの変更が必要になります。
コンセンサスレイヤーでは、トランザクションの検証を行いブロックを生成する部分であり、この部分の変更にはだいぶ時間がかかります。
では次に「ERC4337」について見ていきます!
「ERC4337」には以下のような特徴があります。
メタトランザクションの使用。
現状のAA実装の標準化。
コンセンサスレイヤーの変更をしないAAの実現。
メタトランザクションというのは、「トランザクションの実行を別のアドレスに託す」ことを指します。
例えばブロックチェーンゲームなどで運営がガス代を負担したい時に、トランザクションを起こすために必要な情報をユーザーから受け取り、その情報を使用して運営がトランザクションを起こすことができます。
詳しくは以下を参考にしてください。
「ERC4337」ではこのメタトランザクションの仕組みを利用しています。
「AccountAbstraction」の実装について、現状実装する方法として統一されたものがありませんでした。
ERCとは改善提案のことであり、何かを実装するための設計書のような役割を持っています。
「ERC4337」はまさに現状で「AccountAbstraction」を実装するための設計書のような役割を担っています。
前の章で「AccountAbstraction」を実装するにはコンセンサスレイヤーの変更が必要であるとお伝えしました。
コンセンサスレイヤーの変更には長い時間がかかるため、特に変化が早いWeb3の世界においてそれまで待っていられません。
そこで出現したのが、「ERC4337」です。
「ERC4337」はコンセンサスレイヤーの変更が不要なため、現状のEthereumでも「AccountAbstraction」を実現できます。
ではここから具体的な仕組みについて見ていきましょう!
「Bundler」とは、さまざまなトランザクションをまとめて実行する存在のことです。
この部分で先ほど説明した「メタトランザクション」が役立ってきます。
また、「Bundler」はEOAアドレスです。
「あれ?EOAアドレス存在するの?」と思ったそこのあなたは鋭いです。
「ERC4337」では完全な「AccountAbstraction」の実現はまだできていません。
完全な「AccountAbstraction」の実現には、先ほどお話しした「コンセンサスレイヤーの変更」が必要です。
現状で「AccountAbstraction」を実現するにはまだ足りない部分がありますが、そこは目を瞑りながら実装している状態です。
Bundlerがやっていることをまとめると、「複数のコントラクトウォレットからのトランザクションをまとめる」となります。
まずはコントラクトウォレットが用意できました。
「UserOperation」とは、トランザクションを実行するために必要なデータ群のことです。
図のようにさまざまなデータが格納されています。
「UserOperation」内のデータをすべて確認するとこれくらいあります。
1つ1つの紹介は省きますが、色々あるんだなということだけ覚えておいてください。
「Mempool」とはブロックチェーン文脈だと、トランザクションの溜まり場のことを指します。
ただ、「ERC4337」での「Mempool」はもっと上位に位置するもので、先ほどの「UserOperation」の溜まり場だと思ってください。
コントラクトウォレットから渡された「UserOperation」は、この「Mempool」にどんどん溜まっていきます。
コントラクトウォレットで生成された「UserOperation」が「Mempool」に渡されて溜まっています。
ここで「Bundler」が再登場します。
再登場した「Bundler」が何をするかというと、「Mempool」に溜まっている「UserOperation」をとっていきます。
先ほど説明したように、「Bundler」がトランザクションを実行するため、そのために必要なデータである「UserOperation」を取りに来ています。
「Bundler」が複数の「UserOperation」を「Mempool」から取り出しました。
「Bundler」は取ってきた「UserOperation」をまとめて「Bundle Transaction」というものを起こします。
ここでトランザクションが発生し、「EntryPointContract」というスマートコントラクトに渡されます。
「EntryPointContract」に「Bundler」から「UserOperation」たちが渡されました。
「EntryPointContract」内で何をしているか説明していきます。
まずは受け取った「UserOperation」たちを1つずつ検証していきます。
検証時に「UserOperation」内のデータを使用して、各「UserOperation」を作成したコントラクトウォレット内に存在する検証ロジックを実行します。
コントラクトウォレットはコントラクトなので、検証のためのコードが書かれています。
この検証を1つずつ行い検証が成功したもののみ実行されます。
これで「EntryPointContract」内で「UserOperation」の検証と実行がされました。
ここまでが「ERC4337」の処理の流れです。
いかがだったでしょうか?
整理してみると意外と難しくなかったのではないでしょうか?
「ERC4337」の処理の確認ができたところで、補足をしていきます。
「UserOperation」内に使用される想定のガス代が含まれています。
しかし、もちろん予測値のため若干のガス代の前後があったり、より多くのガス代を含む「UserOperation」が存在します。
そのため、「Bundler」がトランザクションを起こしたのち、ガス代が余ることがあります。
この余ったガス代は「Bundler」の手元に返ってきます。
これにより、「Bundler」はガス代がより高い「UserOperation」から処理しようとするインセンティブが働きます。
「EntryPointContract」に「UserOperation」は渡されたが、検証を実行するためのコントラクトウォレットがない時は、「UserOperation」に含まれる「Initcode」という値を使用してコントラクトウォレットが作成されます。
この部分の詳細についてはまだしっかり追えていません…。
通常トランザクションを起こす時のガス代は「Bundler」が負担しています。
そのため、「UserOperation」内にガス代を含み「Bundler」に渡しているのですが、ガス代を負担するアドレスを指定することもできます。
この存在は「PayMaster」と呼ばれています。
「EntryPointContract」にあらかじめガス代を預けておき、預けたガス代まで「PayMaster」が負担できます。
自分の想像では、「Bundler」は「ERC4337」の仕組みを提供するサービスに任せ、ガス代をゲームの運営アドレスなどに負担させたい時に使用されるのではないかと思っています。
これで登場人物が揃いました。
「ERC4337」の全体像は上記のようになっています。
ちなみにVitalik Buterinのブログに掲載されていた図は以下になります。
上記の図の方がより詳しく書かれているので、もっと仕組みを深堀したい方はぜひ以下の一読をおすすめします。
次に「AccountAbstraction」のメリットについて見ていきます。
セキュリティの観点からだと以下のメリットがあります。
不正な送金を防ぐ。
署名方式を任意のものに変更。
ソーシャルリカバリー。
多要素認証
コントラクトウォレットは秘密鍵を持たずに、コントラクト内で資金を管理できるため、今までのような秘密鍵の流出やハッキングを受ける可能性がなくなったり軽減されます。
コントラクトウォレット内で署名を生成するため、署名方式を任意のものに変更することが可能になります。
現在EthereumではECDSA署名が使用されていていますが、量子コンピューターの進化によっては破られる可能性が出てきます。
(現在では近い将来量子コンピューターによってECDSAが破られる可能性は低いそうですが、量子コンピューターの進化の速度が早まれば破られる可能性が高まります。)
そのため、量子耐性がある署名方式を使用することもできるようになります。
ソーシャルリカバリーとは、署名に使用する鍵をユーザーが紛失した場合に復活させることを指します。
詳細は割愛しますが、あらかじめ設定しているガーディアンという複数のウォレットコントラクトによる署名を用いて、署名に使用するキーを復活させる問うことをしています。
詳しくは以下の記事を参考にしてください。
署名の方式を柔軟に変更できるため、指紋認証なども組み込むことができます。
例えば、指紋認証してコントラクトウォレットを作成し、指紋認証をしてもらってトランザクションを起こすなどです。
この場合、「多要素認証」にはなっていないですが、他の署名などと組み合わせれば「多要素認証」を実現できます。
その他の機能として以下の2つが挙げられます。
Session Key
サブスクリプション
セッションキーとは、「一定期間ある一定額の決済を承認する」仕組みのことです。
これによりいちいちトランザクションを起こすたびに検証が不要になり、より早く決済を実行することが可能になります。
一定期間ごとに一定額を支払うなどの機能もコントラクトに持たせることができます。
これによりサブスクリプションが実現できます。
では最後に現状の「ERC4337」の問題点を見ていきましょう。
問題点としては以下の2つが挙げられます。
EntryPointContractの脆弱性
BundlerはEOAアカウント
「EntryPointContract」で実行する処理の検証などを行なっているため、このコントラクトに脆弱性があると問題です。
このコントラクトが攻撃されるとトランザクションの検証や実行時に予期せぬ動作を引き起こすことがあります。
これは問題というよりは課題点なのですが、「Bundler」は現状EOAアカウントです。
そのため、この「Bundler」もコントラクトウォレットにできれば登場人物からEOAアカウントがなくなるため、あと一歩という状態です。
今回は「AccountAbstraction」および「ERC4337」について取り上げてきました。
いかがだったでしょうか?
今後も技術的な部分を中心にわかりやすくまとめていこうと思います。
他の媒体でも情報発信しているのでよければ見ていってください!