Danksharding

Danksharding is a sharding design for Ethereum that fundamentally re-architects how transaction data is posted and verified, prioritizing data availability over execution. Proposed by Ethereum researcher Dankrad Feist, its core innovation is the blob-carrying transaction (introduced in EIP-4844, or "Proto-Danksharding"), which attaches large data "blobs" to blocks. These blobs are cheap to post and are automatically deleted after a short period, but their cryptographic commitments ensure the data was available, enabling Layer 2 rollups to settle transactions cheaply and securely.

The architecture separates the roles of builders and proposers through a mechanism called proposer-builder separation (PBS). Builders compete to construct the most valuable block, including ordering transactions and attaching data blobs. A single block proposer then selects the best block. This design prevents centralization risks and MEV exploitation while enabling the efficient handling of massive data payloads. The system's security relies on validators performing data availability sampling (DAS), where they randomly check small pieces of the blob data to probabilistically guarantee its entirety is published.

The full vision, full Danksharding, will expand this model to multiple blobs per block, potentially increasing data capacity to 128 blobs of 128 KB each. This creates a dedicated data layer with bandwidth exceeding 16 MB per slot, upon which rollups and other scaling solutions can be built. Unlike traditional execution sharding, Danksharding does not shard Ethereum's execution or state; it shards only the data, keeping consensus simple and secure while delegating complex computation to Layer 2 networks.

The implementation is happening in stages. Proto-Danksharding (EIP-4844) deployed the core blob transaction format. Future upgrades will introduce the full PBS, a decentralized builder market, and the scaling of the number of blobs. This incremental approach allows the network to test components like DAS in production while maintaining Ethereum's core security properties, ensuring a smooth transition to a scalable, rollup-centric ecosystem.

The term Danksharding is a compound of 'Dankrad' and 'sharding.' It is named directly after Dankrad Feist, a researcher at the Ethereum Foundation who authored the original proposal. The 'sharding' component refers to the foundational blockchain scaling technique of partitioning the network's data and computational load into smaller, parallel chains called shards. This naming convention follows a tradition in Ethereum development of crediting core researchers, similar to how 'Casper' refers to the proof-of-stake protocol proposed by Vitalik Buterin and Virgil Griffith.

The concept evolved from earlier, more complex sharding models. Initial Ethereum sharding designs involved multiple execution shards with distinct block producers and complex cross-shard communication. Danksharding, specifically Proto-Danksharding (EIP-4844) and full Danksharding, represents a paradigm shift by introducing a data availability sampling (DAS) model. Instead of numerous execution shards, it proposes a single, unified block builder and focuses sharding purely on data availability, making blob-carrying transactions the primary scalable data layer for Layer 2 rollups.

The 'Dank' prefix has become a recognizable namespace within Ethereum's technical lexicon. Proto-Danksharding (the initial, partial implementation) and the envisioned final stage of Full Danksharding are both subsumed under this title. This distinguishes the Feist-inspired data-availability-centric approach from the older execution sharding paradigms. The name's adoption underscores how a researcher's specific proposal can redefine an entire technical trajectory for a major blockchain.

Danksharding is a proposed data availability scheme for Ethereum that fundamentally restructures block production to massively scale data capacity for Layer 2 rollups. Unlike earlier sharding designs, it introduces a proposer-builder separation (PBS) model where a single block proposer selects a complete block from competitive block builders, who assemble transactions and the critical data blobs. This centralizes the task of creating a data-available block, simplifying consensus and enabling the network to support up to 32 data blobs per slot, each containing ~128 KB of call data for rollups.

The core innovation is the separation of consensus from data availability sampling (DAS). Validators do not download the entire massive block; instead, they perform DAS by randomly sampling small chunks of the data blobs via the distributed hash table (DHT). Using erasure coding (specifically, Reed-Solomon codes), the data is redundantly encoded so that if a sufficient number of samples are collected, the entire dataset can be reconstructed. This allows light clients and validators to cryptographically verify data availability with minimal bandwidth, ensuring that data promised by the block builder is actually published and accessible.

A key component is the blob-carrying transaction type, introduced with EIP-4844 (Proto-Danksharding). These transactions carry large data blobs that are not accessible to the Ethereum Virtual Machine (EVM) and are stored only for a short period (~18 days). This separates expensive, permanent calldata storage from cheap, temporary data availability, drastically reducing costs for rollups. The blob gas market independently prices this ephemeral data space, preventing it from competing with standard transaction gas.

The full Danksharding vision involves several technical upgrades. The data availability committee (DAC) from earlier designs is replaced by a cryptoeconomic guarantee enforced by the validator set through DAS. KZG polynomial commitments (or potentially other commitment schemes) create a compact cryptographic proof that the erasure-coded data is available and consistent. The system also requires an efficient peer-to-peer network for propagating blob samples and a robust mechanism for builders to attest to data availability, with severe penalties (slashing) for provable failures.

The rollout is phased, with Proto-Danksharding implementing the core transaction format and a scaled-down version (e.g., 6 blobs/slot) as a crucial first step. Full Danksharding will follow, incrementally increasing blob count and implementing all sampling and proof systems. This evolutionary approach de-risks development and allows the ecosystem—especially optimistic rollups and ZK-rollups—to adapt. The end goal is to position Ethereum as a secure data availability layer, enabling rollups to process tens of thousands of transactions per second at minimal cost.

Proto-danksharding, implemented via Ethereum Improvement Proposal EIP-4844, is a precursor to full danksharding designed to drastically lower data costs for Layer 2 rollups. It achieves this by introducing blob-carrying transactions, which temporarily store large batches of data—known as blobs—in the Beacon Chain for approximately 18 days. Unlike calldata, this blob data is not accessible to the Ethereum Virtual Machine (EVM) and is pruned after this period, which keeps the historical data burden on nodes manageable while providing the data availability that rollups require for security.

The core innovation is the blob, a ~125 KB packet of data attached to a transaction. Rollups use these blobs to post their compressed transaction data, which validators and full nodes must download and make available. The separation of blob data from executable EVM data is key: it allows for a dedicated blob gas market distinct from the standard gas for computation, enabling more predictable and cheaper data posting fees for rollups. This mechanism directly addresses the primary cost driver for end-users on networks like Optimism and Arbitrum.

Proto-danksharding establishes the foundational architecture for the future danksharding vision. It implements the data availability sampling (DAS) client logic, allowing nodes to verify data availability without downloading entire blobs. While full danksharding will expand this to multiple blobs per block and a decentralized validator sampling network, EIP-4844 provides the immediate scaling benefits and real-world testing ground for these critical components, marking a major step toward Ethereum's scalable, rollup-centric roadmap.