👏

Account Abstractionの誤解と真実

2023/03/08に公開
2

ETHIndia以降AccountAbstractionが流行ってますが、世間のAAの認識は実態と少しずれていると感じていました。
この記事はその誤解を解いて行きたいという旨のポエムです。
時間がない方はAA = 秘密鍵の解放ではないの部分だけでも読んでいただければ幸いです。

自己紹介

まず、簡単に自己紹介をします。僕はinaridiyという名前で活動しているエンジニアです。以前ETHIndiaというハッカソンにXWingというチームで参加し、Firewalletというウォレットを作ってEFから1st Prizeをもらいました。
ETHIndia期間ではAAについてのリサーチからコントラクトの実装とフロントエンドロジックの実装を行いました。
https://twitter.com/inaridiy/status/1599384032311382016

そもそもAAとは

まず、AAとはAccount Abstractionのことであり、直訳するとアカウントの抽象化となります。
どういうことかというと、現在のAccount=EOAの状態を解消し、Accountという概念で抽象化するということです。
そのためにAAではContractを最上位アカウント(トランザクションの起点になれるアカウント)にすることで、トランザクション検証処理に任意のロジックを使用できることを目指しています。

トランザクションの検証処理が抽象化したする主な利点は、よりセキュアなウォレットを作ったり、ソーシャルリカバリーといった機能を実装したウォレットを作れるなどです。
また、現状のECDSA以外の暗号技術も用いることができるようになるので、コントラクトに実装次第で量子耐性がある物や計算効率の良いもの、BLS署名なども利用可能になります。

AAに関して最新の規格であるERC4337では真の意味でAAを成し得ている訳ではなく、実質的にContractを最上位アカウントと同等として扱えるようにします。
それらが完全でない故に後述するようなデメリットも生じています。

ここまでがAAそのものの概要です。より詳しく知りたい方はm0t0k1ch1様の名記事をお勧めします。
https://zenn.dev/sivira/articles/d041f1ac44ca1e

AA = 秘密鍵からの解放ではない

AAはトランザクションの検証処理を抽象化しますが、それによって秘密鍵から完全に解放される訳ではありません。
そもそも、自分でしか操作できないものを作るには自分しか知らない秘密を鍵にするしかありません。
これはAAやウォレットにおいても同様で、自分しか操作できないウォレットを作るにはそのウォレットの鍵となる秘密は自分自身で管理するしかありません。
現代人はこのあたりまえをGoogleなどの便利なサービスで忘れがちですが、これは絶対です。
EOAは秘密鍵が、生体認証ウォレットなら指紋などが※1、スマホでいうパスワード※2などがこの自分しか知らない秘密に当たります。
仮に完全に秘密を持たなくても操作できるウォレットがあるなら、それは誰にとっても操作できるウォレットになってしまいます。

※1 生体認証ウォレットによります ※2 スマホなどはメーカーなどが抜いてる可能性があります

秘密の希釈という考え方

それならAAになっても秘密を握るUXは変わらないかというと、そういう訳ではないです。
なぜなら、AAによってトランザクション検証処理が抽象化することによって秘密の希釈をできるからです。
どういうことかというと、今までのEOAでは秘密鍵=全てに対しての秘密でした。
ですが、AAを使うとある秘密に対しての権限を下げることができます。例えば、ある秘密(秘密鍵など)ではウォレットの中の0.1ETHしか使えない、といった制約を設けることができるようになります。
そういった制約はウォレットコントラクトに実装されることになるのですが、実装や設定によってこれらを自由に設定できるので、ある秘密に対しての重要度をEOAに比べて希釈できると言える訳です。

これらの思想を体現したのがEthIndiaで作ったFirewalletです。
Firewalletはウォレットの検証処理に任意の秘密を用いれるようにし、その秘密ごとに使える権限を設定できるというものでした。

秘密の委託という考え方

