Blob Sidecar

A Blob Sidecar is a dedicated data packet attached to an Ethereum beacon block that carries blob-carrying transactions from rollups. Unlike traditional calldata, which is stored permanently on-chain, blob data is stored off-chain by the network for approximately 18 days (4096 epochs) before being pruned. This temporary storage model, facilitated by EIP-4844 (Proto-Danksharding), provides a high-bandwidth, low-cost data availability layer for Layer 2 solutions like Optimism and Arbitrum, decoupling data storage costs from execution costs.

The architecture separates the blob data from the block's execution payload. A beacon block contains only a small commitment to the blob data, while the full blob is broadcast and stored separately by nodes in a blob sidecar. This design ensures that execution clients do not need to process the large blob data, maintaining block validation speed. The data is made available through a peer-to-peer network and can be sampled for availability using Data Availability Sampling (DAS), a precursor to full Danksharding.

For developers and users, the primary impact is dramatically reduced transaction fees on Layer 2 networks. By submitting data via blobs instead of expensive calldata, rollups can pass on savings of 10x or more. The system uses a new transaction type and gas market for blobs, with fees determined by a separate EIP-1559-style mechanism. Validators are responsible for ensuring the availability of blob data during the storage window, after which the data can be safely discarded as its purpose for ensuring rollup security has been fulfilled.

A blob sidecar is a separate, temporary data packet attached to an Ethereum block that carries large batches of transaction data for layer-2 rollups, decoupling this data from the main block's execution to dramatically reduce costs. Introduced by EIP-4844 (Proto-Danksharding), this mechanism creates a new transaction type, the blob-carrying transaction, which posts a commitment to the data in the main block body while the actual blob data is transmitted and stored in the parallel sidecar. This separation is key: the execution layer only processes a small, fixed-size KZG commitment, while the consensus layer and full nodes are responsible for propagating and temporarily storing the much larger blob data itself, typically for about 18 days.

The workflow begins when a rollup sequencer bundles hundreds of transactions and posts them to Ethereum. Instead of using expensive calldata, it sends a blob-carrying transaction. The block builder includes the transaction in a block and attaches the corresponding blob sidecar. Network nodes validate the blob's data against its KZG commitment to ensure correctness. Critically, blob data is not accessible to the Ethereum Virtual Machine (EVM); it can only be referenced by its commitment. This design means execution clients do not need to store blobs long-term, significantly reducing their hardware requirements and keeping block validation times low, even as blob data scales into megabytes.

After validation, blob data enters a peer-to-peer network separate from the main block gossip network, where it is propagated among consensus clients. Full nodes and consensus nodes store blobs in a blob storage cache for a short data availability window, currently set to 4096 epochs (approximately 18 days). After this period, the data is pruned, as its long-term availability is ensured by the rollups themselves or data availability committees. This temporary storage model is the cornerstone of proto-danksharding, providing strong data availability guarantees for rollups at a fraction of the historical cost, paving the way for the full danksharding upgrade where the network will be able to handle many blobs per block.

The Blob Sidecar is a portmanteau of two distinct concepts: blob and sidecar. The term blob is a common computing term for a 'Binary Large OBject,' referring to a large, unstructured chunk of data. In Ethereum's context, it specifically denotes the large, temporary data packets introduced by EIP-4844 (Proto-Danksharding). The term sidecar is borrowed from distributed systems architecture, where a sidecar process or container runs alongside a primary application to provide supplementary functionality without modifying the core. Here, it signifies that this blob data is transmitted and validated alongside the main blockchain block but is not a permanent part of the core block data structure.

The architectural choice of a sidecar was driven by the need for data availability without state bloat. By separating the large blob data from the block's permanent execution payload, the core Ethereum Virtual Machine (EVM) does not need to process or store this data indefinitely. This design is a precursor to full Danksharding, where the sidecar model will be expanded to manage data from many blobs across a distributed network of validators. The terminology thus reflects a transitional, modular approach to scaling.

The 'blob' component emphasizes the data's role: it is a carrier for layer 2 rollup transaction data (like Optimism and Arbitrum proofs), which needs to be available for a short period for verification but does not require costly, perpetual on-chain storage. The etymology underscores a key innovation: enabling cheaper data availability by making storage temporary (approximately 18 days) and separating it from consensus-critical state. This lexical precision helps developers distinguish blob data from calldata, the previous, more expensive method for L2 data posting.