Account Abstraction（アカウント抽象化）とはなにか

April 14th, 2023

こんにちは。

Skyland VenturesでインターンをしているKOJOです。

Web3初心者のKOJOが、Web3について学習した内容をアウトプットしていく連載シリーズを刊行しています。一緒にWeb3について学んでいってもらえれば嬉しい限りです。読みやすく文章を整理するのではなく、なるだけアウトプットをメインにして素早く記事を執筆していこうと思っています。多少見苦しい文面が発生する場合がありますが、ご自愛ください。

文面は、参考にした資料を併記しつつ共有させていただきます。読解の誤りに気づいた場合は、是非とも指摘いただけると幸いです。

今回のテーマはAccount Abstraction（アカウント抽象化）です。

Vitalikの主張

Vitalikは記事にてアカウント抽象化が達成されると以下のようなメリットがあると主張をしています。

マルチシグとソーシャルリカバリー
より効率的でシンプルな署名アルゴリズム（例：Schnorr、BLS）
ポスト量子安全署名アルゴリズム（例：Lamport、Winternitz）
アップグレード可能性

ではなぜAAによってこのようなメリットを受けられるのでしょうか。

今回の作成に利用した資料

SOURCE⓪：ERC 4337　Vitalikの提案内容

SOURCE①：Account Abstraction(ERC4337)を、具体的な処理を追ってしっかりと理解してみましょう。

SOURCE②：m0t0k1ch1さん資料
- AA（Account Abstraction）の先にある、コントラクトウォレット中心の世界
- m0t0k1ch1さんのスライド資料
SOURCE③：Account Abstraction（アカウント抽象化）とは？

SOURCE④：Lawrenceさんニュースレター
- Account AbstractionとERC-4337を区別する①
- Account AbstractionとERC-4337を区別する②
SOURCE⑤：Account Abstractionの誤解と真実

SOURCE⑥：Askyvさんの資料
SOURCE⑦：【EIP-4337】UserOperationをBundlerに投げてからTransactionが発行されるまで

Account Abstraction（AA）とは

いま現在みんなが使っているウォレット（EOA形式）を、新たな形式のウォレット（コントラクトウォレットを利用した抽象化アカウント(?)）に移行させる一連の取り組みのこと。

AAのメリット（砕いて言うと）

ウォレット関連のクリプトにありがちなよくわからない概念（シードフレーズとか）が不要になるかもしれない
今よりも自由にウォレットに機能が追加できる（UXが改善される）かもしれない

なぜこうしたメリットがあるのか？

そもそもウォレットは、種別として２タイプのものが連結している(正確には一つしかないが、普段使いしているものと中身が分離している[アドレスとアドレス先ノードの関係])

SOURCE：Account Abstraction(ERC4337)を、具体的な処理を追ってしっかりと理解してみましょう。

外部所有アカウント(EOA)というのはMetamaskとか、普段われわれが使っているウォレット（のアドレス）
このアドレス＋秘密鍵（パスワード）を使って、私たちはコントラクトアカウントにアクセスしている
EOAを経由せずに、コントラクトアカウントからアクセスすることができれば…？
- コントラクトアカウントはアドレスではない（コード色々書いてある）
- アカウント自体に機能実装が可能なので、色々な機能をウォレット自体につけられる

この2種のウォレット(的なもの)の上下関係がEOA＞コントラクトアカウントだったのだが、アカウント抽象化(AA)を行うことで、コントラクトアカウントをEOAと等しい権限を持つものにする

どうしてAAをやりたい流れがあるのか

先述のコントラクトウォレットに権限を移譲することは直接的には色々な機能がつけられることにつながる。だが、そもそもなぜそのような権限移譲が必要なのか？

SOURCE：m0t0k1ch1さんのスライド資料