次にAAでトランザクション検証処理を抽象化すると、Googleのアカウントでトランザクションを制御できる、などと聞いたことがあるかもしれませんが、これ自体はAAだからできる訳ではありません。
例えばWeb3Authなどがいい例だと思います。Googleなどのアカウントでログインするだけですぐにウォレットが使えるようになります。

では、AAを使えばどうなるのでしょうか? それについて考える前に今のWeb3Auth※3について振り返ってみましょう。
Googleアカウントでトランザクションを投げれるということは、トランザクションを投げる権限を持った秘密をGoogleに握られていることと同義です。もっと言えば、Googleにはトランザクションを投げるサービスはないので、それを仲介しているWeb3Authにも握られていると言えます。
つまり、GoogleとWeb3Authをフルトラストしてウォレットの全権限を持った秘密を委託しています。
その代わりにUXを得ているのです。

ここで思い出してほしいのが、トランザクションの抽象化によって可能となった秘密の希釈です。
そう、AAを使えば希釈した秘密を委託することで、比較的相手をトラストせずにUXを手に入れることができます。

ここではGoogleなどを使った例を挙げましたが、ZkSyncなどでAAウォレットを展開しているArgentにはセッションキーという機能があります。
これは一時的に設定したトランザクションのみを実行できるセッションキーというものを発行して、それをDAppなどに渡すことでDApp側からトランザクションを実行できるようにする機能です。
これを先ほどまでの概念に置き換えると、希釈した秘密をDApp側に委託する機能、と言えそうです。

※Web3Authは秘密鍵自体の管理は比較的分散していますが、そもそもサービスやノードが消滅する可能性、などなどゼロトラストでは運用できないと考えています

規格化 = できることが増える訳ではない

先ほどからAAを使えば、という言葉を度々使用してきましたが、今のEthereumにおけるAA(4337)はプロトコル改修を必要としないただの規格なのでAA以前でもコントラクトウォレットとして同じものを作ることができました。
ERC4337はAAという目的はあれど、今のままだとEthereumお墨付きのコントラクトウォレットとその周辺インフラの実装パターンでしかありません。

それでも、そのお墨付きで大きく二つの効果があります。
一つ目は相互運用性が高まることです。今までのコントラクトウォレット群はほぼ全て実装などがバラバラであるウォレットを別のサービス内では使用できないなどが多々ありました。それがERC4337として規格化されることでさまざまなウォレットとそのインフラの相互運用が容易になります。これはERC20やERC721などでも見られる利点だと思います。
もう一つは理想のAAに近づいたことです。理想のAAとはアカウントの抽象化=コントラクトを最上位アカウントにすることを目標としていますが、現在のEthereumではその対応は大掛かりなものとなるため、易々と行えません。
なので、EOAを起点としたトランザクションしか実行できないのですが、Bundlerという役を規格に含めたため、実質コントラクトウォレットを最上位アカウントに近いUXで扱うことができつつあります。ここまで言葉を濁したのには理由は後述しますが、要するにこれがAAのための現実的な落とし所です。

Bundlerと検閲など

理想のAAに大きく近づいたERC4337ですが、あくまで規格なのでコントラクトが最上位アカウントになるためにBundlerというEOAの手助けが必要です。
ここに大きな問題があって、Bundlerが検閲やMEVなどを行えてしまいます。これに対する解決策は現在議論中で、まだ明確な答えはありません。ブロックチェーンのようにP2Pメモリープールを構築するという意見が主流ですが複雑な機構を必要とする可能性が高そうです。
ですが、機構が複雑になるほどプロトコルレイヤーの改修に近づくので、なかなか厳しい感じがしています。
ただ、 あくまで検閲などの危険性があるだけで、トランザクションそのものを改竄は出来ないです。

終わりに

ここまで読んでいただきありがとうございます。これを読んだ方のAAに対する知見が深まれば幸いです。
もし間違っているところや分かりづらいところなどあれば、DMなどいただければ幸いです。
なんだかんだ言ってきましたが、AAはとても面白い分野です。レッツAAライフ!!!!!!

Discussion

HarukiHaruki

素晴らしい記事ですね!またDiscordで会話させてください!!