Blob Transaction

A blob transaction is a new transaction format introduced by EIP-4844 (Proto-Danksharding). Its primary purpose is to provide a dedicated, low-cost data channel for layer-2 rollups like Optimism and Arbitrum. Unlike standard transactions where data is stored permanently in the execution layer's state, blob data is posted to the consensus layer and is only accessible for a short period, typically about 18 days. This temporary storage model is the key innovation that enables significantly cheaper data availability compared to using calldata.

The transaction structure contains two main components: the standard execution payload and one or more blobs. Each blob is a binary large object (BLOB) of approximately 128 KB. The execution payload includes the transaction's core details (sender, recipient, value), while the blob data is referenced via a commitment (a KZG polynomial commitment) and stored separately. This separation allows the Ethereum Virtual Machine (EVM) to verify the blob's existence and authenticity without needing to process the full data, keeping execution efficient.

The economic model for blobs uses a distinct fee market, separate from the standard gas market for execution. This creates a multi-dimensional EIP-1559 fee market, where blob fees are determined by demand for data space and are burned. The temporary nature of the data—blobs are pruned after the blob expiry window—means nodes are not burdened with storing this data indefinitely, which is the fundamental reason costs remain low for rollups and, by extension, end-users.

For developers and users, the primary interaction with blob transactions is indirect, through layer-2 networks. Rollup sequencers batch thousands of transactions, compress the data, and post it to Ethereum as a blob. This data is essential for fraud proofs (in optimistic rollups) or validity proofs (in ZK-rollups). Wallets and block explorers display blob transactions with specific fields like blobGasUsed, blobGasPrice, and the count of blobVersionedHashes.

The long-term roadmap for blob transactions leads to full Danksharding, where the network's capacity for blobs will scale to 64 per block, further decentralizing rollups and enabling massive throughput. Blob transactions represent a critical scaling milestone, shifting Ethereum's role for rollups from a costly permanent data ledger to a highly efficient, temporary data availability layer.

The word blob is a long-standing computing term, a backronym for Binary Large OBject. It describes a large, unstructured chunk of data stored as a single entity in a database. In the context of Ethereum's EIP-4844 (Proto-Danksharding), a blob refers to a dedicated data packet carrying layer 2 rollup transaction data, which is large (up to ~128 KB) and treated as an opaque binary object by the execution layer.

The transaction component is drawn directly from blockchain fundamentals, denoting a cryptographically signed instruction that initiates a state change. A blob transaction is therefore a new transaction type that includes a commitment to this external blob data. Its design is a direct evolution from earlier data-saving proposals like data gas and calldata, but it is structurally distinct because the blob data is not accessible to the Ethereum Virtual Machine (EVM) and is pruned after a short period (~18 days).

The full term's origin is tightly linked to Dankrad Feist and the Proto-Danksharding proposal, which laid the groundwork for full danksharding. The name effectively describes its function: a transaction that posts a 'blob' of data to be temporarily available for verification. This etymology highlights its role as a bridge technology, optimizing data availability for rollups today while establishing the architectural framework for Ethereum's future sharded data layer.

A blob transaction is a standard Ethereum execution-layer transaction with an added component: a commitment to one or more data blobs stored separately on the beacon chain. The transaction itself includes a small blob_versioned_hashes field, which points to the blob data, while the large blob data (up to ~128 KB per blob) is posted to and propagated through the consensus layer. This separation is key—the execution layer only processes the transaction's core elements (sender, recipient, value, calldata), while the consensus layer handles the bulky blob data, making it available for a short period.

The core innovation is the use of KZG commitments (Kate-Zaverucha-Goldberg) for cryptographic verification. When a user submits a transaction, they generate a KZG commitment and proof for the blob data. The commitment is included in the transaction, and the actual blob is sent to the beacon chain. Nodes can then verify that the blob data matches the commitment without downloading the full blob, a process known as data availability sampling. This ensures Layer 2 networks can trust that the data is available for state verification without imposing the full storage burden on all Ethereum nodes.

After a fixed period, currently 4096 epochs (~18 days), the blob data is pruned from the beacon chain nodes. This temporary data availability is sufficient for the fraud proof or validity proof window of Layer 2 rollups, which need the data to be available long enough to challenge state transitions. By not burdening the Ethereum Virtual Machine (EVM) with this data permanently, blob transactions provide data at a cost roughly 10-100x cheaper than equivalent calldata, dramatically reducing Layer 2 transaction fees while maintaining Ethereum's security guarantees for data availability.

The Path to Danksharding is Ethereum's multi-phase roadmap to achieve scalable data availability through a technique called data sharding. This evolution began with the conceptual separation of execution and consensus, solidified by The Merge, which transitioned Ethereum to Proof-of-Stake. The next critical step was proto-danksharding, introduced via EIP-4844, which added a new transaction type—the blob-carrying transaction—to provide cheap, temporary data storage for Layer 2 rollups. This created a dedicated blobspace market, a precursor to a full sharded data layer.

Proto-danksharding, or EIP-4844, implemented a blob-augmented execution environment where rollup data is posted in large binary data objects called blobs. These blobs are attached to transactions but are not accessible to the Ethereum Virtual Machine (EVM); they exist purely for data availability. The blobs are stored by the consensus layer for a short period (approximately 18 days) before being pruned, significantly reducing node storage burdens while ensuring data is available long enough for fraud proofs and data sampling.

The architecture employs KZG polynomial commitments (a type of cryptographic commitment scheme) to create compact proofs that the blob data is available and correctly formatted. This allows nodes to efficiently verify data without downloading the entire blob. The system introduces new concepts like the blob gas market, which is separate from the main execution gas market, and blob fee calibration via a targeting mechanism that adjusts costs to maintain an optimal number of blobs per block, typically aiming for three.

The final evolutionary stage is full danksharding, which will expand this prototype into a robust, horizontally scalable data layer. Full danksharding aims to increase the number of blobs per block from ~3 to 64, massively boosting data capacity. It will implement data availability sampling (DAS), where light clients and validators can securely confirm data availability by randomly sampling small pieces of the total data, enabling the network to safely scale without requiring any single node to process all the data.

This progression—from a monolithic chain to a rollup-centric ecosystem with proto-danksharding, and onward to a fully sharded data layer—represents a fundamental shift in blockchain design. It moves Ethereum towards becoming a settlement and data availability layer, where execution is primarily handled off-chain by L2s, and the base layer provides secure, abundant, and cheap space for publishing transaction data, enabling global-scale adoption.