こんにちは。
Skyland VenturesでインターンをしているKOJOです。
Web3初心者のKOJOが、Web3について学習した内容をアウトプットしていく連載シリーズを刊行しています。一緒にWeb3について学んでいってもらえれば嬉しい限りです。読みやすく文章を整理するのではなく、なるだけアウトプットをメインにして素早く記事を執筆していこうと思っています。多少見苦しい文面が発生する場合がありますが、ご自愛ください。
文面は、参考にした資料を併記しつつ共有させていただきます。読解の誤りに気づいた場合は、是非とも指摘いただけると幸いです。
今回のテーマはAccount Abstraction（アカウント抽象化）です。
Vitalikは記事にてアカウント抽象化が達成されると以下のようなメリットがあると主張をしています。
マルチシグとソーシャルリカバリー
より効率的でシンプルな署名アルゴリズム（例：Schnorr、BLS）
ポスト量子安全署名アルゴリズム（例：Lamport、Winternitz）
アップグレード可能性
ではなぜAAによってこのようなメリットを受けられるのでしょうか。
今回の作成に利用した資料
SOURCE⓪：ERC 4337 Vitalikの提案内容
SOURCE①：Account Abstraction(ERC4337)を、具体的な処理を追ってしっかりと理解してみましょう。
SOURCE②：m0t0k1ch1さん資料
SOURCE③：Account Abstraction（アカウント抽象化）とは？
SOURCE④：Lawrenceさんニュースレター
SOURCE⑤：Account Abstractionの誤解と真実
SOURCE⑥：Askyvさんの資料
SOURCE⑦：【EIP-4337】UserOperationをBundlerに投げてからTransactionが発行されるまで
いま現在みんなが使っているウォレット（EOA形式）を、新たな形式のウォレット（コントラクトウォレットを利用した抽象化アカウント(?)）に移行させる一連の取り組みのこと。
ウォレット関連のクリプトにありがちなよくわからない概念（シードフレーズとか）が不要になるかもしれない
今よりも自由にウォレットに機能が追加できる（UXが改善される）かもしれない
そもそもウォレットは、種別として２タイプのものが連結している(正確には一つしかないが、普段使いしているものと中身が分離している[アドレスとアドレス先ノードの関係])
SOURCE：Account Abstraction(ERC4337)を、具体的な処理を追ってしっかりと理解してみましょう。
外部所有アカウント(EOA)というのはMetamaskとか、普段われわれが使っているウォレット（のアドレス）
このアドレス＋秘密鍵（パスワード）を使って、私たちはコントラクトアカウントにアクセスしている
EOAを経由せずに、コントラクトアカウントからアクセスすることができれば…？
コントラクトアカウントはアドレスではない（コード色々書いてある）
アカウント自体に機能実装が可能なので、色々な機能をウォレット自体につけられる
この2種のウォレット(的なもの)の上下関係がEOA＞コントラクトアカウントだったのだが、アカウント抽象化(AA)を行うことで、コントラクトアカウントをEOAと等しい権限を持つものにする
先述のコントラクトウォレットに権限を移譲することは直接的には色々な機能がつけられることにつながる。だが、そもそもなぜそのような権限移譲が必要なのか？
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は実際こんな感じ
こういった問題があるわけだが…
SOURCE：Askyvさんの資料
UserOperationのためのpublic mempoolを実装する
任意のbundlerが受信して処理を行えるように、待機中のUserOperationを共有するp2pネットワークを作る
p2pネットワークの参加者（UserOperationをアップロードする人、bundleして署名する人）に報酬を配布する
UserOperationの処理フローの中でPBSを実装する
block builderの役割をbundlerに担わせ、block proposerの役割をvalidatorに担わせることでPBSを実現する
これを理解するには
具体的にAAするウォレットがどういった経路でトランザクションしているのかの理解が必要
SOURCE：Account Abstraction(ERC4337)を、具体的な処理を追ってしっかりと理解してみましょう。
SOURCE：【EIP-4337】UserOperationをBundlerに投げてからTransactionが発行されるまで
以上