Data Blob

Blobs provide a low-cost data availability layer for rollups by storing transaction data off-chain for a short period (≈18 days). This is significantly cheaper than storing the same data permanently as calldata on the Ethereum mainnet, reducing transaction fees for end-users.

• Mechanism: Data is posted to the Beacon Chain consensus layer, not execution.
• Key Benefit: Enables high-throughput, low-cost rollup transactions.

Unlike permanent on-chain storage, data blobs are designed to be pruned after approximately 18 days. This temporary model is viable because:

• Rollups only need the data available long enough for fraud or validity proofs to be submitted.
• Data availability sampling by nodes verifies the data's existence during this window.
• Historical data can be stored by third-party services (e.g., blob explorers, block explorers) for archival purposes.

Data blobs were introduced to Ethereum via EIP-4844, also known as Proto-Danksharding. This upgrade created a new transaction type that carries these blobs.

• Blob-Carrying Transaction: A transaction with attached blob data.
• Blob Gas Market: A separate fee market for blob space, decoupled from standard execution gas.
• Foundation for Danksharding: Serves as the foundational architecture for the full Danksharding scaling roadmap.

Blobs are a key part of Ethereum's post-Merge architecture, cleanly separating data availability from execution.

• Consensus Layer (Beacon Chain): Validators attest to the availability of blob data.
• Execution Layer: Processes transactions but does not permanently store blob data.
• Result: This separation allows the execution layer to scale efficiently while the consensus layer provides secure data guarantees.

The primary purpose of data blobs is to scale Layer 2 rollups (Optimistic and ZK). They solve the data availability problem—ensuring anyone can verify the rollup's state is correct.

• Optimistic Rollups: Require available data to submit fraud proofs during the challenge window.
• ZK-Rollups: Require available data to reconstruct state and verify proofs.
• Without Blobs: Rollups used expensive mainnet calldata, limiting scalability.

Blob transactions consume a new resource called blob gas, which has its own independent fee market. This prevents competition between blob data and standard EVM transactions.

• Target & Limit: The network targets 3 blobs per block with a maximum of 6.
• Dynamic Pricing: Blob gas price adjusts via an EIP-1559-style mechanism based on demand for blob space.
• Fee Burning: Base fees for blob gas are burned, similar to EIP-1559.

Rollups use data blobs as their primary data availability (DA) layer. Instead of posting compressed transaction data as expensive calldata on Ethereum, they post it to a blob. This drastically reduces the cost for users while maintaining Ethereum's security guarantees. The sequencer publishes a blob commitment (a KZG polynomial commitment) to the L1, which validators can use to verify data availability and for fraud/validity proofs.

The primary user-facing impact is a dramatic reduction in L2 transaction fees. By moving data posting from calldata (~16-68 gas per byte) to blobs (~1 gas per byte estimated), the cost of settling data on Ethereum is reduced by ~10-100x. This makes L2s like Optimism, Arbitrum, Base, and zkSync Era significantly cheaper for end-users.

Blob supply and demand are managed by a dedicated blob gas market. The protocol targets 3 blobs per block, with a blob base fee that adjusts via an EIP-1559-style mechanism. During periods of high demand (e.g., NFT mints, airdrops), blob gas prices can spike, but the separate market prevents congestion from spilling over into the main execution gas market.

Proto-danksharding is a stepping stone to full danksharding. The future vision expands the blob capacity from ~0.375 MB per block to ~16-32 MB by distributing data across a committee of validators. This will further scale data availability, enabling hundreds of rollups and reducing costs toward the goal of $0.01 transactions.

A Data Blob (or Blob) is a large, temporary packet of transaction data published to a consensus layer (like Ethereum) but not processed by its execution engine. Its primary purpose is to provide data availability for Layer 2 rollups, allowing them to prove the integrity of their state transitions without incurring the high cost of permanent on-chain storage. This separation of data publication from execution is the foundation of proto-danksharding (EIP-4844).

Blobs are stored in the Beacon Chain consensus layer for a short, fixed period (currently 18 days on Ethereum). They are referenced in a block via blob-carrying transactions which include blob versioned hashes. The data itself is not accessible to the EVM; only commitments (KZG commitments) and hashes are. This design ensures verifiers (like Layer 2 nodes) can download and check the data's availability during the storage window, which is sufficient for fraud or validity proofs.

