Blob

A blob (binary large object), specifically an EIP-4844 proto-danksharding blob, is a dedicated data packet attached to an Ethereum block that provides cheap, temporary data availability for layer 2 rollups. Unlike calldata, which is stored permanently on-chain, blob data is automatically deleted by nodes after approximately 18 days, drastically reducing the long-term storage burden and cost. This mechanism allows rollups like Optimism and Arbitrum to post transaction proofs and data at a fraction of the previous cost, directly lowering fees for end-users.

The technical architecture involves a new transaction type that carries a blob-carrying transaction. Each transaction can include up to six blobs, with each blob holding roughly 128 KB of compressed data. This data is not executed by the Ethereum Virtual Machine (EVM) but is made available for a short period, allowing layer 2 networks to verify the integrity and correctness of their off-chain transactions. The separation of data availability from execution is a core innovation, paving the way for the full implementation of danksharding in the future.

From a network perspective, blobs are validated and propagated through a new peer-to-peer network sub-protocol, ensuring all consensus nodes can access the data during the critical window. Validators are incentivized to include blobs through a separate fee market, the blob gas fee market, which operates independently from the standard gas for execution. This creates a more stable and predictable pricing model for rollup data, decongesting the main Ethereum block space and enabling higher scalability for the entire ecosystem.

In blockchain, a blob (Binary Large Object) is a dedicated data packet introduced by Ethereum's EIP-4844 (Proto-Danksharding) to carry temporary, low-cost transaction data for Layer 2 rollups. The term was chosen for its established meaning in computer science—a large, opaque binary data block—but is re-contextualized as a blob-carrying transaction with specific size (≈128 KB) and lifecycle constraints. Its primary function is to separate bulky data from the main execution layer, enabling cheaper data availability for rollups without permanently burdening Ethereum's consensus nodes.

The conceptual origin of the blob is directly tied to the roadmap for Danksharding, a future scaling upgrade. Proto-Danksharding (EIP-4844) implemented a simplified, interim version of this architecture. The blob's design—being large, committed to via a KZG commitment, and automatically pruned after a short period (≈18 days)—stems from the need to provide a data availability layer that is cost-effective for rollups while ensuring the historical data can be stored by specialized actors like blob archivers. This creates a clear separation between data for immediate verification and data for long-term storage.

The etymology reflects a deliberate shift from previous data structures. Prior to EIP-4844, rollups posted their transaction data as calldata on the main chain, which was permanent and expensive. The blob is a new, first-class citizen in the Ethereum protocol, with its own transaction type and fee market. Its name succinctly captures its role: a large, self-contained binary object whose contents are only interpreted by Layer 2s, while the Ethereum consensus layer merely attests to its availability.

A blob (Binary Large OBject) is a dedicated data structure introduced by Ethereum's EIP-4844 (Proto-Danksharding) to provide temporary data availability for Layer 2 rollups. Unlike traditional transaction calldata, which is stored permanently on-chain, blob data is only accessible for a short period (approximately 18 days) and is not processed by the Ethereum Virtual Machine (EVM). This design allows rollups to post large batches of transaction data at a significantly lower cost, as the network only needs to guarantee the data's availability for verification, not its indefinite storage.

The mechanism relies on a new transaction type, blob-carrying transactions, which include a reference to the blob data in a sidecar. This data is stored in the Beacon Chain consensus layer within the blobspace, a separate resource market from standard gas. Validators are responsible for attesting to the availability of this data for a short window, after which it can be pruned. This separation of execution and data availability is the core innovation, dramatically reducing the cost for rollups to settle their data on Ethereum while maintaining the security guarantees of the base layer.

For developers, blobs are accessed via the BLOBHASH opcode and the blobVersionedHashes field in a transaction. A rollup sequencer will typically compress its batch of transactions, generate KZG commitments for the data, and post it as a blob. The associated KZG commitment (a cryptographic proof) is what is permanently recorded on-chain, allowing anyone to verify the data was available if needed. This system ensures that fraud proofs or validity proofs for rollups can be executed correctly, as the necessary data was publicly accessible at the time of posting.

The practical impact is a new scaling paradigm. By creating a high-bandwidth, low-cost data lane, blobs enable rollups to post more data per block, which translates to higher transaction throughput and lower fees for end-users. This architecture is a critical stepping stone towards full Danksharding, a future upgrade that will further expand blob capacity by distributing data across a committee of validators, solidifying Ethereum's roadmap for scalable, secure settlement.

The evolution from Proto-Danksharding (EIP-4844) to full Danksharding represents Ethereum's incremental roadmap for implementing data availability sampling (DAS), a core scaling technology. Proto-Danksharding, also known as blob-carrying transactions, introduced a new transaction type and a separate fee market for large data packets called blobs. This initial phase established the foundational architecture—including the blob gas mechanism and a beacon chain-managed data layer—without yet implementing the peer-to-peer sampling that defines full sharding. It served as a critical production testbed, allowing the network and its clients to adapt to the new data paradigm while delivering immediate scaling benefits through rollups.

The key technical bridge between these phases is the implementation of data availability sampling. In Proto-Danksharding, validators and clients must download the entirety of each blob to verify its availability. Full Danksharding will decentralize this responsibility: each participant will only need to download a few small random samples of the total data. By collectively sampling the data availability committee (DAC)-less shard data, the network can statistically guarantee its availability without any single node handling the full dataset. This shift transforms data verification from a mandatory full-download task into a lightweight, scalable process, enabling the shard data block size to safely increase by orders of magnitude.

Full Danksharding culminates this vision by scaling the system to 64 data shards, with each proposing a blob in every slot. The proposer-builder separation (PBS) framework, particularly through MEV-Boost and eventual in-protocol PBS, is crucial for managing the immense data load. A specialized block builder will be responsible for constructing a block containing all this shard data, while the consensus layer validators focus on attestations and sampling. This final stage aims to provide massively scalable, low-cost data availability for layer 2 rollups, solidifying Ethereum's settlement layer as a robust foundation for a global, decentralized ecosystem of scalable applications.