Sharding distributes part of a blockchain’s data or workload across multiple groups. The goal is to reduce the burden on each participant while allowing more activity on the network.
However, the term covers several different architectures. Distributing transaction execution is not the same as distributing the data required by rollups. Understanding this distinction prevents sharding from being treated as an automatic promise of higher speed and lower fees.
In brief
- Sharding splits a workload, but its benefits depend on the architecture and on coordination between shards.
- Ethereum is focusing on scaling through rollups and improving the availability of their data.
- Security, cross-shard communication and software complexity remain central constraints.
How does blockchain sharding work?
A network must verify and retain the information required for its operation. Dividing this workload raises a question of decentralization: should machines become increasingly powerful, or can the work be distributed without weakening verification?
In a sharded execution model, different groups process part of the transactions and state. Multiple operations can progress in parallel, provided the protocol organizes their dependencies and results.
The gains are not necessarily exponential. Communications, shared computations and operations spanning several shards limit parallelism. Adding shards therefore does not automatically multiply every performance metric by the same proportion.
Execution and data availability: two different problems
Execution determines what a transaction does—for example, modifying a balance or calling a contract. Data availability allows participants to obtain the information they need to verify the system.
Ethereum’s documentation on data availability explains why an announced result is not enough if the information needed to verify it remains hidden. A blockchain that is fast but impossible to verify is not solving the same problem.
For users, this distinction complements the process of reading a smart contract. The application’s logic, where it is executed and the availability of its data must be assessed separately.
Ethereum is not a collection of small independent chains
Ethereum’s earlier sharding projects do not accurately describe its current direction. The official overview of danksharding frames scaling around the data used by rollups, rather than a general division of execution across multiple identical chains.
Rollups execute transactions outside the main layer, according to their architecture. Systems such as ZKsync illustrate this layer-2 approach. The cost of publishing and accessing data then becomes an important component.
PeerDAS, described in EIP-7594, organizes data-availability sampling. It is part of the Fusaka upgrade, whose official history places activation on December 3, 2025. This mechanism should therefore no longer be presented as an idea that remained at the promise stage in 2024.
NEAR shows another way to divide the workload
NEAR’s Nightshade documentation describes an architecture in which state and processing are distributed across shards. Its goal is to share the workload while maintaining protocol coordination.
This example shows why a single term can refer to different approaches. Comparing NEAR and Ethereum solely by their number of shards is not enough: it is necessary to understand what is distributed and how participants verify the results.
Throughput figures must also be considered in context: simple transactions or complex contracts, tests or a live network, data availability and operators’ hardware. An isolated measurement does not summarize the quality of an architecture.
The risks sharding does not eliminate
The protocol must prevent an insufficiently secured group from validating incorrect information. It must also coordinate communication between shards: an operation may depend on state located elsewhere and require additional coordination.
Software complexity is another cost. A finer distribution adds synchronization, recovery and verification mechanisms. A partial outage or an uneven workload can change the performance observed.
Finally, improving capacity does not guarantee the lowest fees for every user. Demand, transaction construction and application pricing continue to matter.
How to assess a sharding announcement
First ask what is being sharded: the state, execution or data. Then check who validates the results, how the shards communicate and what has actually been deployed on the mainnet.
Finally, examine the consequences for users and operators. A measurable improvement should specify its assumptions and limitations. Sharding is an architectural tool, not a general guarantee of decentralization, security or returns for the associated token.
