FusakaとPeerDASとは？blob fee・L2手数料を実測blockで読む

Fusakaは、Ethereumがblob dataをより多く受け入れながら、各nodeのdata負担を分担するためのupgradeです。中心となるPeerDASはblobをdata columnsへ分け、nodeが一部をcustody・samplingしてdata availabilityを確かめます。

ただし、capacityが増えること、L2 batcherがEthereumへ払うblob feeが変わること、利用者がL2画面で払うtotal feeは別の段階です。PeerDASが動いたからL2手数料が必ず下がる、とは言えません。

この記事では、Fusakaのactivationを確定情報から整理した後、Ethereum mainnetのblock 25,869,397を固定します。このblockは21 blobsを含み、そのうち5 blobsを投稿したOP Mainnet batch transactionについて、execution gasとblob gasを別々に再計算します。

Fusakaは2025年12月3日にmainnetへ入った

Ethereum Foundationのmainnet announcementによると、Fusakaのactivationは次の値です。

field	mainnet value
date / time	2025-12-03 21:49:11 UTC
slot	13,164,544
epoch	411,392
status	activated

Fusakaのactivation時点ではblob target / maxは6 / 9のままでした。後続のBlob Parameter Only fork、BPO1とBPO2がcapacity parameterを段階的に上げています。

step	activation	target blobs / block	max blobs / block
Fusaka	2025-12-03	6	9
BPO1	2025-12-09	10	15
BPO2	2026-01-07	14	21

2026-08-31にpublic RPCのeth_configで確認したcurrent blob scheduleも、target 14、max 21、base fee update fraction 11,684,671でした。これは執筆時点のsnapshotです。後のBPOやnetwork upgradeで変わり得るため、「Fusakaの永久固定値」ではありません。

blobはEVMの通常data storageではない

EIP-4844のblob-carrying transactionはtype 0x03です。1 blobは4,096 field elements、131,072 bytesで、blob gasも1 blobあたり131,072です。

ここでexecution側とconsensus側を分けます。

• execution blockとtransaction: KZG commitmentから作ったblobVersionedHashesを持つ
• consensus data: blob bytesをsidecarとして運び、Fusaka以後はdata columnsへ分割して共有する
• EVM: versioned hashは扱えるが、blob bytesの中身を直接読むことはできない

つまりblobは、contractが後から任意に読む永久storageではありません。L2はbatch dataを安価なdata availability領域へ置き、derivation nodeが一定期間内に取得してL2 chainを再構成します。

versioned hashとblob bytesを同じ場所だと思わない

versioned hashは32 bytesの参照値です。先頭1 byteでversionを示し、現在のKZG commitmentでは残りをcommitmentのSHA-256から作ります。

versioned hash = 0x01 || sha256(kzg_commitment)[1:]

execution RPCでtype 3 transactionを取得すると、このhash一覧は後からも確認できます。一方、raw blob bytesを返すBeacon APIにはretentionの境界があります。hashが残っていても、任意のpublic providerが過去blobを永久に返すわけではありません。

PeerDASはblobを128 data columnsへ分ける

EIP-7594とFulu consensus specsでは、blob dataをerasure codingし、128 data columnsとして扱います。nodeはcustody groupに応じたcolumnsを保持し、samplingによって他のcolumnsがnetwork上で利用可能かを確認します。

重要なのは「全ordinary nodeが、全blob bytesを必ず受信・保存する」という前提を外した点です。全dataを各nodeへ複製する場合より、1 nodeあたりのbandwidthとstorage負担を抑えながらnetwork全体のblob capacityを広げられます。

ただし、「各nodeは必ずちょうど8分の1だけ持つ」と一つの割合へ固定する説明も不正確です。custody requirement、node role、sampling、reconstructionの経路を分ける必要があります。full blobを返したpublic Beacon APIが、すべてのPeerDAS nodeでfull blobを保存している証拠にもなりません。providerがsupernodeとして動くか、columnsから再構成して返せるためです。

21 blobsを含むmainnet blockを固定する

実測例は、2026-08-30 16:51:11 UTCのEthereum mainnet blockです。public execution RPCを2系統、Beacon APIを2系統で照合しました。

field	pinned evidence
execution block	25,869,397 / 0x18abc55
block hash	0x3f3d6d7a5aa24c81e066e2ff674e5df1b21ec18888fb66f61786e0dbb69c22ba
beacon slot / root	15,107,054 / 0x1adb135d…36ee4e
finalized / optimistic	true / false
blobGasUsed	2,752,512 = 21 × 131,072
blob transactions	7 tx、blob数は1 + 5 + 3 + 3 + 3 + 3 + 3
current max at check	21 blobs / block

