Blob Transaction

Blob transactions are the core feature of Proto-Danksharding, a precursor to full Danksharding. The design introduces:

• A new transaction type with a blob-carrying field.
• A separate blob gas market with its own fee mechanism, decoupled from execution gas.
• A blob storage duration of approximately 18 days, after which nodes can prune the data, as it's only needed for short-term consensus and verification.

Blobs have a dedicated gas market (EIP-1559-style) with a target of 3 blobs per block. Key mechanics include:

• Blob Gas Price: Adjusts based on demand for blob space, independent of execution gas.
• Fee Burning: Base fees for blob gas are burned, applying deflationary pressure to ETH.
• Capacity: Each blob provides ~128 KB of data. The initial target allows for ~0.375 MB of blob data per block, creating a scalable data layer for rollups.

For network participants, blob transactions change operational requirements:

• Execution Clients (e.g., Geth, Nethermind): Process the transaction and hold blob data for a short period (~18 days).
• Consensus Clients: Verify the blob's commitment and availability.
• Data Pruning: After the retention window, nodes can safely delete blob data, minimizing long-term storage bloat while preserving data availability for dispute windows.

Blobs lay the groundwork for full Danksharding, where the network scales to ~16 MB per slot. The future state involves:

• Data Availability Sampling (DAS): Light clients and validators can probabilistically verify data availability by sampling small chunks of blobs.
• KZG Commitments: Each blob is accompanied by a KZG polynomial commitment, allowing for efficient cryptographic proofs of data availability and correctness.

Adoption requires ecosystem tooling, which now includes:

• Client APIs: New RPC methods like eth_blobGasPrice and eth_getBlobSidecars.
• Libraries: SDKs and libraries (e.g., in ethers.js, viem) support constructing and signing blob transactions.
• Indexers & Explorers: Block explorers display blob transactions and their associated data commitments, providing visibility into blob space utilization.

A blob transaction wraps a standard Ethereum transaction with extra components for blob data. The key fields are:

• blob_versioned_hashes: A list of KZG commitments, linking the transaction to its blob data.
• max_fee_per_blob_gas: The maximum fee the sender will pay per unit of blob gas.
• blobs: The actual large data packets (each ~128 KB) attached to the transaction. The blobs themselves are not stored in the execution layer but are posted to the Beacon Chain consensus layer.

Blob data consumption is measured in blob gas, a separate resource from standard execution gas. Its pricing is governed by an EIP-1559-style fee market with a target of 3 blobs per block. Key mechanics:

• Base Fee: Adjusts per block based on blob congestion.
• Priority Fee: An optional tip for validators.
• Blob Gas Limit: Each block has a target of ~0.375 MB and a maximum limit of ~0.75 MB of blob data. This design ensures blob space costs remain predictably low compared to calldata.

Blobs provide data availability (DA) for Layer 2s using cryptographic commitments. The process:

1. The sender generates a KZG commitment (a polynomial commitment) for each blob.
2. This commitment is included in the transaction (blob_versioned_hashes).
3. Validators and Layer 2 nodes can cryptographically verify that the full blob data is available and corresponds to the commitment. This allows for efficient data availability sampling (DAS) by light clients in future upgrades, without requiring them to download the full blob.

Blob data is not stored in the traditional Ethereum execution client. Instead, it is transmitted and stored alongside the block as a blob sidecar. This is a separate data structure that contains:

• The raw blob data.
• Proofs (KZG proofs) for each blob. The sidecar is propagated through the P2P network via a dedicated blob gossip subnetwork. After a short retention period (~18 days), the blob data is pruned, as its cryptographic commitment provides long-term data availability guarantees.

A fundamental design choice is the separation of blob data from the EVM:

• Consensus Layer (Beacon Chain): Stores blob data temporarily and verifies its availability via KZG commitments. This is where the data availability guarantee is enforced.
• Execution Layer (EVM): Only sees the blob versioned hashes. The EVM cannot directly access blob contents via opcodes like BLOBHASH (which returns the commitment hash). This separation keeps execution costs stable and prevents bloating the EVM state with large, transient data.

Data Availability Sampling (DAS) is the core security mechanism that allows light clients and rollups to probabilistically verify that all data within a blob is available without downloading it entirely. This is achieved by:

• Nodes requesting small, random samples of the blob data.
• Using KZG polynomial commitments to prove the correctness of each sample.
• Ensuring that if any data is withheld, a sample request will detect it with high probability. This design is critical for maintaining the data availability guarantee, which underpins the security of Layer 2 rollups.

Blobs are priced with a separate blob gas mechanism, distinct from standard execution gas. Its design includes:

• A target and maximum per-block blob count (target: 3, max: 6 as of EIP-4844).
• An exponential pricing model for blob gas that rapidly increases costs when usage exceeds the target, disincentivizing spam and stabilizing network load.
• This separation prevents congestion in blob data from directly impacting the gas prices for standard EVM transactions, improving predictability.

Blobs are designed for ephemeral data availability, not permanent on-chain storage. Key considerations include:

• Nodes are only required to store blob data for 4096 epochs (~18 days).
• After this period, the data can be pruned, as its availability has been sufficiently verified for rollup fraud or validity proofs.
• Only the small blob commitment (a KZG commitment) and blob hash remain in the beacon chain permanently. This design drastically reduces the long-term state growth burden on consensus nodes compared to storing all data in calldata.

Validators have new responsibilities and face inactivity leak penalties for non-compliance:

• They must make blob data available for the required retention window (~18 days).
• Failure to serve blob data when requested can be penalized, as it breaks the data availability guarantee.
• This ensures the peer-to-peer network reliably propagates and stores blob data, which is essential for the security of light clients and rollups.

For Layer 2 rollups, blob transactions shift security assumptions:

• Rollups now post data to blobs instead of calldata, relying on the chain's data availability guarantee.
• ZK-Rollups must ensure their validity proofs account for the KZG commitments in blobs.
• Optimistic Rollups must ensure their fraud proof window (typically 7 days) is shorter than the blob pruning window (~18 days) to guarantee data is available for challenge.
• Rollup sequencers must manage the new blob gas market and potential congestion.

Implementing blob support adds complexity to Ethereum clients (execution and consensus):

• Requires integration of KZG cryptography libraries for commitment and proof verification.
• New network protocols (e.g., BlobSidecar propagation) must be implemented in the P2P layer.
• Execution clients must handle the new transaction type and interact with the consensus layer for blob data.
• This increases the attack surface and requires rigorous auditing of the new cryptographic and networking code.