Blob Transaction

A blob transaction is defined by EIP-4844. It introduces a new transaction format containing a blob-carrying field that holds large data chunks. These blobs are posted to the Beacon Chain but are not accessible to the Ethereum Virtual Machine (EVM), making them a data availability layer. The data is automatically pruned after ~18 days, aligning with rollup finality needs while minimizing permanent storage burden.

The primary consumer of blob space is Layer 2 rollups (Optimistic and ZK). Instead of posting their transaction data as expensive calldata on the mainnet, they post it as a blob. This provides the necessary data availability for security while reducing costs by over 90%. Rollups like Arbitrum, Optimism, and Base have integrated blob usage, passing the savings to end-users.

Blobs use a separate blob gas market, distinct from the standard execution gas (EIP-1559). This creates two parallel fee markets:

• Execution Gas: For computation and storage on mainnet.
• Blob Gas: For posting data blobs. This separation prevents competition between L2 data posting and regular user transactions, stabilizing base layer fees. Blob gas prices are highly volatile based on dedicated blob slot demand.

While the EVM cannot read blob data directly, nodes and clients can verify its availability. This is crucial for data availability sampling (DAS), a precursor to full Danksharding. Light clients and validators sample small, random portions of the blob to probabilistically guarantee the entire dataset is published and retrievable, ensuring rollup security without downloading all data.

Ecosystem tooling has evolved to support blobs:

• Execution Clients (e.g., Geth, Nethermind): Process the transaction wrapper and blob hashes.
• Consensus Clients (e.g., Prysm, Lighthouse): Store and propagate blob data on the Beacon Chain.
• Blob Explorers: Tools like Blobscan allow users to search and inspect blob data and associated transactions.
• RPC Methods: New JSON-RPC calls like eth_getBlobSidecars enable data retrieval.

Proto-danksharding (EIP-4844) is a stepping stone to full Danksharding. The current design limits each block to ~6 blobs. The end goal is to scale to 64+ blobs per slot by distributing data across a committee of validators using KZG polynomial commitments and erasure coding. This will increase data availability capacity by orders of magnitude, further reducing L2 costs.

A blob transaction contains two distinct components:

• Execution Payload: The standard transaction data processed by the EVM, containing the to, value, and calldata fields.
• Blob Sidecar: One or more data blobs (each ~128 KB) attached to the transaction but stored separately in the Beacon Chain consensus layer. The execution layer only processes a small 48-byte KZG commitment and versioned hash for each blob.

Blobs are designed for ephemeral storage to prevent state bloat.

• Consensus Storage: Blobs are stored by Beacon Chain validators for a fixed blob retention period (currently 4096 epochs, ~18 days).
• Pruning: After this period, the blob data is deleted. Only the commitments remain in the blockchain history permanently.
• Data Availability: During the retention window, the data is guaranteed to be available for nodes to download and verify, which is critical for Layer 2 security.

Cryptographic proofs ensure blob data is available and correct without downloading it.

• KZG Commitment: A polynomial commitment (a 48-byte BLS12-381 point) that acts as a succinct fingerprint of the blob's data.
• Versioned Hash: A hash of the commitment included in the execution payload, linking the transaction to its blob.
• Proof Verification: Nodes can cryptographically verify that the published blob data matches the commitment using KZG proofs.

EIP-4844 introduced a new fee market to make blob data cheap and separate from standard gas.

• Blob Gas: A separate resource with its own blob gas price, determined by a dedicated blob fee market (similar to EIP-1559).
• Cost Decoupling: Blob gas costs are kept low and stable, decoupled from volatile execution gas fees for EVM computation.
• Target & Limit: The protocol targets 3 blobs per block with a maximum of 6, managing network bandwidth.

Blob transactions are the primary scaling mechanism for Optimistic Rollups and ZK-Rollups.

• Data Publication: Instead of posting expensive transaction data to calldata, rollups post it as cheap blob data.
• Data Availability Sampling (DAS): Light clients and rollup nodes can efficiently sample small pieces of blobs to verify availability.
• Proto-Danksharding: EIP-4844 is the foundational "proto" version of full Danksharding, which will further scale blob capacity.

Processing blob transactions imposes new requirements on node types.

• Execution Client (EL): Handles the execution payload; only sees blob commitments.
• Consensus Client (CL): Manages the blob sidecar data and its availability.
• Full Nodes: Must download and store all blob data during the retention period to serve peers.
• Light Clients: Can use Data Availability Sampling to verify blob availability without downloading full blobs.

Data Availability refers to the guarantee that transaction data is published and accessible for network participants to verify state transitions. For blob transactions, DA is critical because:

• Rollups post their data as blobs, allowing anyone to reconstruct the chain state.
• The beacon chain temporarily stores blob data (for ~18 days), providing strong DA guarantees.
• Data availability sampling (DAS) is a future technique, enabled by danksharding, that allows light nodes to verify data availability without downloading entire blobs.

Blob gas is a separate fee market introduced by EIP-4844, distinct from the existing execution gas used for computation. Its key characteristics are:

• Priced independently via a targeting mechanism that adjusts based on blob space demand.
• Capped per block (initially 3 blobs, target of 2).
• Designed for data, not computation, making costs predictable for rollups.
• Blobs are ephemeral; the gas pays for temporary data availability, not permanent on-chain storage.

KZG Commitments (Kate-Zaverucha-Goldberg) are cryptographic proofs used to commit to the data within a blob. They are essential for blob transactions because they:

• Provide a constant-size proof (a single elliptic curve point) for a large data blob.
• Enable efficient data availability sampling and fraud proofs.
• Allow the consensus layer to verify that a blob's data is available without downloading it entirely.
• Require a trusted setup ceremony (the Ethereum KZG Ceremony) to generate the necessary cryptographic parameters.

A Rollup is a Layer 2 scaling solution that executes transactions off-chain and posts compressed data to Ethereum. Blob transactions are primarily designed for rollups:

• Optimistic Rollups (like Arbitrum, Optimism) post transaction data as blobs to allow for fraud proofs.
• ZK-Rollups (like zkSync, Starknet) post validity proofs and state diffs as blobs.
• By using blobs instead of calldata, rollups achieve ~10-100x cost reduction for their data posting fees, directly lowering transaction costs for end-users.

Danksharding is the full realization of Ethereum's data sharding vision, building upon proto-danksharding (EIP-4844). Its advanced features include:

• Massively increasing blob capacity to ~64 blobs per slot (128 MB).
• Implementing data availability sampling (DAS), where validators sample small pieces of data to confirm availability.
• Proposer-builder separation (PBS) to efficiently handle the large data load.
• Making all blobs available to the entire network, not just a single shard committee, simplifying the design.