USDHow Sharding Works
In a sharded design, the network’s responsibilities are split so each participant only needs to handle a portion of the total load. Depending on the design, shards can divide data storage, transaction execution, or both.
Early Ethereum sharding proposals focused on many shard chains where smart contract execution could happen across shards (often called execution sharding). That approach increases throughput by parallelizing computation, but it also introduces complexity around cross-shard communication and security.
Ethereum’s roadmap evolved as rollups became the main way to scale execution. Instead of scaling L1 by running lots of smart contract execution in parallel shards, Ethereum increasingly focuses on scaling data availability (DA)—making it cheap and verifiable for rollups to publish the transaction data needed for independent verification.
A key step is proto-danksharding (EIP-4844), which adds temporary blob data to blocks. Blobs are cheaper than posting rollup data as calldata, are not readable by the EVM, and are pruned after a retention window (about 18 days), limiting long-term node storage growth.
Separately, Ethereum also uses a form of “sharded consensus”: validators are split into committees so each validator processes only a subset of attestations, keeping consensus overhead manageable as the validator set grows.
Example
If a single-lane road is like one blockchain where every node handles every transaction, then sharding is like adding multiple lanes so traffic (work) can move in parallel.
Why It Matters
Sharding is about increasing capacity without forcing every node to do all the work, which helps preserve decentralization. On Ethereum today, “sharding” mostly means cheaper, scalable data availability for rollups—often translating into lower L2 costs and higher ecosystem throughput.
Risks or Limitations
“Sharding” can be misunderstood: it does not automatically mean L1 smart contracts get more throughput, especially on Ethereum where rollups handle most execution scaling. Blob data is temporary by design, so rollups and third-party watchers must reliably download and store what they need before pruning. DA can still become congested, and more builder-centric designs may raise centralization concerns if proof-generation hardware requirements are high.
Related Terms
- Rollup
- Data Availability
- Proto-Danksharding (EIP-4844)
- Danksharding
- Calldata
