Blob Transactions (EIP-4844)

A blob transaction is a new type of Ethereum transaction that includes large, temporary data packets called blobs. These blobs are stored on the consensus layer (Beacon Chain) for approximately 18 days and are not accessible to the Ethereum Virtual Machine (EVM). The primary purpose is to provide a low-cost data availability layer for Layer 2 rollups like Optimism and Arbitrum, allowing them to post their transaction data (proofs and state commitments) cheaply and securely, which is essential for trust-minimized withdrawals. This mechanism is the core innovation of proto-danksharding, a precursor to full danksharding.

The cost reduction is achieved through a separate fee market. Blob data is priced using a distinct blob gas mechanism, which is independent of the standard execution gas used for smart contract computations. This separation prevents competition between rollup data posting and regular network activity, leading to more stable and predictable costs for L2s. Blobs are large (up to ~128 KB each) and a transaction can carry multiple blobs, but they are pruned after their short storage period, preventing indefinite state bloat on the network.

For developers and users, blob transactions are largely abstracted away. Rollup sequencers construct and submit them, while end-users simply benefit from lower transaction fees on L2s. Node operators must implement new logic to validate and propagate blob data. The data itself is referenced in the transaction via KZG commitments, a form of cryptographic commitment that allows the network to verify the data's availability and correctness without every node needing to store the full blob permanently.

The long-term vision of EIP-4844 is to pave the way for danksharding, a scaling design where the data availability sampling of many blobs will allow Ethereum to process tens of thousands of transactions per second through rollups. By establishing the foundational transaction format, consensus rules, and fee market for blob-carrying transactions, proto-danksharding delivers immediate scaling benefits while building the necessary infrastructure for Ethereum's multi-year scaling roadmap.

The term blob in EIP-4844 is a technical acronym for Binary Large OBject, a concept borrowed from database management systems where it describes a field designed to hold a large, unstructured chunk of binary data. In the context of Ethereum, a blob-carrying transaction is a new transaction type that includes a dedicated data 'blob'—a large, temporary data package attached for the primary purpose of being posted to the consensus layer for Layer 2 rollups. This naming convention was chosen for its descriptive accuracy and its established history in computer science, immediately signaling to developers that this is a distinct, sizable data container.

The choice of 'blob' over more blockchain-native terms like 'calldata' or 'log' was deliberate. While transaction calldata is execution-layer data permanently stored on-chain, blobs are designed for a different lifecycle: they are posted, verified for availability, and then discarded after a short period (approximately 18 days). This ephemeral nature is key to proto-danksharding, the scaling framework EIP-4844 introduces. The term's generic, non-specific quality helped differentiate this new, temporary data structure from Ethereum's existing, permanent state and execution data structures, preventing conceptual confusion.

Historically, the proposal's authors, including Proto Lambda and Dankrad Feist (whose pseudonyms give proto-danksharding its name), needed a simple, memorable term for this new primitive. 'Blob' fit perfectly as it is a short, catchy, and technically accurate descriptor for a 'big lump of bytes.' Its adoption followed a pattern in Ethereum's development culture of using accessible, slightly whimsical names (e.g., 'ghost', 'uncle', 'sharding') for complex cryptographic constructs, making the underlying technology more approachable for developers engaging with Layer 2 scaling solutions and data availability sampling.

A blob transaction is a new Ethereum transaction type, introduced by EIP-4844, that includes a large, temporary data packet called a blob (Binary Large OBject) designed for Layer 2 rollups. Unlike calldata, which is stored permanently on-chain, blob data is stored off-chain by consensus nodes for a short period (approximately 18 days) but its cryptographic commitment is verified on-chain. This separation creates a data availability layer that is orders of magnitude cheaper for rollups to use, dramatically reducing transaction fees for end-users while maintaining Ethereum's security guarantees.

The technical workflow involves several key components. When a rollup submits a transaction, it bundles its batch of L2 transactions into a blob and creates a KZG commitment, a cryptographic proof of the blob's contents. The transaction posted to Ethereum includes this commitment and a small amount of calldata, but not the blob data itself. Validators and full nodes temporarily store the full blob and verify that the data matches the on-chain commitment. This ensures the data is available for anyone to download and reconstruct the rollup's state, which is the critical security requirement for optimistic and zk-rollups.

