Blobs

Blobs are the large binary data chunks rollups attach to Ethereum blocks since EIP-4844: up to six per block, roughly 128 KB each, priced on their own blob-fee market, and auto-deleted after about 18 days. They are the mechanism that lets L2s publish transaction batches to Ethereum without paying execution-gas prices — the engine behind the sub-cent rollup fees of the post-Dencun era. How it works A rollup combines thousands of L2 transactions into one compressed batch, then posts that batch as blob data and references it from an ordinary L1 transaction. The block header carries a KZG commitment to each blob, so anyone holding the header can later confirm that the blob content a rollup claims to have posted is the exact content that was committed on-chain. The lifecycle has three phases: Posting. The rollup separator (batcher) publishes blobs and pays the blob base fee; each block reserves a target of 3 blobs, up to a maximum of 6. Verification window. Ethereum consensus nodes store blob data for ~18 days — long enough for an optimistic rollup's fraud-proof window to close, or for ZK rollups to prove inclusion. Pruning. Nodes delete expired blobs so blob storage never balloons into permanent datacenter-grade history; explorers, archivers, and the rollups themselves keep long-term copies. Because blob data is never "executed" — no EVM bytecode runs on it — it competes in its own fee market instead of bidding against user transactions for block space. That separation is exactly what makes it cheap when rollup demand is low and gracefully prices up when demand spikes. Why it matters for decentralization Blob space is the price that keeps settlement honest. If posting batch data to Ethereum were expensive enough, every rollup would face an economic argument for a private data-availability committee — a handful of servers vouching for data instead of Ethereum itself. Cheap on-chain availability is what preserves the "verify, don't trust" property for anyone running a node or a light client. The same mechanism previews full full danksharding: more blobs per block plus data-availability sampling, so the base layer can scale data without raising node hardware requirements into the clouds. Fewer hardware requirements means more home validators, which is the infrastructure-pillar core of the Ethereum audit. See how the methodology weights infrastructure when auditing any chain. Example: blob math on a live rollup Consider Base in a busy week. The chain packs user transactions into batches and posts them as blobs at a blob-fee cost often under a dollar per blob. Divide that by the tens of thousands of transactions represented, and each transfer may owe only a fraction of a cent in L1 data cost. Before Dencun, the same batch posted as calldata would have owed L1 execution gas — an order of magnitude more — which is precisely why rollups either stayed expensive or outsourced data to committees. PropertyBlobsCalldata Capacity3 target / 6 max per blockCompetes with normal transactions Persistence~18 days, then prunedForever in chain history Fee marketSeparate blob base feeExecution base fee Typical per-byte costRoughly 10x cheaperExecution-driven Node storage impactBounded and prunedGrows forever Risks & limitations Fixed supply, spiky demand: with only 3-6 blobs per block, periods of sustained L2 activity overflow the lane and blob fees spike — exactly when small rollups can least afford to post. Pruned ≠ archived: after expiry, canonical history no longer contains blob contents; permanent retrieval depends on third parties, a trust assumption against the "everything on Ethereum" narrative. No execution, no smart contract access: blobs are data-only; applications that needed ETH across rollups still rely on bridges. Sequencer centralization remains: cheap data concentrates activity on dominant sequencers — sameness of blob economics does not decentralize the sequencer that orders your transaction. For spec-level clarity, each blob carries 4,096 field elements of 32 bytes each (~128 KB), and a block header commits to all included blobs with a KZG versioned hash persistent across gossip. Rollup batchers decide how many blobs a block of user transactions needs; the L1 enforces the target-of-3 / max-of-6 budget with a single blob_gas accounting field. The infrastructure around blobs is the part users rarely see but audits depend on: Sidecar propagation: blobs travel over libp2p gossip as attached sidecars, then are pruned locally after the data-availability horizon — the design reason validator disk requirements stayed flat after Dencun. Indexers and archivers: tools like Beaconcha.in or L2Beat dashboards re-serve blob data long after pruning; the canonical chain says they were available, not that it remembers them. Censorship and MEV surfaces: because blob inclusion affects batch fee health, a sequencer's batch cadence and a relay's blob-sidecar handling are measurable decentralization signals — the kind of signal the W3D methodology encodes into the infrastructure pillar. Track three numbers when researching any rollup's data story: how many blobs it posts per day, its average blob base-fee paid, and how its batch size compares to the target-3 limit. Cheap + regular posting is the honest-rollup signature; erratic giant batches under congestion tells you the chain is batching for subsidies, not for users. A two-minute check before trusting any rollup "posts to Ethereum": Open an L2 explorer or Blobscan, filter the chain, and count how many blobs the batch contract posted in the last 7 days. Note the average blob base fee those blobs paid — a steady low number means data posting is genuinely cheap, which is the whole point of the design. Check for gaps: long multi-minute windows with no blob posts under load are the signature of batching for batching's sake or queueing problems. Compare batch cadence across a quiet week and a busy week; honest rollups stay near their normal cadence, subsidized ones spike with marketing events. Blob fees vs regular gas The pricing is separate on purpose. Blob consumption is priced by an independent blob market (target now ~6 blobs per block), while execution gas keeps its own EIP-1559 curve. L2s therefore stress-test two cost surfaces: batch data fees from blobs and pending congestion on the L1 execution layer. When blob spot prices spike (surge bursts and dencun-adjacent demand), L2 fees jump even if L1 execution stays calm — a distinction worth checking before concluding "Ethereum is expensive." The two markets move independently, and each is visible in its own fee tracker. Frequently asked questions Blobs vs calldata — what is the difference? Calldata lives in chain history forever and is priced at execution-gas rates; blobs are temporary (about 18 days), priced on their own market, and typically about 10x cheaper per byte. Blobs trade permanence for cost. Who stores blobs long-term? The protocol does not. Rollup teams, block explorers, and professionally operated archivers keep permanent copies; consensus nodes prune blobs after the verification window precisely to keep node requirements flat. Can blob fees spike like gas fees? Yes. Blob fees run on the same base-fee-plus-priority mechanism as EIP-1559 gas against a fixed 3-per-block target, so sustained blob demand reliably pushes fees up. Calm demand pushes them back to near zero. Sources & methodology EIP-4844 spec — blob framing, fee market, and KZG commitment design. L2Beat risk pages — how each rollup actually uses (or fails to use) Ethereum data availability. W3D methodology + academy dataset on GitHub. Related terms EIP-4844 · Data availability · Data availability sampling · Rollup · Proto-danksharding Chain audits: Base · Arbitrum · tool: L2 gas estimator