EIP-4844 introduced Data Blobs to Ethereum, implementing a precursor to full danksharding. Key specifications include:

• Blob Size: Each blob is ~128 KB.
• Target per Block: 3 blobs, with a maximum of 6.
• Storage: Temporary, with automatic pruning after the blob data availability window.
• Fee Market: A separate blob gas market decouples blob pricing from regular transaction gas fees, making L2 costs more predictable and stable.

Blobs provide critical infrastructure for optimistic rollups and zk-rollups:

• Cost Reduction: L2s publish data for ~10-100x less cost than calldata.
• Security Maintenance: Data remains available for the full challenge window of optimistic rollups, ensuring security guarantees are upheld.
• Throughput Enablement: By providing cheap, dedicated data bandwidth, blobs allow L2s to scale transaction throughput without compromising on decentralization or security.

In the future, full danksharding will rely on Data Availability Sampling. Light nodes or validators will be able to verify blob availability by randomly sampling small portions of the data. If a blob is available, a few samples are sufficient for high confidence. If it's withheld, sampling will detect its absence. This allows the network to securely scale blob capacity without requiring any single node to download all data.

• Data Availability Committee (DAC): A trusted alternative used by some L2s, where a committee signs off on data availability.
• Celestia: A modular blockchain network specialized as a data availability layer.
• KZG Commitments: Cryptographic commitments used to create compact proofs for blob data.
• Blob Gas: The resource unit for publishing blobs, with its own pricing mechanism.
• Data Availability Proof: A proof that specific data was published and is retrievable.

The Ethereum Improvement Proposal that introduced blob-carrying transactions. It defines the format for data blobs as a new transaction type, creating a separate fee market for data and laying the groundwork for full Danksharding. Key features include:

• Blob Gas: A separate gas mechanism for blob data, decoupled from execution gas.
• Blob Sidecar: The blob data attached to a transaction but stored separately from the main execution payload.
• Beacon Chain: Blobs are committed to and validated by the Beacon Chain consensus layer.

A Layer 2 (L2) scaling solution that executes transactions off-chain and posts compressed data to a Layer 1 (L1) for security. Data blobs are the primary mechanism for this data posting post-EIP-4844.

• Optimistic Rollups: Post transaction data (as blobs) and assume validity, with a fraud-proof challenge period.
• ZK-Rollups: Post validity proofs along with state differences (as blobs) to finalize batches.
• Data Availability: The security of rollups depends on this data being available for verification, which blobs provide at a lower cost.

The guarantee that the data necessary to verify or reconstruct a blockchain's state is published and accessible to all network participants. Data blobs are engineered specifically to provide high-throughput, low-cost data availability.

• DA Sampling: In full Danksharding, validators will sample small pieces of blobs to verify availability without downloading everything.
• DA Layer: A blockchain layer responsible for ensuring data is published. Ethereum's consensus layer acts as the DA layer for its rollups via blobs.

The traditional, expensive method of posting data on Ethereum by including it in a transaction's execution payload. Data blobs were created as a direct, cheaper alternative.

• Key Difference: Calldata is processed by the Ethereum Virtual Machine (EVM) and stored permanently on the execution layer, incurring high gas costs. Blobs are stored on the consensus layer for a short period (~18 days) and are not accessed by the EVM.
• Cost Reduction: Post-EIP-4844, blobs reduced L2 data posting costs by over 90% compared to calldata.

KZG polynomial commitments (Kate-Zaverucha-Goldberg) are the cryptographic primitive used to commit to the contents of a data blob. They enable efficient verification of blob data without revealing the entire dataset.

• Commitment: A short cryptographic proof (a point on an elliptic curve) that binds to the blob's data.
• Proof of Custody: Allows validators to attest that they hold the blob data by verifying the KZG commitment against a random challenge.
• Data Availability Sampling (DAS): Relies on the properties of KZG commitments to allow light clients to verify data availability.

The future, full implementation of Ethereum's sharding design focused solely on data availability scaling. It expands on EIP-4844 to partition the data blob space across the validator set.

• Blob Count: Aims to support up to 64 blobs per block (≈2 MB each), dramatically increasing throughput.
• Validator Committees: Validators are randomly assigned to small committees responsible for sampling and attesting to the availability of specific blob shards.
• Purpose: To provide massively scalable, cheap data availability for hundreds of rollups, making L2s extremely low-cost.