アカウント抽象化（ERC-4337）

なぜアカウントを「抽象化」するのか

Ethereum のアカウントには2種類あります。外部所有アカウント（EOA, Externally Owned Account）は秘密鍵に対応するアカウントで、残高だけを持ちコードを持ちません。もう一方のコントラクトアカウントはコードと永続ストレージを持ちますが、自発的にトランザクションを起こせません。この非対称が問題の根です。台帳の状態を動かすトランザクションは、必ず EOA の秘密鍵による ECDSA 署名から始まる必要があります。署名方式は secp256k1 の ECDSA 一択、権限は鍵1本、ガスは必ずその EOA の残高（ネイティブ通貨）から支払う——これらがプロトコルに固く焼き付けられています。

帰結は重い。鍵を失えば資産は永久に動かせず（/blockchain/signatures-wallets-keys/ で述べた通り、復旧窓口は存在しません）、新しい署名アルゴリズムに乗り換える術もなく、ガス用のネイティブ通貨を必ず自分で用意せねばなりません。**アカウント抽象化（Account Abstraction, AA）**は、この「アカウントが何を認証とみなし、誰がガスを払うか」をプロトコルから引き剝がし、プログラム可能なコントラクト側へ移す取り組みです。

ERC-4337：コンセンサスを変えずに実現する

アカウント抽象化の理想は、EOA を廃してすべてのアカウントをコントラクトにすることですが、それにはプロトコル本体（コンセンサス層）の改修が要り、ハードフォークの合意形成は重い。ERC-4337 は、コンセンサスに一切手を入れず、アプリケーション層だけでアカウント抽象化を実現した設計です。鍵となるのは、通常のトランザクションを模した別レイヤの取引オブジェクトを新設し、それを既存のトランザクションで包んでチェーンへ届ける発想です。

登場する構成要素は次の通りです。

流れはこうです。ユーザーは秘密鍵でトランザクションを直接発行する代わりに、UserOperation に「呼び出したい処理（calldata）」と「認証情報（signature）」を詰めて署名し、専用メモリプールへ投げます。Bundler（自らガス代を立て替えられる EOA を持つ運用者）がプールから複数の UserOperation を拾い、EntryPoint コントラクトの handleOps を呼ぶ1本の通常トランザクションに束ねて送信します。EntryPoint は束の各要素について、まず各 Account の検証を回し、通過したものだけ実行します。ここで Bundler は /blockchain/layer2-rollups/ の順序付けと同様に取引を集約する役ですが、あくまで既存プロトコルの上に追加のインフラ層として乗る点が違います。

UserOperation（主要フィールドの概念図）
  sender               # 操作を実行するアカウント（コントラクト）のアドレス
  nonce                # リプレイ防止の一意カウンタ（アカウント単位）
  callData             # sender 上で実行したい処理の呼び出しデータ
  signature            # 検証関数が解釈する任意形式の認証情報
  maxFeePerGas 等      # ガス上限・手数料の指定
  paymasterAndData     # ガスを肩代わりする Paymaster 指定（無ければ自己負担）
  factory / factoryData # 未デプロイ時にアカウントを生成する情報（任意）

検証フェーズ：署名方式を柔軟にする核心

アカウント抽象化の主役は、各 Account コントラクトが実装する検証関数 validateUserOp です。EntryPoint は実行に先立ちこの関数を呼び、アカウントに「この UserOperation を本当に承認するか」を問います。返り値が承認（かつ手数料の前払いが可能）なら実行へ進み、そうでなければその操作は束から除外されます。

ここが従来 EOA との決定的な差です。EOA では「secp256k1 の ECDSA 署名が公開鍵に一致するか」という判定がプロトコルに固定されていました。ERC-4337 ではこの判定がコントラクトのコードそのものなので、アカウントごとに自由に定義できます。

nonce によるリプレイ防止も検証段で担われます。/blockchain/utxo-vs-account-model/ で触れた通り、アカウントモデルでは同じ取引の使い回し（リプレイ）を防ぐために単調増加のカウンタが要ります。ERC-4337 でも UserOperation ごとに nonce を持ち、EntryPoint が消費済みか検査するため、同一操作を二度実行させられません。

Paymaster：ガス代行の仕組み

Paymaster は、ユーザーの代わりにガス手数料を負担できるコントラクトです。従来、取引を出すには必ずネイティブ通貨（ETH 等）を保有せねばならず、新規ユーザーの参入障壁でした。Paymaster を使えば、この前提を崩せます。

仕組みは、Paymaster が EntryPoint に**あらかじめデポジット（担保）**を積んでおき、UserOperation の paymasterAndData で指定されると、その操作のガスを Paymaster のデポジットから支払う、というものです。検証フェーズでは EntryPoint が Paymaster にも「この操作の肩代わりを引き受けるか」を確認し、承認されれば実行後に実費がデポジットから引かれます。

ソーシャルリカバリと単一障害点の緩和

ERC-4337 が実務にもたらす最大の価値の一つがソーシャルリカバリです。従来のシードフレーズ方式は、/blockchain/signatures-wallets-keys/ で述べた通り、ニーモニックが全鍵の親であり唯一にして最大の単一障害点でした。漏洩すれば全資産を奪われ、失えば永久に取り戻せません。

アカウントがコントラクトなら、この所有権のモデル自体を作り替えられます。典型は、日常の署名に使う所有者鍵とは別に、信頼する複数のガーディアン（家族・別デバイス・友人のアドレス）をあらかじめ登録しておく設計です。所有者鍵を紛失したら、ガーディアンの過半数が合意して所有者鍵を新しい鍵へ差し替えるトランザクションを承認します。資産そのものはアカウント（コントラクト）に留まったまま、それを操作する「鍵」だけを付け替えるわけです。

安全装置として、鍵の差し替えにはタイムロック（例：申請から数日後に発効）を組み合わせるのが定石です。万一ガーディアンが結託または乗っ取られても、正当な所有者は発効前に異議を唱えて差し替えを取り消せます。これは「即時性」と「取り消し可能性」を天秤にかける設計判断で、コントラクトだからこそ表現できます。

まとめ

• EOA は秘密鍵1本が唯一の権限で、ECDSA 署名・ネイティブ通貨でのガス支払いがプロトコルに固定される。この硬直性が鍵紛失＝資産喪失などの弱点を生む。
• アカウント抽象化は認証とガス支払いのロジックをプロトコルからコントラクトへ移す。ERC-4337 はコンセンサス層を無改修のまま、アプリ層だけでこれを実現した。
• UserOperation を専用メモリプールに集め、Bundler が束ねて EntryPoint に投入し、EntryPoint が全件検証→実行の2相で処理する。検証と実行の分離は Bundler の手数料回収を守るため。
• validateUserOp を差し替えることで、マルチシグ・パスキー・セッション鍵など任意の署名方式を実装できる。検証段は Bundler の DoS 耐性のため共有状態依存が制限される。
• Paymaster はデポジットからガスを肩代わりし、ETH 非保有ユーザーやトークン払いを可能にする。ソーシャルリカバリはガーディアン合意で操作鍵を付け替え、シードフレーズという単一障害点を緩和する。