Sharding in Blockchain: What it is in Simple Terms

What Is Sharding?

Sharding (sharding) is the process of splitting large volumes of data or tasks into smaller, independent parts. The idea of sharding itself is not new and is used wherever it is important to boost performance without increasing the requirements for each individual network participant.

As data volumes and the number of operations grow, traditional systems run into technical limits — at some point, it becomes difficult to process every request. Splitting data makes it possible to use multiple servers, each of which handles only its own portion.

For example, Notion uses this technology to split data across workspaces. Twitter also used sharding to store a large stream of posts.

In blockchain, sharding is used to increase throughput and speed up transaction processing.

Why this technology matters for blockchain

Modern blockchains face scalability constraints. In many networks, the transaction processing architecture limits throughput, so as load increases, fees can rise, and transaction confirmations can take longer.

To scale, solutions like rollups are used — Zero-Knowledge Rollups and Optimistic Rollups process transactions off the main network and then write their results to the blockchain.

However, rollups still depend on the capabilities of the base layer. Sharding makes it possible to distribute part of the load and data across its segments, so the two approaches can complement each other.

The idea behind sharding is that the blockchain is split into independent or semi-independent segments, each of which does its part of the work. This enables more efficient load distribution, but it requires additional security mechanisms and coordination between segments.

How sharding works

Sharding differs in terms of which data or tasks are distributed across nodes and how their work is organized. Based on the first criterion, the following types are distinguished:

• Transaction sharding — the overall transaction flow is split into several smaller streams, and then each network segment processes its share and keeps local records. This increases the network’s throughput;
• State sharding — splits blockchain data across segments. Each one processes only its portion of the information. This reduces storage and compute load, but fragmentation increases the risk of attacks on individual shards and makes interoperability more complex.

At the same time, there are also two main approaches to network sharding, which differ in implementation complexity and flexibility:

• Static partitioning — involves segmenting the blockchain state into a predefined number of shards and nodes within each. This architecture is easier to implement, but it does not adapt to changes in user activity, which limits efficiency;
• Adaptive partitioning — a more flexible approach in which the number or size of shards changes depending on the number of active nodes, data volume, and network activity. If the load increases, the system can automatically add new segments to process additional transactions.

Depending on the goals and architecture, a blockchain can combine several types of sharding at once. This helps achieve the right balance between performance, decentralization, and security.

Sharding at the Technical Level

One implementation option is transaction sharding. In a simple model, the overall flow of operations is distributed across network segments, each of which processes its share. This makes it possible to increase overall throughput.

Transactions that belong to a single shard are processed within it. If an operation touches other segments, messages and execution results are passed between them. The exact sequence depends on the network architecture.

If validators from different shards cannot interact, the segments effectively turn into isolated networks. To connect them, cross-shard transactions are used. Depending on the coordination method, there are two approaches:

• Synchronous — the involved shards coordinate the execution of the operation to preserve state consistency. One research variant of this kind of interaction is the Merge Blocks concept;
• asynchronous — the operation goes through several sequential stages. The execution result in one shard is passed to another, where processing continues after the required data is received.

In some sharded networks, interaction between segments is handled by a separate coordination layer. For example, in MultiversX, this role is performed by Metachain. Depending on the architecture, such a layer can:

• distribute validators across segments
• coordinate messaging between shards
• confirm data about produced blocks
• maintain network consistency.

A structure with a coordination layer makes it possible to preserve the network’s integrity and security even when it is split into dozens of independent segments. However, it requires protecting both individual shards and the main chain, as well as data exchange mechanisms.

What projects use sharding?

As of this writing, relatively few networks use sharding technology or are in the process of implementing it. Their examples show that the concept is being implemented and evolving in different variations, and a single standard has yet to be established.

NEAR Protocol

NEAR Protocol uses the Nightshade model, in which each shard processes a portion of transactions and produces its own block fragment — a chunk. These fragments are combined into a block on the main chain, and special messages are used for communication between segments.

This architecture makes it possible to increase throughput by adding shards. According to NEAR, the network uses nine shards.

NEAR also uses single-block resharding, which allows a shard to be split within a single block. This mechanism simplifies changing the network configuration as it scales.

