Blob Transactions

A blob transaction is an Ethereum transaction type that includes one or more data blobs—large, temporary data packets stored separately from the main execution layer. Each blob can hold approximately 128 KB of calldata, but is priced and processed through a new fee market, making it orders of magnitude cheaper for posting data availability proofs. This mechanism is the core innovation of proto-danksharding, a precursor to full danksharding, aimed at scaling Ethereum by subsidizing Layer 2 rollup costs.

The architecture separates the blob-carrying transaction in the execution layer from the blob data itself, which is only accessible to the consensus layer for a short period (currently 4096 epochs, ~18 days). This ephemeral storage, verified by KZG polynomial commitments, ensures nodes can confirm data availability without the burden of permanent storage. Rollups like Optimism and Arbitrum use these blobs to post cheap, verifiable transaction batches, passing the savings directly to end-users through lower L2 transaction fees.

From a network perspective, blob transactions introduce a new resource, blob gas, governed by its own EIP-1559-style fee market, which is independent of standard execution gas. This prevents competition for block space between regular smart contract operations and rollup data posting. Validators and nodes have a blob sidecar attached to the beacon block, containing the blob data and its proofs, which is pruned after the retention window to control state growth.

The primary impact of blob transactions is a dramatic reduction in Layer 2 (L2) operating costs, making applications like decentralized exchanges and social networks economically viable. By providing a dedicated, low-cost data channel, Ethereum strengthens its role as a secure settlement layer while enabling high-throughput execution on L2s. This design is a critical step toward a scalable, modular blockchain ecosystem where security and scalability are optimized across different layers.

In computer science, a Binary Large Object (BLOB) is a generic term for a large, unstructured chunk of data stored as a single entity in a database. The Ethereum community adopted this established term to describe the new, large data packets introduced by EIP-4844 (Proto-Danksharding). These packets are designed to be large (initially ~128 KB), opaque to the Ethereum Virtual Machine (EVM), and temporarily stored—all characteristics fitting the classic BLOB data type. The name succinctly conveys that this data is a bulk, binary payload attached to a transaction.

The choice of 'blob' over more technical alternatives was intentional for its simplicity and memorability. It serves as a clear, distinct namespace separating this new data format from existing concepts like calldata or regular transaction data. While calldata is executed and permanently stored on-chain, blob data is intended for layer 2 rollups to post cryptographic commitments (via KZG commitments) to transaction data. The blob itself is only held by consensus nodes for a short period (approximately 18 days) before being pruned, making it a large, temporary attachment—a perfect fit for the blob metaphor.

The terminology extends to related components: a blob-carrying transaction is a new transaction type, the data itself is the blob, and the fee market for this data is governed by a blob gas mechanism separate from execution gas. This lexical clarity helps developers and researchers precisely discuss the protocol's architecture. The term's prior use in distributed systems, such as the BLOB pattern in peer-to-peer networking, further cemented its appropriateness for a large, disseminated data chunk in a decentralized network.

A blob transaction is a special type of Ethereum transaction that includes a large, temporary data packet called a blob in a new transaction format defined by EIP-4844. Unlike calldata, which is stored permanently on-chain, blob data is posted to the Beacon Chain consensus layer and is only accessible for a short period (approximately 18 days) before being pruned. This separation of data availability from permanent storage is the fundamental mechanism that drastically reduces the cost of posting large amounts of data to Ethereum for Layer 2 rollups.

The transaction structure contains two key components: the standard execution payload and the blob sidecar. The execution payload includes the sender, recipient, value, and a commitment to the blob data (a KZG commitment). The blob sidecar is the actual data, consisting of up to 4096 32-byte field elements, equating to roughly 128 KB per blob. Validators are responsible for verifying that the data in the sidecar matches the KZG commitment in the execution payload, ensuring data availability without forcing every node to download the full blob for execution.

From a network perspective, blob transactions propagate through a distinct blob gossip subnetwork. This prevents the large blob data from congesting the standard transaction gossip network. Execution clients (like Geth) process the transaction's execution payload, while consensus clients (like Prysm) handle the associated blob sidecar. This client-level separation mirrors the architectural separation of data availability from execution, a core tenet of Ethereum's roadmap.

The economic model for blobs uses a separate fee market, governed by a blob gas mechanism. Blob gas prices are determined by demand for blob space and adjust independently from the standard EIP-1559 gas used for execution. This prevents competition between blob data and standard transactions, creating a stable, predictable cost environment for rollups. The blob gas cost is primarily driven by the number of blobs in a block, not their content, incentivizing efficient data packing.

Finally, the lifecycle of blob data is ephemeral. After the ~18-day blob retention period, the data is deleted by nodes. Rollups and other users must have retrieved and stored the data they need within this window. The permanent record on-chain is only the small KZG commitment, which serves as a cryptographic proof that the data was available, enabling trust-minimized fraud proofs and validity proofs for Layer 2s. This design achieves scalable data availability without imposing indefinite storage costs on the network.

EIP-4844 (Proto-Danksharding) introduced blob-carrying transactions as a foundational upgrade, creating a new, separate data channel for Layer 2 rollups. This mechanism provides a large, temporary data space—blobs—that are posted to the consensus layer but are not permanently stored by execution clients. By decoupling data availability from execution, EIP-4844 dramatically reduces the cost for rollups to settle data on Ethereum, enabling cheaper L2 transaction fees while laying the architectural groundwork for the full Danksharding vision.

The transition to full Danksharding represents the complete realization of this data-centric scaling model. It expands the single blob lane introduced by EIP-4844 into a multi-dimensional space with many concurrent blob lanes, massively increasing data capacity. Core to this design is data availability sampling (DAS), a technique that allows nodes to verify the availability of all data by randomly sampling small portions, enabling the network to securely handle data volumes far exceeding the capacity of any single node. This preserves Ethereum's decentralized security model while enabling orders-of-magnitude higher throughput.

Key technical bridges between proto-danksharding and full danksharding include the implementation of PeerDAS for decentralized blob distribution and the eventual adoption of a modular architecture separating the consensus and data availability layers. The final state envisions a network where specialized builder-proposer separation roles and advanced cryptographic constructs like KZG commitments and Erasure Coding work in concert to create a robust, scalable, and trust-minimized data layer, fulfilling Ethereum's roadmap for scalable sovereignty.