Ethereum Danksharding: The Next Step After EIP-4844

Ethereum danksharding emerged from a fundamental rethink of how the network should scale. Rather than splitting Ethereum into parallel execution chains, the original sharding plan, developers pivoted to a data-focused approach that gives rollups cheap, temporary block space without burdening every node with permanent storage.

Danksharding didn't appear overnight. It's the result of years of research, a major architectural pivot, and a chain of incremental upgrades – each one building the foundation for the next. Here's how it works and why it matters.

What Is Ethereum Danksharding?

The name comes from Ethereum researcher Dankrad Feist, who co-proposed the design alongside researcher Protolambda (hence "Proto-Danksharding" for the earlier version).

A few things set danksharding apart from what most people picture when they hear "sharding":

• There is no splitting of the chain into multiple parallel pieces. Shard chains are no longer on Ethereum's roadmap.
• Ethereum uses a single block proposer across the whole network – simpler and more secure than coordinating multiple shard proposers.
• The focus is purely on making data cheap and verifiable for rollups – actual transaction execution stays on Layer 2.

As the Ethereum Foundation puts it, danksharding is "how Ethereum becomes a truly scalable blockchain." The end goal is supporting hundreds of individual rollups and enabling millions of transactions per second across the ecosystem.

Why Ethereum Needed a New Approach to Sharding

It never shipped, and for good reason.

Between 2020 and 2023, Layer 2 rollups matured faster than anyone expected. Arbitrum, Optimism, and zkSync demonstrated that rollups could handle execution efficiently off-chain, with the base layer only needing to store the data that lets anyone verify those rollups are honest. Execution sharding became unnecessary. Data sharding became the priority.

This pivot had a deeper architectural implication: Ethereum was formally choosing its role in the modular blockchain stack.

Ethereum L1 → security, consensus, data availability, final settlement L2 rollups → execution, throughput, user-facing applications

Instead of one monolithic chain doing everything, Ethereum became the trust anchor for a growing ecosystem of rollups. Danksharding is the infrastructure that makes that anchor capable of supporting hundreds of rollups at scale without forcing every Ethereum node to store all their data forever.

Proto-Danksharding vs. Full Danksharding: What's the Difference?

Proto-Danksharding is the live, intermediate version. It introduced blobs but still requires all nodes to download every blob.

Full Danksharding is the complete design, where nodes only need to verify small random samples of data rather than downloading everything.

Here's how they compare:

Proto-Danksharding (EIP-4844) went live on March 13, 2024 as part of the Dencun upgrade. It introduced a new transaction type, blob-carrying transactions, that let rollups post data in temporary "blobs" instead of expensive calldata. Rollup fees dropped 80–90% almost immediately.

Full Danksharding takes this further: 64 blobs per block instead of 6, combined with Data Availability Sampling so the network can handle that scale without centralizing around high-bandwidth nodes. As of mid-2026, the Ethereum Foundation describes full danksharding as "several years away," with no concrete mainnet activation date.

The blob count has been increasing gradually:

• 3 blobs/block at EIP-4844 launch
• 6 target / 9 cap after Pectra (May 2025), via EIP-7691
• 16 → 32 → 64 as DAS infrastructure matures

The Four Technical Pillars of Full Danksharding

Full Danksharding is four interlocking components that all need to be in place before the design can work at scale.

Data Blobs: The Raw Material

Blobs are large, temporary data packets attached to Ethereum blocks specifically to carry rollup data. They are fundamentally different from regular on-chain data in two ways:

1. The EVM cannot read them. Blobs are stored on the consensus layer (Beacon Chain), not the execution layer. The EVM only sees a small cryptographic reference, not the blob itself.
2. They self-delete. Blobs are automatically pruned after approximately 18 days (~4,096 epochs). Rollups only need this data for a short window to validate transactions. There's no reason to keep it forever.

Each blob holds ~128 KB of data. At 64 blobs per block, full danksharding provides roughly 8.2 MB of DA throughput per block – a ~22x increase over the current post-Pectra cap.

Blobs also have their own fee market, separate from regular gas. The pricing follows an EIP-1559-style mechanism – dynamic and based on supply/demand – so blob fees don't compete with regular transactions for the same block space.

KZG Commitments: The Cryptographic Glue

KZG (Kate-Zaverucha-Goldberg) is the polynomial commitment scheme at the core of danksharding's cryptography. Here's what it does in plain terms:

• It compresses an entire blob (128 KB of data) into a single small point on an elliptic curve – the "commitment."
• It allows anyone to prove that a specific value exists within that blob without revealing the full blob contents and without processing every byte.
• It is compatible with zero-knowledge proofs, making it a natural fit for ZK rollups that already use ZK-based verification.

The KZG ceremony, a one-time trusted setup required to generate the cryptographic parameters, concluded with over 140,000 contributions. The security assumption is that at least one contributor deleted their randomness, which is considered highly probable at that scale.

ByteByByte's take:

KZG commitments solve a problem that sounds impossible on paper: letting anyone verify a large piece of data without actually downloading it. Compress an entire blob into a single elliptic curve point, then prove any specific value belongs to it without revealing the rest. That's the reason danksharding is viable in practice. Without KZG, data availability sampling has nothing to authenticate the samples it checks. With it, even a 2 KB sample carries enough information to be trustworthy. The 140,000-contributor KZG ceremony that preceded EIP-4844 was Ethereum's way of distributing the trust that makes the whole system safe. No single entity holds the keys. That's the point.

Data Availability Sampling (DAS): The Scale Enabler

DAS is the upgrade that makes 64 blobs per block actually feasible. Without it, every node would need to download 8.2 MB per block – a bandwidth requirement that would push out home validators and centralize the network.

How it works:

1. Blob data is encoded with erasure coding – a technique that adds redundancy so the original data can be reconstructed even if a portion is missing.
2. Each blob is broken into small cells (~2 KB each).
3. Light nodes randomly sample a small number of cells. If they can retrieve their samples successfully, they can be statistically confident the full data is available even without downloading everything.
4. Each sample is authenticated against the KZG commitment, so a malicious node can't fake a valid response.

The guarantee is probabilistic, but it becomes very strong as more nodes sample independently. A block proposer trying to withhold data would almost certainly be caught within the first few rounds of sampling.

PeerDAS is the peer-to-peer networking implementation of DAS. It shipped as part of the Fusaka upgrade (December 2025), establishing the foundation for the blob count increases that full danksharding requires.

Proposer-Builder Separation: The Decentralization Guardrail

At 64 blobs per block, generating KZG proofs for ~8 MB of blob data per block becomes computationally expensive. If every validator had to do this work, it would require hardware far beyond what a home staker can afford, gradually pushing out smaller participants and centralizing the validator set.

PBS solves this by splitting the block production process into two roles:

• Builders: specialized entities that construct blocks and handle the expensive proof generation work.
• Proposers (validators): choose from available blocks without needing to do the heavy computation themselves.

This separation means home stakers can continue validating without investing in high-end hardware. Decentralization is preserved even as the data demands of danksharding increase.

Enshrined PBS (ePBS) – a version of this separation baked directly into the protocol rather than relying on external MEV-Boost software – is targeted for the Glamsterdam/Hegotá upgrades in H2 2026.

What Danksharding Does for L2 Rollups and DeFi Users

For everyday users, the most immediate effect is that L2 transaction fees get dramatically cheaper, even at peak network demand.

Proto-Danksharding already cut L2 fees 80–90% after March 2024. Full Danksharding pushes this much further. With 64 blobs per block and near-zero marginal cost per blob, rollups can serve hundreds of millions of users without data costs becoming a bottleneck again.

What becomes possible:

• Sub-cent fees on L2s, even during high demand
• Hundreds of rollups operating simultaneously without competing for the same blobspace
• DeFi protocols, payments, gaming, and AI agent micropayments that are economically viable at scale
• Tokenized real-world assets settling cheaply at high volume

But Ethereum's native DA isn't the only option rollups have.

While danksharding is still being built out, a competitive market for data availability has emerged. Celestia offers lower costs by focusing exclusively on DA and using its own validator set. EigenDA leverages restaked ETH for security and offers "Reserved Throughput" tiers, allowing rollups to lock in predictable monthly bandwidth costs rather than competing in Ethereum's blob fee market. Data availability currently accounts for roughly 90% of L2 operating costs post-EIP-4844, which means rollups are increasingly choosing DA layers based on economics rather than ideology.

The tradeoffs are real. Celestia and EigenDA offer lower costs today, but they introduce different trust assumptions. Rollups using them are no longer anchored to Ethereum's native security. Danksharding is Ethereum's long-term answer. Native DA that inherits Ethereum's consensus security, with no external trust layer required. If Ethereum is live, the data is available.

Where Is Danksharding on the Ethereum Roadmap Right Now?

Timeline:

There's active debate about the pace. Dankrad Feist himself argued in July 2026 that the three-to-four-year roadmap timeline "is very slow" and that the Foundation "should be ambitious and get it done in ~1 year." Others pushed back, noting that underpromising is the safer approach given Ethereum's history of delayed upgrades.

What's clear is that each upgrade ships a working piece of the puzzle – Proto-Danksharding, PeerDAS, ePBS – rather than attempting one massive release. The staged approach reduces risk and lets each component be stress-tested in production before the next layer is added.

Sources and Further Reading

• Ethereum Foundation – "Danksharding" https://ethereum.org/roadmap/danksharding/
• Ethereum Foundation – "Ethereum Roadmap" https://ethereum.org/roadmap/
• Ethereum Improvement Proposals – "EIP-4844: Shard Blob Transactions" https://eips.ethereum.org/EIPS/eip-4844
• Vitalik Buterin – "Proto-Danksharding FAQ" https://notes.ethereum.org/@vbuterin/proto_danksharding_faq
• Dankrad Feist – "KZG Polynomial Commitments" https://dankradfeist.de/ethereum/2020/06/16/kate-polynomial-commitments.html
• Ethereum Consensus Specs – "PeerDAS (EIP-7594)" https://github.com/ethereum/consensus-specs/blob/dev/specs/_features/eip7594/das-core.md
• Ethereum Foundation – "Data Availability" https://ethereum.org/developers/docs/data-availability