AAは具体的には
- トランザクション(TX)の正当性検証/手数料支払いを抽象化したい
- なんで？
EOAはトランザクションの起点（端、end）に存在するもの
- EOAはブロックチェーンの外部にあり、以下の機能だけを持つ（SOURCE）
  - アカウントで利用可能なETHの量を表す残高
  - 全てのトランザクションが一意であることを保証するためのナンス
  - ネットワーク上でアカウントを一意に識別するためのアドレス
EOAからトランザクションに署名を書くことでアカウント所有者本人がトランザクションに対して合意している
- この本人が合意している部分が分散化のミソ。endである個人のウォレットがオーナーシップを持てる所以である
つまり…
- EOAという署名をする存在は必要不可欠
  - しかし、現行の署名機能を持ったEOAは「単純な署名の機能しかない」
  - endになるEOA（本人）にアドオンをつけにくいから、そのendの手前にあるコントラクトウォレットにつけたものを利用したい
  - アカウントを抽象化することで、コントラクト部分の機能をendに寄せたい！
- tx正当性検証
- 手数料支払い
  - txの相手に手数料を相手に押し付けることとかできる

AA＝トランザクション(TX)の正当性検証/手数料支払いを抽象化したい

アカウント抽象化を深ぼる

SOURCE：Account Abstractionの誤解と真実

AA＝秘密鍵からの解放ではない
秘密の希釈化
- 秘密鍵＝全てに対しての秘密であった
- 秘密鍵がバレると全部終わり
- 秘密鍵を分散（分割）させたい
  - 部分的に自分の秘密を解放したい
  - 部分的に自分のアカウント情報を開示する／権限を譲渡することができるようにしたい
  - マルチシグウォレット的な、ソーシャルリカバリー可能なウォレットが作れる(例：Gnosis Safeはマルチシグウォレット)
    - 多要素認証とセキュリティ強化
    - プラグインによる柔軟性
    - ソーシャルリカバリー
    - DECDSAとは異なる署名方式を使いたい場合には、そのためのアカウントを作成することができます。
    - トランザクションの認証に複数の鍵を使用したい場合には、そのためのアカウントを作成することができます。
    - 毎週、署名者を変更したい場合にも、そのためのアカウントを作成することができます。

SOURCE：Lawrenceさんニュースレター① と②

SOURCE：AA（Account Abstraction）の先にある、コントラクトウォレット中心の世界

ここまで説明してきたAAは、現在実装されているERC4337とは微妙に異なる
- AAを目指してヴィタリックはいくつかの提案をしてきた
  - EIP86
  - EIP2938
  - EIP4337（←New！）
- EIP4337はこれまでの提案と比べてプロトコルレイヤーをいじらない新たな提案
  - ERC4337として規格になっている（プロトコルではなく規格をいじっているのみ）
- 本来的なAA（完全なるアカウント抽象化）に、ERC4337だけでは到達できない

（ERC4337において）Bundlerと呼ばれるトラストポイントの発生
- BundlerはUserのトランザクションをまとめて署名をする
- これによりBundlerを信頼する必要ができてる
- Bundlerに署名してもらう代わりに、個々人のアカウントは抽象化することができる（擬似的にAA達成）
ERC 4337は実際こんな感じ

こういった問題があるわけだが…

Askyvさん：ERC 4337のこういった問題（トラストポイントの発生）の解決策を提案

SOURCE：Askyvさんの資料

ERC4337のためのpublic mempool参加者のincentive構造について
Discussion Points on MEV attack targeting on UserOp
bundlerによるMEV抽出を放置するとどうなるか
ERC4337 public mempool実装に関する最新状況(1/5)
UserOperationのためのpublic mempoolを実装する
- 任意のbundlerが受信して処理を行えるように、待機中のUserOperationを共有するp2pネットワークを作る
- p2pネットワークの参加者（UserOperationをアップロードする人、bundleして署名する人）に報酬を配布する
UserOperationの処理フローの中でPBSを実装する
- block builderの役割をbundlerに担わせ、block proposerの役割をvalidatorに担わせることでPBSを実現する