Account Abstraction（AA）メモ：ERC‑4337 と EIP‑7702

この補足は「AAって何？」「4337と7702はどう違う？」を、初学者向けに最小限で整理する。

1. AAでやりたいこと（例）

• 複数操作をまとめて実行（batch）
• ガス代を別の主体が肩代わり（スポンサー支払い）
• セッションキーや権限の制限（期間限定・機能限定の操作）

2. アプローチA：ERC‑4337（コンセンサス変更なし）

ポイント：チェーンのコンセンサス変更なしで、コントラクト構成だけでAAを実現する。

よく出てくる登場人物：

• UserOperation：ユーザーが署名する「実行依頼」データ
• Bundler：UserOperationを集めてTxにし、EntryPointへ送る中継者
• EntryPoint：UserOperationの検証と実行を行うコントラクト
• （任意）Paymaster：ガス代スポンサー等の仕組みを提供するコントラクト

ざっくりフロー（概念）： 1) ユーザーがUserOperationに署名
2) BundlerがまとめてEntryPointへ送信
3) EntryPointがスマートウォレット（アカウントコントラクト）を呼び出して実行

3. アプローチB：EIP‑7702（EOA委任）

ポイント：プロトコル側の変更により、EOAが「委譲先コード」を署名付きで指定し、EOAの code を delegation indicator に設定できる。結果として、EOAが“スマートウォレットっぽく”振る舞うための土台になり得る。

最低限の仕様要点（概念）：

• 新しい tx type（EIP‑2718 系）に authorization_list を持ち、要素は概ね [chain_id, address, nonce, y_parity, r, s] の形式
• クライアントは実行前に authorization_list を処理し、権限者（EOA）の code を delegation indicator 0xef0100 || address に設定する（address=0 でクリア）
• 「委譲先コードの実行」はトランザクション単位の一時処理ではなく、EOAの code 状態として残り得るため、解除/更新の運用が必要

初学者向けの直感としては：

• 「EOAは必ず code empty」と思い込まない
• EOAが“スマートウォレットっぽく”振る舞うための土台になり得る

4. 4337と7702の関係（整理）

• 競合というより“レイヤーが違う” と捉えると混乱しにくい。
  • ERC‑4337：コントラクトだけでAAを実現（ネットワーク変更不要）
  • EIP‑7702：EOAの実行モデルを拡張（ネットワーク側のアップグレードが必要）
• 組み合わせる設計も考えられる（例：4337のアカウント実装を、7702の委任先コードとして使う等）。

注：どのチェーンでどの機能が有効かは時期により変わる。実際の利用可否は各チェーンの公式アナウンス・EIPを確認すること。