Account Abstraction とは何か？ブロックチェーンの体験を変えるERC4337について

Table of Contents

最初に

Account Abstraction は、ブロックチェーンにおけるユーザ体験を劇的に改善することが期待されている技術です。
これまで、多くのブロックチェーンにおいてユーザが直接秘密鍵を管理・処理を実行することから、セキュリティやガスの支払い等、ユーザ体験に大きな問題を抱えていました。

Account Abstraction はこれらの問題を解決することが期待されており、特にEthereum考案者のVitalik Buterin氏は、自身のブログにて「Account Abstraction はEthereum開発者コミュニティにとっての長年の夢である」と述べていることから、Ethereumコミュニティを中心に今後更に大きなトレンドとなることが予想されています。

どのように体験が変わるのか？

まずはどのように体験が変わるのか見ていきましょう。
具体的には以下のようなことができるようになります。

秘密鍵の保持が不要になり、パスワードや生体認証を元にウォレットを操作できる
任意のセキュリティ機能をつけることができる
例)
- 特定のNFTのtransferはできないようにする
- 特定のNFTに関わる操作は2段階認証を必要とする
ガス代の代行、ガス代をERC20での支払い
ウォレット作成時に (FT, NFT, SBTなど) Tokenを付与
今まで複数回トランザクションを実行する必要があったものが、1回（または、より少ない回数）で実行できる

ERC4337のAccount Abstractionの仕組みに入る前にまず、EVM (Ethereum Virtual Machine) のアカウントについて見ていきましょう。

ブロックチェーンのアカウントについて

ブロックチェーン上にもweb2サービスと同様にアカウントが存在します。
EthereumだとコントラクトウォレットとEOA (Externally Owned Account) という大きく分けて2つのアカウントの種別があります。

まずはコントラクトウォレットとEOAの違いについて理解していきましょう。
Account Abstractionを理解するにあたって、この2つのアカウントの種類の違いを理解するのはとても大切です。

スマートコントラクトとは？

Solidity等で自由にロジックを書けるEthereum等のブロックチェーン上で動くプログラム

スマートコントラクトの特徴

秘密鍵がない
自分でtxを発行できない

コントラクトウォレット

Solidityなどで書かれたスマートコントラクトウォレットのことです。
スマートコントラクトなのでウォレットの機能を自由に開発することができます。（セキュリティ強化機能なども開発して付けることが可能です。）

例）

Multisig wallet (Safeなど)
Token Bound Account (ERC6551)
Account Abstraction の Contract Account

EOA

EOAは皆さんがMetaMaskなどで利用しているアカウントのことです。
ECDSAを利用した公開鍵・秘密鍵形式のEthereum上で一番基本的なアカウント形式です。
特に意識をしてなければEOAを使っているはずです。

EOAにはセキュリティ面など、様々な課題があると言われています。
この課題がコミュニティがAccount Abstractionを求める理由です。

コントラクトウォレットとEOAの違い

	EOA	コントラクトウォレット
秘密鍵	ある	ない
処理の記述	できない	できる

現在のEOAの課題について

EthereumのEOAの課題は様々ありますが、主には以下の課題があります。

ガス代が高く、ガス代の支払いに柔軟性がない
- 署名し、トランザクションを発行したアカウントからしかガス代が払えない
- ガス代がETHでしか払えない（WETHなどネットワーク内で価値が確立しているERC20 tokenでもガス代の支払いができない）
特定のアセットに対してセキュリティを強めるなど、柔軟なセキュリティ設定ができない
- 詐欺師や詐欺スマートコントラクトによって暗号資産やNFT略奪などの詐欺が横行している
アカウントの管理、体験が複雑でweb2に比べてUXが悪い
- アカウントを作る際に数十個から成るニーモニックを紙に書いて保管する必要がある
- 毎回トランザクションを署名しないといけない
- 秘密鍵を無くしたり盗まれると一貫の終わり。復旧が出来ない

ブロックチェーンの世界では上記課題に長年悩まされてきました。
その解決をするために考案されたのがAccount Abstractionです。

Account Abstraction

Account Abstractionとはアカウントの抽象化という意味です。
アカウントの抽象化という名前が使われる理由はブロックチェーンネットワーク、ユーザそれぞれにアカウントが抽象化されるからです。

ネットワークレベルの観点から見ると、「アカウントの抽象化」とは、アカウントタイプの詳細が Ethereum プロトコルからは見えないことを意味します。すべてのアカウント (セルフカストディーアカウントを含む) は単なるスマートコントラクトであり、ユーザは個々のアカウントをどのように管理および運用するかを自由に決定できます。

ユーザレベルの観点から見ると、「アカウントの抽象化」とは、 Ethereum アカウントとのやり取りに関する特定の技術的な詳細が、より高いレベルのインターフェースの後ろに隠されることを意味します。これによりウォレットの設計が改善され、web3アプリケーションの利用の複雑さが大幅に軽減されます。

Account Abstractionの歴史

Account Abstractionは早くは2016年から提案されており、幾度とEIPが提案されてきました。

