What Is Danksharding?

Ethereum's data availability roadmap has a specific destination. It's called Danksharding, named after Ethereum researcher Dankrad Feist, who formalized the design in 2022. The concept unfolds in stages: proto-danksharding shipped in March 2024, PeerDAS is in active development, and full Danksharding is further out still. Each step adds capacity. The full design is a meaningfully different beast from what's running today.

If you've seen "EIP-4844" and "Danksharding" used interchangeably — they're not the same thing. EIP-4844 was the on-ramp. It introduced blob transactions and a blob fee market without implementing the scaling architecture that Danksharding actually requires. Full Danksharding is the architecture.

The Problem Being Solved

Rollups post compressed transaction data to Ethereum to inherit its security. The more rollup activity there is, the more data needs to land on Ethereum. Data posting is the bottleneck — it's what limits how cheap rollup transactions can get.

Before EIP-4844, rollups posted data as calldata, which competes with regular transactions for block space and gas. EIP-4844 created a separate blob data market, which helped substantially. As of mid-2026, Ethereum supports a target of 3 blobs per block (up to 6), each roughly 128 KB. That's around 375 KB of blob data per block.

Full Danksharding targets roughly 64 blobs per block — approximately 8 MB per block — with some designs targeting up to 128 blobs and 16 MB. That's one to two orders of magnitude more data than proto-danksharding delivers.

Getting from 3 blobs to 64 blobs isn't a configuration change. The fundamental constraint is that you can't ask every full node to download and store that much more data per block. At 16 MB every 12 seconds, bandwidth requirements become prohibitive for home validators. The design itself has to change.

The Core Innovation: Data Availability Sampling

Danksharding doesn't require nodes to download full blobs. Instead it uses data availability sampling (DAS) — a mechanism where nodes randomly sample small chunks of data and use the results to statistically verify that the full blob is available somewhere on the network.

Here's the mechanism. When a blob is prepared for inclusion in a block, it gets encoded using an erasure code that expands the original data. In Danksharding's specific design, this encoding is two-dimensional: imagine spreading blob data across a grid, then applying erasure coding along both rows and columns independently. Any 50% of the data across both dimensions is sufficient to reconstruct the whole grid. To fool a sampler, an attacker would need to withhold data such that both row and column reconstruction fails simultaneously — which requires hiding a much larger fraction of the data than a one-dimensional erasure code would demand.

A node running DAS samples random cells from this grid. If it receives all requested samples back from the network, it concludes the data is available with high probability. If an attacker is withholding data, they need to selectively hide specific cells — but because sampling is random and independent across many nodes, the probability of fooling even a single node falls exponentially as the number of sampled cells increases. Fool one sampler, and you've failed.

Each cell comes with a KZG polynomial proof — a small (~48 byte) cryptographic commitment that the cell is consistent with what was committed in the block header. Nodes verify samples without downloading the full blob. KZG commitments are already deployed in proto-danksharding; Danksharding extends them to the per-cell level in the 2D grid.

The result: a node can verify data availability for a 16 MB blob by downloading a few kilobytes of random samples. Per-node bandwidth doesn't scale linearly with blob size. This is what makes massive blob counts viable without centralizing the validator set.

The Path from Here: PeerDAS

Full Danksharding requires a purpose-built p2p networking layer designed to distribute blob chunks across the validator set and serve samples on demand. That doesn't exist at mainnet scale yet.

PeerDAS is the intermediate step. It implements a simpler version of distributed blob storage over Ethereum's existing p2p network: validators are organized into groups (subnets), each responsible for storing specific blob columns. Sampling works across these subnets rather than requiring a new network architecture.

PeerDAS doesn't achieve the full security guarantees of 2D DAS — it operates closer to a 1D model, using column sampling — but it's deployable with significantly less infrastructure change and gets the blob count meaningfully higher than the current 3–6 blob target. It's on the roadmap for a near-term upgrade (the Osaka upgrade era or adjacent). No mainnet date is confirmed as of mid-2026, but the specification is substantially more mature than full Danksharding.

Why Proposer-Builder Separation Matters Here

At current blob counts, validators can download blobs, verify them, and attest to their availability without specialized hardware. At full Danksharding scale, block assembly becomes computationally intensive. An entity building a block at 64+ blob capacity needs to receive all blob data, encode it, compute KZG proofs across a two-dimensional grid, and include the results — within a 12-second slot window. That's serious compute.

It can't be done by home validators running consumer hardware.

This is why Proposer-Builder Separation (PBS) is required infrastructure for full Danksharding. PBS separates the roles: block builders (well-resourced, specialized entities) assemble block content and handle blob data; block proposers (validators) simply select from available blocks and sign the best one. Proposers don't process blob data directly — they just attest that they received a valid header committing to it.

Proto-danksharding already benefits from PBS in practice via mev-boost, but that's a voluntary market structure, not a protocol guarantee. Full Danksharding needs PBS enshrined into the protocol. Enshrined PBS (ePBS) is on the Ethereum roadmap but hasn't shipped.

What Would Confirm This Direction

PeerDAS deploying on mainnet and increasing the blob count — say, to 12 or more blobs per block — without network degradation is the first concrete signal. If validators handle the increased load cleanly and rollup fees continue compressing, the DAS approach is working at its current scale.

After PeerDAS: a full 2D DAS specification merged into the Ethereum consensus spec, followed by testnet performance matching expected mainnet conditions under adversarial load. Confirmed blob capacity well above the current 6-blob maximum without reorganization events or latency increases.

What Would Break It

The DAS security model depends on a sufficiently large, independent sampling population. If the validator set becomes highly concentrated — a small number of entities running most validators — the "many independent samplers" assumption weakens. Combined with PBS centralization (a few block builders dominating block production), you get a scenario where data withholding attacks become more viable. The sampling math holds at decentralization; it weakens under consolidation.

A more specific invalidation: if the 2D erasure coding or KZG proof implementation contains bugs allowing inconsistency between a committed blob and its actual content, the security model breaks at its core. The KZG trusted setup ceremony (completed in early 2023, with roughly 141,000 participants contributing randomness) reduced the trusted setup risk substantially. Implementation bugs in the polynomial arithmetic are a separate concern.

Full Danksharding also depends on ePBS working as specified. If enshrined PBS proves incompatible with other Ethereum protocol goals — Single Slot Finality, fork choice stability — it could stall the full Danksharding timeline.

Timing

Now: Proto-danksharding (EIP-4844) is live. Rollups use blob transactions instead of calldata. Target is 3 blobs per block, maximum 6. KZG polynomial commitments are deployed and in active use. This alone reduced major rollup transaction fees substantially after Dencun in March 2024.

Next: PeerDAS. An incremental step toward full DAS via subnet-based column sampling. Specification is active; mainnet deployment is on the near-term development horizon, no confirmed date as of mid-2026.

Later: Full Danksharding — 2D DAS, 64+ blobs per block, enshrined PBS. Requires several pieces of infrastructure that aren't deployed yet. No mainnet timeline has been confirmed. This is a multi-year horizon.

Boundary

This covers the Danksharding design and the staged path toward it — proto-danksharding, PeerDAS, and the full architecture. It doesn't address how individual rollups use blob data internally, the economics of the blob fee market for rollup operators, or execution layer scaling (which rollups handle independently of Ethereum's data layer). Data availability scaling and execution scaling are different problems. Danksharding is only about the former.