L2のガス代はどう決まる？execution・L1 data・blob・operator feeを分解

L2のwalletに表示される「gas代」は一つの数字でも、内部では複数の費目が動いています。EVMを実行する費用、transaction dataをL1へ届ける費用、chain固有のoperator feeは、同じ混雑指標でも同じ比率では増減しません。

そのため、gasUsed × effectiveGasPriceだけで全L2の総額を説明することはできません。Baseではこの積へreceiptのl1Feeとoperator feeを加えます。Arbitrum OneではL1 poster costがL2 gasへ換算され、receiptのgasUsedに含まれます。

L2手数料は、chainとversionを固定し、execution・data availability・operatorを別々に再計算してから合計します。

この記事では2026年9月1日にBase MainnetとArbitrum Oneの公開RPCをread-onlyで確認しました。同じ数分内の4件の完了済みtransactionと、chainごとに固定した1,024 blockを使います。wallet接続、署名、transaction送信、個人balance、API key、実資産操作は使っていません。これは最安chainのランキングではなく、明細を追う方法の比較です。

一つのL2手数料を三つの層へ分ける

費目	何に対する支払いか	値を確認する場所
execution	EVM opcode、memory、storage、callなどL2上の実行	receiptのgasUsed、effectiveGasPrice、chain固有の分解field
L1 data / poster	transactionを圧縮し、batchとしてparent chainへ投稿する費用の回収	Baseのl1Fee、ArbitrumのgasUsedForL1、各chainのoracle / precompile
operator	chain operatorが設定する追加費用	OP StackのoperatorFeeScalar、operatorFeeConstantなど
priority / ordering	inclusion順序へ関係するtipやchain固有の優先機構	transaction、receipt、現在のsequencer仕様

executionとdata availabilityは独立した変数です。L2が空いていてもEthereum側のdata priceが高い場合があり、逆にL2 execution priceが上がってもblob側の価格が下がる場合があります。operator feeもchainごとの設定で、OP Stackだから必ず同じ値ではありません。

Baseはexecution・l1Fee・operatorを足す

OP Stackの基本形は次です。effectiveGasPriceにはblock base feeと実際に支払ったpriority feeが反映されます。

executionFee = gasUsed × effectiveGasPrice
totalFee = executionFee + l1Fee + operatorFee

Jovian後のoperator feeは、対象chainの設定値を使って次のように計算します。

operatorFee = gasUsed × operatorFeeScalar × 100 + operatorFeeConstant

今回のBase block 50,713,856ではscalarとconstantがどちらも0だったため、2件ともoperator feeは0です。「OP Stackにoperator feeの仕組みがある」と「このBase transactionで追加額が発生した」は別の主張です。

同じblockの2件をreceiptから再計算する

Base Mainnet	calldata	gas used	execution	L1 data	operator	合計
native transfer 0xbdc0…de61	0 bytes	21,000	126,000,000,000 wei	487,492,768 wei	0 wei	126,487,492,768 wei
contract call 0x2460…bf05	1,348 bytes	755,382	4,683,368,400,000 wei	1,280,823,388 wei	0 wei	4,684,649,223,388 wei

1件目は21,000 × 6,000,000 + 487,492,768、2件目は755,382 × 6,200,000 + 1,280,823,388でreceiptの総額を再構成できます。結果はそれぞれ0.000000126487492768 ETHと0.000004684649223388 ETHです。

この2件ではexecutionが大部分ですが、別時刻・別data・別scalarでも同じ比率になるとは限りません。また、l1GasUsed × l1GasPriceをそのままl1Feeとみなすこともできません。Fjordの圧縮推定、L1 base feeとblob base fee、それぞれのscalarを含むchain側の計算結果をreceiptのl1Feeで確認します。

BaseのblobGasUsedは「利用者がL1 blob gasを直接使った量」ではない

今回のreceiptにはblobGasUsedがあり、0 byteの例で14,800、1,348 bytesの例で38,776でした。しかしJovian仕様では、このfieldはtransactionのDA footprintを表すために再利用されています。block header側でもDA footprintを制限とbase fee更新へ使います。

したがって、Base receiptのblobGasUsedをEthereum L1のtype 3 transactionにあるblob gasと同一視しません。利用者のL2 transactionが自分専用のblobをL1へ直接投稿した証拠でもありません。batcherが複数transactionをまとめて投稿する境界や、Ethereum側のblob供給変更はPeerDAS・blob throughputの記事で分けて確認できます。

Arbitrum Oneはposter costをL2 gasへ換算する