(Reference: WHY ACCOUNT ABSTRACTION IS A GAME-CHANGER FOR DAPPS)

いくつかある Account Abstraction の提案の中で、採用された提案はまだ1つもありません。
ERC4337は一番最近の提案で、過去の提案の多くの機能を包括した提案でありつつ、他より実現できる可能性が高いです。
かつブロックチェーン上での体験を大きく変えられる技術規格なので、コミュニティがかなり盛り上がっています。

EIPのステータスはまだDraftで現在も開発、議論が行われている最中です。
データのスキーマやサンプルの実装の監査が OpenZeppelin によって実施されました。
最新の実装状況は Ethereum Infinitism の Github repository で確認できます。
他のAccount Abstractionに関するEIPは最後の おまけ で触れております。

ERC4337の処理の流れ

ERC4337に登場する人物と役割、用語は以下の通りです。

用語

UserOperations (UserOps): ユーザが実行したいトランザクションに関する情報が入ってる
- 今でいうトランザクションの情報
UserOperation Mempool: UserOperationが実行前に保管される場所。トランザクションMempoolと同様の機能を果たす。
Bundler（バンドラー (意味: 束にする人)）: ERC4337の世界で登場する唯一のEOA。現在のNode運営者の中の希望者がBundlerとして動き、UserOperation（ユーザが実行したいトランザクション）を処理する想定がされている。
- ERC4337の世界ではBundlerが唯一のEOAなので、一般ユーザはEOAを持つ必要がない。
Bundler Marketplace: ユーザが設定したガス代をもとにBundlerがどのUserOperationを実行するかを選ぶ場所。既存のガスマーケットと同様のもの。
Global Entry Point: 各ネットワークに1つしかないEntry Point Contract。束になったUserOperationsの処理を実行する。
Users Contract Accounts: ユーザのウォレット。ウォレットがコントラクトになったのでウォレットに処理や設定を加えることができる。ウォレット作成時にコントラクトをデプロイする必要がある（=ガス代がかかる）。
Paymaster Contract: 必須ではない任意のコントラクト。ユーザのガス代を肩代わりしたり、別ERC20で支払うことを可能にします。
Aggregator （アグリゲーター (意味: 集約する人)）: UserOperationsを集約する場合のみに使用される任意のコントラクト。集約された署名を検証するために Users Contract Accounts によって信頼されるHelperコントラクト。BundlerはサポートしているAggregatorをホワイトリストに登録する。
- 集約しない際と比べて、集約すると、ガス代が安くなる想定がされている。

UserOperations のスキーマ（型）

フィールド	タイプ	説明
sender	address	処理を実行するコントラクトアカウント
nonce	uint256	リプレイアタック防止のためのパラメータ（ウォレット生成の際は salt として利用される）
initCode	bytes	コントラクトアカウントの初期化コード（コントラクトアカウントが生成される際のみ必要）
callData	bytes	メイン実行呼び出し中に`sender (処理を実行するコントラクトアカウント)`に渡すデータ
callGasLimit	uint256	メイン実行呼び出しに割り当てるガスの量
verificationGasLimit	uint256	検証処理のために割り当てるガスの量
preVerificationGas	uint256	事前検証実行とcalldataの補償のために支払うガスの量
maxFeePerGas	uint256	ガスあたりの最大手数料（EIP-1559と似てる）
maxPriorityFeePerGas	uint256	ガスあたりの最大優先手数料（EIP-1559のmax_priority_fee_per_gasと似てる）
paymasterAndData	bytes	トランザクションをスポンサーするPaymsterのアドレス、およびPaymsterに送信する追加データ（自分で (`senderが`) ガス代を払う場合は空）
signature	bytes	検証処理中にnonceとともにアカウントに渡されるデータ。（パスワードや生体認証などの電子署名情報）

処理の流れ

ユーザの意図する処理（UserOperations）をUserOperation Mempoolに送る
BundlerがBundler Marketplaceを介してUserOperations MempoolからUserOperationを取得する
BunderがUserOperationsを束にして、Global Entry Point Contractにトランザクションを発行
(Paymasterがいる場合) Global Entry Point ContractからPaymasterを呼び、処理の検証をして、実行
Global Entry Point ContractからUsers Contract Accountsを呼び、処理の検証をして、実行
- この際にセキュリティロジックを実装してる場合、5. の処理の際にセキュリティロジックが走る

(Reference: Rethink Digital Transactions with Account Abstraction)

ただ、ユーザが気にする必要がある部分は下記の User/Sender with Non-custodial ERC-4337 Wallet (ユーザ) と Users Contract Accounts (コントラクトウォレット) だけです。Dapps開発者も原則は上記2つに加えて、Paymaster Contract と Global Entry Contract の接続部分を気にするだけで大丈夫です。
Global Entry Contract は前述の通り各チェーンに1つなので、接続箇所だけ気に留めるだけで大丈夫です。

ここまで読んで「あんまりよくわからなかったな」と感じた方は

💡 「Account Abstraction って、コントラクトウォレットが基本になって、セキュリティ、UX、ガス代など様々な問題が解決できるもの」

