.webp)
Adaptive state sharding is a blockchain scaling technique that divides a network into smaller subsets of nodes, called shards, each capable of processing a portion of the network's transactions in parallel. The "adaptive" element means the number of shards can increase or decrease dynamically in response to network load, automatically scaling capacity when demand rises and consolidating when activity slows. This approach addresses one of blockchain's most persistent challenges: most networks require every node to process every transaction, which limits throughput as the user base grows.
Basic network sharding splits nodes into groups that share workload, but each shard still requires global knowledge of the complete ledger state. Transaction sharding processes different transactions in parallel but does not divide the stored data. State sharding goes further by partitioning both the transaction processing and the actual state data, meaning each shard only needs to store and maintain the portion of the ledger relevant to its own set of accounts and contracts. Think of it like a library where different sections hold different books, instead of every librarian memorizing every book in the building.
MultiversX (formerly Elrond) is the blockchain most closely associated with adaptive state sharding. According to MultiversX's official documentation, its architecture applies sharding simultaneously across three layers: transaction sharding, data sharding, and network sharding. This makes it the first public blockchain to implement all three sharding types at once.
The MultiversX network currently operates with three execution shards plus a Metachain that coordinates them. Each execution shard contains approximately 800 validators. At the end of each 24-hour epoch, one-third of the validators in each shard rotate to a different shard. This shuffling mechanism prevents any group of validators from colluding to attack a single shard, since they cannot predict which shard they will occupy next epoch. The Metachain finalizes cross-shard transactions and maintains a global record of shard states.
The adaptive element works through a governance-controlled mechanism that can split a shard into two when the network load on that shard becomes too high, or merge two lightly loaded shards into one when activity falls. This allows the network to scale horizontally by adding shards as demand grows, without requiring a hard fork or protocol change. Network scaling therefore follows user adoption rather than requiring operators to predict future capacity years in advance.
According to MultiversX's documentation, the sharding mechanism ensures that adding or removing shards affects only a small portion of nodes at any one time, avoiding downtime during the transition.
| Sharding Type | What It Splits | Shard Count | Example Network |
|---|---|---|---|
| Network sharding | Communication groups among nodes | Fixed | Zilliqa |
| Transaction sharding | Transaction processing across shards | Fixed or dynamic | Zilliqa, Ethereum (planned) |
| State sharding | Transaction processing AND stored ledger state | Fixed | NEAR Protocol |
| Adaptive state sharding | All three layers, dynamically | Dynamic (merges and splits) | MultiversX |
When a transaction involves accounts in two different shards, both shards must coordinate to process it. MultiversX handles this through an asynchronous cross-shard execution process. The sending shard initiates the transaction and broadcasts a message to the receiving shard. The Metachain finalizes the settlement once both shards confirm the outcome. Cross-shard transactions take slightly longer than intra-shard transactions, but MultiversX's documentation reports finality within seconds even across shards.
The security of cross-shard communication depends on the Metachain's integrity. Because validators rotate between shards at each epoch, no group can accumulate the sustained presence in one shard needed to corrupt cross-shard messages.
The most significant security concern with sharding is that each shard represents a smaller validator pool than the full network. A smaller pool is theoretically easier to attack. MultiversX addresses this by using BLS multi-signatures to aggregate validator votes efficiently and by reshuffling validators at each epoch. The combination means that an attacker would need to control a substantial share of the total validator set and correctly predict or influence the shuffle to compromise a specific shard, which the protocol's use of verifiable random functions makes effectively impossible.
With deep roots in traditional finance and the digital asset industry, Acquire.Fi operates as a specialist M&A advisory firm. Coverage spans M&A, secondaries, OTC, and capital markets advisory across digital assets and frontier tech. Our team has decades of combined experience across every stage of the deal lifecycle.
.webp)