What Is Danksharding and Data Availability Sampling?

Why Ethereum cannot just "make blocks bigger"

The pitch for danksharding only makes sense if you first understand the constraint it is solving. Every node on a blockchain has to download, verify, and store every block. If you simply raise the block size from, say, a few hundred kilobytes to several megabytes, you do not get more throughput. You get a higher hardware floor, because the cheapest consumer laptop still has to keep up with the chain.

This is the tension behind the famous blockchain trilemma: a network wants to be decentralized (lots of independent nodes), secure (no easy way to forge history), and scalable (lots of cheap transactions). Cranking up block size improves one property at the expense of the others, because the node requirements rise and the operator count falls.

Ethereum's rollup-centric roadmap is a partial answer. Instead of doing everything on layer 1, you let layer 2 rollups execute thousands of transactions, then post a compressed summary back to Ethereum. Ethereum becomes a settlement and data layer, not a world computer. That works, but it has a bottleneck: the rollups need somewhere cheap and verifiable to publish their data, and that somewhere is currently Ethereum's call data, which is expensive and competes with every other use of block space.

Danksharding is the plan to remove that bottleneck by giving rollups a dedicated, abundant data channel, without forcing every node to download all of it.

EIP-4844: the first step you already saw

Before danksharding can exist, Ethereum shipped proto-danksharding, formalized as EIP-4844, in March 2024. This is the part you may already know under the name blobs.

A blob is a chunk of data attached to a transaction that lives on a separate fee market (often called the blob gas market) and is automatically pruned from the chain after about 18 days. Nodes do not have to execute blob contents; they only have to store them temporarily and prove they were published. Rollups like Arbitrum, Optimism, and Base shifted from posting compressed data as calldata to posting it as blobs, which immediately made rollup transactions several times cheaper.

EIP-4844 is the engineering compromise. It does not change how Ethereum verifies data availability. It still requires every node to download every blob in full to confirm the block is valid. That works at a few blobs per block, but it does not scale to the volumes danksharding envisions.

So think of proto-danksharding as the on-ramp. It introduces the blob transaction format, the separate fee market, and the consensus rules that future danksharding will reuse. Full danksharding is what happens when Ethereum stops forcing every node to download every blob and starts sampling instead.

What "data availability" actually means

The phrase "data is available" sounds obvious, but it has a precise meaning in consensus research. A block is data-available if every honest node can actually fetch the underlying data, not just the header or a commitment to it. Without that guarantee, a malicious block producer could publish a block header that looks valid but withhold the data behind it, and full nodes would have no way to detect fraud or reconstruct the chain.

This is the data availability problem, and it is one of the harder problems in scaling blockchains. It is why light clients on Bitcoin cannot fully verify the chain: they download block headers but trust that someone else is storing the bodies. If a miner ever withholds a block's transactions, a light client cannot tell.

Ethereum wants to give light clients real verification instead of trust. That requires a primitive where a node can confirm a large dataset was published without downloading the dataset. Data availability sampling is that primitive, and danksharding is the Ethereum-specific design that deploys it at consensus level.

Erasure coding: the math that lets samples imply the whole

DAS only works because of erasure coding, a technique borrowed from storage and communication theory. The simplest mental model is to imagine writing a 1 MB file in a spreadsheet, then adding 1 MB of redundant rows that are linear combinations of the original cells. Now you have 2 MB, but you can reconstruct the original 1 MB from any 1 MB of the 2 MB.

In danksharding, block producers do roughly the same thing with blob data. They extend each blob's underlying data with extra parity chunks computed using a Reed-Solomon style code, doubling the on-chain size in exchange for a powerful guarantee: if the data is even partially available, an honest node can reconstruct all of it.

Why does this matter for sampling? Suppose a block producer tries to withhold a quarter of the extended data so that nobody can reconstruct it. That is statistically impossible to hide, because the samples are chosen uniformly at random across the extended dataset. A light node that successfully downloads, say, 30 random chunks and confirms they all match can be mathematically certain (with tunable probability) that the full dataset is reconstructible by someone.

The key insight is that erasure coding converts a download-the-whole-thing problem into a random-spot-check problem. Without it, sampling would be useless, because a malicious producer could withhold a single targeted byte and no spot check would catch it.

How data availability sampling actually runs on a node

In the danksharding design, the chain's data is conceptually arranged as a two-dimensional grid. Each row corresponds to one slot's blob data, and each column is a stripe of extended chunks. A block producer commits to the whole grid using polynomial commitments (KZG commitments in the current plan), which act as a cryptographic fingerprint small enough to fit in a block header.

Light nodes then do the following for each slot:

• Receive the block header and the KZG commitments to the extended data.
• Download a handful of random cells from the grid, asking different peers for different positions.
• Verify each downloaded cell against its commitment. A bad cell fails the check immediately.
• Increase their confidence, with each successful sample, that the full grid is available.

After enough successful samples, the light node treats the data as available. If the block producer tried to withhold even a small fraction of the grid, the probability that all random samples land in the honest portion shrinks exponentially. At a few dozen samples, the failure probability becomes negligible.

