Sharding

Sharding is a way of scaling a blockchain or database by splitting it into smaller pieces, called shards, each handled by a different group of computers. Instead of every node processing and storing every transaction, each node deals with only part of the load, so the network as a whole can handle more activity at the same time.

The term comes from database engineering, where large databases have long been split across servers. In crypto it is one of several answers to the problem described in scaling blockchain networks, alongside bigger blocks, Layer 2 networks and off-chain channels. It is the opposite of a monolithic blockchain, in which every node does everything.

Think of a supermarket with one checkout. However fast the cashier works, the queue grows when the shop gets busy. Opening more checkouts lets many customers pay at once. Sharding is the blockchain version of opening more checkouts: each lane serves its own customers, and the shop's total capacity rises.

The catch is coordination. A shopper with items from two lanes needs both lanes to talk to each other, and the manager has to make sure no single lane is run by a dishonest cashier. Most of the difficulty in sharding is about those two problems: moving value between shards and keeping each shard secure.

Designs differ, but most sharded networks share a few elements:

• Partitioned state or data. Accounts, transactions or data are divided among shards, so each shard keeps a smaller slice of the ledger.
• Random validator assignment. Validators are assigned to shards at random and rotated, which makes it hard for an attacker to concentrate stake in one shard.
• A coordinating layer. A main chain, beacon chain or relay chain tracks the shards and finalises their results.
• Cross-shard messaging. When a transaction touches more than one shard, a protocol moves the message or value between them, usually with some delay.

Sharding usually depends on Proof of Stake (PoS), because random assignment of a known validator set is much easier than dividing anonymous mining power.

Ethereum's early roadmap planned 64 shard chains that would each run transactions, coordinated by the beacon chain. In October 2020 Vitalik Buterin proposed a "rollup-centric" roadmap. Under it, transaction execution would move mainly to rollups such as ZK-rollups and optimistic rollups, and the base layer of the Ethereum blockchain would instead shard data, offering cheap space for rollups to post their transaction data.

That plan is called danksharding, after researcher Dankrad Feist. Its first step, proto-danksharding, was specified in Ethereum Improvement Proposal EIP-4844 and activated in the Dencun hard fork on 13 March 2024. EIP-4844 added "blobs", large pieces of data attached to blocks that the execution layer cannot read and that nodes delete after about 18 days. Blobs have their own fee market, separate from the ordinary gas fee, and rollup costs fell sharply after the upgrade. It replaced an earlier idea, EIP-4488, which would simply have made calldata cheaper.

Later upgrades raised blob capacity. Pectra (May 2025) increased the blob target per block, and Fusaka, activated on 3 December 2025, introduced PeerDAS (EIP-7594). With PeerDAS each node samples small parts of blob data instead of downloading all of it, which is the data-sharding step itself. Full danksharding remains a longer-term goal.

• NEAR. NEAR Protocol (NEAR) uses a sharding design called Nightshade. Its Nightshade 2.0 upgrade, live on mainnet in August 2024, added stateless validation: validators no longer need to store the full state of every shard, which lowered hardware requirements.
• Polkadot. Polkadot (DOT) is sometimes described as heterogeneous sharding: many independent chains run in parallel and share security from a central relay chain.
• Modular data layers. Projects such as Celestia (TIA) use data-availability sampling, the same idea as PeerDAS, to offer data space to other chains.

• Single-shard attacks. If too few honest validators end up on one shard, an attacker needs far less stake to corrupt it than to attack the whole network.
• Weaker composability. Contracts on different shards cannot call each other within one transaction, which breaks the instant composability DeFi relies on.
• Complexity. Cross-shard messages, resharding and data-availability proofs add code and new failure modes.
• Misleading throughput claims. Adding shards raises theoretical transactions per second, but real throughput depends on demand, cross-shard traffic and the hardware of full nodes.

Sharding addresses the same scaling problem as state channels and rollups, from a different direction. Because it splits one network's work, rather than linking separate networks, it is also distinct from blockchain interoperability.

• ethereum.org: Danksharding
• EIP-4844: Shard Blob Transactions