Arbitrum Nitroでは、L1へdataを投稿する見積費用をL2 gas単位のbufferへ変換します。完了後のreceiptでは、今回確認したnodeがgasUsedForL1を返しました。

totalFee = gasUsed × effectiveGasPrice
posterFee = gasUsedForL1 × effectiveGasPrice
executionFee = (gasUsed - gasUsedForL1) × effectiveGasPrice

Arbitrum One	calldata	gas used	gas used for L1	execution	poster	合計
short call 0xb7bb…de5	4 bytes	1,470,652	85	29,411,340,000,000 wei	1,700,000,000 wei	29,413,040,000,000 wei
larger call 0x7951…636e	814 bytes	159,833	280	3,191,060,000,000 wei	5,600,000,000 wei	3,196,660,000,000 wei

どちらもblock 500,440,832、effectiveGasPrice = 20,000,000 weiです。poster部分を足し直すとreceipt totalと一致します。

ここで4 bytesのcallの方が814 bytesのcallより高額です。calldataが短くても、呼び出したcontractの処理が重ければexecution gasは増えます。反対に、dataが長くてもexecution pathが軽いことがあります。この2件を「1 byteあたりのchain価格」や「Arbitrumの平均」として比較してはいけません。

small・largeとlow・highを同じ表で見る

一時的な値を普遍化しないため、low / highは固定した1,024 block窓の中だけで定義しました。

chain	観測窓	base feeの最小	base feeの最大
Base	block 50,712,977〜50,714,000	5,000,000 wei	5,030,833 wei
Arbitrum One	block 500,440,468〜500,441,491	20,000,000 wei	21,248,000 wei

これは長期の最小・最大、平均、通常値、将来の上限ではありません。数分の固定窓における観測値です。

Base：同じexecution gasでdata sizeだけ変える

BaseのGasPriceOracle.getL1FeeUpperBoundへ、200 bytesと2,200 bytesのunsigned serialized transaction sizeを渡しました。calldataだけの長さではなく、transaction envelopeを含む概算sizeです。executionは比較のため50,000 gasに固定しています。

L2観測条件	serialized size	execution	L1 fee upper bound	合計upper bound
窓内base fee最小	200 bytes	250,000,000,000 wei	1,363,923,801 wei	251,363,923,801 wei
窓内base fee最小	2,200 bytes	250,000,000,000 wei	13,057,659,001 wei	263,057,659,001 wei
窓内base fee最大	200 bytes	251,541,650,000 wei	889,502,027 wei	252,431,152,027 wei
窓内base fee最大	2,200 bytes	251,541,650,000 wei	8,515,735,364 wei	260,057,385,364 wei

窓内でL2 base feeが高いblockの方が、L1 fee upper boundは低くなりました。矛盾ではありません。L2 execution demandとEthereum由来のdata priceは別の軸だからです。「混雑が高い」という一語だけで総額の全componentが同方向に動くとは限りません。

Arbitrum：NodeInterfaceのcomponentを分ける

4 bytesと2,048 bytesの決定的なdataをEOA宛てcallとしてNodeInterface.gasEstimateComponentsへ渡しました。表のpriceはheader値ではなく、precompileが計算用に返したbaseFeeです。

L2観測条件	input	execution gas	L1 buffer gas	execution	poster	total estimate
窓内header base fee最小	4 bytes	21,230	117	424,812,300,000 wei	2,341,170,000 wei	427,153,470,000 wei
窓内header base fee最小	2,048 bytes	54,535	1,767	1,091,245,350,000 wei	35,357,670,000 wei	1,126,603,020,000 wei
窓内header base fee最大	4 bytes	21,230	159	424,684,920,000 wei	3,180,636,000 wei	427,865,556,000 wei
窓内header base fee最大	2,048 bytes	54,538	2,391	1,090,978,152,000 wei	47,829,564,000 wei	1,138,807,716,000 wei

large dataではposter bufferが増えました。ただし圧縮率はbyte数だけで決まらず、同じ長さでもdata patternで変わります。また、このpre-inclusion estimateを後のreceiptへコピーせず、採用後は実際のgasUsedとgasUsedForL1へ戻ります。

wallet estimate・RPC estimate・receiptがずれる理由

eth_estimateGasは「このcallに必要なgas unit」の見積もりであり、全chain共通の最終fee見積もりではありません。Baseではexecution estimateとL1 fee queryを分けます。Arbitrumでは標準gas estimateにposter bufferが含まれるため、gasLimit - execution gasを一律に「余った無駄gas」と判断できません。

wallet表示はさらに、gas limitの安全margin、max fee、priority fee、独自RPC、fiat換算、sponsorship、UIの丸めを加える場合があります。表示値が同じでも、どのmethodとblock tagを使ったかが分からなければ再計算できません。

