A shard is an independent partition of a blockchain network or database formed through sharding. Each shard holds its own subset of data and processes its own transactions while remaining a functional part of the broader network. The term originates from database architecture and has been adopted by the blockchain industry as a horizontal scaling technique to improve throughput and reduce latency without sacrificing decentralization.
The concept of sharding predates blockchain technology by decades. In traditional database systems, a shard is a horizontal partition of a dataset spread across multiple servers. Instead of a single database managing all records, the data is divided into smaller, targeted segments. Each shard can be queried independently, distributing the processing load and preventing any single server from becoming a bottleneck. This architecture became widely adopted in large-scale web applications where read and write demands often exceeded what a single database could handle.
Blockchain networks face a similar scaling problem. In a conventional blockchain, every node stores a complete copy of the ledger and validates every transaction independently. As the network grows in users and activity, this places a heavy computational and storage burden on each node. Nodes that cannot meet the demand drop off the network, which can reduce decentralization over time.
Sharding addresses this by splitting the blockchain into multiple smaller chains called shard chains or data layers. Each shard chain has its own group of validators, sometimes called a committee, that processes and confirms only the transactions for that shard. Since no single node processes the full transaction history of the entire network, the system can handle much greater volumes of activity in parallel.
A sharded network must operate as a single, coherent system. To achieve this, sharding relies on a coordination layer above the individual shard chains. Once a shard's validators confirm a block, it is broadcast to the coordination layer, which verifies its validity and maintains a unified record across all shards. This layer also enables cross-shard communication, allowing shards to read and share data with one another. Without this, the shards would function as separate blockchains rather than cooperative segments of one.
The primary gains from sharding are higher transaction throughput and faster confirmation times. Because multiple shard chains process transactions simultaneously rather than sequentially, the network capacity scales with the number of shards. For context, Ethereum currently processes 15 to 30 transactions per second on a single chain. Payment networks like Visa operate at roughly 1,000 to 4,000 transactions per second. Sharding, combined with other scaling mechanisms, is expected to bring major blockchain networks closer to that range.
Each shard chain also maintains a shorter transaction queue than a unified chain under the same activity volume. Validators on a single shard see less data and fewer pending transactions, which leads to quicker processing times for users.
Sharding introduces challenges absent in monolithic blockchain designs. One major concern is validator centralization. When a network's validators are spread across many shards, each shard is protected by fewer validators than the whole network. A motivated attacker could try to control a majority of validators within a single shard, a threat called a shard takeover or 1% attack. Mitigations like random validator assignment and frequent reshuffling aim to make this attack statistically impractical.
A second risk is data inconsistency. Because shard chains operate independently, discrepancies can arise if one shard records a different state than another. In financial applications on blockchain, such as decentralized finance protocols, an inconsistent network state can cause loss of user funds. Techniques like fraud proofs and enforced transaction ordering at the coordination layer keep the network's state synchronized.
The added architectural complexity means the system has more components that must remain functional. A failure in the coordination layer or breakdown in cross-shard communication can affect the entire network's reliability in ways a simpler, non-sharded chain would not.
Several blockchain networks have implemented sharding in different forms. NEAR Protocol uses a model called Nightshade, where each shard produces a portion of each block and validators are assigned dynamically. Polkadot achieves a similar outcome through its parachain architecture, where independent chains run in parallel and are secured by a central relay chain acting as the coordination layer. Cardano has also explored sharding-adjacent approaches through its Hydra scaling protocol.
Ethereum's sharding roadmap has evolved considerably since it was first proposed. The original plan called for 64 shard chains to operate alongside the Beacon Chain following the network's transition to proof-of-stake. More recent thinking in the Ethereum development community has shifted toward a rollup-centric model in which sharding primarily serves to expand data availability for layer-two solutions, rather than directly sharding execution. This updated approach, often discussed under the heading of danksharding, was introduced progressively through upgrades such as EIP-4844 (proto-danksharding), which went live in March 2024 as part of the Dencun upgrade.
Sharding is a layer-one scaling solution, meaning it modifies the blockchain's base protocol. This distinguishes it from layer-two solutions like rollups, state channels, and sidechains, which process transactions outside the main chain and then settle results back onto it.
Rollups bundle many transactions and submit a compressed proof to the base layer, reducing the data each block must carry. Sharding, by contrast, expands the base layer's capacity by running multiple chains in parallel. The two approaches are not mutually exclusive. Ethereum's roadmap treats them as complementary, using sharding to increase data space for rollups rather than replacing them.
.webp)