{"id":3064,"date":"2026-08-24T10:08:27","date_gmt":"2026-08-24T10:08:27","guid":{"rendered":"https:\/\/nownodes.io\/blog\/?p=3064"},"modified":"2026-08-24T10:08:28","modified_gmt":"2026-08-24T10:08:28","slug":"what-is-ethereum-sharding-from-shard-chains-to-danksharding","status":"publish","type":"post","link":"https:\/\/nownodes.io\/blog\/what-is-ethereum-sharding-from-shard-chains-to-danksharding\/","title":{"rendered":"What Is Ethereum Sharding? From Shard Chains to Danksharding"},"content":{"rendered":"\n

Ethereum sharding is the effort to split the network’s data and validation work into smaller pieces, so it can handle more activity without forcing every single node to process every single byte. That’s the short definition \u2014 but it’s also slightly behind the times. The shard chains Ethereum designed back in 2020 were never shipped, and what the network actually runs today under that name is a different mechanism called danksharding, live in part since March 2024.<\/p>\n\n\n\n

Here’s Ethereum sharding explained the way it actually happened, not the way older roadmaps described it: what the term originally meant, why Ethereum walked away from it, and what runs in its place right now. Search for eth sharding today and plenty of results still describe the abandoned plan, so it’s worth being precise about which version applies in 2026.<\/p>\n\n\n

What Does Sharding Mean in Crypto?<\/h2>\n\n\n
\"\"<\/figure>\n\n\n\n

Sharding started as a database technique: instead of one server holding an entire dataset, the data gets split into pieces \u2014 shards \u2014 spread across several servers that each handle a slice of the load. Sharding in blockchain systems borrows that same logic. Rather than every node storing and verifying a network’s entire history, the job gets divided into smaller, more manageable chunks.<\/p>\n\n\n\n

Shard:<\/strong> a partition of a larger dataset or network, small enough for a limited set of participants to store and verify, that combines with other shards to form the complete system. See the Ethereum Foundation’s danksharding overview<\/a> for how the concept applies to blockchains.<\/p>\n\n\n\n

The appeal of a sharding blockchain design is straightforward: a node that only tracks a fraction of total activity needs less bandwidth, storage, and computing power, which keeps the hardware bar low enough for ordinary people to keep participating. That’s the trade-off sharding is built to solve \u2014 more total capacity without raising what each participant needs to run.<\/p>\n\n\n

How Does This Apply to Ethereum?<\/h3>\n\n\n

On Ethereum specifically, “sharding” has referred to two very different designs over the network’s history. The original 2020-era plan called for roughly 64 independent shard chains, each processing its own transactions under coordination from the Beacon Chain. That plan was shelved before it shipped, and Ethereum sharding today means something narrower: splitting up the job of storing and verifying data for Layer-2 rollups, not splitting up transaction execution itself.<\/p>\n\n\n

Why Did Ethereum Need to Scale?<\/h2>\n\n\n

The case for sharding Ethereum’s data load starts with a hard limit: every full node has to process every transaction, so the whole network can only move as fast as an average computer can keep up. Ethereum’s base layer settles around 26 transactions per second on its own, according to CoinLaw’s 2026 chain-comparison data<\/a> \u2014 nowhere near what a busy consumer app needs.<\/p>\n\n\n\n

Pushing that number up the naive way, with bigger blocks or faster block times, trades away decentralization, since fewer people can afford the hardware to keep up. That tension is what the blockchain trilemma<\/a> describes, and it’s exactly what both the original sharding plan and danksharding were built to loosen.<\/p>\n\n\n\n

Layer-2 rollups solved execution scaling years ago by moving computation off Ethereum’s base layer, but they still had to publish their transaction data back to L1 so anyone could verify it. Before March 2024, that data rode inside ordinary Ethereum transactions and competed for the same block space as everything else, which kept rollup fees higher than they needed to be. Sharding, in its current form, exists to fix that specific bottleneck.<\/p>\n\n\n

How Ethereum’s Plan Changed: From Shard Chains to Blobs<\/h2>\n\n\n

Here’s the part most explainers skip: Ethereum didn’t add danksharding on top of the old sharding design \u2014 it replaced it. The Ethereum Foundation is explicit about this<\/a>: shard chains are no longer part of the roadmap at all, because rollups turned out to scale execution faster and more safely than splitting the base layer ever could.<\/p>\n\n\n\n

Vitalik Buterin has framed the shift as a deliberate choice, not a retreat. “Our task is to bring the rollup-centric roadmap to completion, and solve these problems, while preserving the robustness and decentralization that makes the Ethereum L1 special,” he wrote in October 2024, describing the merged rollup-and-data-sharding strategy as Ethereum’s scaling path going forward<\/a>, not an interim step.<\/p>\n\n\n\n

The actual ethereum sharding timeline, then, is a sequence of upgrades that gradually built out data availability instead of shard chains:<\/p>\n\n\n\n

Date<\/th>Upgrade<\/th>What changed<\/th><\/tr><\/thead>
Sept 15, 2022<\/td>The Merge<\/td>Ethereum moved to Proof of Stake, the base later upgrades built on<\/td><\/tr>
March 13, 2024<\/td>Dencun (EIP-4844)<\/td>Proto-danksharding launches: blob transactions go live, target 3 \/ max 6 blobs per block<\/td><\/tr>
May 7, 2025<\/td>Pectra (EIP-7691)<\/td>Blob capacity raised to target 6 \/ max 9<\/td><\/tr>
Dec 3, 2025<\/td>Fusaka<\/td>PeerDAS (data availability sampling) goes live, letting nodes verify blobs without downloading all of them<\/td><\/tr>
Dec 2025 \u2013 Jan 2026<\/td>BPO1 \u2192 BPO2 forks<\/td>Blob capacity stepped up again to target 14 \/ max 21, without a full network upgrade<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n

Dates and blob figures per ethereum.org’s roadmap<\/a> and the Ethereum Foundation’s January 2026 checkpoint post<\/a>.<\/p>\n\n\n\n

That timeline also answers a question a lot of people still search for: there is no single “Ethereum 2.0 sharding date,” because Ethereum 2.0 stopped being the project’s name years ago, and the shard-chain feature that name once promised never launched under any date. What did launch is the danksharding sequence above, and it’s still moving \u2014 the next scheduled upgrade, Glamsterdam, is targeted for Q4 2026.<\/p>\n\n\n

What Is Danksharding, and How Do Blobs Actually Work?<\/h2>\n\n\n
\"\"<\/figure>\n\n\n\n

Danksharding:<\/strong> an Ethereum scaling design, named after Ethereum Foundation researcher Dankrad Feist, that shares the job of storing and checking rollup data across the validator set instead of splitting transaction execution into separate chains. See the official roadmap page<\/a>.<\/p>\n\n\n\n

Blob:<\/strong> a temporary 128-kilobyte packet of data a rollup attaches to an Ethereum transaction, cheaper than ordinary calldata and pruned after roughly 18 days. Defined in EIP-4844<\/a>.<\/p>\n\n\n\n

A rollup such as Arbitrum, Optimism, or Base bundles thousands of user transactions, compresses them, and attaches the result to an Ethereum transaction as one or more blobs instead of stuffing it into ordinary calldata. Blobs get their own, separate fee market, so a busy NFT mint or DeFi rush on Ethereum’s main chain doesn’t spike the cost of publishing rollup data at the same time. That separation is a big part of why fees on most rollups dropped sharply once proto-danksharding launched in 2024.<\/p>\n\n\n\n

The harder problem danksharding solves is trust: how does a node confirm a blob’s data is real without downloading all 2.6-plus megabytes of it per block? The answer is data availability sampling \u2014 checking small random pieces of a blob and using math to confirm the whole thing is there, an approach PeerDAS brought to Ethereum’s mainnet with the Fusaka upgrade in December 2025.<\/p>\n\n\n\n

Dankrad Feist, the Ethereum Foundation researcher the technique is named after, has argued the term itself undersells what’s happening. “It seems to me that we should rename data availability to data publishing,” he said at the Permissionless conference in 2023<\/a>, pointing out that the network isn’t just confirming data exists somewhere \u2014 it’s making sure the data actually got published where anyone can reach it.<\/p>\n\n\n\n

As of the most recent BPO fork, Ethereum targets 14 blobs per block and allows up to 21 \u2014 roughly 2.6 to 2.7 megabytes of rollup data per block, about a 2.3x jump from before Fusaka. Full danksharding, the eventual end state, aims for 64 blobs per block: coincidentally the same number of shard chains the original 2020 plan called for, though this time the number describes data slots, not independent execution chains.<\/p>\n\n\n

Who Actually Relies on Ethereum’s Data Sharding?<\/h2>\n\n\n

Danksharding is infrastructure, so most people who benefit from it never touch a blob directly. Four groups feel it most:<\/p>\n\n\n\n