Blob Sidecar

What Is a Blob Sidecar?

A blob sidecar is the data structure that carries blob payloads in Ethereum's proto-danksharding system, introduced by EIP-4844 in the Dencun upgrade (March 2024). When a user submits a blob transaction (type 0x03), the actual blob data does not travel inside the transaction itself. Instead, it is packaged into a sidecar: a separate data structure that accompanies the block through the consensus layer.

The term "sidecar" reflects the relationship: the blob data rides alongside the block rather than inside it, much like a motorcycle sidecar carries a passenger separately from the main vehicle. This architectural separation is what makes blob transactions cheaper than using regular calldata: blobs never enter the execution layer, never compete for block gas, and are pruned after a fixed retention window.

The design exists to solve a specific problem: Layer 2 rollups need to post transaction data to Ethereum for security, but storing that data permanently on-chain is expensive and unnecessary. Blob sidecars provide a middle ground: the data is available long enough for anyone to verify it, then discarded to keep node storage manageable.

How It Works

A blob sidecar ties together three components for each blob in a transaction: the raw data, a cryptographic commitment, and a validity proof. Together, these allow the network to verify that the data matches what the transaction references without embedding it in the block.

Sidecar Structure

Each blob sidecar item contains the following fields:

• Index: the position of this blob within the transaction (starting from 0)
• Blob: the raw data payload, exactly 131,072 bytes (128 KiB), composed of 4,096 field elements of 32 bytes each
• KZG commitment: a 48-byte KZG polynomial commitment that cryptographically binds to the blob contents
• KZG proof: a 48-byte proof that the blob data matches its commitment
• Signed block header: a reference to the block that included this blob

On the execution layer side, the transaction itself only contains versioned hashes: 32-byte identifiers derived by hashing each KZG commitment with SHA-256 and prepending a version byte (0x01). This keeps the transaction small while still linking it to its blob data.

Blob Data Encoding

Each blob holds 4,096 field elements, where each element is a 32-byte value that must be less than the BLS12-381 modulus. Because each element can only use 254 of its 256 bits for arbitrary data, the usable capacity per blob is slightly less than 128 KiB. In practice, rollups encode their compressed transaction batches into this format using padding schemes that respect the field element constraint.

// Blob parameters (EIP-4844)
FIELD_ELEMENTS_PER_BLOB  = 4096
BYTES_PER_FIELD_ELEMENT  = 32
BYTES_PER_BLOB           = 131072  // 4096 * 32 = 128 KiB

// KZG versioned hash construction
versioned_hash = 0x01 || sha256(kzg_commitment)[1:]

Propagation and Gossip

Blob sidecars do not travel through the same network path as regular blocks. They are propagated through dedicated gossip subnets on the consensus layer peer-to-peer network. Under the Dencun upgrade, the network used 6 blob sidecar subnets. The Pectra upgrade (May 2025) increased this to 9 subnets, matching the new maximum of 9 blobs per block introduced by EIP-7691.

When a validator proposes a block containing blob transactions, the block itself is broadcast on the standard block gossip topic, while each blob sidecar is broadcast on its assigned subnet. Receiving nodes validate each sidecar by verifying the KZG proof against the commitment and confirming the commitment matches the versioned hash in the corresponding transaction.

Validation Process

Before accepting a blob sidecar, consensus clients perform several checks:

1. Verify the sidecar references a valid block header for the current slot
2. Confirm the blob index is within the allowed range (0 to max blobs minus 1)
3. Run KZG proof verification: the proof must demonstrate that the blob data matches its commitment
4. Check that the KZG commitment hashes to the versioned hash stored in the block's execution payload

If any check fails, the sidecar is rejected and the sending peer may be penalized. This ensures that only valid blob data enters the network.

Retention and Pruning

Unlike regular transaction data that is stored indefinitely, blob sidecars have a finite retention window. The consensus specification sets a minimum retention period of 4,096 epochs, which equals approximately 18 days. After this window, consensus clients prune the blob data from local storage.

