Blob Size Limit

The blob size limit is a core parameter in Ethereum's EIP-4844 (Proto-Danksharding) that restricts each blob-carrying transaction to a maximum of approximately 128 KB of data, specifically defined as 4096 field elements of 32 bytes each. This limit is not a target but a hard cap enforced by consensus rules, ensuring that the data blobs attached to transactions remain bounded and manageable for network nodes. The primary purpose is to prevent any single transaction from consuming excessive block space or imposing unsustainable data storage burdens on the network before full danksharding is implemented.

Mechanically, the limit is enforced by Ethereum clients, which will reject blocks containing transactions with blobs exceeding the specified size. This constraint works in tandem with other EIP-4844 parameters like the blob gas pricing mechanism and the target per-block blob count to regulate the network's overall data bandwidth. The 128 KB size was chosen as a balance between providing meaningful scale for layer-2 rollups—which use blobs for cheap, temporary data availability—and maintaining the practical operational limits of nodes that must temporarily store and propagate this data.

For developers and users, the blob size limit directly impacts how data is batched and submitted from layer-2 networks to Ethereum. Rollup sequencers must structure their calldata or state diffs into chunks that fit within this constraint. Exceeding the limit requires splitting data across multiple blob transactions, which incurs additional gas costs. Understanding this limit is crucial for optimizing data submission strategies and cost calculations in the post-EIP-4844 ecosystem.

The blob size limit is a protocol-enforced constraint that restricts each blob-carrying transaction to a maximum of approximately 128 KB of data, specifically 131,072 bytes. This limit is not a simple size check but is enforced through a dedicated gas pricing mechanism for data. Each blob consumes a fixed amount of blob gas, and the total blob gas per block is capped, creating a separate, secondary block size limit specifically for this new type of data. This design prevents blob data from competing with or congesting the gas market for standard Ethereum execution.

The enforcement occurs in two primary layers. First, consensus clients validate that the total blob gas consumed by all transactions in a proposed block does not exceed the per-block limit, which is a target of 3 blobs (or 384 KB) with a maximum of 6 blobs (768 KB). Second, execution clients verify that each individual transaction's blob data, when encoded, does not surpass the 131,072-byte hard cap. This layered validation ensures the network consensus rules are upheld and that the data is available for data availability sampling by Layer 2 rollups and other clients.

The limit is intrinsically linked to the KZG commitment scheme used in EIP-4844. Each blob is a vector of 4096 field elements, with each element representing 32 bytes, resulting in the 128 KB total. The commitment to this data is a single KZG polynomial commitment, which is small and efficient to verify. The size limit ensures the polynomial operations required for commitment and proof generation remain computationally feasible for the network, maintaining the scalability benefits of the design.

Adjusting the blob size limit is a governance decision requiring a network upgrade. Parameters like the max blobs per block (6) and the field elements per blob (4096) are defined as constants in the Ethereum protocol specification. Future upgrades, such as full danksharding, are designed to increase this limit significantly—potentially to 16 MB or more per blob—by scaling the number of data samples validators must check rather than requiring them to download the entire dataset.

The blob size limit in EIP-4844, also known as Proto-Danksharding, is a protocol-enforced maximum of 128 KB per individual blob-carrying transaction. This limit is a critical parameter that balances the goals of scaling Ethereum's data availability for Layer 2 rollups with the practical constraints of network propagation and storage. Each blob is a dedicated data packet attached to a transaction, stored separately from the main execution chain and subject to a short pruning period. The 128 KB cap ensures that these large data packets can be efficiently broadcast across the peer-to-peer network without causing excessive latency or overwhelming individual nodes, acting as a safeguard during the initial phase of Ethereum's sharding roadmap.

This limit is enforced through consensus rules and gas economics. The BlobTransaction network wrapper and the execution layer's ExecutionPayload contain a maximum of six blobs per block in the initial specification, creating a theoretical per-block data availability limit of 768 KB. The gas cost for a blob, defined by the blob_gasprice mechanism, is independent of execution gas and is designed to dynamically adjust based on demand for blob space. This two-dimensional fee market prevents congestion in blob data from spilling over and affecting the gas fees for standard Ethereum transactions, ensuring that the core network's performance remains stable even as blob usage fluctuates.

The choice of 128 KB is a deliberate stepping stone. It provides a substantial increase in cheap data availability for rollups—each blob can hold roughly the equivalent of ~4 full blocks of calldata—while remaining manageable for the existing network. All consensus nodes (validators) are required to download and validate blob data for a short window (currently ~18 days), after which the data can be pruned. This model, known as data availability sampling (DAS), is foundational for the future full Danksharding implementation, where the blob count per block will scale massively and validators will only sample small portions of the total data, relying on the security provided by the size limit and erasure coding.