Proto-Danksharding (EIP-4844)

Proto-Danksharding, formalized as Ethereum Improvement Proposal 4844 (EIP-4844), is a major network upgrade that introduces blob-carrying transactions to reduce the cost of data availability for Layer 2 rollups. It achieves this by creating a new, separate data channel for large data packets called blobs, which are stored temporarily by the consensus layer rather than permanently on the execution layer. This design significantly lowers the gas fees for rollups to post data to Ethereum, directly addressing a primary bottleneck in scaling transaction throughput while maintaining security.

The core innovation is the blob, a data packet of up to ~128 KB that is attached to a transaction but is not accessible to the Ethereum Virtual Machine (EVM). Blobs are verified by consensus clients and stored for a short, fixed period (approximately 18 days), after which they are pruned. This temporary storage model, coupled with a separate fee market for blob space, ensures that blob data does not compete with or inflate the cost of regular Ethereum transactions. The mechanism is enabled by a new transaction type, TransactionType=0x03, and utilizes KZG polynomial commitments for efficient cryptographic verification of the data.

Proto-Danksharding serves as a critical stepping stone to full Danksharding, a future scaling paradigm where the network can process many blobs per block. By implementing the core data structures and verification logic now, EIP-4844 allows rollups, clients, and tooling to adapt in advance. The immediate impact is a dramatic reduction in data publishing costs for Optimistic Rollups like Arbitrum and Optimism and ZK-Rollups like zkSync and StarkNet, making Layer 2 transactions cheaper for end-users and enabling higher throughput.

For developers and node operators, Proto-Danksharding introduces new concepts like the blob gas fee market and requires updates to client software. The upgrade does not change how smart contracts interact with calldata but provides a far more economical path for rollup sequencers to commit their transaction data. By separating data availability from execution, EIP-4844 enhances Ethereum's role as a secure data layer, a foundational principle of the modular blockchain architecture, where execution is handled off-chain and settlement and data availability are secured on-chain.

Proto-Danksharding is the colloquial name for EIP-4844, a pivotal Ethereum upgrade that introduced blob-carrying transactions as a precursor to full Danksharding. The term is a portmanteau: 'Proto-' (from Greek prōtos, meaning 'first') signifies its role as the foundational, initial implementation, while 'Danksharding' honors Ethereum researcher Dankrad Feist, who proposed the novel sharding design. This nomenclature distinguishes it from the earlier, more complex sharding roadmap, positioning it as a practical first step.

The concept originated from the need to scale Ethereum's data availability layer without immediately implementing a full sharded blockchain architecture. Researchers, led by Dankrad Feist and the Ethereum Foundation, devised a method to attach large data 'blobs' to blocks that could be efficiently verified by the consensus layer and then discarded. This data blob approach directly addressed the high cost of calldata used by Layer 2 rollups, providing them with abundant, cheap temporary data storage and paving the way for the future multi-blob per block system of full Danksharding.

The 'Proto' prefix is crucial; it signals that this is not the final state. While full Danksharding aims to partition the network into multiple shards for parallel transaction processing, Proto-Danksharding implements only the data availability component. It provides the essential blob transaction type and the framework for data availability sampling (DAS), allowing the network to practice verifying the availability of this new data format before the full system goes live. This iterative, research-driven naming reflects Ethereum's pragmatic development philosophy.

Proto-Danksharding, formalized as EIP-4844, is an Ethereum upgrade that introduces blob-carrying transactions to provide a dedicated, low-cost data space for Layer 2 rollups. Instead of storing rollup data permanently in Ethereum's expensive calldata, these transactions attach large "blobs" of data that are only stored for a short period (~18 days), sufficient for verification. This creates a new data availability layer, drastically reducing the cost for rollups to post their transaction data to Ethereum's base layer, which is the primary expense for end-users.

The core innovation is the blob, a data package of up to ~128 KB that is separate from a transaction's execution. Blobs are verified for availability by the consensus layer (the Beacon Chain) using data availability sampling principles, but are not accessible to the Ethereum Virtual Machine (EVM). After a short retention window, blob data is pruned, preventing indefinite state bloat. This design is a precursor to full Danksharding, which will scale this system to handle many blobs per block, distributed across a committee of validators.

For the network to process these blobs, a new transaction type, TransactionType=3, was introduced. The fee market for blobs operates separately from standard gas fees via a blob gas mechanism, with its own price that adjusts based on demand for blob space. This separation prevents competition between blob data and regular transaction execution, ensuring that rollup costs remain predictably low even during periods of high mainnet congestion.

The immediate impact is a 10-100x reduction in data posting costs for Optimistic Rollups like Arbitrum and Optimism and ZK-Rollups like zkSync and StarkNet. This cost saving is directly passed on to users in the form of lower transaction fees on these Layer 2 networks. Proto-Danksharding does not increase Ethereum's transaction throughput for regular users but is a critical infrastructural upgrade that enables the scalable, low-fee ecosystem envisioned by the rollup-centric roadmap.

Implementation required coordinated changes across Ethereum's execution layer (via the Cancun-Deneb upgrade) and consensus layer. Key components include the new transaction format, blob validation rules, and the blob sidecar—a separate data structure propagated through the peer-to-peer network. Validators are responsible for attesting to the availability of blob data, and full nodes must temporarily store blobs to serve them to light clients and other validators performing sampling.

The transition to Full Danksharding is a multi-phase roadmap designed to scale Ethereum's data availability capacity by orders of magnitude, ultimately aiming for a target of 128 data shards. This evolution is not a single upgrade but a series of carefully orchestrated Ethereum Improvement Proposals (EIPs) that build upon each other. The primary goal is to decouple data publishing from execution, creating a high-throughput data layer that enables Layer 2 rollups like Optimism and Arbitrum to post data cheaply and abundantly, thereby driving down transaction fees for end-users across the ecosystem.

The first and critical step in this journey is Proto-Danksharding, implemented via EIP-4844 and commonly known by its transaction type, blob-carrying transactions. This proposal introduces a new, separate data container called a blob (Binary Large OBject) that is attached to a transaction. Blobs are large (~128 KB each) and are designed to be cheap and ephemeral—they are stored by consensus nodes for only about 18 days, a duration sufficient for rollup fraud or validity proofs. This creates a dedicated, low-cost data market distinct from the expensive, permanent storage of calldata, establishing the foundational mechanics for the full system.

Following Proto-Danksharding, subsequent upgrades will incrementally realize Full Danksharding. Key future steps include increasing the number of blobs per block from a few to hundreds, implementing data availability sampling (DAS) to allow light nodes to securely verify data availability without downloading everything, and adding proof-of-custody to ensure validators are actually storing the shard data they attest to. This modular approach de-risks development, allowing core components like the blob market and KZG commitment scheme to be battle-tested in production before the more complex peer-to-peer data sampling network is deployed.