Sharding

The idea behind sharding comes from traditional database engineering, where a large dataset is split into smaller pieces so no single machine has to hold or process all of it. Applied to blockchains, sharding lets a network divide its validators, state, and transaction history into separate shards that operate largely in parallel, so throughput scales with the number of shards rather than being capped by what one machine can verify.

Implementations differ in how far they push the idea. Some networks shard the state and let validators specialize in one portion of it while still agreeing on a single canonical chain; others assign whole subsets of validators to independent shard chains that periodically checkpoint back to a central chain. Cross-shard transactions are the hardest part to get right: a transfer touching two shards typically has to be split into two steps, with a message or "receipt" passed between shards once the first half is confirmed, adding latency and complexity compared with a single-shard transaction.

Ethereum's own roadmap moved away from classic execution sharding once Layer 2 rollups proved they could scale transaction throughput faster; its current "danksharding" design shards data availability for rollups rather than execution. NEAR's Nightshade and Zilliqa remain the clearest examples of sharding applied directly to transaction processing.

Sharding raises its own security trade-off: a shard with too few validators becomes easier to attack, so protocols periodically reshuffle validators between shards to prevent any single group from quietly gaining control of one.