Blob Transaction (EIP-4844)

What Is a Blob Transaction?

A blob transaction is a new Ethereum transaction type that carries large chunks of data called "blobs" alongside the transaction itself. Introduced by EIP-4844, also known as Proto-Danksharding, this transaction format was activated on March 13, 2024 through the Dencun hard fork (combining the Cancun execution layer upgrade and Deneb consensus layer upgrade).

The primary motivation was cost: rollups need to publish transaction data to Ethereum's Layer 1 for security guarantees, but storing that data as calldata was expensive. Before EIP-4844, Layer 2 networks collectively spent approximately $34 million per month on calldata fees. Blob transactions introduced a dedicated, cheaper channel for this data, with a separate fee market that reflects the true cost of temporary data availability rather than permanent on-chain storage.

EIP-4844 is the first step toward full Danksharding, a long-term Ethereum roadmap item that aims to massively scale data availability. "Proto" in Proto-Danksharding signals that this is the scaffolding: it introduces the transaction format, the fee market, and the cryptographic primitives that full Danksharding will later expand.

How It Works

Blob transactions are designated as Type 3 transactions (transaction type 0x03). They function like regular Ethereum transactions (they can transfer ETH, call contracts, and pay gas) but carry additional blob data as a sidecar. The blobs travel on the consensus layer, not the execution layer, which is why they avoid competing for regular block gas.

1. A rollup sequencer batches user transactions and compresses them into one or more blobs
2. The sequencer creates a Type 3 transaction referencing the blobs via versioned hashes (32 bytes each)
3. The transaction is broadcast to the network with the blobs attached as a sidecar
4. Validators verify the KZG commitments, confirming blob integrity without processing the blob contents
5. The transaction is included in a block; the versioned hashes are stored on-chain permanently, but the blob data itself lives only on the consensus layer
6. After approximately 4,096 epochs (about 18 days), consensus clients prune the blob data

Blob Specifications

Each blob consists of 4,096 field elements of 32 bytes each, totaling 131,072 bytes (approximately 128 KB). Each blob costs 131,072 blob gas (2^17). The network originally launched with a target of 3 blobs per block and a maximum of 6. With the Pectra upgrade (EIP-7691, activated May 7, 2025), the target was raised to 6 blobs per block and the maximum to 9, roughly doubling daily blob capacity from 5.5 GB to 8.15 GB.

KZG Commitments

Blobs are verified using KZG (Kate-Zaverucha-Goldberg) polynomial commitments, a cryptographic scheme that allows anyone to verify properties of the blob data without downloading all of it. Each blob is represented as a polynomial, and the KZG commitment (48 bytes) acts as a compact fingerprint. On-chain, the commitment appears as a versioned hash: a 32-byte value prefixed with the version byte 0x01.

EIP-4844 also introduced a point evaluation precompile (at address 0x0A) that verifies KZG proofs on-chain. This precompile costs 50,000 gas and confirms that a blob evaluates to a specific value at a given point. KZG commitments are foundational for the future: they enable data availability sampling, where nodes can verify blob availability by checking small random samples rather than downloading entire blobs.

The Blob Fee Market

Blob transactions operate under a fee market completely separate from EIP-1559's regular gas market. The blob base fee adjusts using an exponential mechanism similar in spirit to EIP-1559 but with its own parameters:

• If blobs in a block exceed the target: the blob base fee increases (approximately 12.5% per full block under original parameters, approximately 8.2% post-Pectra)
• If blobs in a block fall below the target: the blob base fee decreases
• The minimum blob base fee is 1 wei, allowing near-zero cost during low-demand periods

The network tracks an excess_blob_gas value that carries between blocks, analogous to how EIP-1559 uses excess gas to adjust the base fee. This means blob pricing fluctuates independently from regular transaction fees: a congested execution layer does not make blobs more expensive, and heavy blob usage does not increase regular gas costs.

Cost Savings for Rollups

The financial impact has been substantial. In the first year after activation, blob transactions cost L2s approximately $8 million total in blob fees and associated EIP-1559 fees, compared to roughly $34 million per month under the old calldata model. This represents an approximately 90% reduction in data posting costs.

These savings flow directly to end users. Transaction fees on major Layer 2 networks like Optimism, Arbitrum, and Base dropped dramatically after Dencun. For rollups, the cost of posting a batch of transactions went from dollars to fractions of a cent during low-demand periods, since the blob base fee can drop to its 1-wei minimum.

Use Cases

Rollup Data Availability

