Blob-Carrying Transaction

A blob-carrying transaction is a standard Ethereum transaction that includes one or more data blobs as a new transaction field. Each blob is a ~128 KB packet of data. The key innovation is that blob data is not stored in the EVM's state or calldata long-term. Instead, it is posted to the Beacon Chain consensus layer, where it is made available for a short period (currently ~18 days) before being pruned, significantly reducing the permanent storage burden on the network.

The primary purpose of blob-carrying transactions is to serve as a cost-effective data availability layer for Optimistic and ZK Rollups. Instead of posting their transaction data (calldata) directly to Ethereum mainnet, rollups post compressed data into blobs. This separates the cost of data availability from execution, allowing Layer 2s to batch thousands of transactions into a single, inexpensive blob, dramatically reducing fees for end-users.

Blobs have a separate fee market from standard Ethereum gas, governed by its own version of EIP-1559. This creates two parallel auction markets:

• Gas for execution and storage.
• Blob gas for data availability. This separation prevents competition between Layer 2 data posting and regular user transactions, making blob fees more predictable and stable. Excess blob gas fees are burned, similar to base fee burns on mainnet.

Blobs are designed to be compatible with future Danksharding. In this fully scaled vision, validators and users will use Data Availability Sampling (DAS) to probabilistically verify the availability of blob data without downloading it entirely. Blob-carrying transactions establish the format and propagation rules needed for this system, where nodes sample small, random chunks of each blob to ensure the data is published and can be reconstructed.

Each blob is cryptographically committed to using KZG (Kate-Zaverucha-Goldberg) polynomial commitments. The transaction includes the KZG commitment and proof, not the full blob data, in the execution layer. This allows the consensus layer to efficiently verify that the provided blob data matches the commitment. This scheme is essential for enabling light clients and future scaling techniques to trustlessly verify data availability.

Blob data is not stored permanently on the Beacon Chain. After the blob data availability window (currently 4096 epochs, ~18 days), the data is pruned and becomes unavailable from consensus nodes. This is acceptable because rollups only need the data to be available long enough for fraud proofs or state commitments to be settled. Long-term data storage is the responsibility of Layer 2s, block explorers, and data availability committees.

A blob-carrying transaction bundles two key components:

• Execution Payload: Standard transaction data (sender, recipient, calldata) processed by the EVM and stored permanently.
• Blob Data: Large, off-chain data (up to ~128 KB per blob) referenced by a commitment in the transaction. This data is posted to the consensus layer and is only guaranteed to be available for a short retention period (e.g., 18 days in Ethereum's EIP-4844).

The primary security guarantee is that blob data is made available for network participants to download and verify. This is enforced by consensus-layer validators who attest to the availability of the data referenced by the KZG commitment. Data availability sampling (DAS) allows light clients to probabilistically verify this availability without downloading the entire blob, forming the foundation for secure Layer 2 scaling.

Blobs are priced via a separate blob gas market, distinct from EVM execution gas, making data posting orders of magnitude cheaper than calldata. Their data is not stored long-term by Ethereum execution clients, reducing node storage burdens. After the retention period, nodes prune blob data, relying on the assumption that users and rollups have stored what they need.

Blob-carrying transactions are the intended data solution for optimistic rollups and ZK-rollups. Instead of posting expensive transaction data as calldata, rollups post compressed batch data as blobs. This drastically reduces Layer 1 costs while maintaining the security guarantee that the data is available for fraud proofs or state reconstruction.

Each blob is accompanied by a KZG commitment, a polynomial commitment that acts as a succinct cryptographic fingerprint. This allows for:

• Efficient verification that the downloaded blob data matches the commitment.
• Construction of proofs of possession, ensuring the blob carrier actually possesses the data.
• Enabling future upgrades like proto-danksharding where the commitment can be used to reconstruct missing data shards.

A data blob is the core payload of a blob-carrying transaction. It is a large (≤128 KB) piece of data with specific properties:

• Commitment: The blob's data is committed to via a KZG polynomial commitment.
• Temporary Storage: Blobs are stored by consensus nodes for ~18 days (4096 epochs) before being pruned.
• Gas Efficiency: Blob data is priced separately from regular calldata using a blob gas market, making it significantly cheaper for bulk data.

A separate fee market introduced by EIP-4844 to price data blobs independently from standard execution gas. Key mechanics include:

• Target & Limit: The network targets 3 blobs per block with a maximum of 6.
• EIP-1559-style Pricing: Blob gas fees adjust based on network demand for blob space.
• Decoupled Pricing: This separation prevents competition for block space between execution and data availability, stabilizing L1 gas fees.

KZG (Kate-Zaverucha-Goldberg) polynomial commitments are the cryptographic primitive that enables efficient verification of blob data.

• Commitment: A short cryptographic proof (48 bytes) that commits to the blob's contents.
• Proof of Custody: Validators only need to store the commitment, not the full blob, to verify data availability.
• Efficiency: Allows for lightweight data availability sampling (DAS) by Layer 2 rollups and other clients.

Proto-Danksharding (EIP-4844) is the initial, partial implementation of full Danksharding on Ethereum.

• Foundation: It introduces the blob-carrying transaction format and blob gas market.
• Scalability Path: This sets the stage for full Danksharding, where the blob capacity per block will scale to 16 MB+.
• Immediate Benefit: It provides a dedicated, low-cost data layer for rollups today, reducing transaction fees.

A technique where network participants download small, random samples of blob data to probabilistically verify its full availability.

• Light Client Role: Enables light clients and Layer 2 nodes to confirm data is published without downloading entire blobs.
• Security Foundation: DAS is the core security mechanism that will underpin full Danksharding's scalability.
• EIP-4844 Enablement: Blob-carrying transactions provide the data structure required for efficient DAS.

Ethereum Improvement Proposal 4844, also known as Proto-Danksharding, is the upgrade that introduced blob-carrying transactions to mainnet in March 2024.

• Primary Goal: To drastically reduce data publishing costs for Ethereum Layer 2 rollups.
• Key Components: Defines the blob transaction type, blob gas, and KZG commitment scheme.
• Impact: It is the most significant scalability upgrade since The Merge, enabling cheaper L2 fees.