Blob Transactions

A blob transaction is a special Ethereum transaction type, formalized by EIP-4844 (Proto-Danksharding), that carries large binary data objects called blobs in a separate, low-cost data layer. Unlike standard calldata, which is stored permanently on-chain, blob data is only accessible for a short data availability window—approximately 18 days—after which it is pruned, dramatically reducing the long-term storage burden on consensus nodes. The primary purpose of blob transactions is to provide an inexpensive and scalable source of data availability for Layer 2 rollups like Optimism and Arbitrum, allowing them to post their transaction data to Ethereum mainnet at a fraction of the previous cost.

The mechanism relies on a multi-dimensional fee market. Blob transactions pay two separate gas fees: one for standard execution and a separate fee for the blob data, priced in a new unit called blob gas. This creates a distinct pricing market for data, decoupling it from the congestion of the main execution layer. Validators and clients store blob data temporarily in a blob sidecar, ensuring the data is available for nodes and rollups to download and verify during the critical window. This architecture is a precursor to full Danksharding, which will further scale data capacity by distributing blob storage across the validator set.

For developers and users, the most immediate impact of blob transactions is drastically reduced L2 transaction fees. By moving bulk data off the expensive main execution calldata and onto this dedicated data layer, rollups can pass significant cost savings to end-users. The BLOB opcode (0x0A) allows smart contracts within the Ethereum Virtual Machine (EVM) to read the data from blobs attached to the current block, enabling verification of commitments. Key related concepts include the KZG polynomial commitments used to cryptographically commit to blob contents and data availability sampling, which will be used in full Danksharding to allow light nodes to verify data availability efficiently.

The term blob transaction originates from the technical descriptor Binary Large OBject transaction. This nomenclature directly references the core innovation of Ethereum's EIP-4844 (Proto-Danksharding): a transaction that carries a large, dedicated data packet—the blob—separate from the standard transaction calldata. The acronym BLOB is a well-established term in computer science for storing unstructured binary data, making it a fitting label for this new carrier of off-chain data.

The conceptual lineage of blob transactions is deeply tied to scaling research, particularly Danksharding. The 'blob' prefix was adopted to distinguish this data type from regular calldata and to signify its temporary, non-execution nature. Unlike standard transaction data, which is processed by the Ethereum Virtual Machine (EVM), blob data is designed to be cheaply available for a short period (approximately 18 days) for layer-2 rollups to verify proofs, after which it can be pruned. This ephemeral characteristic is central to its economic and scaling model.

The full terminology includes related constructs like the blob-carrying transaction (the wrapper that includes the blob), the blob data itself, and blob gas, a new fee market for pricing this dedicated data space. The etymology reflects a deliberate design choice to create a distinct, purpose-built data pathway for rollups, moving away from overloading the existing calldata mechanism and paving the way for a more scalable, modular blockchain architecture.

A blob transaction is a standard Ethereum transaction that carries an extra piece of data called a blob (Binary Large OBject) in a new format known as blob-carrying transactions. This blob is a packet of up to ~128 KB of raw data, typically containing compressed Layer 2 rollup transaction batches. The core innovation is that this data is posted to the consensus layer (Beacon Chain) but is not accessible to the execution layer (EVM), making it cheaper than calldata. A critical mechanism is the blob gas market, a separate fee market from standard EIP-1559 gas that dynamically prices blob space, preventing network congestion from data posting.

The lifecycle of a blob involves several stages. First, a rollup sequencer constructs a blob and submits it within a blob transaction. The Ethereum network validates and confirms the transaction, storing the blob's KZG commitments and versioned hashes on-chain. The actual blob data is only held by consensus layer nodes for a short blob retention period (currently 4096 epochs, ~18 days). After this period, the data is pruned, but its availability is guaranteed because the commitments allow anyone to reconstruct it using Data Availability Sampling (DAS). This separation—keeping data available for verification but not permanently on-chain—is the key to scalability.

