Blob Transactions

What are Blob Transactions?

Blob transactions represent a fundamental innovation in how blockchains handle data availability for scaling solutions, introduced through Ethereum’s EIP-4844 upgrade, commonly known as proto-danksharding. This upgrade created a new transaction type that can carry large binary data attachments called blobs, specifically designed to provide cheap data availability for rollups and other Layer 2 systems. Unlike regular transaction data that lives in calldata and persists forever, blobs occupy a separate data space with its own fee market and temporary storage model.

The significance of blob transactions lies in their recognition that rollups have fundamentally different data requirements than regular blockchain transactions. Rollups need to publish transaction data so that anyone can reconstruct their state and verify correctness, but this data only needs to remain available long enough for fraud proofs to be submitted or for users to sync and exit. By creating a dedicated space for this ephemeral data with appropriate pricing and storage policies, blob transactions dramatically reduce the cost of operating rollups while preserving their security guarantees.

Proto-danksharding derives its name from being the first step toward full danksharding, a more ambitious data availability design named after researcher Dankrad Feist. While full danksharding will incorporate data availability sampling and dramatically higher data capacity, proto-danksharding establishes the foundational transaction format and fee market mechanics. This incremental approach allows the ecosystem to adapt to blob transactions and develop tooling before the more complex sampling mechanisms arrive.

How Blobs Work

Each blob transaction can carry multiple blobs, with each blob containing approximately 128 kilobytes of data. The blobs themselves do not enter the execution layer or become accessible to smart contracts directly. Instead, only cryptographic commitments to the blob data appear in the execution environment, while the actual data propagates through the consensus layer. This separation keeps the execution layer lean while ensuring the data reaches all validators who need to verify its availability.

The cryptographic foundation of blobs relies on KZG polynomial commitments, a form of cryptographic commitment that enables efficient verification of data properties. When a blob is created, the data is interpreted as evaluations of a polynomial, and a commitment to that polynomial is computed. This commitment can later be used to verify that specific points in the data are consistent with the original blob, enabling the data availability sampling that will become critical in full danksharding. The KZG scheme requires a trusted setup ceremony, which Ethereum conducted with over 140,000 participants to ensure security.

Blobs follow a pruning schedule that differs fundamentally from regular blockchain data. While normal transaction data and state persist indefinitely, blobs are guaranteed available for only approximately 18 days before nodes may delete them. This temporary availability window provides sufficient time for optimistic rollup challenge periods and for users to sync rollup state, while dramatically reducing long-term storage requirements. The ephemeral nature of blobs allows much higher data throughput without proportionally increasing node storage costs over time.

Blobs for Rollups

Before blob transactions, rollups faced expensive choices for publishing their transaction data. Posting data as calldata required competing in the same fee market as regular transactions, paying for permanent storage of data that only needed temporary availability. During periods of high network activity, calldata costs could spike dramatically, translating directly into higher fees for rollup users. This created a significant bottleneck for rollup scalability and made certain applications economically unviable.

Blob transactions fundamentally change this dynamic by providing dedicated data space optimized for rollup needs. Rollups can now post their compressed transaction data as blobs rather than calldata, paying fees that reflect the actual cost of temporary data availability rather than permanent storage. This targeted pricing has reduced rollup data costs by over 90% in many cases, making transactions that previously cost dollars now cost pennies. The savings flow directly to users, making blockchain applications more accessible.

The security model for rollups remains unchanged with blob transactions. For optimistic rollups, fraud proofs can still reference blob data during the challenge period when the data remains available. For ZK rollups, validity proofs guarantee correct execution regardless of data availability duration, and users only need data available long enough to learn their balances and construct exit transactions. By matching the storage duration to actual security requirements rather than providing unnecessary permanence, blobs achieve efficiency without compromising rollup security.

Blob Economics

Blob transactions operate under a fee market separate from regular transactions, allowing prices to reflect supply and demand for data availability specifically. Each block targets three blobs and can include up to six, creating a dynamic where prices adjust based on usage. When blob usage consistently exceeds the target, a base fee mechanism similar to EIP-1559 increases blob prices. When usage falls below target, prices decrease, creating natural equilibrium around the target capacity.

The separate fee market prevents data availability demand from competing directly with computation demand. Previously, a surge in rollup activity would drive up gas prices for all Ethereum users, even those not interacting with rollups. With dedicated blob space, rollup data costs can spike during periods of high L2 activity without affecting the base gas market. Conversely, high demand for regular transactions no longer creates artificial scarcity for rollup data posting. This separation allows both markets to function more efficiently.

The economic design incentivizes rollups to batch transactions efficiently and compress data aggressively. Since blob space is limited and priced dynamically, rollups that can fit more transactions into fewer blobs gain competitive advantages in user fees. This drives innovation in data compression techniques and transaction batching strategies. The fixed blob size of approximately 128 kilobytes also encourages rollups to right-size their batches, avoiding waste from submitting partially-filled blobs or paying multiple blob fees for marginally larger batches.

Road to Danksharding

Proto-danksharding represents an intermediate step toward full danksharding, which will dramatically expand data availability capacity while maintaining decentralization. The key innovation that danksharding will introduce is data availability sampling, where nodes can verify that data is available by randomly sampling small portions rather than downloading everything. This technique allows the network to support far more data than any individual node could store, with statistical guarantees that the full data is available.

Full danksharding will increase the target from three blobs to potentially 64 or more per block, multiplying the available data throughput for rollups by an order of magnitude. This expansion becomes possible because data availability sampling removes the requirement for each node to download and store all blob data. Nodes will instead participate in a distributed sampling protocol, collectively ensuring availability while individually handling only a fraction of the total data. The mathematical properties of erasure coding guarantee that the full data can be reconstructed if any sufficient subset remains available.

The transition to full danksharding requires additional research and engineering work beyond proto-danksharding. Peer-to-peer networking protocols must efficiently distribute blob data and sampling queries across the network. The erasure coding and KZG commitment infrastructure established by EIP-4844 will extend to support the sampling use case. Proposer-builder separation, another component of Ethereum’s roadmap, may become more important as the value of building blocks with optimal blob inclusion increases. The roadmap envisions a future where the base layer serves primarily as a secure data availability foundation for a diverse ecosystem of rollups, with proto-danksharding proving the core concepts before full deployment.