What is a Blob?
A blob (Binary Large Object) is a new transaction data type introduced in Ethereum's EIP-4844 (Proto-danksharding) upgrade in March 2024, specifically designed for Layer 2 rollups to post data efficiently. Blobs provide approximately 128KB of cheap data space per blob transaction, significantly reducing rollup costs while maintaining Ethereum's security guarantees for data availability.
How Blobs Work
Blob-carrying transactions attach data blobs that are available for approximately 18 days before automatic pruning from consensus layer nodes. Unlike regular calldata that lives in transaction history forever, blobs are temporary. They exist long enough for rollups to finalize state and for fraud proofs to be submitted, but don't permanently burden the chain's storage requirements.
Blobs use a separate fee market with its own base fee mechanism, similar to EIP-1559 for regular gas. When blob demand is low, costs approach the minimum. When demand increases, blob fees rise to manage capacity. This market-based approach efficiently allocates the limited blob space among competing rollups.
Impact on Rollup Costs
Before blobs, rollups posted data as calldata, costing approximately 16 gas per byte. Blobs reduce this cost dramatically. In practice, by 10-100x depending on demand patterns. This translates to proportional reductions in user transaction fees on rollups.
Major rollups immediately adopted blobs upon EIP-4844 activation. Arbitrum, Optimism, Base, Scroll, and others switched from calldata to blob posting, passing cost savings to users. Some rollup transaction fees dropped below $0.01, enabling use cases that were uneconomical before.
Blob Capacity and Future
EIP-4844 currently supports a target of 3 blobs per block (approximately 375KB), with a maximum of 6 blobs (750KB). This is a stepping stone toward full danksharding, which aims to scale to 16MB+ of blob space through data availability sampling.
Current blob capacity can become congested during high rollup activity (inscriptions, popular L2 airdrops), causing blob fee spikes. The system handles this gracefully through fee adjustments, but capacity limitations are real until future upgrades.
Technical Foundation
Blobs use KZG (Kate-Zaverucha-Goldberg) polynomial commitments for efficient verification. Each blob has a corresponding commitment included in the beacon block. This cryptographic structure enables future data availability sampling without downloading full blobs. Verification via random sampling of portions.