estimateからreceiptまでに変わる主な要素は次です。

• call直前のcontract stateと実際のexecution path
• inclusion blockのbase feeと実際のpriority fee
• L1 base fee・blob base fee・chain側のdata price estimate
• compression estimate、serialized transaction size、batch条件
• operator scalar / constant、minimum fee、network upgrade
• transactionのrevert、refund、replacement、sponsorship条件

receiptが得られたら、gas limitやwalletの最大表示ではなく、receipt componentから合計を作り直します。block numberだけでなくhashも固定する理由はRPC snapshotの作り方で整理しています。

blob feeが下がっても利用者feeが同率で下がるとは限らない

EIP-4844のblob gasはEthereum execution gasとは別のfee marketです。ただしL2利用者が払うdata componentは、blob base feeだけでなく、圧縮推定、scalar、minimum transaction size、calldata floor、operatorの回収設計を通ります。

したがって、Ethereumのblob base feeが50%下がったとしても、L2総額が50%下がるとは限りません。executionが大部分なら総額への影響は小さくなります。chainがcalldataを使う場合、Alt-DAを使う場合、scalarを変更した場合も別です。

sponsored・paymaster・alternative fee tokenはpayerと単位を分ける

「利用者の画面で0円」と「network feeが0」は同じではありません。

• ERC-4337 paymasterは利用者の代わりにfeeを支払えますが、bundler transactionのexecutionとdata costは残ります
• token paymasterがERC-20で後精算する場合、native feeとtoken請求、exchange rate、上限、refundを別に記録します
• OP StackのCustom Gas Token chainではnative fee currency自体がETH以外になり得ます。token symbolだけでなくaddress、decimals、chain IDを固定します
• dappのsponsorshipは期間、対象operation、quota、失敗時負担が製品条件です。protocol formulaとは分けます

paymasterを含むUserOperationの検証境界はAccount Abstractionのstage分解も参照してください。sponsor表示がある場合でも、この記事の比較表や測定結果へ広告条件を混ぜません。今回のデータにsponsor、affiliate、token換算はありません。

bridgeでは一つの操作に複数transactionがある

bridge画面に出る「手数料」は、source transaction、message relay、destination execution、liquidity provider feeなどをまとめて表示する場合があります。この記事のreceipt計算は一つのL2 transactionだけです。

送金全体を確認する場合は、source・message・destinationを結ぶ手順とL2 withdrawalのprove・finalize・executeへ分けます。source側のL2 feeが安くても、別stageのL1 transaction、bridge service fee、token price impactまで安いとは限りません。

sequencer停止やRPC lagが疑われるときも、gas priceだけでnetwork状態を決めません。L2 sequencer feedの停止境界のように、uptime、grace period、block time、複数RPCを照合します。

再計算するときに保存するchecklist

1. chain名だけでなくchain IDとmainnet / testnetを保存する
2. network upgrade、fee formula version、確認日を保存する
3. tx hash、type、block number、block hash、timestampを一組にする
4. input byte数と内容のcompressibilityを分ける
5. receiptのgasUsed、effectiveGasPrice、chain固有fieldをraw quantityで保存する
6. Baseならl1Feeとoperator parameter、ArbitrumならgasUsedForL1とNodeInterface methodを確認する
7. estimateはmethod、request、block tag、安全marginを保存する
8. fee token、address、decimals、payer、paymaster、sponsor条件を保存する
9. bridgeやbatchなら別transactionのfeeを同じreceiptへ足さない
10. 単発例を平均、ランキング、将来保証へ広げない

今回の4 receipt、固定block hash、raw RPC quantity、8 scenario、再計算結果は検証用JSONで確認できます。全てweiを正本とし、ETH価格や法定通貨換算は使っていません。

まとめ

Baseのようにexecution + l1Fee + operatorを足すchainと、Arbitrumのようにposter costをL2 gasへ換算してgasUsedへ含めるchainでは、同じfield名だけを横並びにできません。

まずchainとversionを固定し、次にexecution、data availability、operator、payer、denominationを分けます。estimateは上限やbufferを含む予測、receiptは採用後の観測です。最後に各componentを同じwei単位へそろえて合計すると、「L2なら常に安い」「blobが下がれば総額も同率で下がる」「gas price×gas usedだけで十分」という一般化を避けられます。

この記事にスポンサー掲載はありません。将来L2、RPC、wallet、fee monitoring関連の広告を掲載する場合も、広告枠とformula、公開data、比較結果を明確に分離します。