In addition, NEAR validators are not required to store complete information about other shards. Instead, they use special proofs, which makes it possible to scale the network not only at the transaction processing level, but also at the data availability level.

MultiversX

MultiversX has been operating since July 2020, using adaptive state sharding. The network is split into three shards and the Metachain coordination chain. Blocks are finalized in their respective shards, while Metachain confirms their headers and enables cross-shard communication. Validators are also regularly reshuffled between shards, which increases decentralization and security.

In the MultiversX explorer, you can track the network’s current load, including the number of transactions and active addresses. These metrics change over time, so they should be distinguished from the stated maximum throughput.

Sui

In the Sui ecosystem, researchers are exploring a different approach to scaling — distributing transaction execution across multiple machines. In 2024, developers introduced a Pilotfish prototype that splits the workload across three types of nodes:

• Primary — responsible for ordering transactions
• Sequencing Workers (SW) — distribute transactions for execution
• Execution Workers (EW) — store state and execute transactions.

In tests, Pilotfish showed performance gains as additional compute nodes were added. When processing compute-intensive operations, the developers achieved an eightfold increase in throughput on eight servers. This is the result of prototype testing, not an indicator of Sui mainnet performance.

Aptos

In early 2025, the Aptos team introduced Shardines — an experimental system for parallel transaction execution using Executor Shards. In tests on 30 shards, it exceeded 1 million transactions per second when processing independent operations. Further performance gains were limited by the data storage layer.

Shardines is still an experimental development. At the same time, Aptos already uses the Jellyfish Merkle Tree (JMT) to store state and has implemented data partitioning within individual nodes. To scale further, developers will need to distribute the storage load across multiple machines.

Ethereum is also worth noting separately, where sharding is developing primarily as a way to scale data availability for rollups. In March 2024, the Dencun upgrade introduced proto-danksharding (EIP-4844), and in December 2025, Fusaka added PeerDAS — distributed data availability sampling. Full danksharding remains one of the network’s longer-term development directions.

Advantages and disadvantages of the technology

Sharding has several advantages related to distributing load across network segments:

• scalability and performance — segmentation allows more transactions to be processed through parallel network operation, increasing overall throughput;
• reducing the load on nodes — with state sharding, individual nodes can store and process only part of the network’s data, which lowers their resource requirements. This reduces the barrier to running nodes and can potentially support decentralization;
• load distribution — splitting the blockchain into segments helps process transactions in parallel. At the same time, congestion in one shard can affect cross-shard operations linked to it;
• potential to reduce fees — thanks to higher throughput and more efficient data storage, sharding helps make transactions cheaper.

However, sharding is not an industry “standard” and is far from being used across all networks. The reasons for its limited adoption include:

• implementation complexity — full-fledged sharding requires developing mechanisms for synchronization and protecting network segments;
• security threats — splitting a blockchain into segments can allow an attacker to focus efforts on a single shard with fewer validators. This increases the risk of a shard takeover, and the impact of an attack depends on the network’s protection and coordination mechanisms;
• cross-shard coordination complexity — executing or storing transactions across different segments requires synchronization. This can increase transaction processing time, complicate the architecture, and raise the likelihood of technical failures;
• lack of a standard — many blockchain sharding models remain experimental. Different networks implement it in their own way, so there are simply no universal or standardized solutions. The technology requires extensive testing and audits.

Sharding helps distribute load, but it makes the network architecture more complex and requires additional coordination mechanisms.

Sharding development outlook in the crypto industry

Sharding remains one of the approaches to scaling blockchains. Its adoption depends on the network architecture, the nature of the workload, and the complexity of implementation.

At the same time, there is still no universal model. Developers are experimenting with the number of shards, the ways they synchronize them, and how the load is distributed. As a result, the viability of existing projects will show whether sharding can gain broader adoption.

In the future, other general-purpose blockchains that need load distribution may also use sharding.

Conclusions

Sharding is already used in a number of blockchains to distribute load across segments. How significant the performance gains will be depends on the network architecture, the nature of the workload, and the coordination mechanisms.

That said, the technology is still far from mass adoption. Most projects face technical challenges, and implementation takes time, testing, and the development of new — often unique — solutions. The future of sharding depends on how successfully current limitations can be addressed.