Danksharding is a future Ethereum scaling architecture designed to provide much greater data availability for Layer 2 rollups without requiring every Ethereum node to download and process all rollup data. Rather than dividing Ethereum into independent execution shards, Danksharding focuses primarily on distributing data efficiently across the network so rollups can scale transaction processing while continuing to use Ethereum for security and settlement.
The concept is named after Ethereum researcher Dankrad Feist. It represents a major change from Ethereum’s earlier sharding plans. Older designs envisioned multiple shard chains that could process transactions and execute smart contracts separately. As Ethereum adopted a rollup-centric scaling strategy, the role of sharding changed. Layer 2 networks became responsible for most transaction execution, while Ethereum increasingly needed to provide them with large amounts of secure and verifiable data capacity.
Danksharding is designed around this division of responsibilities. Rollups execute transactions and compress their data, while Ethereum provides consensus, settlement and data availability. The objective is not simply to make Ethereum Layer 1 execute more transactions per second. It is to give Layer 2 systems enough data capacity to increase their combined throughput substantially without making the hardware requirements for ordinary Ethereum nodes impractical.
Ethereum has not introduced Danksharding as one single upgrade. Elements required for the architecture are being deployed progressively. EIP-4844, or Proto-Danksharding, introduced blob transactions in March 2024, while subsequent development has focused on expanding blob capacity and improving how nodes handle that data.
Why Ethereum Changed Its Original Sharding Strategy
Sharding has been discussed as an Ethereum scaling solution for many years, but the meaning of the term has changed considerably.
Traditional blockchain sharding generally involves splitting network responsibilities among several groups of nodes. Instead of every participant processing every transaction, different shards handle different subsets of activity. In theory, additional shards can increase total network capacity because work happens in parallel.
Early Ethereum roadmaps explored a similar model involving multiple shard chains. These shards were expected to contribute more directly to transaction processing. However, the rapid development of optimistic and zero-knowledge rollups changed the scaling landscape.
Rollups demonstrated that large amounts of execution could be moved away from Ethereum Layer 1 while retaining Ethereum as a settlement and security layer. This created a different bottleneck. If rollups execute transactions themselves, Ethereum does not necessarily need dozens of additional execution environments. What rollups need most from Layer 1 is a reliable way to publish large quantities of transaction data.
Data availability is essential because independent participants must be able to reconstruct and verify what happened on a rollup. A Layer 2 system cannot provide strong trust-minimised guarantees if the operator can publish a new state commitment while withholding the underlying transaction data.
Danksharding therefore focuses Ethereum’s sharding effort on data rather than execution. This makes it fundamentally different from the older idea of creating many separate Ethereum execution shards.
How Danksharding Is Designed to Work
At the centre of Danksharding are blobs, large packages of data intended primarily for rollups. Blobs were first introduced through EIP-4844, but the long-term Danksharding architecture is intended to support substantially more data than the initial implementation.
The challenge is straightforward. Increasing blob capacity increases the amount of information propagated through Ethereum. If every node had to download every blob in full, continually increasing capacity would eventually increase bandwidth requirements to levels that could damage decentralisation.
Danksharding addresses this problem through techniques that allow network participants to verify data availability without requiring every node to store or download the entire dataset.
A simplified version of the intended process is:
- Rollups execute transactions outside Ethereum Layer 1 and produce batches of data representing their activity.
- This data is published to Ethereum through blobs rather than being stored as ordinary permanent calldata.
- Blob data is distributed across Ethereum’s peer-to-peer network using specialised data availability mechanisms.
- Nodes obtain portions of the available data rather than requiring every node to download everything.
- Cryptographic techniques allow participants to gain strong confidence that the complete dataset is available.
- Rollups use Ethereum’s consensus and data availability guarantees to support verification and settlement of their Layer 2 states.
This architecture allows Ethereum to increase total data throughput while limiting the amount of work required from an individual node.
The important point is that Danksharding does not move all rollup execution back to Ethereum. A rollup remains responsible for processing its transactions. Ethereum provides the common infrastructure that makes the rollup’s underlying data reliably available.
Danksharding, Proto-Danksharding and Traditional Sharding
The distinction between these concepts is important because they are sometimes incorrectly used as synonyms. Proto-Danksharding is an implemented step towards the broader Danksharding architecture, while traditional execution sharding represents an earlier scaling direction.
| Feature | Proto-Danksharding | Danksharding | Traditional Execution Sharding |
| Primary purpose | Introduce blob-based data availability | Scale rollup data availability substantially | Scale blockchain execution |
| Ethereum status | Implemented through EIP-4844 | Multi-stage future architecture | No longer the main Ethereum scaling plan |
| Rollup-focused | Yes | Yes | Not necessarily |
| Blob data | Yes | Central to the design | Not a defining feature |
| Data availability sampling | Not the full long-term architecture | Fundamental to scaling capacity | Not the primary mechanism |
| Separate execution shards | No | No | Yes |
| Main scaling target | Layer 2 data costs and capacity | Large-scale Layer 2 throughput | Parallel Layer 1 execution |
Proto-Danksharding should therefore not be described as a small version of multiple execution shards. EIP-4844 established key foundations for the data-centric roadmap, including blob transactions and a dedicated market for blob capacity.
Danksharding builds on that direction by addressing the next problem: how Ethereum can support much more blob data without forcing every node to handle all of it.
The transition is deliberately incremental. Ethereum can introduce individual networking, cryptographic and consensus improvements instead of attempting to deploy a completely new sharding architecture in one coordinated upgrade.
PeerDAS and Data Availability Sampling
Data availability sampling is one of the most important ideas behind Ethereum’s path towards Danksharding. It addresses the conflict between increasing blockchain data capacity and keeping node requirements manageable.
If a block contains a very large amount of rollup data, requiring every node to download the entire dataset limits how large blocks can become. Sampling changes the model. Nodes can request and verify smaller portions of the data, and the network can collectively establish that the full dataset is available.
PeerDAS, or Peer Data Availability Sampling, is an Ethereum mechanism developed to put this principle into practice for blob data. Rather than treating every node as a complete recipient of all blobs, data can be distributed so individual nodes are responsible for only part of the total information while the network collectively maintains availability.
This approach is closely connected to erasure coding. Data can be encoded with redundancy so that the original information can be reconstructed even when only a sufficient subset of encoded pieces is available. Sampling randomly selected pieces then makes withholding a substantial portion of the data increasingly difficult to conceal.
The main objectives of this architecture include:
- increasing Ethereum’s total blob capacity without proportionally increasing bandwidth requirements for every node;
- preserving the ability of ordinary participants to run Ethereum nodes as rollup activity grows;
- providing rollups with strong guarantees that their published data is accessible;
- distributing data responsibilities across Ethereum’s peer-to-peer network;
- allowing data capacity to scale separately from Layer 1 execution capacity;
- creating infrastructure capable of supporting substantially greater Layer 2 transaction throughput.
Data availability sampling does not mean that nobody stores the complete data. Different participants collectively possess enough information for the data to remain available and recoverable. The important change is that every individual node does not need to process the entire dataset independently.
Danksharding and Ethereum’s Block Production
Another defining idea associated with Danksharding is that data is integrated into Ethereum’s existing block production rather than being divided among many independent shard block producers.
This differs from earlier sharding designs in which separate shard chains could have their own blocks and responsibilities. Danksharding is based around a more unified Ethereum block production model.
This architecture is related to proposer-builder separation. Ethereum’s block-building ecosystem already distinguishes, to varying degrees, between validators proposing blocks and specialised builders assembling economically optimised block contents. A future system with much larger quantities of rollup data creates additional demands on block construction, propagation and verification.
Specialised builders can have more powerful infrastructure than ordinary validators, but the protocol must prevent this from making validation itself prohibitively expensive. The wider Danksharding roadmap therefore involves balancing high-capacity block construction with decentralised verification.
This is an important distinction in Ethereum’s scaling philosophy. It may be acceptable for producing highly optimised blocks to require specialised infrastructure, provided that verifying Ethereum remains accessible to a much broader group of participants.
The design is intended to increase throughput without requiring every validator to become a data-centre-scale operator.
What Danksharding Means for Ethereum Rollups
The direct beneficiaries of Danksharding are expected to be Layer 2 networks. Rollups already reduce Ethereum execution costs by processing many user transactions outside Layer 1, but they still need to publish information to Ethereum.
More available blob capacity gives rollups more room to publish transaction batches. If data supply grows faster than demand, this can also reduce the data availability cost allocated to each Layer 2 transaction.
The potential effects include:
- greater combined transaction capacity across Ethereum Layer 2 networks;
- lower data availability costs per transaction when sufficient blob capacity exists;
- less dependence on expensive permanent Layer 1 calldata;
- stronger support for high-volume optimistic and zero-knowledge rollups;
- increased separation between Ethereum settlement and Layer 2 execution;
- the ability to scale rollup activity without requiring equivalent growth in Ethereum node bandwidth.
However, Danksharding should not be interpreted as a guarantee of permanently negligible Layer 2 fees. Rollup costs depend on several factors, including blob demand, execution costs, proof generation, sequencing, infrastructure and individual network fee policies.
Nor does Danksharding remove the differences between Layer 2 networks. Rollups can still have different proof systems, sequencers, governance mechanisms, bridges and security assumptions. Danksharding primarily improves the shared Ethereum data layer on which these systems can depend.
Danksharding as Part of Ethereum’s Rollup-Centric Architecture
Danksharding represents a broader shift in what Ethereum Layer 1 is expected to do. Instead of trying to execute every application transaction directly, Ethereum can serve as a highly secure foundation for many execution environments operating above it.
Rollups handle much of the computation. Ethereum provides consensus and settlement. Danksharding is intended to make large-scale data availability another core service of the base layer.
This approach avoids recreating dozens of independent execution shards inside Ethereum itself. The Layer 2 ecosystem already provides multiple parallel execution environments, so the base layer can concentrate on the resources those environments need most.
The roadmap is being implemented progressively rather than through a single event called the “Danksharding upgrade”. EIP-4844 established blobs and a dedicated data market, while data availability sampling and related networking improvements expand what Ethereum can do with them.
The ultimate significance of Danksharding is therefore not simply higher Ethereum throughput. It is a change in how that throughput is achieved. Ethereum does not need every node to execute or download everything. By combining rollup execution with distributed data availability, Danksharding is intended to let Layer 2 capacity grow while preserving Ethereum’s role as a decentralised security and settlement layer.