This is the part that changes the hardware story. A light node no longer needs to be a beefy server with a fast SSD. It needs to download something on the order of a few kilobytes per slot, then gossip those samples around the network. That keeps solo stakers and home validators competitive, which preserves decentralization.

The risks nobody talks about honestly

Danksharding is technically elegant, but it ships with real failure modes. Honest coverage requires talking about them.

The first risk is the data availability withholding attack. A block producer could still try to publish a header and then withhold enough cells that honest light nodes fail to sample. If the network does not have enough light nodes sampling redundantly, an attacker can grind through the randomness until enough light clients miss the available data and reject the block, causing a liveness failure (the chain stalls). Research mitigations include having multiple block producers per slot and forcing light nodes to wait until the network has had time to gossip samples, but both add latency.

The second risk is the failure mode of erasure coding itself. If a bug or implementation error makes the encoding inconsistent across clients, honest light nodes could reject valid blocks or accept unavailable ones. This is partly why the design relies on KZG commitments, which can prove individual cells are consistent with the header, and why extensive testnets (devnets like the Celestia-inspired da-dedi and EIP-7591 work) are run before mainnet deployment.

The third risk is centralization around infrastructure. Even if the on-paper requirements for a light node are tiny, the real requirements for a full validator (the ones that actually propose and attest to blocks) keep rising. If solo stakers drop out because attestation duties require fancy hardware, the network becomes more centralized regardless of how cheap light clients are.

Finally, there is the social risk of overselling. The phrase "unlimited scalability" gets attached to DAS frequently, and it is wrong. Erasure coding roughly doubles the data footprint, so there is a real cost. Sampling only verifies availability; it does not magically let the network process more execution. Rollups still pay for execution elsewhere, and throughput caps remain, just at a much higher level than today.

Why Celestia, EigenDA, and Avail look similar

Ethereum is not the only team betting on data availability sampling. Celestia launched in late 2023 as a standalone blockchain whose entire job is to be a data availability layer. It uses the same DAS-and-erasure-coding recipe: data is encoded into a 2D grid, light nodes sample random cells, and a KZG-style commitment anchors the whole grid.

The pitch is that rollups and app-chains do not have to live on Ethereum at all. They can post their data to Celestia, pay Celestia fees, and use Ethereum (or any other settlement layer) only for fraud or validity proofs. Celestia positions itself as a modular blockchain piece rather than a smart contract platform.

EigenDA is a different shape. It is a data availability service built on top of EigenLayer, which lets ETH stakers opt in to secure additional services by restaking their collateral. EigenDA's claim is that it inherits Ethereum's economic security, because the operators running its storage network are also Ethereum validators with real slashing exposure.

Avail, originally spun out of Polygon, takes a third path: it positions itself as a data availability layer that can serve many chains, including non-Ethereum ones, and it uses a different polynomial commitment scheme (Kate commitments can be replaced or supplemented by other designs) to stay flexible. Polygon itself has shipped a Polygon POS chain that historically used a different approach, while newer "Polygon CDK" rollups are free to pick any DA layer.

Why does Ethereum bother building its own? Two reasons. First, the Ethereum community wants DA security backed by ETH stakers rather than by a separate token, which keeps the trust assumptions of an Ethereum rollup inside the Ethereum ecosystem. Second, competition is healthy. Knowing Celestia exists forces Ethereum's researchers to ship, and vice versa.

What this means for you as a user or builder

If you are just transacting on Ethereum or on a rollup, danksharding mainly shows up as cheaper fees. Once blobs are abundant and cheap, rollups can post larger batches and squeeze gas down further. The exact numbers depend on blob fee market dynamics and rollup compression improvements, but the directional impact is real: rollup transactions that already cost a few cents can fall to fractions of a cent at high blob counts.

If you are a developer picking a rollup stack, the new decision is which DA layer to use. Choices now include Ethereum native (after full danksharding), Celestia, EigenDA, and Avail, each with different cost, security, and bridge assumptions. A rollup on Celestia is not as deeply tethered to ETH stakers, but it may be cheaper and more flexible. A rollup on EigenDA inherits restaked ETH security but is only as decentralized as EigenLayer's operator set. There is no free lunch.

If you are a staker or home validator, the practical message is more reassuring than alarming. Light client requirements stay low, so the day-to-day hardware floor does not jump the way it would under naive block size increases. Attestation requirements may still rise, but at a more controlled pace, and improvements like enshrined proposer-builder separation aim to reduce the operational burden.

What you should not do is assume danksharding is "finished." As of early 2026 it is still on testnets, with EIP-7591 (PeerDAS, an interim step) being the near-term deployment and full danksharding later. Treating any timeline as guaranteed is a recipe for disappointment.

Stay ahead of the Ethereum scaling roadmap

Danksharding, DAS, blob fees, and competing data availability layers move quickly, and the credible coverage is scattered across research forums, EIP drafts, and core developer calls. Zippfeed aggregates Ethereum scaling headlines with sentiment scoring (bullish, neutral, or bearish) and an importance rating, so you can tell which protocol milestones actually move the needle and which are just reposts.