Sharding

What is sharding, and how does it differ from the common assumption of "splitting a chain into multiple chains"?

The earliest intuitive understanding of sharding was indeed "splitting one chain into several parallel chains (shards), each processing a portion of transactions" — a design called execution sharding. Ethereum's original sharding plan followed exactly this direction, intending to split into 64 parallel chains. But this design was later abandoned because Layer 2 rollups proved able to handle transaction execution effectively sooner than expected, removing the need for the main chain to shard execution itself.

Today, sharding mostly refers to data sharding (concretely implemented as danksharding) — an entirely different concept. The main chain itself remains a single chain and isn't split into multiple chains; what gets sharded is the task of verifying data availability. Nodes don't need to download all the data to confirm it genuinely exists and hasn't been tampered with — sampling a small portion is enough to confirm the integrity of the entire dataset with high probability.

Why does sharding exist, and what problem does it solve?

Blockchain scalability faces a fundamental dilemma: if every node is required to fully download, verify, and store all transaction data, fewer and fewer nodes can afford the necessary hardware and bandwidth as usage grows, gradually pushing the network toward centralization. But if that requirement is relaxed and nodes only verify part of the data, how do you ensure the unverified portion is honest and complete?

Sharding is designed to resolve exactly this tension: maintaining high confidence in the integrity of the entire network's data without requiring every node to process all of it. On Ethereum's data sharding path specifically, the problem being solved is that Layer 2 rollups need to post large volumes of transaction data back to the main chain to inherit its security, but the main chain's data bandwidth is limited. Sharding — through data availability sampling — lets the main chain safely carry far greater data throughput than before, without requiring every node to download all of it.

How does sharding actually work, and where does Ethereum's data sharding implementation currently stand?

Ethereum's data sharding path has progressed through several stages. The first step was EIP-4844 (proto-danksharding), activated via the Dencun upgrade in March 2024, which introduced a new transaction type called blobs, letting Layer 2s post data back to the main chain far more cheaply than before — though this stage did not yet introduce true data availability sampling. The second step is PeerDAS (Peer Data Availability Sampling), introduced via the Fusaka upgrade, which lets nodes verify with high probability that an entire batch of data is genuinely available by sampling only a small random portion, without every node needing to download all blob data — a key step toward full danksharding.

The goal of full danksharding is to substantially increase, by another order of magnitude, how much data the main chain can carry — directly affecting how much transaction volume Layer 2 rollups can process cheaply and securely, rather than directly speeding up transaction execution on the Ethereum main chain itself. This is also why understanding sharding requires first distinguishing that it addresses a "data availability" problem, not an "execution speed" problem.

What does sharding mean for me, and what should I watch for?

If you primarily use Layer 2 networks (various rollups) rather than operating directly on the main chain, progress on sharding technology directly shows up in the fees you actually experience — data sharding substantially lowers the cost for Layer 2s to post data back to the main chain, which is one of the key technical reasons Layer 2 fees have kept dropping in recent years. Once full data sharding launches, this downward trend is expected to continue.

Worth noting: the term "sharding" refers to different technical approaches depending on the era and context in which it's used. Earlier articles may be discussing the now-abandoned execution sharding plan, while more recent articles are discussing data sharding / danksharding — two entirely different technical paths solving different problems. When encountering the term "sharding," it's worth first confirming which era and which specific implementation an article is discussing, so an outdated plan doesn't get mistaken for the current state of the technology.