What Proto-Danksharding Changes
What is proto-danksharding? Put simply, it is Ethereum’s first major step toward full danksharding: a way to make publishing rollup data less expensive without turning that data into permanent Ethereum history.
Introduced through EIP-4844, proto-danksharding created a separate transaction type for large packages of rollup data called blobs. Before this change, rollups typically posted their batch data as calldata. Calldata remains useful,but it is permanent transaction data and competes directly with other activity for Ethereum block space. Blobs are different. They are made available to the network for a limited period, giving rollups time to verify and reconstruct batches without adding the same long-term storage burden to ethereum.
That distinction gets to the heart of the design. Rollups do not need Ethereum to execute every transaction in a batch individually. They need users,verifiers,and other participants to be able to obtain the underlying data and check the rollup’s work. Blob transactions provide that data-availability layer while Ethereum continues to handle settlement and security.
Proto-danksharding is not the finished version of danksharding.It does not yet deliver the full data-availability system Ethereum intends to build over time. What it does provide is the basic model: blob transactions, cryptographic commitmentsand a separate market for data availability. That gives rollups something useful now while preparing the protocol for larger-scale changes later.
How Blobs Affect Layer two Fees
EIP-4844 introduced blob-carrying transactions, which let rollups publish batch data without putting that data into Ethereum’s permanent execution history. A blob is attached to a transaction and represented by a cryptographic commitment. The EVM can work with that commitment, but it cannot freely read the blob’s contents during normal contract execution. That is intentional: the goal is data availability, not another form of on-chain storage. ([eips.ethereum.org](https://eips.ethereum.org/EIPS/eip-4844?utm_source=openai))
For rollups, this can materially change the cost of submitting batches to Ethereum. Posting data as calldata uses the ordinary gas market.Blob data has its own fee market, so the price of publishing a batch is no longer tied as closely to calldata demand. This does not make rollup transactions cheap in every situation, but it gives rollups a more suitable channel for a cost that can otherwise be significant. ([ethereum.org](https://ethereum.org/developers/docs/data-availability/blockchain-data-storage-strategies/?utm_source=openai))
There is no guaranteed discount. Blob fees still respond to demandand a busy blob market can make batch posting more expensive. A user’s final fee on a Layer Two network also depends on the rollup’s own choices, including batch size, compression, proof costs, sequencer policyand how many users share the cost of a submission. ([ethereum.org](https://ethereum.org/roadmap/danksharding?utm_source=openai))
Still, the practical effect is clear: blobs separate temporary rollup data from ordinary execution demand. That creates room for rollups to reduce their data-publication costs when blob space is available, without relying on Ethereum to store every byte forever. ([eips.ethereum.org](https://eips.ethereum.org/EIPS/eip-4844?utm_source=openai))
The Road to full Danksharding
Proto-danksharding matters as it gives Ethereum a working version of a more data-focused scaling model. Rollups can publish their data in blobs, validators can verify the relevant commitmentsand the protocol can price data availability separately from computation. Those are not side details; they are the building blocks for what comes next.
Full danksharding is intended to expand the amount of blob data Ethereum can support while keeping validation practical. The long-term plan includes data availability sampling, a technique designed to let participants gain confidence that data is available without requiring every node to download and process every piece of it likewise.
That is why proto-danksharding should not be viewed only as a rollup-fee change. It is also a transition in how Ethereum thinks about scaling. Rather than asking the base layer to execute ever-growing volumes of activity, the network can focus on making data available, settling resultsand enforcing the rules that let rollups remain verifiable.
What Validators Still Need to do
Blob transactions add data-availability responsibilities,but they do not create a separate security system or a new class of validator. Ethereum remains proof-of-stakeand validators still secure the chain by proposing, checkingand attesting to blocks under the protocol’s rules. A blob-carrying block must satisfy those rules before honest validators accept it.
Block proposers include valid blob transactions and their associated commitments. Other validators independently check the proposed block rather than taking the proposer’s word for it. Nodes also retain and serve blob data during the protocol’s availability window. The details differ from ordinary transaction execution, but the principle is familiar: a block is accepted because participants can verify that it follows the rules.
Data availability is essential here.A cryptographic commitment is useful only if the data it represents can be obtained and checked when the protocol requires it.Ethereum does not need to preserve blob contents as permanent execution data, but it does need participants to enforce the conditions that make the published data accountable in the first place.
in that sense, proto-danksharding changes the handling and economics of large data payloads without weakening the verification standards that protect Ethereum. It remains a decentralized platform for smart contracts and applications; blobs simply give it a more efficient way to support networks that publish large amounts of temporary batch data.
What Rollup Teams Should plan For
For Layer Two developers, blobs should be treated as a distinct data-availability path, not as a drop-in archival replacement for calldata. A rollup still needs a clear answer to several basic questions: what data it publishes, how users and provers retrieve itand how its system continues to function after Ethereum’s blob-retention period ends.
That makes self-reliant archiving crucial.Blob data may be enough to support timely verification and state derivation, but it is not meant to be a permanent historical database. Rollups should keep durable copies of the data needed by users, indexers, recovery toolsand their own infrastructure. They should also make sure their node software can retrieve blob data and verify that it matches the commitment attached to the Ethereum transaction.
fee policy deserves the same attention. Blob fees and execution gas are separate costs, so a batcher that watches only ordinary gas prices may make poor submission decisions. Teams need policies for batch sizing, fee limitsand delayed publication that do not compromise the rollup’s safety or liveness when blob prices rise.
It is also worth testing the awkward cases before they become production problems: delayed blob retrieval, malformed batch data, chain reorganizations near publicationand missing off-chain archives.A transaction receipt alone should not be treated as a complete record of a rollup’s history. The underlying batch data and its commitment must remain usable by the people and systems that need to verify it.
What to Watch as Adoption Grows
As Ethereum moves from proto-danksharding toward fuller danksharding, blob usage, blob feesand rollup transaction costs will be useful indicators. A single period of low fees says little on its own.More meaningful is whether rollups can keep publishing data affordably as demand grows, while the network remains accessible to validators and node operators.
Cost is only part of the picture. Block propagation, validator participation, missed slots, and client performance can show whether higher data-availability demand is putting stress on the network.Ethereum’s security depends in part on broad participation, so scaling improvements should not quietly make it impractical for smaller operators to run the software needed to verify the chain.
There are practical risks to monitor as well. Blob demand could become concentrated among a small number of major rollups, fee swings could make data-publishing costs less predictableand differences between client implementations may matter more during heavy use. It will also be important to see whether lower publication costs are actually passed on to users rather than remaining only an operational benefit for rollup operators.
Proto-danksharding is a preliminary step, not the final destination. Its value lies in giving Ethereum and its rollup ecosystem a usable framework for cheaper, temporary data publication today while laying the groundwork for a much larger data-availability system tomorrow. The real measure of success will be whether Ethereum can expand that capacity without giving up the verification, resilienceand decentralization that make the network valuable.
