AccountAbstractionのガス構造の全体像

---

1. はじめに

目的

AccountAbstraction(AA)におけるガス代の構造を理解する
AAでは、トランザクションの代わりに UserOperation という構造体を用いて処理が行われます。この UserOperation には、ガス代に関する複数のパラメータが含まれており、それぞれが異なるフェーズのガス消費に対応しています。

↓ 以下5つのフィールドが今回の解説対象

uint256 preVerificationGas;
uint256 verificationGasLimit;
uint256 callGasLimit;
uint256 maxFeePerGas;
uint256 maxPriorityFeePerGas;

この記事ではpreVerificationGas・verificationGasLimit・callGasLimitの3つのフェーズに分かれるガス消費の流れと、それに伴うmaxFeePerGas,maxPriorityFeePerGasの役割についても体系的に整理します。

対象読者

• ガス代の設定を理解したい人
• AA に関する専門用語（UserOperation, Bundler, EntryPoint, Paymaster など）を知っていて、各要素の全体図を把握している人

---

2. EVMにおける一般的なガス代の仕組み

Ethereumでは、各トランザクションを処理するために「ガス」という単位で計算資源の使用量を測り、そのコストをETHで支払う必要があります。この記事では、EIP-1559以降のガス料金の計算方法を中心に、バリデータの選別基準やcalldataの重さなども解説します。

2.1 ガス代の計算式（EIP-1559）

EIP-1559に基づくトランザクションでは、支払うガス代は以下の式で決まります。

gas fee = gasUsed × (baseFee + priorityFee)

• gasUsed: 実際に消費されたガスの量（スマートコントラクトのコードの処理内容で変動）
• baseFee: ネットワークの混雑状況によりブロックごとに自動調整される固定値（burnされる）
• priorityFee（tip）: バリデータに支払う報酬。多めに設定すると優先されやすい

この仕組みは、maxFeePerGas と maxPriorityFeePerGas という2つの値をユーザーが指定することで実現されます。

effectiveGasPrice = min(maxFeePerGas, baseFee + maxPriorityFeePerGas)

この effectiveGasPrice が gasUsed に掛け算されて、最終的な支払いが確定します。

2.2 各パラメータの意味

パラメータ名	説明
gasUsed	EVMが実行時に実際にスマートコントラクトが消費したガス量
baseFee	ブロックごとに自動調整される固定料金（全額burn）
maxPriorityFeePerGas	バリデータに支払うtipの上限
maxFeePerGas	baseFee + tip を合わせたガス単価の最大値（ユーザーが払ってもいい上限）

2.3 バリデータがトランザクションを選ぶ基準

バリデータは以下のような基準で、どのトランザクションをブロックに含めるかを判断します：

1. maxFeePerGas ≥ baseFee：これを満たしていないTxは拒否
2. priorityFee が高いTxを優先的に処理
3. ブロック全体の gasLimit に収まる範囲内で選別
4. calldataのサイズが小さいほどガス効率が良くなるため好まれる傾向もある

2.4 誰がガスを払うのか？

通常のトランザクションでは、EOA（Externally Owned Account） が直接送信者となり、以下のように処理されます。

• msg.sender = EOA
• msg.sender の残高からガス代が差し引かれる
• トランザクションが revert（失敗） しても消費した gasUsed 分は戻らない
• 使用しなかった gasLimit - gasUsed の差分は返金される

---

3. Account Abstraction（AA）のガス代構造

3.1 UserOperation の登場とガス設計

• EOAではなく SmartAccount（コントラクト）で tx を処理
• UserOperation の構造体が EntryPoint に渡される
• Bundler がオフチェーンで中継・見積もりを担当
• Paymasterを設定すれば利用者が直接ガス代を払わなくて済む

3.2 ガスの3フェーズ構成

totalGas = preVerificationGas
         + verificationGasUsed (最大 verificationGasLimit)
         + callGasUsed         (最大 callGasLimit)

項目	説明
preVerificationGas	calldata長、署名サイズ、UserOpの配列処理などの静的なコスト
verificationGasLimit	validateUserOp() で署名検証・nonceチェックなどを行うロジック
callGasLimit	実際の処理本体（例：トークン送信）に必要なガス

3.3 SmartAccountのメソッド例

modifier onlyEntryPoint() {
    require(msg.sender == entryPoint, "not EntryPoint");
    _;
}

function validateUserOp(...) external view onlyEntryPoint returns (uint256) {
    // 署名検証やPaymaster検証などを実行
}

function execute(...) external onlyEntryPoint {
    // 実行本体を forward
}

function _isValidSig(...) internal view returns (bool) {
    // 署名とownerアドレスの一致確認
}

function recover(...) internal pure returns (address) {
    // ecrecoverでアドレスを復元
}

---

4. まとめ：EVMとの違い

観点	EOA (従来)	AA (4337)
署名の検証	EVMレベル	validateUserOp()
ガス代の負担	EOAが必ず負担	Paymasterによる委任可能
柔軟性	固定的	任意ロジック・バッチ処理可能
カスタムトランザクション	不可能	SmartAccountの execute 次第

---

5. 補足・参考資料

• EIP‑1559: Fee Market Change for ETH 1.0 Chain
  Ethereumガス料金モデル（baseFee／tip／burn）を定義した公式EIP。

• EIP‑4337: Account Abstraction via Entry Point Contract
  UserOperation・Entrypointを主体としたAA設計を定義するERC。

• AA docs – ERC‑4337
  alt‑mempool・EntryPointアーキテクチャ・ガス設計まで公式に網羅されたポータル。