The primary use case is providing data availability for rollups. Both optimistic rollups and ZK-rollups need to publish transaction data to Layer 1 so that anyone can independently verify state transitions or submit fraud proofs. Blobs provide this data channel at a fraction of the former cost.

All major Ethereum rollups have adopted blob transactions: Arbitrum One, Optimism, Base, Starknet, zkSync Era, Linea, and Scroll. Each switched their data posting strategy from calldata to blobs shortly after Dencun.

Data Availability for Future Applications

While rollups are the current consumers, the blob format is designed to support any application needing temporary large-data availability on Ethereum. Potential future uses include publishing data for validiums, data availability committees, and cross-chain messaging protocols that need proof of data publication.

How Bitcoin Approaches Data Availability Differently

Ethereum and Bitcoin take fundamentally different approaches to Layer 2 data availability. Where Ethereum created a dedicated blob layer with its own fee market and cryptographic verification scheme, Bitcoin relies on simpler mechanisms rooted in its UTXO model.

Bitcoin Layer 2 solutions like Lightning, Spark, and sidechains typically use compact on-chain commitments rather than publishing full transaction batches to the base layer. Lightning channels settle with a single transaction regardless of how many payments occurred off-chain. Spark uses statechains and FROST threshold signatures to transfer ownership of virtual UTXOs without broadcasting intermediate states. These designs avoid the data availability problem entirely by minimizing the data footprint on the base layer, which aligns with Bitcoin's more conservative approach to block size.

For a deeper comparison of how different Bitcoin Layer 2 architectures handle scaling and data availability, see the Bitcoin Layer 2 comparison.

Risks and Considerations

Temporary Data Availability

Blob data is pruned after approximately 18 days. Any system that relies on blob data being available must complete its verification within that window. For optimistic rollups, this means fraud proofs must be submitted within the pruning period. If the challenge window exceeds the blob retention period, the rollup needs an alternative data retrieval strategy (such as archival services or data availability committees).

Blob Fee Volatility

The separate blob fee market can experience its own congestion spikes. Since the fee adjusts exponentially relative to the target, bursts of demand can cause rapid price increases. During high-demand periods, blob fees have spiked significantly before settling back down. Rollups must implement fee estimation strategies specific to the blob market.

Centralization Pressures

Larger blobs (and more of them per block) increase bandwidth and storage requirements for validators. While the 18-day pruning window limits storage growth, the bandwidth needed to propagate blobs during their active window is substantial. As the network moves toward full Danksharding with potentially 48 or more blobs per block, node operators will need increasingly capable infrastructure.

Blob Space Competition

With a limited number of blob slots per block, rollups compete for space. During congested periods, smaller rollups may be priced out by larger ones willing to pay higher blob fees. This mirrors the regular gas market but operates on a different scale and timeline.

EIP-4844 Transaction Structure

A Type 3 transaction includes all standard EIP-1559 fields plus additional blob-specific fields:

// Type 3 (Blob) transaction fields
{
  // Standard EIP-1559 fields
  chainId,
  nonce,
  maxPriorityFeePerGas,
  maxFeePerGas,
  gasLimit,
  to,
  value,
  data,
  accessList,

  // Blob-specific fields
  maxFeePerBlobGas,     // max price per blob gas unit
  blobVersionedHashes,  // list of versioned hashes (one per blob)

  // Sidecar (not in signed tx, propagated separately)
  blobs,                // the actual blob data
  commitments,          // KZG commitments (48 bytes each)
  proofs                // KZG proofs for verification
}

The maxFeePerBlobGas field lets the sender set a ceiling on what they are willing to pay for blob inclusion, similar to how maxFeePerGas works for regular gas. The sidecar (blobs, commitments, proofs) is propagated alongside the transaction but is not included in the signed transaction hash, which only references the versioned hashes.

Future: Full Danksharding

EIP-4844 is explicitly designed as a stepping stone. Full Danksharding aims to increase the number of blobs per block from single digits to 64 or more, while introducing data availability sampling (DAS). With DAS, validators will not need to download all blob data: instead, they will sample random chunks and use KZG proofs to verify completeness. This would allow Ethereum to scale data availability to megabytes per block without proportionally increasing node requirements.

The Pectra upgrade in May 2025 already moved the target from 3 to 6 blobs per block. The next planned upgrade, Fusaka, may further increase this toward 48 blobs per block, though final parameters are not yet confirmed.

This glossary entry is for informational purposes only and does not constitute financial or investment advice. Always do your own research before using any protocol or technology.