What is Blob Transaction?

A Blob Transaction is an Ethereum transaction type designed to provide rollups with a cheaper way to publish large amounts of data to the Ethereum network. Blob transactions were introduced through EIP-4844, commonly known as Proto-Danksharding, and became available with Ethereum’s Dencun upgrade on 13 March 2024.

The word “blob” stands for Binary Large Object. In Ethereum, a blob is a temporary package of data attached to a special transaction. Unlike ordinary calldata, blob data is not permanently accessible through the Ethereum Virtual Machine and does not need to remain in Ethereum’s active state indefinitely. This makes blobs particularly suitable for Layer 2 rollups, which need Ethereum to make transaction data available long enough for verification but generally do not need that raw data to be stored permanently by every node.

Blob transactions introduced a separate market for this type of data. Instead of forcing rollups to compete with ordinary Ethereum transactions for the same calldata capacity, Ethereum can price blob space separately. This was an important step in Ethereum’s rollup-centric scaling strategy and laid technical groundwork for further data-availability improvements.

Why Ethereum Introduced Blob Transactions

Rollups process transactions outside Ethereum’s main execution layer and then publish information to Layer 1. Optimistic rollups and zero-knowledge rollups use different verification mechanisms, but both need access to Ethereum’s data availability to reconstruct or verify the Layer 2 state.

Before EIP-4844, rollups commonly published this information as transaction calldata. Calldata is data supplied to Ethereum smart contract calls. It works well for many purposes, but using it for large quantities of rollup data has an important disadvantage: calldata forms part of Ethereum’s permanent blockchain history.

Rollups usually do not need their raw transaction batches to remain directly available through Ethereum forever. They need the data to remain available for a sufficient period so network participants can retrieve it, verify the Layer 2 state, generate proofs where necessary, and respond to invalid state transitions.

Blob transactions were designed around this difference.

Instead of storing rollup data in conventional calldata, a Layer 2 can attach one or more blobs to a blob-carrying transaction. Ethereum’s consensus layer makes the blob data available to the network temporarily, while the execution layer receives cryptographic commitments rather than direct access to all the blob contents.

The result is a data channel designed specifically for high-volume Layer 2 publishing. This reduces the need for rollups to consume comparatively expensive permanent calldata capacity for information whose main purpose is short-term data availability.

How a Blob Transaction Works

EIP-4844 introduced a new typed transaction known as a blob-carrying transaction, using transaction type 0x03. Its structure builds on Ethereum’s existing transaction system while adding fields related to blobs and their pricing.

The blobs themselves are not simply inserted into the EVM execution payload like ordinary calldata. Instead, the transaction references them through cryptographic commitments. Ethereum uses polynomial commitments based on KZG, or Kate-Zaverucha-Goldberg, commitments, allowing the network to verify that particular data corresponds to a commitment without treating the entire blob as ordinary EVM-readable transaction data.

A blob contains 4,096 field elements, with each field element occupying 32 bytes. This produces a nominal blob size of 131,072 bytes, or 128 KiB. The structure was chosen as part of the data-availability architecture introduced by EIP-4844.

The basic lifecycle can be summarised as follows:

1. A rollup collects and processes a batch of Layer 2 transactions.
2. The rollup encodes the required batch information into blob data.
3. A blob-carrying transaction is created with commitments referencing the attached blobs.
4. The transaction and associated blob data are propagated through Ethereum.
5. Ethereum validators verify the relevant commitments and make the blob data available according to protocol rules.
6. Layer 2 participants retrieve the data when they need to reconstruct or verify the rollup state.
7. The blob data can eventually be pruned because Ethereum does not require it to remain permanently available through the protocol.

Ethereum’s execution environment does not provide arbitrary direct access to blob contents. Smart contracts can work with the associated versioned hashes and verify relationships involving the commitments, but blobs are intentionally different from calldata.

This separation is essential to their economic purpose. If every byte of rollup data had to remain permanently available in the same way as traditional blockchain history, Ethereum would have much less room to reduce the cost of Layer 2 data publishing.

Blob Transactions vs Regular Ethereum Transactions

Blob transactions do not replace ordinary Ethereum transactions. They solve a specialised problem, particularly the publication of data by rollups.

A blob transaction still consumes normal execution gas for the transaction itself. Blob space, however, has its own pricing mechanism. Users therefore need to distinguish between execution gas and blob gas.

This dual structure means a rollup submitting a blob transaction can effectively pay for two resources: Ethereum execution required to process the transaction and the separate data-availability capacity occupied by its blobs.

Blob Gas and the Separate Fee Market

One of the most important innovations introduced with blobs is their separate fee market. Before EIP-4844, rollups publishing calldata competed for block space in the same general execution environment as token transfers, decentralised exchange trades, NFT transactions and other Ethereum activity.

Blob space has separate pricing based on demand for blob capacity. This allows the cost of Layer 2 data availability to respond to rollup demand without directly using the same pricing mechanism as ordinary EVM execution.

