Proto-Danksharding (EIP-4844)

Proto-Danksharding, formalized as Ethereum Improvement Proposal EIP-4844, is a major scaling upgrade that introduces a new transaction type called a blob-carrying transaction. Its primary purpose is to dramatically reduce the data costs for Layer 2 rollups (like Optimism and Arbitrum) by providing them with dedicated, inexpensive data storage space on Ethereum. This new data format, known as blobs, is designed to be large (up to ~128 KB each) and is not permanently stored by Ethereum execution clients, making it far cheaper than calldata. The proposal is named after Ethereum researchers Proto Lambda and Dankrad Feist.

The core innovation is the separation of data availability from execution. Rollups post their transaction data in blobs, which are cryptographically committed to by consensus layer validators and made available for a short window (approximately 18 days). This ensures anyone can verify the rollup's state transitions, preserving Ethereum's security guarantees, while the main network is not burdened with storing this data forever. The key new data structure is the blob, which is a sidecar of data attached to a beacon chain block and referenced via a KZG commitment, a type of cryptographic proof.

For end-users, the most immediate impact of EIP-4844 is significantly lower transaction fees on Layer 2 networks. By decoupling data costs from the expensive computational gas market, rollups can pass on savings to their users. This upgrade is a critical stepping stone toward full Danksharding, a future state where the network can process many blobs per block in parallel. Proto-Danksharding implements the essential architecture—blobs, KZG commitments, and a separate fee market—without yet implementing data sampling or the full sharded validator architecture required for the final vision.

The name Proto-Danksharding is a compound term with two distinct parts. 'Danksharding' refers to the full, theoretical scaling architecture for Ethereum, named after its principal researcher, Dankrad Feist. 'Proto-' is a prefix from Greek, meaning 'first' or 'earliest form of,' indicating that this is a preliminary, simplified version designed to be deployed before the complete system. Therefore, Proto-Danksharding is the foundational, incremental step that establishes the necessary framework and data structures—specifically blob-carrying transactions—without implementing the full complexity of data availability sampling and shard chain consensus.

The 'Danksharding' component itself represents a significant evolution from earlier sharding designs. Traditional sharding proposals involved splitting the blockchain into multiple shards, each with its own block producers and complex cross-shard communication. Dankrad Feist's design, introduced in 2021, simplified this by having a single proposer select all transactions and data for a block, with the validation and data availability work distributed across the network. This 'merged fee market' and streamlined approach made the scaling model more feasible and secure, forming the conceptual backbone for which Proto-Danksharding is the initial prototype.

The 'Proto-' prefix is critical because it signals a minimal viable product (MVP) strategy for Ethereum's rollup-centric roadmap. Instead of attempting to deliver the entire Danksharding vision in one complex upgrade, developers introduced EIP-4844 as a standalone, compatible precursor. This proto-implementation delivers the core benefit—cheaper data availability for Layer 2 rollups via blobs—while postponing more advanced features like peer-to-peer networking for blobs and full data availability sampling. This incrementalism reduces initial risk and allows the ecosystem to build on the new primitive immediately.

In developer vernacular, the term is often shortened to 'The Blob Update' or by its Ethereum Improvement Proposal number, EIP-4844. While these are functional synonyms, 'Proto-Danksharding' remains the technically precise name, as it explicitly links the upgrade to its ultimate goal and architectural lineage. Understanding this etymology clarifies that EIP-4844 is not a standalone feature but the first critical phase in a multi-year transition towards a fully scaled, sharded Ethereum data layer, with future upgrades like Full Danksharding expected to build directly upon its foundation.

Proto-danksharding, implemented via EIP-4844, is an Ethereum upgrade that introduces blob-carrying transactions to provide a dedicated, low-cost data availability layer for Layer 2 rollups. Instead of storing rollup data permanently in Ethereum's execution layer, these transactions attach large data 'blobs' that are temporarily stored by consensus nodes and verifiably available for a short period (approximately 18 days). This separation of data availability from execution is the core innovation, allowing rollups to post data at a fraction of the historical cost without requiring the full implementation of data sharding.

The mechanism relies on a new transaction type and a parallel data market. A blob-carrying transaction includes a small pointer to a blob—a large packet of data (up to ~128 KB) that is not accessible to the Ethereum Virtual Machine (EVM). Validators and consensus clients have a new duty to store and propagate these blobs for the required window, ensuring the data is available for anyone to download and verify rollup state transitions. A separate blob gas fee market, distinct from standard EIP-1559 gas, dynamically prices blob space, preventing network congestion from spilling over into the main execution block gas limit.

For rollups like Optimism and Arbitrum, this means submitting transaction data (calldata) as blobs instead of as expensive call data within an EVM transaction. The rollup's smart contract on Ethereum only needs to store a small commitment to the blob data, drastically reducing its permanent storage footprint and associated fees. End-users experience this as significantly lower transaction fees on L2s, as data posting constitutes the largest cost component for rollup operators.

The architecture is designed for forward compatibility with full Danksharding. The blob data structure, the KZG commitment scheme for verification, and the separate fee market are all foundational components that will scale in the final design. In full Danksharding, the responsibility for storing these blobs will be distributed across a committee of validators, enabling massive parallel data throughput while proto-danksharding acts as a 'training wheels' phase with a simpler, monolithic blob storage model.

Implementation requires coordinated upgrades across Ethereum's execution layer (EL) and consensus layer (CL). The EL processes the blob transaction and its pointer, while the CL (Beacon Chain) manages the blob data pool, its propagation protocol, and the attestations that confirm data availability. This division reinforces Ethereum's post-Merge architecture, where the CL is responsible for data availability and consensus, and the EL handles execution.

Proto-Danksharding, implemented via EIP-4844, is the foundational step in Ethereum's Danksharding roadmap, introducing a new transaction type called a blob-carrying transaction. These transactions carry large packets of data known as blobs, which are temporarily stored on the consensus layer but are not accessible to the Ethereum Virtual Machine (EVM). This design provides rollups with a dedicated, low-cost data channel, separating data availability from execution and significantly reducing the cost of posting data to Ethereum, which is the primary expense for Layer 2s.

The architecture of Proto-Danksharding centers on blobs and a new fee market. Each blob is ~128 KB of data, and transactions can carry multiple blobs. A separate blob gas fee market ensures that blob space is priced independently from standard execution gas, preventing congestion in one from affecting the other. Crucially, blobs are pruned after approximately 18 days, a period deemed sufficient for fraud proofs and data availability sampling, which keeps the historical data burden on nodes manageable while still guaranteeing long-term data availability for security.

The transition to Full Danksharding builds upon this foundation by scaling the system from ~0.4 MB per slot (with a few blobs) to a target of ~16-32 MB per slot. This scaling is enabled by distributing the blob data across a committee of validators, a process managed by the Distributed Validator Technology (DVT)-inspired Data Availability Sampling (DAS). With DAS, light nodes and validators can cryptographically verify data availability by randomly sampling small pieces of the total data, enabling secure scaling without requiring any single node to download the entire dataset.

The final state, Full Danksharding, transforms Ethereum into a robust data availability layer. In this model, the consensus layer's primary role is to order and guarantee the availability of massive amounts of data for rollups, while execution is fully delegated to Layer 2 networks. This separation of concerns—consensus for data, execution off-chain—allows Ethereum to scale transaction throughput by orders of magnitude while maintaining the security and decentralization of its base layer, solidifying its role as the foundational settlement and data layer for a modular blockchain ecosystem.