Danksharding is Ethereum’s long-term plan for handling far more rollup data without turning the main network into an increasingly costly place to run every transaction. The basic idea is straightforward: Ethereum provides security, settlementand data availability, while Layer 2 rollups do most of the transaction processing.
What Danksharding Is Meant to Do
Ethereum was not designed to have every node execute every action from every request forever. That approach is secure, but it becomes expensive as usage grows. Danksharding points Ethereum toward a more modular model, where the base layer remains the shared trust anchor and rollups take on much of the day-to-day execution.
In practice, Ethereum mainnet is expected to focus on ordering transactions, reaching consensus, settling results, and making rollup data available. Rollups can then handle user transactions in their own environments while still relying on ethereum for finality and security. This lets different rollups compete on speed, proving methodsand application design without needing separate security models. ()
The first major step in this direction was proto-danksharding, introduced through EIP-4844. It added blob-carrying transactions, which give rollups a dedicated way to publish batch data. That data is available for a limited period rather than being kept forever as ordinary execution calldata. ()
Put simply, Ethereum provides the secure shared layer, rollups execute transactionsand blobs carry the temporary data rollups need to remain verifiable.
Why Blobs Matter for Rollups
Before blobs, rollups generally published transaction data through calldata, which becomes part of Ethereum’s permanent execution history. That works, but it is not an ideal fit for data that primarily needs to be available long enough for a rollup to verify its history, reconstruct its stateor challenge an invalid claim.
Blob data is built for that narrower job. A rollup can batch many transactions, process them off the main chainand publish the necessary data to Ethereum in a blob. Ethereum can verify commitments to that data and make it available for the required period, without treating every byte as permanent smart-contract input.
This can reduce one of the biggest costs for rollups: publishing data back to Ethereum. It does not mean Ethereum stops verifying or securing rollup activity. Rather, it separates two jobs that do not need to be handled in the same way: high-volume execution happens on the rollup, while Ethereum provides the settlement layer and the data availability that keeps the rollup accountable.
Proto-Danksharding: The First Step
proto-danksharding is not full danksharding. it is the practical starting point that introduced the blob-based approach without waiting for every part of the broader design to be ready.
That distinction is important. Proto-danksharding already gives rollups a more suitable channel for publishing transaction data, but it does not yet represent the final scale envisioned for Ethereum’s data-availability layer. its value is immediate and structural: it changes how rollups interact with Ethereum and makes the network better suited to a rollup-centered future.
For users,the clearest effect is usually indirect. When rollups can publish their data more efficiently, they may be able to offer lower transaction fees than they coudl when relying entirely on ordinary calldata. Actual fees will still depend on demand,batching practices,and the conditions on both Ethereum and the rollup itself.
Data Availability sampling
Full danksharding is expected to expand Ethereum’s ability to make large amounts of data available without requiring every participant to download every byte. A key part of that direction is data availability sampling.
Rather of retrieving an entire dataset, participants can check randomly selected pieces of encoded data.When enough independent samples are available and valid, they provide strong evidence that the full dataset is accessible. The goal is to make it arduous for a block producer to claim that data exists while withholding the actual contents from the network.
This matters as rollups depend on available data. If users, validators, or other participants cannot access the data needed to verify a rollup’s activity, the rollup cannot be trusted in the way it is intended to be. Sampling aims to protect against that problem while keeping bandwidth and storage demands more manageable than a system in which every validator must download everything.
Ethereum’s broader data-availability work is designed around that balance: more room for rollup data, without giving up the decentralization that makes the base layer valuable in the first place. ()
How rollups Benefit
Rollups already reduce pressure on Ethereum by processing many transactions away from the main chain and posting the information needed to verify those results back to it. Their economics, however, are closely tied to the cost of publishing that information.
Blobs give rollups a purpose-built data channel, which can make batch publication less expensive than using permanent calldata for the same purpose. That may help optimistic rollups, which rely on data being available for challengesand zero-knowledge rollups, which publish proofs and related transaction data.
The important point is that danksharding does not replace rollups. It supports them. Ethereum remains the common settlement and security layer, while rollups handle much of the transaction volume that would otherwise compete for scarce mainnet block space.
For applications involving frequent activity-such as payments, games, exchanges, or social applications-lower data-publication costs could make Layer 2 networks more practical. The outcome will vary by rollup and network conditions,but the direction is clear: Ethereum is being shaped to support more execution happening above the base layer.
What Developers Should Keep in Mind
Developers working with rollups should treat blob data as temporary data availability, not as permanent storage or ordinary EVM-accessible contract state. Anything an application must preserve for the long term should be stored through an appropriate archival strategy rather than assuming blob contents will remain available indefinitely.
It also helps to account for the separate costs of execution gas and blob gas. Rollup operators, infrastructure providersand wallets may need to consider both when estimating fees, building batchesand presenting costs to users.
- Test blob submission and retrieval flows before relying on them in production.
- Verify commitments, hashesand proofs independently where the protocol requires it.
- Plan for delayed inclusion,limited blob retention,and incomplete RPC support.
Teams should avoid hard-coding assumptions about future capacity. Danksharding is a roadmap directionand Ethereum’s data layer will continue to evolve. Versioned interfaces around batch construction, data publicationand proof verification can make that evolution easier to manage.
Conclusion
So, what is danksharding? It is indeed Ethereum’s planned approach to scaling data availability for a world where rollups handle much of the execution. Proto-danksharding and blobs have already established the foundation, while fuller danksharding is intended to increase capacity further through techniques such as data availability sampling.
The larger shift is architectural. Ethereum does not need to execute every transaction itself to remain the system that secures and settles them. By giving rollups a cheaper, more scalable way to publish data, it can support a broader ecosystem of Layer 2 networks while preserving the role of the base chain as the shared source of trust. ()