This pruning is safe because blob data serves a specific purpose: providing data availability for rollups. Rollup operators and verifiers have 18 days to download and verify the data. Once the challenge period for optimistic rollups has passed (typically 7 days), the blob data is no longer needed for dispute resolution.

Blob Limits and Capacity

The number of blobs allowed per block directly determines how much data throughput the network can handle. These limits have evolved across upgrades:

The target and maximum work together through a blob fee market modeled after EIP-1559. When blob usage exceeds the target, the blob base fee increases exponentially, discouraging excess usage. When usage falls below the target, the fee decreases. This mechanism keeps average blob consumption near the target while allowing short bursts up to the maximum. For a deeper analysis of how blob pricing works, see the EIP-4844 blob fee market research.

Use Cases

Rollup Data Posting

The primary use case for blob sidecars is rollup data availability. Layer 2 rollups like Arbitrum, Optimism, Base, and others batch user transactions off-chain, then post the compressed batch data to Ethereum. Before EIP-4844, this data was posted as calldata, which is stored permanently and competes with regular transactions for block gas.

With blob sidecars, rollups post their batches as blobs instead. The data is available for verification during the retention window but does not permanently inflate Ethereum's state. This has reduced rollup data posting costs significantly: blob transactions operate in a separate blob space fee market, and the base fee is typically a fraction of what equivalent calldata would cost.

Data Availability for Validity Proofs

ZK rollups use blob sidecars to publish the transaction data that corresponds to their validity proofs. While the proof itself verifies correct state transitions, the underlying data must be available so that users can reconstruct the rollup state independently. Blob sidecars provide this availability guarantee at a lower cost than permanent on-chain storage.

Bridge and Oracle Data

Some protocols use blob sidecars to post large datasets to Ethereum temporarily: bridge attestation data, oracle price feeds in bulk, or proof data for cross-chain messaging systems. Any application that needs Ethereum-grade data availability without permanent storage can benefit from blob sidecars.

Relationship to Danksharding

Blob sidecars are part of proto-danksharding, which is a stepping stone toward full danksharding. In the current system, every node downloads and verifies every blob sidecar. Full danksharding will introduce data availability sampling (DAS), where nodes only download small random samples of blob data while still achieving statistical certainty that the full data is available.

When DAS is implemented, the blob sidecar format is expected to evolve. The EIP-7594 specification introduces a cell-based sidecar variant, where each blob is divided into cells that can be individually sampled and verified using cell-level KZG proofs. This will allow the network to support far more blobs per block without requiring each node to download all of them.

Risks and Considerations

Temporary Availability

Blob data is pruned after approximately 18 days. Any application that needs the data beyond this window must archive it independently. Rollup explorers, indexers, and historical data services must maintain their own blob archives. If a dispute arises after the pruning window, the blob data may no longer be recoverable from the Ethereum network directly.

Bandwidth Requirements

Each blob is 128 KiB, and validators must download all blobs in a block to validate it. At the Pectra maximum of 9 blobs per block, this adds up to approximately 1.15 MiB of additional bandwidth per block (every 12 seconds). As blob limits increase in future upgrades, the bandwidth burden on node operators grows proportionally, which may affect decentralization if home node operators cannot keep up.

Storage During Retention

During the 18-day retention window, consensus clients must store all blob sidecars. At full blob utilization with Pectra parameters, this amounts to several hundred gigabytes of additional storage. Node operators need to account for this when provisioning infrastructure.

Sidecar Propagation Latency

Because blob sidecars travel on separate gossip subnets from the block itself, there is a risk of timing mismatches: a node may receive a block before its associated blob sidecars arrive, or vice versa. Consensus clients handle this by buffering and waiting, but under high network load, delayed blob propagation could affect block validation timing and attestation deadlines.

This glossary entry is for informational purposes only and does not constitute financial or investment advice. Always do your own research before using any protocol or technology.