After the blob data is no longer needed for dispute resolution or state verification—a window currently set to 4096 epochs (≈18 days)—nodes prune it. Only the tiny KZG commitment remains permanently in the blockchain history. This ephemeral storage model is what enables the massive cost reduction; users pay for expensive, permanent storage only for the essential commitment and transaction overhead, not for the entire bulk data. The system is governed by a separate fee market, blob gas, which fluctuates based on demand for blob space, preventing congestion in blob usage from affecting the execution layer's gas prices for standard transactions.

A blob transaction is a specialized Ethereum transaction type, introduced by EIP-4844 (Proto-Danksharding), that carries large, inexpensive data packets called blobs in a separate data layer. Unlike calldata, which is stored permanently on-chain, blob data is designed for temporary availability, significantly reducing the cost of posting data for Layer 2 rollups. The lifecycle of a blob is a precisely timed, multi-stage process managed by the consensus and execution clients, ensuring data is available for verification when needed but not burdening historical storage indefinitely.

The lifecycle begins when a user or rollup submits a blob-carrying transaction. The transaction's execution data (e.g., sender, recipient, value) is processed normally by the Execution Layer, while the attached blob data is sent to the Consensus Layer. Here, the beacon block builder includes a commitment to the blob—a KZG commitment—in the block body. The actual blob data is not stored in the block itself but is propagated and made available on a separate peer-to-peer network for a short, fixed period, typically 4096 epochs (approximately 18 days).

During its active window, the blob data must remain available for nodes to download and verify against its commitment. This is enforced by data availability sampling (DAS), where light clients or validators sample small random chunks of the blob. If the data cannot be fully reconstructed from these samples, the block is considered invalid. This mechanism ensures Layer 2s can trustlessly derive their state without needing to store the entire blob chain, a core principle of Danksharding.

After the blob retention period elapses, the data is systematically pruned. Execution clients delete the blob data from their local storage, as its purpose for consensus and verification has been fulfilled. Only the small commitments and transaction receipts remain permanently on-chain, serving as a compact proof that the data existed and was available. This ephemeral design is what enables blob storage costs to be orders of magnitude lower than permanent calldata, directly passing savings on to rollup users.

The final state of the lifecycle is a historical record containing only cryptographic references. A blob transaction receipt contains the blob versioned hashes, which point to the now-deleted data. While the blob data itself is gone, these hashes allow anyone to cryptographically verify that specific data was once part of the chain, providing the necessary data commitment for long-term fraud proofs or validity proofs in rollup systems. This completes the efficient, purpose-driven lifecycle of a blob.

Proto-Danksharding, implemented via EIP-4844 and known as blob transactions, is the foundational first step toward full Danksharding on Ethereum. Its primary innovation is the introduction of a new transaction type that carries large data "blobs"—temporary, inexpensive data packets intended for Layer 2 rollups. These blobs are stored in the Beacon Chain for approximately 18 days, a period sufficient for fraud-proof and validity-proof verification, but are not accessible to the Ethereum Virtual Machine (EVM). This design separates data availability from execution, creating a dedicated, low-cost data market for rollups while keeping base layer consensus simple and secure.

The transition to Full Danksharding represents the complete realization of the vision, where the network's data availability capacity scales with the number of active validators. This phase introduces a data availability sampling (DAS) scheme, allowing light nodes and validators to verify data availability by randomly sampling small pieces of the total data. Coupled with KZG polynomial commitments (or potentially other cryptographic schemes) for efficient data verification, full Danksharding aims to enable Ethereum to securely process 16 MB of data per slot initially, with the potential for 1.3 GB per slot as the validator set grows. This transforms Ethereum into a robust data availability layer for potentially hundreds of rollups.

The evolutionary path is defined by key technical milestones. Proto-Danksharding establishes the core transaction format and fee market (blob gas) for blobs. Full Danksharding then builds upon this by distributing blob data across a committee of validators using an erasure-coding technique called Reed-Solomon codes, making the data highly redundant and recoverable. Critical enabling upgrades include PeerDAS for peer-to-peer data distribution and the integration of a Danksharding-ready consensus layer. This phased approach allows for iterative testing, risk mitigation, and community adaptation, ensuring the stable introduction of one of blockchain's most complex scaling upgrades.