Danksharding

Danksharding is a sharding design for Ethereum that fundamentally re-architects how transaction data is posted and verified, with the primary goal of providing cheap, abundant data availability (DA) for Layer 2 rollups. Unlike earlier sharding proposals that would have created multiple execution chains, Danksharding, named after researcher Dankrad Feist, introduces a single, unified block builder role and treats data blobs as a separate resource from execution. This design simplifies consensus and paves the way for rollups to post their data to Ethereum at a fraction of the current cost, which is the primary bottleneck for scaling.

The core innovation enabling Danksharding is data availability sampling (DAS). In this model, the network does not require every node to download all the data in a block. Instead, light clients and validators can perform multiple random samplings of small pieces of the data blob. Through statistical probability, if enough samples are successfully retrieved, the entire data is guaranteed to be available. This allows the network to securely scale its data capacity—proposed to reach 128 data blobs per slot (≈ 1.33 MB)—without forcing all participants to process the full dataset, maintaining decentralization.

Implementation occurs in distinct phases. Proto-Danksharding (EIP-4844), implemented with the Dencun upgrade, introduced blob-carrying transactions and a separate fee market for blobs, establishing the foundational architecture. Full Danksharding will later expand this by implementing the full DAS protocol, increasing the number of blobs per block, and distributing blob data across a committee of validators. This phased approach allows critical infrastructure like blob explorers and peer-to-peer networks for blob propagation to mature alongside the protocol changes.

The ultimate impact of Danksharding is to transform Ethereum into a robust data availability layer for Layer 2s. By providing a high-throughput, low-cost DA guarantee, it enables rollups to settle transactions more efficiently and offer users significantly lower fees. This scaling model, often called "rollup-centric scaling," keeps execution complex on L2s while leveraging Ethereum's consensus for security and data availability, creating a scalable and modular blockchain ecosystem.

The term Danksharding is a compound word fusing Dankrad Feist, a prominent Ethereum researcher at the Ethereum Foundation, with sharding, the database partitioning technique it evolved from. It was coined informally within the Ethereum research community to distinguish this new, simplified design from the more complex data sharding plans that preceded it. The name stuck due to its specificity and the central role of Feist's proposals, notably EIP-4844 (Proto-Danksharding) and the full Danksharding specification.

This nomenclature follows a tradition in Ethereum of naming major upgrades after their key contributors or conceptual themes, such as the Merge or Surge. The 'Dank-' prefix specifically credits the architectural insights that reimagined sharding not as a consensus-layer change for execution, but as a data availability layer for rollups. The shift from traditional sharding to Danksharding represents a pivotal strategic simplification, focusing on providing cheap, abundant data blobs rather than attempting to fragment the state and execution across many chains.

The etymology underscores the proposal's practical intent: to solve the core scalability bottleneck—data availability for Layer 2s—with maximal efficiency. By moving the complexity to a specialized data availability sampling protocol and a new transaction type (blob-carrying transactions), Danksharding maintains the simplicity and security of the existing Ethereum consensus model. The name, therefore, is not just an attribution but a marker of a fundamental conceptual pivot in Ethereum's scaling strategy.

Danksharding is a sharding architecture for Ethereum that fundamentally rethinks the relationship between proposers and validators. Unlike earlier sharding proposals, it introduces a single proposer-builder separation (PBS) entity, the block proposer, who is responsible for constructing a complete block containing all transactions and data blobs. This centralization of block construction simplifies the consensus process, as validators no longer need to coordinate across multiple shard chains. Instead, their primary role shifts to verifying and attesting to the availability of the data within the proposed block through a process called Data Availability Sampling (DAS).

The core innovation enabling Danksharding is the use of data blobs—large packets of data (up to ~128 KB each) that are committed to the beacon chain but not executed by the Ethereum Virtual Machine (EVM). These blobs are temporarily stored by the network and are essential for Layer 2 rollups, which post their transaction data here. The block proposer uses a KZG polynomial commitment to create a cryptographic proof that all blob data is available. Validators then perform DAS by randomly sampling small portions of the data; if all samples can be retrieved, they can be statistically confident the entire dataset is available, without any single validator needing to download it all.

This design achieves data availability scaling by making the cost of verifying data availability independent of its size. The security model assumes that if a sufficient number of validators perform random sampling, a malicious proposer cannot hide a significant portion of the data without being detected. The implementation is phased, beginning with Proto-Danksharding (EIP-4844), which introduces the blob transaction format and a separate fee market for data, laying the groundwork for the full Danksharding specification where block size can expand to 16 MB or more per slot.

Proto-Danksharding, implemented as EIP-4844 (also known as blobs), is the critical first step. It introduces a new transaction type that carries large "blobs" of data, which are significantly cheaper than calldata. These blobs are not accessible to the Ethereum Virtual Machine (EVM) and are automatically deleted after a short period (e.g., ~18 days). The primary goal is to establish the infrastructure for rollups to post data cheaply, enabling lower L2 fees, without yet implementing the full sharding logic or data availability sampling.

The core innovation paving the way for Full Danksharding is data availability sampling (DAS). This allows light nodes to verify that all data in a block is available by randomly sampling small pieces. If the data is available, the block is valid. This is made possible by encoding the data with erasure coding, specifically KZG polynomial commitments or Verkle trees, which allow the data to be reconstructed even if some pieces are missing. This lightweight verification is key to scaling without requiring every node to download the entire dataset.

Full Danksharding builds upon this foundation by fully distributing the data load. In this final stage, the block builder role is separated from the block proposer (a concept from proposer-builder separation). A single block proposer selects a block from builders, but the massive block data (e.g., 32-64 MB blobs) is split across a committee of validators. Each validator only stores and attests to a small, randomly assigned shard of the total data, relying on DAS for security. This creates a scalable data layer where throughput is limited only by the aggregate bandwidth of the network.

The transition is designed for minimal disruption. Proto-Danksharding's blob-carrying transactions use the same format planned for the full system, allowing rollups and infrastructure to develop immediately. Later upgrades simply increase the number of blobs per block and fully deploy the distributed validation architecture. This evolutionary path ensures Ethereum can scale its data capacity by orders of magnitude, targeting a goal where data availability is no longer a bottleneck for rollup-centric scaling.