Sharding

What Is Sharding?

Sharding is a horizontal partitioning technique originally developed for databases, where a large dataset is divided across multiple storage units (shards) so that each unit handles only a fraction of the total workload. Applied to blockchains, sharding extends this idea to state, transactions, and validation: instead of every node processing every transaction, the network is divided into parallel subsets that operate concurrently.

The goal is to overcome the throughput ceiling imposed by requiring all nodes to validate all transactions. A single-shard blockchain like Bitcoin or pre-sharding Ethereum can only process as many transactions as each individual node can handle. Sharding breaks this constraint by distributing the work, allowing the network's total capacity to grow with the number of shards.

Unlike database sharding, blockchain sharding must also solve a security problem: validators must be assigned to shards in a tamper-resistant manner, typically using verifiable randomness and staking penalties, to prevent an attacker from concentrating power in a single shard.

How It Works

Blockchain sharding divides three layers of the network across parallel groups:

1. State sharding: the global state (account balances, contract storage) is partitioned so each shard stores only its portion
2. Transaction sharding: incoming transactions are routed to the appropriate shard based on the accounts or contracts involved
3. Network sharding: nodes are divided into groups, and each group only needs to communicate internally for intra-shard consensus, reducing bandwidth overhead

With K shards each capable of N transactions per second, the network can theoretically handle K × N TPS. In practice, cross-shard communication overhead reduces this linear scaling.

Validator Assignment

Security depends on how validators are assigned to shards. If an attacker can choose which shard to join, they could concentrate enough stake to control a single shard and double-spend within it. Sharded blockchains use several techniques to prevent this:

• Random assignment via verifiable random functions (VRFs) that produce tamper-proof randomness
• Periodic reshuffling: validators are rotated between shards at regular intervals (every epoch or every 24 hours) to prevent collusion
• Minimum shard size: requiring hundreds of validators per shard makes statistical attacks impractical
• Economic penalties via proof-of-stake slashing for malicious behavior

Cross-Shard Communication

When a transaction involves accounts on different shards, those shards must coordinate to execute it atomically. This is the cross-shard communication problem, and it is the primary bottleneck in sharded systems.

As shard count grows, the probability of a transaction being cross-shard increases rapidly. With 16 shards, approximately 93% of two-party transactions are cross-shard. Different chains handle this differently:

Ethereum's Sharding Pivot

Ethereum's original sharding roadmap called for 64 independent execution shards, each with its own block proposer and a committee of at least 128 validators. This would have multiplied throughput by up to 64×. However, by 2020, the plan was abandoned for several reasons:

• Implementation complexity was extreme, with unsolved cross-shard atomicity challenges
• Layer-2 rollups (Arbitrum, Optimism, zkSync) were already delivering significant throughput gains off-chain
• Security concerns around shard-level attacks remained unresolved

In late 2020, Vitalik Buterin proposed a "rollup-centric roadmap," pivoting Ethereum's L1 role from executing everything to providing cheap, abundant data availability for rollups. Rather than sharding execution, Ethereum would shard data.

Proto-Danksharding (EIP-4844)

Proto-danksharding (EIP-4844) was the first step in this new direction. Activated on March 13, 2024, as part of the Dencun hard fork, it introduced a new transaction type called blob-carrying transactions. Blobs are approximately 128 KiB data objects stored outside the EVM, designed specifically for rollup data. They are committed using KZG polynomial commitments, a scheme forward-compatible with full data availability sampling.

At launch, the network targeted 3 blobs per block with a maximum of 6. The Pectra upgrade in May 2025 doubled this to a target of 6 and maximum of 9. The impact was dramatic: L2 transaction costs dropped by 10–100× compared to posting data as calldata.

Full Danksharding

Named after Ethereum researcher Dankrad Feist, full danksharding is the end state of Ethereum's data sharding plan. It targets 64 blobs per block (each 128 KiB), which would enable over 100,000 TPS when combined with rollup execution. Key components include:

• Data availability sampling (DAS): validators randomly sample small portions of blob data and use KZG proofs to verify completeness, eliminating the need for every node to download every blob
• Proposer-builder separation (PBS): separates block building from block proposing so that no single validator must generate expensive cryptographic commitments for large datasets
• 2D erasure coding: data is encoded across two dimensions so that the original can be reconstructed from any 50% of samples

