Blob Transaction
A type of transaction introduced in Ethereum's EIP-4844, designed to reduce transaction fees by storing data blobs separately from the main transaction data.
Blob transactions, introduced via Ethereum Improvement Proposal (EIP) 4844 (also known as Proto-Danksharding), represent a significant architectural shift aimed at reducing transaction fees, particularly for Layer 2 scaling solutions. Unlike traditional Ethereum transactions that embed data directly within the main transaction calldata, blob transactions utilize a separate, albeit still on-chain, data structure called 'blobs'. These blobs are designed to be cheaper to post and are subject to different gas limits and pricing mechanisms than regular transaction data. The primary motivation is to lower the cost of data availability for rollups. Rollups bundle transactions off-chain and post a compressed summary or proof to the main Ethereum chain (Layer 1). The cost of posting this data to Layer 1 is a major bottleneck. EIP-4844 introduces a new transaction type that allows rollups to post larger amounts of data more cheaply by separating it into these blobs. These blobs are not directly processed by the Ethereum Virtual Machine (EVM) but are instead committed to via a KZG (Kalai-Shen-Goldwasser) polynomial commitment scheme. This commitment is included in the block header, ensuring data availability without requiring every node to download and store the full blob data indefinitely. This separation and specialized handling significantly reduce the gas cost associated with data availability, making rollups more economically viable and thus enhancing Ethereum's overall scalability.
graph LR
Center["Blob Transaction"]:::main
Rel_eip_4844["eip-4844"]:::related -.-> Center
click Rel_eip_4844 "/terms/eip-4844"
Rel_layer_2["layer-2"]:::related -.-> Center
click Rel_layer_2 "/terms/layer-2"
Rel_data_availability["data-availability"]:::related -.-> Center
click Rel_data_availability "/terms/data-availability"
classDef main fill:#7c3aed,stroke:#8b5cf6,stroke-width:2px,color:white,font-weight:bold,rx:5,ry:5;
classDef pre fill:#0f172a,stroke:#3b82f6,color:#94a3b8,rx:5,ry:5;
classDef child fill:#0f172a,stroke:#10b981,color:#94a3b8,rx:5,ry:5;
classDef related fill:#0f172a,stroke:#8b5cf6,stroke-dasharray: 5 5,color:#94a3b8,rx:5,ry:5;
linkStyle default stroke:#4b5563,stroke-width:2px;
🧠 Knowledge Check
🧒 Explain Like I'm 5
Imagine sending a big package (your [transaction](/en/terms/transaction)) where you used to pay a lot to include all the packing paper inside. Blob transactions let you send the packing paper separately and much cheaper, making your overall delivery cost way less.
🤓 Expert Deep Dive
EIP-4844 fundamentally alters Ethereum's data availability strategy by introducing 'blobs' and KZG commitments. Blobs are contiguous chunks of data attached to a block, with a maximum size and a separate gas limit distinct from calldata. Crucially, blobs are not directly accessible by EVM contract logic; their primary purpose is data availability verification. The commitment to blob data is achieved using KZG polynomial commitments, where the blob data represents coefficients of a polynomial, and the commitment is a point on an elliptic curve. This allows for efficient proof generation and verification. Nodes are required to download blob data for a limited period (e.g., ~4096 blocks or ~27 hours) for verification purposes, after which they can prune it, reducing state bloat. The gas cost for posting blobs is significantly lower than calldata, calculated based on blob size and a separate 'blob gas price'. This mechanism is a precursor to full Danksharding, where blobspace will be expanded and distributed across multiple shards. Trade-offs include the complexity of the KZG commitment scheme and the temporary storage requirement for nodes, but the primary benefit is a substantial reduction in rollup data posting costs.