18 posts tagged with "blobs"

June 18 looked like a new blob demand record.

It was, technically. Ethereum carried 40,822 actual blobs that day, beating June 3's 38,445.

But the record was weirdly hollow. June 18 carried 25% less useful blob payload than June 3, even with more blobs.

I expected the 21-blob blocks to look ugly.

They don't. At least not in the median case.

Every blob you add to a block makes it slightly harder for validators to attest to it on time. This isn't a theoretical concern — it shows up in the data today, at the current limit of 6 blobs per block. When Fulu raises that limit, the cost scales with it.

The mechanism is straightforward. The cost of getting it wrong is less obvious.

The blob count limits on Ethereum have always been embedded in the consensus spec. Pre-Fulu, both the target and maximum blobs per block were hardcoded: currently 3 target / 6 max (post-Dencun). Changing them required a hard fork.

EIP-7742 changes that. From Fulu onward, the consensus layer sends the target and max as fields in the ExecutionPayloadHeader. The execution layer reads them and applies them dynamically. No recompile. No fork vote required for the limit itself — only for the mechanism that sets it.

This is a real change to how the blob fee market works.

Ethereum has two fee markets now. The execution fee market — EIP-1559, base fee, familiar — and the blob fee market introduced by EIP-4844. They're superficially similar: both have a target utilization, both use an exponential update rule, both burn the base fee. But they behave very differently in practice, and the reason is the parameter choices.

The blob fee market oscillates. It spends most of its time near the floor, spikes hard when demand exceeds the target, then crashes back. There's rarely a stable equilibrium. This post is about why.

In December 2025, Ethereum's Fulu upgrade raised the blob cap from 6 to 15, then to 21 in January. That's a 3.5× increase in the data availability space available to rollups per block — the single biggest capacity jump since EIP-4844 launched blobs in March 2024.

Three months later, not a single major rollup has used more than 6 blobs in a single transaction.

Correction — 17 July 2026: I misread Xatu's derived UNSUPPORTED collector label as a response from the execution client. The snooper applies that label to a null or non-array result, while V2 permits null for missing or pruned blobs, syncing, and other inability to serve the complete request. The client-support, version-upgrade and performance conclusions below are not supported by these rows. I also attributed V2 to Pectra; it is specified in the Osaka execution fork paired with Fulu. The full correction reproduces the same calls across both capture paths.

One month after Pectra went live, roughly 44% of all Nethermind validator nodes are rejecting a blob retrieval call that was introduced in that very fork. Every other major execution client has mostly fixed this. Nethermind hasn't moved.

This is the data on what's happening, why it matters, and where the fault line sits.

Each blob on Ethereum costs the same regardless of how much data you actually put inside it. The slot doesn't know if you packed all 131,072 bytes or left 99% empty. You pay either way.

That flat pricing creates a question that hasn't been answered cleanly: how efficiently are rollups actually using the space they're buying? The answer turns out to span an enormous range — from 100% fill all the way down to a rollup that's posting the same completely empty blob, over and over, every block.