Sharding is the general idea of splitting a blockchain’s transaction processing across multiple parallel “shards”, each of which handles a subset of the network’s activity. The total throughput of the system is then the sum of what each shard can process, instead of being capped by the single-threaded throughput of one chain. Sharding is borrowed directly from traditional database design, where the same approach has been used for decades to scale large databases across multiple machines. Applied to blockchains, it is one of a small set of architectural approaches for scaling beyond what a single chain can do.
The concept sounds clean in the abstract, and it was one of the main pillars of Ethereum’s scaling roadmap for years. “Sharded Ethereum” would have 64 parallel shard chains, each processing its own subset of transactions, with cross-shard communication handled by a beacon chain coordinating everything. The original vision, articulated around 2018-2020, was that sharding would give Ethereum effectively unlimited throughput by letting the system scale horizontally as more shards were added.
The plan has changed significantly since then. The rollup-centric roadmap, which Vitalik Buterin formalised in 2020, shifted the focus from sharding as a way to scale execution to sharding as a way to scale data availability for rollups. In this view, the base layer does not need to do sharded execution — it just needs to provide enough data bandwidth for rollups to post their transaction data cheaply. The execution happens on the rollups; the L1 scales by providing more space for rollups to use.
Danksharding and Blob Transactions
The specific form of data-availability sharding that Ethereum is pursuing is called danksharding, named after researcher Dankrad Feist. The idea is that validators will sample random pieces of large blocks of data without downloading the whole block, using techniques from data-availability sampling and KZG polynomial commitments, so that the network can handle much more data throughput than any single node needs to process.
The first step in this direction shipped in March 2024 as EIP-4844 (proto-danksharding). This introduced a new transaction type called a blob transaction, which lets rollups post data in a dedicated “blob” space that is cheaper than ordinary calldata but is automatically deleted after 18 days (since it is only needed for the rollup to prove correctness during that window). The result was a roughly 10x reduction in the cost of posting rollup data to L1, and a corresponding 10x reduction in the cost of an L2 transaction for end users. EIP-4844 is the closest thing Ethereum has shipped to “real sharding” so far, and it has been notably successful on its own terms — blob space is actively used by every major rollup, and the fee savings have been substantial.
Full danksharding is still on the roadmap but is a multi-year effort. The main challenges are around the cryptographic primitives (making KZG commitments efficient enough for production validators to use), the distributed protocol for data-availability sampling, and the coordination of the many components that need to work together. Most Ethereum researchers expect it to ship over the next several years in incremental steps rather than as one big upgrade.
What Happened to Execution Sharding
The original plan to do execution sharding — having multiple parallel shards each running their own EVM — was effectively abandoned in favor of the rollup-centric approach. The reasoning: execution sharding is very hard to get right, cross-shard composability is a deeply unsolved problem, and rollups can deliver similar benefits (more execution capacity for end users) with a much simpler architectural layer. A rollup gets you multiple parallel execution environments (each rollup is effectively a separate execution shard), inherits security from L1, and solves the cross-execution-environment problem through the clarity of “this rollup or that rollup” rather than “shard 3 or shard 17”.
Other chains have continued to pursue execution sharding in various forms. Near Protocol uses a sharded design (Nightshade) from the start. Polkadot’s parachain model is conceptually similar to sharding — each parachain is like a shard of the relay chain. Cosmos’s interchain model is a related but differently-structured approach. None of these have achieved the level of activity that Ethereum’s rollup ecosystem has, and the general trajectory of the industry is that execution sharding has been less successful in practice than its advocates predicted in 2018-2020.
Why This Matters for Understanding Ethereum
If you read Ethereum articles from 2018-2020, you will see a lot of references to “Eth 2.0”, “sharded Ethereum”, “shard chains”, and “execution shards” that describe a vision Ethereum never actually built. The terminology is somewhat confusing because parts of what was called “Eth 2.0” did ship (the Merge, the Beacon Chain, proof-of-stake) while other parts (execution sharding) quietly became “not happening as originally planned”. When you see old articles referencing sharding as Ethereum’s scaling path, they are describing an older roadmap that has been partially replaced. The current scaling path is rollups + data-availability sharding, and the word “sharding” by itself has mostly faded from Ethereum discussion in favor of more specific terms like “blob space” and “proto-danksharding”.