Blob Transaction (EIP-4844)
A blob transaction, introduced by EIP-4844 (Proto-Danksharding) and activated on Ethereum in March 2024, is a new transaction type that carries large binary data attachments called blobs alongside regular transaction data, providing a cheap temporary data posting mechanism that dramatically reduces the cost for rollups to publish their transaction data to Ethereum.
Before EIP-4844, rollups posted their transaction data to Ethereum using calldata — a field in regular Ethereum transactions that is relatively expensive because it is stored by Ethereum full nodes indefinitely as part of the permanent transaction record. This cost was the dominant expense for rollup sequencers and was passed on to users as elevated L2 fees, particularly during L1 congestion.
EIP-4844 created a separate data lane. Blob-carrying transactions include one or more blobs — each blob holds approximately 128 kilobytes of data — that are stored by Ethereum nodes only temporarily, for approximately two to three weeks, before being pruned. Because blobs do not need to be available permanently (rollup provers only need data during their challenge or proof window, which is much shorter), they can be priced far below equivalent calldata.
The EIP introduced a separate blob fee market alongside the existing EIP-1559 calldata fee market. Blob fees have their own base fee that adjusts based on blob consumption relative to a target of three blobs per block (with a maximum of six per block). This separation prevents blob demand from driving up regular transaction calldata prices.
The real-world impact of EIP-4844 (activated in the Dencun upgrade in March 2024) was immediate and dramatic. Average transaction fees on Arbitrum, Optimism, Base, and other Ethereum rollups dropped by 90% or more within days of activation, as rollups switched from calldata to blob posting. L2 transaction fees that previously cost tens of cents in gas frequently fell to fractions of a cent.
From a data availability perspective, blobs must be propagated across the peer-to-peer network and stored by beacon nodes for the two- to three-week pruning window. Blobs are committed to using KZG polynomial commitments (named after Kate, Zaverucha, and Goldberg), a cryptographic scheme that enables efficient verification of blob inclusion and integrity. EIP-4844 laid the cryptographic groundwork for full Danksharding by establishing the KZG commitment infrastructure that the complete sharding design will extend.