このblockを選んだ理由は、authoring時点のmaxと同じ21 blobsを含み、blob countを整数で検算しやすいからです。満杯blockを一つ示しただけで、平均利用率、混雑度、fee trend、PeerDASの性能を証明するものではありません。

5 blobsのOP Mainnet batch transaction

7件のblob transactionから、transaction index 46を選びました。

field	value
tx hash	0x94dff4d56139f0286804297841f8bdc09154a1834464baeff5480b163b29c1a3
type	0x3
from	0x6887246668a3b87f54deb3b94ba47a6f63f32985
to	0xff00000000000000000000000000000000000010
blob count	5
maxFeePerBlobGas	1,000,000,000 wei / blob gas
receipt status	1

Superchain Registryの固定commitでは、同じfromがOP Mainnet batcher、同じtoがbatch inboxです。addressだけを見て推測せず、chain ID 10、eth-da設定と一緒に照合しています。

transactionの5 versioned hashesは、Beacon sidecars indices 1〜5のKZG commitmentsから再計算した値とすべて一致しました。各blobのdecoded lengthも131,072 bytesです。raw blob bytesは容量が大きくretention-limitedなため、公開データには含めず、commitment、hash、lengthだけを確認用JSONへ固定しました。

execution gasとblob gasは別のfee market

同じtype 3 transactionでも、receiptには通常のexecution gasとblob gasが別々にあります。

component	quantity	price	fee
execution	21,000 gas	1,114,005,115 wei / gas	23,394,107,415,000 wei
blob	655,360 blob gas	6,996,870 wei / blob gas	4,585,468,723,200 wei
total	—	—	27,979,576,138,200 wei

計算は次の2本です。

execution fee
= 21,000 × 1,114,005,115
= 23,394,107,415,000 wei

blob fee
= 655,360 × 6,996,870
= 4,585,468,723,200 wei

合計は0.0000279795761382 ETHです。これは5 blobsを含む一つのL1 batch transactionのexecution + blob feeで、L2利用者一人のfeeではありません。

maxFeePerBlobGasの1,000,000,000 weiは上限、receiptのblobGasPrice 6,996,870 weiは実際に掛けた価格です。capをそのまま支払額として計算しないでください。blockのbaseFeePerGas 114,005,115 weiとreceiptのeffectiveGasPrice 1,114,005,115 weiも役割が違います。

EIP-7918は単純な固定floorではない

Fusakaには、blob base feeが極端に低いときの挙動を調整するEIP-7918も含まれます。BLOB_BASE_COSTとexecution base feeの積を、1 blob分のgasとblob base feeの積と比較し、条件を満たすとexcess_blob_gasの更新へreserve priceを反映します。

「blob feeを常に固定額以上へclampする」だけの仕組みではありません。execution側のcostと比べながら次blockのblob fee状態を更新するため、transaction receiptの実際のblobGasPriceを確認するのが安全です。

L2利用者feeが必ず下がるわけではない

OP Stackの公式fee資料では、Isthmus以後の利用者total feeを、概ね次のcomponentへ分けています。

L2 user total
= L2 execution fee
+ L1 data fee
+ operator fee

L1 data feeは、利用者transactionの圧縮後size、L1 base feeまたはblob base fee、rollupが設定するscalarなどから計算されます。batcherがまとめたL1 transactionのreceiptを、利用者一人へそのまま転記するわけではありません。

PeerDASが直接変えるのは、Ethereum networkが受け入れられるblob data capacityと、node間でavailabilityを確かめる方法です。そこから利用者feeへ届くまでには、少なくとも次の条件があります。

• L2が増えたcapacityを実際に利用するか
• batch compressionで一人あたり何bytesになるか
• blob demandとblob base feeがどう動くか
• L2 execution gasがどれくらい必要か
• scalar、overhead、operator feeをrollupがどう設定するか
• capacity増加分を需要増加がどれだけ使うか

そのため、blob posting costが下がってもoperator componentが上がればtotalは下がらないことがあります。逆にblob feeが一時的に上がっても、compression改善やscalar変更で利用者feeが抑えられる場合があります。protocol capacity、batcher cost、user feeを別々に観測してください。

public RPCで同じblockを再確認する

次の検証scriptはdefaultでnetworkへ接続せず、保存済みJSONのhex / decimal、blob count、fee、commitment hashを再計算します。