The Fusaka upgrade in December 2025 introduced PeerDAS (Peer Data Availability Sampling via EIP-7594), where nodes download only 1/8 of blob data while still guaranteeing full availability. This marked Ethereum's entry into the data sharding era, with blob counts being progressively increased toward the full danksharding target throughout 2026. For a deeper look at the fee dynamics this introduced, see Ethereum EIP-4844 blob fee market analysis.

Sharding in Practice

NEAR Protocol: Nightshade

NEAR uses a design called Nightshade, where each shard produces a "chunk" of transactions every round. These chunks are aggregated into a single block header, so the protocol presents one canonical chain despite parallel execution underneath. As of 2026, NEAR runs approximately 8 shards on mainnet with dynamic resharding that adjusts shard count based on demand. Nightshade 2.0 (released in 2024–2025) introduced stateless validation, removing the requirement for validators to store the entire blockchain state.

TON: Infinite Sharding

The Open Network (TON) implements a three-level hierarchy: a masterchain for coordination, up to 2³² workchains with independent rules, and up to 2⁶⁰ shardchains per workchain. Shards split and merge automatically based on transaction volume. Accounts are assigned to shards by matching the most significant bits of their account ID to shard prefixes. Cross-shard messages use hypercube routing with a maximum path length of 15 hops.

MultiversX: Adaptive State Sharding

MultiversX (formerly Elrond) implements the most complete form of sharding: adaptive state sharding that combines state, transaction, and network sharding. The network runs 3 execution shards plus 1 coordination shard (Metachain), with approximately 3,200 validators. Every 24 hours, one-third of validators in each shard are randomly reassigned to prevent collusion.

Sharding vs. Rollup-Centric Scaling

The blockchain scaling debate has increasingly centered on two paradigms: native execution sharding versus rollup-centric scaling. Each makes different tradeoffs:

The industry is converging on a hybrid approach: rollups handle execution while the L1 uses data sharding to provide cheap data availability. This is Ethereum's current strategy. Chains like NEAR and TON pursue execution sharding natively. For a comparison of how these tradeoffs play out across different scaling approaches, see rollup vs. state channel scaling tradeoffs.

Use Cases

• High-throughput DeFi: sharded chains can process thousands of concurrent swaps, liquidations, and settlements without congestion
• Gaming and social applications: interactive apps requiring frequent small transactions benefit from the parallelism sharding provides
• Data availability for rollups: Ethereum's data sharding approach makes ZK-rollups and optimistic rollups economically viable by reducing the cost of posting transaction data to L1
• Enterprise blockchain: organizations needing predictable throughput can isolate workloads in dedicated shards

Risks and Considerations

Security vs. Shard Count

Each additional shard dilutes the validator set. If a network has 1,000 validators split across 100 shards, each shard has only 10 validators: far fewer than needed to resist Byzantine attacks. Sharded blockchains must maintain minimum shard sizes and use random validator assignment to keep attack probabilities acceptably low. Zilliqa, for example, requires a minimum of 600 nodes per shard to keep the probability of a one-third-malicious committee below 10^-6.

Cross-Shard Complexity

As noted above, cross-shard transactions dominate as shard count grows. Two-phase commit protocols require at least four cross-shard messages per transaction plus intra-shard BFT consensus on each coordination message. This overhead can negate throughput gains if cross-shard transactions are not handled efficiently.

State Growth and Data Availability

Sharding does not eliminate state growth: it distributes it. If the total state grows faster than the number of shards, individual shard sizes still increase. Stateless validation (as implemented by NEAR) mitigates this by removing the requirement for validators to store full shard state, but introduces new complexity around state witnesses and proof generation.

Developer Experience

Building applications on sharded chains requires awareness of shard boundaries. Smart contracts that interact with state on multiple shards face latency from async cross-shard calls and must handle partial failures. This is a meaningful departure from the single-state programming model developers are accustomed to.

Why It Matters

Sharding represents the most direct approach to scaling blockchain throughput: if one chain cannot handle the load, run many chains in parallel. While Ethereum's pivot toward data availability sharding has shifted the narrative toward rollup-centric scaling, the underlying idea remains central to how blockchains will serve billions of users. Whether through execution sharding (NEAR, TON) or data sharding (Ethereum's danksharding), partitioning work across parallel segments is foundational to the next generation of blockchain infrastructure.

For Bitcoin-based scaling, different architectural approaches have emerged. Layer-2 protocols like Spark use off-chain state management rather than sharding, achieving high throughput without modifying the base layer's consensus mechanism. Learn more in the Spark layer-2 overview.

This glossary entry is for informational purposes only and does not constitute financial or investment advice. Always do your own research before using any protocol or technology.