The system has similarities to the EIP-1559 fee model. Blob fees respond algorithmically to utilisation, increasing when demand remains above the protocol’s target and decreasing when usage is below it.

This distinction has several consequences:

• rollups gain access to data capacity specifically designed for their requirements;
• heavy demand for blobs can increase blob fees without producing exactly the same effect as equivalent demand for ordinary execution gas;
• Layer 2 transaction costs can become less dependent on the price of permanent calldata;
• Ethereum can adjust blob capacity over time as the network’s data-availability architecture develops;
• blob pricing creates an observable market for Ethereum data availability.

The number and target of blobs supported by Ethereum are protocol parameters rather than permanent constants. Ethereum upgrades can increase blob capacity as networking, storage and data-availability technology improve. This has already made blobs an evolving resource rather than a feature whose capacity was fixed permanently when Dencun launched.

The practical price advantage also varies. Blobs were designed to make rollup data publishing more efficient, but this does not guarantee that blob fees will always be negligible. When demand for blob space becomes high, the blob fee market can become more expensive.

Why Blobs Reduce Layer 2 Costs

For many rollups, posting data to Ethereum is one of the major components of operating costs. Layer 2 execution itself can be inexpensive, but a rollup still needs to publish sufficient information to Ethereum so users do not have to trust the rollup operator to provide transaction history.

Before blobs, calldata costs could therefore account for a substantial share of Layer 2 transaction fees. EIP-4844 created a resource better matched to the actual requirements of rollups.

Several major Ethereum Layer 2 networks adopted blobs after the Dencun upgrade. The transition allowed rollups to move significant amounts of batch data away from calldata, contributing to lower data-publishing costs and, depending on the rollup’s fee model and network demand, lower fees for end users.

The advantages of blob-based data availability include:

• temporary rather than protocol-mandated permanent storage of bulk rollup data;
• dedicated capacity for Layer 2 transaction batches;
• a fee market separated from ordinary Ethereum execution;
• cryptographic commitments that allow the network to verify relationships to blob data efficiently;
• a foundation for future Ethereum data-availability scaling.

Blobs do not make Layer 2 transactions free. Rollups still incur costs for execution, proof generation, sequencing, Ethereum settlement, infrastructure and data availability. Networks also use different fee policies, so reductions in Layer 1 publishing costs are not necessarily passed to users in exactly the same way.

Nevertheless, blobs changed one of the most important cost components in Ethereum’s Layer 2 architecture.

Blob Storage, Availability and Security

Temporary storage sometimes creates confusion about the security model of blob transactions. A blob disappearing from the protocol’s required storage period does not mean the rollup suddenly loses its current state.

The purpose of Ethereum’s data-availability requirement is to ensure that the relevant data is accessible when participants need it to independently verify what happened. Once sufficient time has passed, historical blob data does not have to remain permanently stored by every Ethereum node.

Applications, rollup operators, block explorers, archival services and other participants can preserve blob data for longer if historical access is useful. The difference is that Ethereum’s protocol does not require every node to retain that bulk data forever.

This design helps prevent Ethereum’s permanent storage requirements from growing at the same rate as all Layer 2 transaction data. That consideration becomes increasingly important if rollups eventually process thousands or tens of thousands of transactions for every transaction executed directly on Layer 1.

Blob transactions therefore represent a deliberate trade-off between permanent storage and verifiable data availability. Ethereum provides the data when it is operationally important, while avoiding an indefinite protocol-level storage obligation for every blob.

From Proto-Danksharding to Ethereum’s Data Scaling Roadmap

EIP-4844 is called Proto-Danksharding because it introduced several components required for Ethereum’s broader data-scaling architecture without implementing the original vision of full Danksharding at once.

Blob transactions established a new transaction format, KZG commitments, blob fee accounting and a dedicated data-availability resource. These components gave rollups an immediate scaling benefit while preparing Ethereum for further improvements.

A particularly important direction is PeerDAS, or Peer Data Availability Sampling. The general objective of data availability sampling is to allow nodes to verify that blockchain data is available without requiring every participant to download every piece of that data. This can make it possible to support substantially more blob capacity while limiting bandwidth requirements for individual nodes.

The long-term significance of blob transactions is therefore larger than the initial reduction in Layer 2 fees after Dencun. They represent a change in how Ethereum treats computation and bulk data as separate resources.

Ethereum Layer 1 remains responsible for settlement, consensus and security, while rollups perform much of the transaction execution. Blobs provide the specialised data-availability layer needed to connect those systems efficiently.

As Layer 2 activity grows, demand for Ethereum is increasingly measured not only in conventional gas but also in blob space. Blob transactions have consequently become a core part of Ethereum’s scaling architecture, giving rollups a purpose-built method for publishing transaction data without requiring every byte to occupy permanent Layer 1 history.