Blob Data

Unlike traditional calldata, which is stored permanently on-chain, blob data is designed for ephemeral storage. Blobs are attached to a block and made available for a fixed period (currently 4096 epochs, ~18 days) before being pruned by nodes. This temporary nature is the core mechanism for reducing the long-term data storage burden on the network while ensuring data is available long enough for fraud proofs and data availability sampling.

Blobs provide a dedicated, low-cost channel for data availability (DA). By separating blob data from standard block execution data, EIP-4844 creates a more efficient market. The gas cost for posting data in a blob is significantly lower than using calldata, directly reducing transaction fees for Layer 2 rollups (like Optimism, Arbitrum, zkSync) that post their transaction data to Ethereum for security. This is measured by the new blob gas fee market.

Each blob is a fixed size of approximately 128 KB. Ethereum blocks have a target of 3 blobs and a maximum of 6 blobs per block, creating a dedicated, separate resource from the standard gas limit. This design prevents blob transactions from competing with standard EVM execution for block space, ensuring predictable capacity and pricing for rollup data. The data within a blob is formatted as KZG commitments for efficient verification.

Blob data is not directly processed by the Ethereum Virtual Machine (EVM). Instead, each blob is cryptographically committed to using KZG (Kate-Zaverucha-Goldberg) commitments. The block header includes a small, fixed-size commitment (a blob hash), and nodes can cryptographically prove that specific data is contained within the blob without downloading all of it. This enables efficient data availability sampling (DAS) by light clients and Layer 2s.

Blob data is the foundational component of proto-danksharding, the initial step toward full danksharding. It introduces the architecture and fee market for blob transactions without implementing data sharding itself. This allows the ecosystem to benefit from reduced costs immediately while the infrastructure for distributing blob data across a committee of validators (full danksharding) is developed. It's a "sharding-ready" data structure.

Blob data is propagated and stored separately from the execution payload. Full nodes and consensus clients (Beacon Nodes) are responsible for making blob data available over a dedicated peer-to-peer network. Applications and Layer 2s retrieve blob data by querying the Beacon Node API, typically targeting the eth_getBlobSidecars method, rather than the standard Ethereum JSON-RPC endpoint used for execution data.

A blob-carrying transaction is a new Ethereum transaction type that includes one or more blobs in addition to regular transaction data. The blob data itself is not accessible to the Ethereum Virtual Machine (EVM); only a commitment (KZG commitment) and versioned hash are.

• Structure: Contains a standard transaction execution payload and attached blob data referenced by its hash.
• Fee Market: Blobs have a separate fee market (blob gas), which is dynamically priced based on demand, decongesting the standard execution gas market.

Blob data is designed for short-term data availability, not permanent on-chain storage. After the blob data retention period (~18 days, 4096 epochs), nodes prune the blob data. Long-term data availability is the responsibility of rollups, block explorers, and data availability committees.

• Purpose: This temporary storage model keeps node storage requirements manageable, a prerequisite for full Danksharding.
• Archival: Services like Ethereum Beacon Chain archival nodes and third-party indexers (e.g., The Graph, Block Explorers) store blob data historically.

The integrity and availability of blob data are cryptographically guaranteed using KZG polynomial commitments. This creates a binding commitment to the blob's data that can be efficiently verified without needing the full data.

• Function: Provides a succinct proof that the data behind the blob hash exists and is correct.
• Trust Assumption: Relies on a trusted setup ceremony (the KZG Ceremony), which was completed by Ethereum contributors to generate secure parameters.

By moving rollup data off the main execution lane, blob data significantly increases Ethereum's effective data capacity for scaling. This creates a multi-dimensional fee market, separating costs for execution (EVM gas) from data availability (blob gas).

• Result: More stable and predictable base layer gas fees for standard transactions (DeFi, NFTs).
• Capacity: Each block can target ~3 blobs (0.375 MB), with a maximum of 6 blobs, translating to ~0.75 MB of additional data per block.

Ethereum execution and consensus clients (e.g., Geth, Nethermind, Lighthouse, Teku) had to implement new logic to handle blob transactions, gossip blob data via blobsidecars, and validate KZG proofs. Ecosystem tooling has evolved to support developers.

• APIs: New RPC endpoints (e.g., eth_getBlobSidecars) for fetching blob data.
• Libraries: Development kits and libraries (e.g., in Foundry, Viem) now include utilities for constructing and decoding blob transactions.

Blob data (Binary Large OBject) is a dedicated data packet introduced by EIP-4844 (Proto-Danksharding) to carry temporary transaction data for Layer 2 rollups. Unlike traditional calldata, blobs are stored separately from the main execution payload and are only available for a short period (~18 days), significantly reducing the cost of posting data to Ethereum.

• Purpose: Provides a high-bandwidth, low-cost data channel for rollups.
• Structure: Each blob is ~128 KB of raw data attached to a beacon block.
• Key Property: Data is not executed by the EVM, only its commitment (KZG commitment) is.

Data Availability Sampling (DAS) is a cryptographic technique that allows light nodes to verify the availability of large datasets (like blob data) by randomly sampling small portions. This is foundational for scaling data layers without requiring nodes to download entire blocks.

• How it works: Nodes request random chunks of the data. If all samples can be retrieved, the data is statistically guaranteed to be available.
• Importance for Blobs: Enables secure scaling by ensuring data is published and accessible for dispute resolution, without bloating all nodes.
• Future Role: Core to full Danksharding, where blobs will be much larger.

KZG commitments (Kate-Zaverucha-Goldberg) are cryptographic proofs used to commit to blob data efficiently. They create a binding fingerprint of the data that can be verified without revealing the entire dataset.

• Function: Each blob is associated with a KZG commitment posted on-chain. This commitment proves the blob's existence and specific content.
• Verification: Layer 2s and validators use the commitment to verify the correctness of data off-chain.
• Trust Assumption: Relies on a trusted setup ceremony (the Ethereum KZG Ceremony), but the security is considered robust post-ceremony.

Blob data follows a specific lifecycle designed for temporary, high-availability storage, not permanent archival.

• Phase 1: Propagation & Consensus: Blobs are broadcast, included in a beacon block, and made available via the peer-to-peer (p2p) network for ~18 days.
• Phase 2: Pruning: After the blob data availability window expires (~18 days), nodes prune the raw blob data to save space.
• Permanent Record: Only the small KZG commitment and a few metadata fields remain in the consensus layer forever. Long-term archival is the responsibility of blob explorers and data availability committees.

The security of systems using blob data hinges on its guaranteed short-term availability, which enables fraud and validity proofs.

• Core Guarantee: Data is available for the dispute window (days/weeks), allowing anyone to challenge invalid state transitions on L2s.
• Risk: If data is withheld during this window, L2s cannot force inclusion of their transactions, potentially halting withdrawals.
• Ethereum's Role: The consensus layer enforces that validators only sign blocks where blob data is available (through DAS in the future). This makes data withholding a slashable offense.

Blob data interacts with several key scaling and data concepts in the blockchain stack.

• Rollups (L2s): The primary users of blobs, posting batched transaction data cheaply.
• Danksharding: The future full implementation where the blob space is massively expanded, relying entirely on DAS.
• Data Availability Committees (DACs): Alternative, more centralized data availability providers sometimes used by validiums.
• EIP-4844: The specific Ethereum Improvement Proposal that implemented proto-danksharding and introduced blob transactions.