Ethereum’s scaling strategy has changed significantly over the past few years. Instead of splitting Ethereum into separate execution shard chains, the network now relies heavily on Layer 2 rollups and is expanding how much data those rollups can publish to Ethereum.
Two important parts of this strategy are proto-danksharding and danksharding.
Proto-danksharding arrived through Ethereum Improvement Proposal 4844 (EIP-4844) in the Dencun upgrade on March 13, 2024. It introduced temporary data objects called blobs, giving rollups a cheaper place to publish transaction data.
Ethereum has since gone further, with the Fusaka upgrade activated on December 3, 2025, that introduced Peer Data Availability Sampling (PeerDAS), allowing nodes to verify blob availability without every node downloading every blob in full, making it possible to increase Ethereum’s blob capacity without increasing node bandwidth at the same rate.
Full danksharding remains a longer-term goal, but several of the technologies needed are already live.
Why Does Ethereum Need Danksharding?
Ethereum Layer 1 has limited block space. When many users compete for that space, transaction fees can increase.
Rollups such as optimistic and zero-knowledge (ZK) rollups help by processing transactions outside Ethereum’s main execution layer and then publishing the information needed to verify those transactions back to Ethereum.
The problem is that rollups still need data availability. Users need confidence that the underlying transaction data is available so they can independently verify the rollup’s state.
Before EIP-4844, rollups commonly published this information using calldata, which competes with ordinary Ethereum transactions for block space and is stored permanently.
Ethereum introduced blobs as a specialized, temporary data layer for rollups.
The goal is not to make Ethereum Layer 1 process every transaction directly. Ethereum increasingly acts as a secure settlement and data-availability layer, while Layer 2 networks handle most transaction execution.
What Is Proto-Danksharding?
Proto-danksharding is the first major implementation step toward Ethereum’s danksharding design.
EIP-4844 introduced it as part of the Dencun upgrade in March 2024, and its most important feature is blob-carrying transactions.
Blobs, short for binary large objects, provide temporary data space designed mainly for rollups. The Ethereum Virtual Machine (EVM) does not execute blob contents directly, so Ethereum handles the data differently from normal transaction calldata.
Instead of keeping the full blob data permanently, Ethereum nodes retain it for a limited period. Ethereum.org currently lists the retention period as 4,096 epochs, or roughly 18 days, long enough for rollups and other participants to verify the data while avoiding permanent growth of Ethereum’s state and history.
How Proto-Danksharding Works
Proto-danksharding separates rollup data from normal Ethereum execution.
Rollups Process Transactions
Layer 2 rollups process many transactions outside Ethereum’s main execution layer.
They then need to publish enough information to Ethereum so the rollup’s state can be independently verified.
Data Is Published in Blobs
Instead of putting all that information into standard calldata, rollups can place it in blobs attached to special blob-carrying transactions.
The blob itself is separate from normal EVM execution data. Ethereum instead keeps a cryptographic commitment to the blob that can be used to verify it.
Blob Data Uses a Separate Fee Market
Blob space has its own pricing mechanism rather than competing directly with ordinary Ethereum execution gas.
That separation lets demand from Layer 2 networks affect blob prices without putting the same direct pressure on the normal transaction fee market.
Blob Data Eventually Expires
Ethereum nodes do not need to retain blob data forever.
Once the availability period passes, nodes can prune it. Rollups, indexers, or other services that need historical copies can store the data separately.
This is one reason blobs can provide significantly cheaper data availability than permanent calldata.
What Is Danksharding?
Danksharding is the broader long-term architecture for dramatically increasing the amount of rollup data Ethereum can support.
Despite the name, it is different from Ethereum’s older shard-chain plan.
Earlier versions of Ethereum’s roadmap proposed splitting the blockchain into many separate chains or shards. That approach was dropped as Layer 2 rollups developed more quickly and became Ethereum’s primary scaling strategy.
Modern danksharding is primarily about data sharding.
Instead of every Ethereum node downloading all of the rollup data being published, the network distributes responsibility for checking that data.
That allows total data capacity to grow without requiring every validator or node operator to continuously upgrade to much more powerful hardware.
Proto-Danksharding Versus Danksharding
Proto-danksharding introduced the blob system. Danksharding expands that architecture so Ethereum can handle much more blob data efficiently.
| Feature | Proto-Danksharding | Danksharding |
| Status | Live since March 2024 | Longer-term roadmap |
| Main upgrade | EIP-4844 | Multiple protocol upgrades |
| Blobs | Yes | Yes, at much greater scale |
| Temporary rollup data | Yes | Yes |
| Separate blob fee market | Yes | Yes |
| Data availability sampling | Added later through PeerDAS | Central to the broader design |
| Goal | Make rollup data cheaper | Greatly expand Ethereum data capacity |
Table 1. Proto-Danksharding Versus Danksharding
The key point is that Ethereum is not waiting for a future upgrade called “full danksharding” to get the benefits, since the roadmap is being implemented in stages.
What Are Blobs?
Blobs are temporary data packets attached to Ethereum blocks.
They were designed because rollups need large amounts of data for verification but usually do not need Ethereum nodes to store it permanently.
A blob is different from normal calldata in several ways.
Blob contents are not directly accessible to EVM smart contracts; they are priced through a separate fee market, and the full data is eventually removed from normal node storage.
Ethereum still retains cryptographic commitments that allow the data to be verified.
For rollups, the result is a specialized data lane that is generally better suited to publishing transaction batches than permanent calldata.
PeerDAS Is Now a Major Part of Ethereum Scaling
One of the biggest updates missing from the older version of this article is PeerDAS.
PeerDAS stands for Peer Data Availability Sampling, and it went live with the Fusaka upgrade on December 3, 2025.
Before PeerDAS, every full Ethereum node still had to download every blob even though EIP-4844 made blobs temporary, which limited how far Ethereum could increase blob capacity.
PeerDAS changes the model by distributing blob data across the network. Individual nodes can download and verify portions of the data rather than downloading every complete blob.
Erasure coding helps ensure that enough pieces exist across the network for the original data to be reconstructed and verified.
This means Ethereum can increase total blob throughput without increasing each node’s bandwidth requirements at the same rate.
Ethereum Has Already Increased Blob Capacity
Proto-danksharding originally launched with much more limited blob capacity.
Ethereum increased the target to six blobs per block and the maximum to nine with the Pectra upgrade in May 2025.
Fusaka then introduced a mechanism called Blob Parameter Only (BPO) forks, allowing Ethereum to adjust blob limits without waiting for another large network upgrade.
Two BPO upgrades followed Fusaka:
| Stage | Target Blobs per Block | Maximum Blobs per Block |
| Before BPO1 | 6 | 9 |
| BPO1 | 10 | 15 |
| BPO2 | 14 | 21 |
Table 2. Ethereum Blob Capacity After Fusaka
BPO2 activated on January 7, 2026, increasing the target to 14 blobs per block and the maximum to 21.
Ethereum’s 2026 scaling work continues to focus on increasing both execution capacity and blob throughput.
How Data Availability Sampling Works
Data availability sampling (DAS) tackles a difficult scaling problem: how can Ethereum verify that a large amount of data exists without forcing every node to download it?
The basic idea is sampling.
Instead of every node downloading an entire dataset, nodes request smaller pieces from different parts.
Once enough independent nodes successfully retrieve samples, the network can be confident the underlying data is available.
PeerDAS applies this approach to Ethereum’s blob network, reducing the blob data each node must handle while letting the network support much more data overall.
DAS is therefore one of the technologies connecting today’s proto-danksharding implementation with the longer-term danksharding architecture.
Why Blobs Matter for Layer 2 Networks
Rollups rely on Ethereum for security and data availability, so publishing data to Ethereum can represent a significant part of what users ultimately pay.
Blob space gives Layer 2 networks a purpose-built alternative.
Increasing blob capacity can allow rollups to publish more transaction data before competition for blob space pushes fees higher.
That does not mean every Layer 2 transaction becomes free. User costs can still depend on rollup demand, execution costs, sequencer policies, and other factors.
But cheaper and more abundant Ethereum data availability gives rollups more room to scale.
Does Danksharding Increase Ethereum Layer 1 TPS?
Not in the simple way the term “transactions per second” can imply.
Danksharding is mainly designed to increase data availability capacity for Layer 2 networks, rather than putting every additional user transaction directly onto Ethereum Layer 1.
Rollups process their own transactions and use Ethereum for settlement, verification, and data availability.
As Ethereum supports more blob data, many rollups can handle more transactions collectively.
Ethereum.org describes the long-term danksharding roadmap as part of a system that can support more than 100,000 transactions per second across Ethereum and its Layer 2 ecosystem. That is an ecosystem-level scaling target, not a claim that Ethereum Layer 1 itself will directly execute every one of those transactions.
Is Full Danksharding Live Yet?
No. Proto-danksharding has been live since 2024, and an important part of the next stage, PeerDAS, has been live since December 2025.
Ethereum has also substantially increased blob capacity through Pectra, Fusaka, and subsequent BPO upgrades.
However, Ethereum.org still describes full danksharding as a longer-term project requiring additional protocol work.
One remaining area is deeper proposer-builder separation.
Ethereum’s roadmap currently lists Glamsterdam for Q4 of 2026, with enshrined Proposer-Builder Separation (ePBS) among its major planned features.
Ethereum development is community-driven, so upgrade contents and dates can change before activation.
Why Danksharding Matters for Ethereum
Danksharding is important because Ethereum is increasingly scaling through a combination of Layer 1 security and Layer 2 execution.
The system needs to provide enough data capacity for many rollups without making Ethereum nodes prohibitively expensive to operate.
Proto-danksharding solved the first part of that problem by introducing blobs, and PeerDAS took it further by letting nodes sample blob data instead of downloading it all.
Future upgrades can increase that capacity further while preserving Ethereum’s decentralization.
The result is a gradual shift from the older idea of Ethereum processing everything itself toward a modular model where Ethereum provides settlement and data availability while rollups handle much of the execution.
Where Ethereum’s Danksharding Roadmap Stands in 2026
Ethereum is already well beyond the first stage of the danksharding roadmap.
EIP-4844 brought blobs to mainnet in 2024. Pectra increased its capacity in 2025. Fusaka introduced PeerDAS later that year, and subsequent BPO upgrades raised the blob target to 14 and the maximum to 21 per block by January 2026.
Full danksharding is still not a single finished feature that has been switched on. Instead, Ethereum is implementing the architecture piece by piece.
For users, the practical effect should appear mainly through Layer 2 networks: more data capacity, lower pressure on rollup costs, and greater room for Ethereum’s rollup ecosystem to grow without requiring every node to process or download everything.
Frequently Asked Questions
Need a refresher? Here are the most common questions about danksharding and proto-danksharding.
Is Proto-Danksharding Already Live?
Yes. Proto-danksharding was introduced through EIP-4844 during Ethereum’s Dencun upgrade on March 13, 2024. It introduced blob-carrying transactions for cheaper temporary rollup data.
What Is the Difference Between Proto-Danksharding and Danksharding?
Proto-danksharding introduced blobs and the basic data architecture. Danksharding is the broader long-term design that scales this system much further through greater blob capacity, data availability sampling, and other protocol changes.
What Is PeerDAS?
PeerDAS is Peer Data Availability Sampling. It allows Ethereum nodes to verify portions of blob data rather than requiring every node to download every blob. It went live through the Fusaka upgrade in December 2025.
How Long Does Ethereum Store Blob Data?
Ethereum.org currently states that blob data is retained for 4,096 epochs, or roughly 18 days, before nodes can prune it. The cryptographic commitments used to verify the blobs remain available.
Will Danksharding Make Ethereum Fees Cheaper?
Its main fee benefit is expected on Layer 2 networks. More, cheaper blob capacity gives rollups more space to publish transaction data, which can reduce a major cost. Layer 1 execution fees remain governed by a separate market and can still rise when Mainnet demand increases.
Be the first to comment