For developers and users, the process is largely abstracted. Layer 2 networks handle blob construction and submission. End-users signing transactions on an L2 may have their data eventually batched into a blob. To verify data, light clients or validators can perform DAS by randomly sampling small sections of the blob; successful sampling proves the entire dataset is available. This trust-minimized verification is fundamental to proto-danksharding, the initial phase of Ethereum's danksharding roadmap. The BLOBHASH opcode allows smart contracts in the execution layer to reference the versioned hash of a blob in the same block, enabling verification logic without direct data access.

The economic and security model is distinct. Blob transactions pay two separate gas fees: one for execution and one for blob gas, which is burned via EIP-1559. The blob gas price is adjusted per block based on demand for the limited blob slots (currently 6 per block). This design ensures that high demand for L2 data posting does not inflate gas costs for simple ETH transfers or DeFi swaps. The temporary storage model reduces the perpetual storage burden on nodes while maintaining security, as the commitment cryptographically secures the data for the entire retention window, long enough for any fraud proof challenge to be submitted.

A blob transaction is a specialized Ethereum transaction type, introduced by EIP-4844, that carries large data packets called blobs in a separate, low-cost data layer. Unlike calldata, which is stored permanently on-chain, blob data is designed for temporary availability, significantly reducing the cost for Layer 2 rollups to post their transaction data. This transaction format is the core mechanism enabling proto-danksharding, a precursor to full danksharding, by creating a new, high-volume data market.

The lifecycle begins when a user or, more commonly, a rollup sequencer constructs and signs a blob transaction. This transaction includes the standard execution payload and attaches one or more blobs—each a 128 KB chunk of data committed to via a KZG commitment. The transaction is then broadcast to the network, where validators bundle it into a block. Crucially, the blob data itself is transmitted and validated separately through a peer-to-peer network, ensuring its availability for a fixed period.

Once included in a beacon block, the blob enters its availability window, typically lasting 4096 epochs (approximately 18 days). During this time, the blob data must remain accessible for nodes to download and verify against its KZG commitment. This guarantees that Layer 2 networks or anyone else can reconstruct the rollup's state. After this window expires, the blob data is pruned from the network's active storage. Only the small KZG commitments remain permanently in the consensus layer, acting as a cryptographic proof that the data was once available.

The path from Proto-Danksharding (EIP-4844) to Full Danksharding represents Ethereum's methodical, rollup-centric roadmap for achieving scalable data availability. This evolution is designed to lower transaction costs for Layer 2 rollups by orders of magnitude, transitioning from a temporary blob-carrying transaction format to a fully sharded data layer. The core innovation, Danksharding, introduces a paradigm where block proposers and builders are separated from the responsibility of attesting to data availability, a task delegated to a specialized committee.

Proto-Danksharding, implemented via EIP-4844, introduced blob transactions as a precursor to full sharding. These transactions carry large data "blobs" that are cheap to post because they are not permanently stored by Ethereum execution clients and are not accessible to the EVM. Instead, they are stored temporarily by consensus clients, just long enough for rollups to verify and process the data. This creates a dedicated data availability market separate from gas competition for execution, dramatically reducing L2 costs as an interim solution.

The transition to Full Danksharding expands this model from a single blob per block to 64 data blobs per slot, effectively creating multiple shards for data. Key technical components enable this: Data Availability Sampling (DAS) allows light clients to verify data availability with minimal downloads, KZG polynomial commitments provide cryptographic proofs of data integrity, and a distributed block builder architecture separates block building from proposal. The Builder-Blockchain API (BAPI) and crLists ensure censorship resistance within this new design.

This architectural shift fundamentally changes validator responsibilities. In Full Danksharding, validators no longer need to download the entire sharded data set. Through DAS, they randomly sample small segments of each blob. Only if a threshold of samples is unavailable do they need to download the full data to reconstruct it and identify malicious block builders. This keeps hardware requirements low and maintains Ethereum's decentralized validator set while supporting massive data throughput estimated at 1.3 MB per slot or ~40 TB per year.

The end-state of Full Danksharding positions Ethereum as a robust settlement and data availability layer. Rollups will post their transaction data to this high-throughput, low-cost data layer, while execution and state growth remain managed on L2. This completes the vision of a modular blockchain stack, where Ethereum provides security and data availability, and rollups provide scalable, specialized execution. Future upgrades may focus on further refinements, such as PeerDAS for more efficient data distribution or increased blob counts.