The term "blob transaction" started appearing in crypto discourse around early 2024, roughly when Ethereum's Dencun upgrade went live. If you followed the subsequent drop in rollup fees — L2 transaction costs fell by 90 percent or more overnight — blobs are the reason. But the mechanism is easy to mischaracterize.
A blob isn't just a big attachment to a regular transaction. It's a new data format with three specific properties: it's temporarily available rather than permanent, invisible to the EVM, and priced in a completely separate fee market from execution gas. Understanding those three properties is most of what you need to understand how this changes Ethereum's data layer.
The Mechanism
EIP-4844, activated in the Dencun upgrade on March 13, 2024, introduced Ethereum's transaction type-3 — formally called blob-carrying transactions. The core addition: a transaction can now carry one or more blobs alongside its regular calldata and execution instructions.
Each blob is a fixed-size data chunk: 128 KB (131,072 bytes, to be precise). A single block can hold up to 6 blobs, with a target of 3. That target number is the adjustment mechanism. If recent blocks average above 3 blobs, the blob base fee increases; if below 3, it decreases. This is structurally identical to how EIP-1559 adjusts the execution gas base fee — the same asymmetric correction logic applied to a completely separate resource.
Temporarily available, not permanent. Blob data lives on the consensus layer — beacon chain nodes — for approximately 18 days, or 4,096 epochs. After that window, it's pruned. Execution layer nodes never need to store it long-term at all. This is deliberate: rollups need their data to be available for a bounded window, not forever. A 7-day fraud proof window for an optimistic rollup fits well inside 18 days with room to spare.
Invisible to the EVM. The raw blob data cannot be read by smart contracts. Only a cryptographic commitment — a KZG commitment — is accessible on-chain. The rollup contract on L1 stores and verifies this commitment. If the full data is ever needed during a dispute, nodes can retrieve it from the network while it's still within the availability window. The EVM never sees the raw bytes.
Separately priced. Blob gas is a distinct resource from execution gas. The two don't compete for the same pool. When blob usage is low, blob base fees start near-zero — exactly what happened post-Dencun. Rollup data posting became nearly free because the blob fee market began essentially empty. As utilization approaches the target, fees adjust upward.
Where Constraints Live
The 18-day retention window is a soft constraint rather than a cryptographic one. It's a network norm for beacon node operators — nodes are expected to hold blob data for that duration, but it isn't enforced by protocol cryptography the way block validity is. This works because the window substantially exceeds operational requirements: 7-day fraud proof periods, ZK validity proofs that settle in hours or minutes, both fit well inside 18 days.
The 6-blob-per-block ceiling is a hard protocol constraint at the current level. Raising it requires either accepting that nodes without data availability sampling (DAS) infrastructure would struggle to keep up, or implementing DAS first. Nodes today download and verify all blob data in full — at 6 blobs per block, that's roughly 768 KB of blob data per 12-second slot. Raising to 64 blobs would require 8 MB per slot, which is why DAS infrastructure needs to come first.
The KZG commitment scheme was chosen over alternatives specifically for its computational efficiency. Ethereum ran a multi-party computation ceremony in 2023 — the "powers of tau" ceremony — with over 140,000 participants contributing randomness. KZG security relies on at least one participant in that ceremony having acted honestly. The ceremony happened and its output is now baked into the protocol.
What's Changing
The immediate roadmap incrementally increases blob throughput. The Pectra upgrade (May 2025) raised the target from 3 to 6 blobs per block and the maximum from 6 to 9 via EIP-7691. Parameters will continue increasing as the network demonstrates capacity to handle the load.
PeerDAS is the next significant development — a partial implementation of data availability sampling intended to let the blob ceiling rise substantially before full Danksharding is complete. Under PeerDAS, nodes download only a portion of each blob and verify availability probabilistically rather than downloading everything in full. If enough independent samplers confirm partial availability, the blob is considered available. This is in active testing on testnets.
Full Danksharding — targeting 64 or more blobs per block — requires DAS to be robust at mainnet scale. That's a meaningful research and engineering effort, not an imminent activation.
What Would Confirm This Direction
Blob capacity increases deploying without incident. Rollup fees staying compressed as blob adoption grows. PeerDAS successfully activating on mainnet with consistent data availability. The blob fee market adjusting fees in response to utilization — the same way EIP-1559 does for execution gas — without the two markets distorting each other.
What Would Break This
A vulnerability discovered in the KZG commitment scheme that allowed blob data to be withheld while still passing commitment checks — that would undermine the data availability guarantees rollups depend on. Blob data becoming unavailable during an active fraud proof window would compromise rollup security. A DAS implementation that produced systematic false positives at scale would make the probabilistic availability model unreliable. Or rollup adoption failing to materialize, which would make the entire data availability layer redundant.
Timing
Now: Blob transactions are live on Ethereum mainnet. Major rollups — Arbitrum, Optimism, Base, zkSync, Scroll, Starknet — post their batch data as blobs by default. If you're transacting on any of these L2s, your activity is settled via blob transactions. Blob fees are currently very low due to utilization well below the target ceiling.
Next: The blob target ceiling will increase incrementally. PeerDAS testnet results and eventual mainnet activation will signal how quickly blob capacity can scale. Watch for EIP discussions on further parameter increases as utilization grows toward current limits.
Later: Full Danksharding with 64+ blobs per block and mature DAS infrastructure is multi-year work. Proto-Danksharding (what's live now) is explicitly a stepping stone — it establishes the data format, the KZG ceremony outputs, and the fee market before DAS is ready.
Boundary
This explanation covers the blob transaction mechanism: how type-3 transactions work, what makes blobs different from calldata, and where the development roadmap stands. It doesn't cover rollup architecture in depth, how specific L2 fees are calculated at the user level, or the economics of individual chains. Not financial advice.
