4844 Blobs

A new transaction type that carries large data packets called blobs (Binary Large Objects). Unlike calldata, blob data is not accessible to the EVM and is stored separately on the consensus layer, making it much cheaper for rollups to post their data.

• Structure: A transaction includes a small reference (a commitment) to the blob data.
• Purpose: Dedicated for high-volume, temporary data storage required by Layer 2s.

Blobs use KZG polynomial commitments (also called Kate commitments) to cryptographically commit to their data. This allows nodes to verify that the data is available and correct without downloading the entire blob.

• Commitment: A small, fixed-size proof attached to the transaction.
• Verification: Light clients and other nodes can perform efficient data availability sampling using these commitments.

Blobs have a separate gas fee market from standard Ethereum transactions, preventing competition and keeping mainnet execution gas prices stable.

• Blob Gas: A new resource type with its own price, determined by demand for blob space.
• Temporary Storage: Blobs are automatically pruned from nodes after approximately 18 days (4096 epochs). This is sufficient for fraud/validity proof windows while minimizing storage burden.

EIP-4844 is the first step towards full Danksharding. It implements the core data structure and verification logic without yet implementing data availability sampling across a distributed network of validators.

• Foundation: Establishes the blob format and transaction framework.
• Forward Compatibility: Designed so that future upgrades can expand the number of blobs per block (from 6 to 64+) and implement full sharding with minimal changes.

The primary beneficiary of blob transactions. Rollups like Optimism, Arbitrum, and zkSync can post their batch transaction data (the calldata) as a blob, reducing their operational costs by over 90%.

• Cost Reduction: Moves the most expensive part of a rollup's operation off the expensive EVM calldata.
• Throughput: Enables rollups to post more data per batch, increasing their effective transaction capacity.

Blobs are a consensus-layer feature. The Beacon Chain is responsible for their consensus, ordering, and the proof-of-custody mechanism that ensures validators actually store the blob data.

• Block Structure: Beacon blocks contain a new field for blob sidecars.
• Validator Duty: Validators must temporarily store and serve blob data for the pruning period, underpinning the network's data availability guarantee.

A blob-carrying transaction is a new Ethereum transaction type that includes:

• A standard Ethereum transaction execution payload.
• One or more blobs (large data packets, ~128 KB each).
• KZG commitments and proofs for each blob, allowing for cryptographic verification of the data without full download. This structure ensures execution clients only process the commitment, keeping blob data off the critical execution path.

Blobs use a separate blob gas mechanism from standard EIP-1559 execution gas.

• Target & Limit: The protocol targets 3 blobs per block with a maximum of 6, creating a distinct fee market.
• Dynamic Pricing: Blob gas price adjusts based on demand for blob space, independent of mainnet congestion for computations.
• Burn Mechanism: Blob base fees are burned, similar to EIP-1559, making the fee reduction deflationary for ETH.

Blobs change data handling requirements for node operators.

• Consensus Nodes: Must store blobs for ~18 days (4096 epochs) to ensure data availability for rollups and challengers.
• Execution Nodes: Only store and process the small KZG commitments, not the full blob data.
• Automatic Pruning: After the retention period, blob data is automatically pruned from consensus nodes, preventing indefinite storage bloat.

While full danksharding is future work, EIP-4844 sets the foundation for Data Availability Sampling (DAS).

• Blob Format: The blob structure is designed to be easily sampled by light clients in the future.
• KZG Commitments: Provide the cryptographic basis for proving data availability without downloading entire blobs.
• Path to Scaling: This is a critical step towards enabling validators to securely confirm data availability with minimal resource requirements.

Blobs have a separate fee market from standard transactions, governed by its own EIP-1559-style mechanism. This creates two parallel gas markets:

• Execution Gas: For computation and storage on the main chain.
• Blob Gas: For posting data to blobs. A blob base fee adjusts dynamically based on blob block usage, burning excess fees. This separation prevents L2 data posting from congesting the primary transaction market.

Validators are compensated for including blobs through priority fees (tips). The blob market introduces new considerations for Maximal Extractable Value (MEV). While blob transaction ordering is less time-sensitive than DeFi arbitrage, validators may prioritize blobs based on fees, influencing L2 sequencing and potential cross-domain MEV opportunities between L1 and L2s.

A core security assumption is that data is only needed for fraud or validity proofs within the ~18-day window. After this, nodes prune blob data. Long-term data availability is delegated to Layer 2s, block explorers, or data availability committees. This shifts the burden of data storage and historical data retrieval off the core protocol, reducing node hardware requirements but creating reliance on external providers for old data.

Blob data is committed to using KZG polynomial commitments (a type of cryptographic commitment scheme). This allows for:

• Efficient verification that data corresponds to the commitment.
• Fraud proofs where a single point of incorrect data can be challenged.
• Data availability proofs via erasure coding. The security relies on the trusted setup of the KZG ceremony, a one-time cryptographic ritual.

Blob gas pricing is designed to accurately charge for a node's cost of bandwidth and temporary storage. The blob gas limit per block (~0.75 MB initially) and the separate fee market prevent spam attacks that could overwhelm network bandwidth. The target blob gas mechanism ensures the fee adjusts to keep blob block usage around 50%, creating predictable long-term costs for L2s.

Proto-Danksharding is the initial, partial implementation of the full Danksharding vision, introduced by EIP-4844. It adds the core data availability layer—blobs—without implementing data availability sampling or a full sharding architecture. This allows Layer 2 rollups to post data more cheaply immediately, paving the way for the full Danksharding upgrade in the future.

• Purpose: A pragmatic, phased approach to scaling.
• Key Feature: Introduces the blob-carrying transaction type.

A blob-carrying transaction is a new EIP-2718 transaction type (Type 3) that includes one or more data blobs in a dedicated field. Unlike calldata, this blob data is not accessible to the Ethereum Virtual Machine (EVM) and is pruned from execution client storage after approximately 18 days.

• Structure: Contains execution payload + attached blob(s).
• EVM Access: Blob data is not readable by smart contracts.
• Fee Market: Uses a separate gas market from standard execution.

KZG Commitments (Kate-Zaverucha-Goldberg) are cryptographic commitments used to create a short proof for a blob of data. In EIP-4844, each blob is accompanied by a KZG commitment, which allows nodes to verify that the blob data is available and correct without downloading the entire blob.

• Function: Provides a binding cryptographic proof of the blob's contents.
• Efficiency: Enables lightweight data availability verification.
• Requirement: Relies on a trusted setup ceremony for the initial parameters.

Data Availability Sampling (DAS) is a technique where light clients randomly sample small pieces of blob data to probabilistically verify its full availability. While not fully implemented in Proto-Danksharding (EIP-4844), the blob architecture is designed to enable DAS in the future full Danksharding upgrade.

• Goal: Allows nodes with minimal resources to trustlessly verify data availability.
• Future State: Core to the security model of full Danksharding.

Blob gas is a separate resource and fee market specifically for the data space in blob-carrying transactions. Its price is determined by a dedicated EIP-1559-style mechanism, independent of standard execution gas. This prevents competition for block space between blob data and regular transactions.

• Separation: Decouples L2 data posting costs from mainnet congestion.
• Target: Aims for ~3 blobs per block (0.375 MB) initially.
• Burn: Blob base fees are burned, similar to EIP-1559.

In EIP-4844, blobs are consensus-layer objects. They are included in Beacon Block proposals by validators and their availability is guaranteed by the consensus client network. Execution clients receive blob data via the Engine API but are not responsible for its long-term storage.

• Storage: Blobs are stored by consensus clients, not execution clients.
• Pruning: Data is pruned after the blob data availability window (~18 days).