とだけでも覚えてもらえば良いと思います。

ERC4337の課題

どのように体験が変わるのか？ で記載した通りERC4337で様々な課題が解決され、ブロックチェーンのユーザ体験が劇的に良くなることが予想されます。一方でERC4337も完璧ではありません。ERC4337には以下の課題、懸念点があります。

DoSの脆弱性の懸念
単一のECDSA検証という現状よりもやや複雑な検証ロジックが許可されるため、プロトコルは最善の努力を尽くしてますが、DoSの脆弱性がわずかに増加します。
ガス代が高くなる可能性もある
※複数transactionを一括で発行することで安くなる可能性もある。ガス代の最適化も同時に議論、検討が進んでいます。
エントリーポイントコントラクトのSPOF (単一障害点)
エントリーポイントコントラクトというグローバルな単一のゲートウェイコントラクトが出来たことによって、トラストポイントが生まれました。トラストポイントができたことにより新しい課題が生じます。ERC4337 コントラクトアカウントから実行される処理は全てエントリーポイントコントラクトを経由するため、ここにバグや脆弱性が潜んでいた場合、それと接続している全ての ERC4337 コントラクトアカウントの資産が攻撃の危険に晒されることになります。よって、エントリーポイントコントラクトには、非常に厳しい監査や形式検証が求められます。
※ Ethereum communityや提案者、その関係者もこの課題はもちろん認識しており、徹底的な監査を実行する想定です。
Contract Account をデプロイするのにガス代がかかる
コントラクトウォレットの生成にはガスが必要です（一方、EOA の生成にガスは必要ありません）。コントラクトウォレットの普及に、生成時にガスが必要な点は大きな課題となるでしょう。

ブロックチェーン業界での注目

最後にブロックチェーン業界でどれだけERC4337のAccount Abstractionが注目されているか、各キープレイヤーの動きを共有します。

ウォレット

今まではユーザ用のEOAウォレットとMultisigなどのコントラクトウォレットは別のペルソナをイメージし、ユーザ層はあまり重なっていなかったように思います。
ただこれからはERC4337の台頭により、このユーザ層が交わってきます。今までMulsitigウォレットのデファクトスタンダードのSafeとエンドユーザ用ウォレットのユーザ層が競合し、ウォレット業者は今までより競合が増えるでしょう。

Metamask
ウォレット大手のMetamaskも、もちろんERC4337には注目し、Snapsという機能でAccount Abstractionをサポートすることをブログでも言及しています。
Safe
Multisigコントラクトウォレットで有名のSafeも ERC4337 の Account Abstraction に強く注目し、様々な記事を記載したり、既に想定される問題についての検証・解決方法の模索などを行なっています。SDKの開発も実施済みで既にソースも公開されています。
Alchemy
AlchemyもERC4337 の Account Abstraction のSDKを開発しており、ソースを公開しています。
かつAlchemyはRPC providerでもあるので、bundlerになることも期待されています。AlchemyにとってERC4337 の Account Abstraction は切り離せない技術で今後強く関係することが想定されています。

Paymaster

VISA
VISAがPaymasterのコントラクトをEthereum testnetのgoerliにデプロイしたとニュースがありました。
VISAは早くから会社としてブロックチェーンに関わっていますし、Paymasterで積極的に技術検証を行なっています。
大企業のVISAがPaymasterの検証を実施してるのはERC4337 Account Abstraction がどれだけ影響力が大きいかを示していると思います。

その他

その他にも多くのweb3企業が ERC4337 Account Abstraction に対して多種多様なアクションを取っています。
ブロックチェーン上の体験が大幅に変わるので、その他にもいろんな分野で新しいDappsが登場するでしょう。
Account Abstractionによりサブスク支払い機能などもウォレットに組み込むことが可能なので、よりweb2のUXにして近づくことが想定されています。
ブロックチェーン上の体験が大きく変わることで業界でのビジネスインパクトもかなり大きく、新しい事業形態がweb3の業界に生まれるでしょう。今後のweb3の発展がより楽しみです。

おまけ

過去のAccount AbstractionのEIPが採用されなかった理由の一つは、全て提案がEIPのカテゴリの中のCoreというコンセンサスアルゴリズムレイヤーに修正が入るような改修コストの大きいジャンルのEIPだったからと言われています。

2016年からEIPが定義されている
- EIP-86: Abstraction of transaction origin and signature (Core)
  - 新しいトランザクション形式と新しい opcode を導入
    - CREATE2 は既に https://eips.ethereum.org/EIPS/eip-1014 で導入済み
  - プロトコルの代わりにコントラクトがトランザクション検証処理（電子署名や nonce の検証）や手数料徴収処理を担えるようにする
2020年にCore（難しくて手間のかかる）のEIPが2つ出てる
- EIP-2938: Account Abstraction (Core)
- EIP-3074: AUTH and AUTHCALL opcodes (Core)
  - EOAの権限をスマートコントラクトに委任することで、Account Abstraction を実現してる
  - スマートコントラクトをデプロイしなくても、Account Abstraction を実現できる