node scripts/fetch-fusaka-blob-evidence.mjs

出力する主な値は、blockの21 blobs、selected transactionの5 blobs、execution fee、blob fee、total fee、検証した5 commitmentsです。

public endpointから再取得する場合だけ--fetchを付けます。wallet、browser extension、API key、署名、transaction送信は不要です。

node scripts/fetch-fusaka-blob-evidence.mjs --fetch

scriptは次をread-onlyで照合します。

1. 2つのexecution RPCでblock hash、blobGasUsed、receiptを比較する
2. type 3 transactionのsender、batch inbox、5 versioned hashesを確認する
3. 2つのBeacon APIでslotとcanonical rootを比較する
4. sidecarsがまだ取得できる間は、indices 1〜5のcommitment、versioned hash、blob lengthを確認する
5. 現在のeth_configをauthoring snapshotと分けて表示する

public RPCを使った調査で値が動くときは、latestを何度も読む前にraw RPCをblockへ固定する手順を参照してください。transactionのpending、included、confirmedを区別する基礎はtransaction statusの確認順、L2 depositが見えない場合のsource transaction、message、destinationの切り分けはbridge未着金の確認手順で扱っています。canonical L2→L1のproof・challenge・L1 executionを追う場合はL2出金のstage確認手順へ進みます。bridgeのdestination実行後に取引所残高へ反映されない場合は、さらにchain状態と取引所内statusを分ける手順へ進みます。

sidecarは後から取得できなくなる

Fulu P2P specのminimum request windowは4,096 epochsです。1 epochを約6.4分として換算すると約18.2日ですが、これはarchive提供を永久に義務付ける期間ではありません。

後日--fetchを実行してsidecar endpointが404 / 410を返した場合、scriptはretention-limitedな確認が終了したと表示します。execution blockのversioned hashesとreceiptは照合できるため、「sidecarを取得できない＝元transactionにblobがなかった」とは判断しません。長期保存が必要なら、執筆時のcommitmentsか、信頼条件を明示したarchive sourceを別に残します。

mainnet・current snapshot・futureを分ける

仕様変更の記事では、proposal名よりstatusとactivation条件が重要です。

class	この記事で確定扱いするもの	読み方
mainnet activated	Fusaka、PeerDAS、EIP-7918、BPO1、BPO2	activation date / slot / epochを一次情報へ結ぶ
authoring-time current	eth_configのtarget 14 / max 21、next:null	2026-08-31のprovider snapshotとして扱う
future / unstable	後続fork directory、draft EIP、未activation parameter	mainnet behaviorへ混ぜず、再確認日を付ける

eth_config.next === nullは、そのRPCが現在「次の設定を返していない」という意味です。Ethereumに次のupgradeが存在しない、今後parameterが変わらない、という保証ではありません。

またEIP pageのstatusがFinalでも、どのnetworkでいつactivationしたかは別の確認です。EIP本文、fork specification、mainnet announcement、current RPCの順に対応させると、draftと稼働中仕様を混ぜにくくなります。

Fusaka・blob・L2 fee確認チェックリスト

• mainnet activation date、slot、epochを一次情報で固定した
• Fusaka activationと後続BPOのparameter変更を分けた
• type 3 transactionのversioned hashesとblob bytesの保存場所を分けた
• 1 blobを131,072 bytes / blob gasとして整数検算した
• PeerDASのcustody、sampling、reconstructionを全nodeのfull copyと混同していない
• execution gasとblob gasをreceiptから別計算した
• maxFeePerBlobGasと実際のblobGasPriceを分けた
• batcher senderとbatch inboxを対象L2のofficial registryで照合した
• batch posting costを利用者一人のfeeとして転記していない
• compression、L2 execution、scalar、operator policy、demandを条件へ残した
• sidecar retention後に何が再現できないか明示した
• current config、future proposal、mainnet activated specを別の欄へ置いた

結論は、Fusaka / PeerDASはblob data capacityとnodeのdata availability検査を変えたが、L2利用者feeは別のcomponentを含むということです。block、transaction、receipt、Beacon data、L2 fee formulaを順番に固定すれば、「blobが増えた」「batcher costが変わった」「利用者feeが下がった」を別々に検証できます。

この記事にスポンサー、affiliate、wallet接続、bridge、署名要求、transaction送信、資産操作のCTAはありません。将来L2、RPC、node infrastructure、data availability、developer hostingの広告を置く場合も広告であることを明示し、公式仕様、mainnet evidence、fee計算、protocol評価から分離します。