Adaptive State Sharding

Adaptive state sharding is a blockchain scaling design that divides a network into smaller groups, called shards, and adjusts the number of shards as demand rises or falls. It combines three kinds of sharding in one system: network sharding (splitting the nodes), transaction sharding (splitting the work) and state sharding (splitting the stored data such as account balances). The term was introduced by the Elrond project in its 2019 whitepaper, and the design underpins the network now known as MultiversX.

Adaptive state sharding is one answer to the scaling problem faced by single-chain, or monolithic, designs, in which every node processes every transaction. Other answers include moving activity to a layer 2 network and the data-sharding plans pursued on the Ethereum blockchain. The "adaptive" element distinguishes it from systems with a fixed number of shards.

Picture a supermarket with one checkout. As the queue grows, the shop opens more tills and splits customers between them; when it is quiet, it closes some tills again. Each till keeps its own record of sales, and a supervisor checks all of them and keeps the overall accounts.

Adaptive state sharding does the same for a blockchain. Instead of one long queue of transactions, the network runs several shards in parallel, each with its own group of computers and its own part of the ledger. A coordinating chain keeps them in step, and the number of shards can change as the crowd grows or shrinks.

The MultiversX design has several key elements:

• Shards. Each shard has its own set of validators, processes the transactions for the accounts assigned to it and stores only its slice of the overall state.
• Metachain. A separate coordinating chain records and notarises the block headers produced by each shard, tracks validators and handles cross-shard information.
• Account assignment. Accounts are allocated to shards by their address, so the system knows where each balance lives.
• Splitting and merging. The protocol is designed to split a shard when load rises and merge shards when activity falls, with a binary tree structure that tells nodes which data to keep.
• Cross-shard transactions. A payment between accounts in different shards is processed in steps: the sender's shard debits the account, and the receiver's shard credits it once it sees the result.

The mainnet launched in July 2020 with three execution shards plus the metachain, and the project rebranded from Elrond to MultiversX in November 2022.

MultiversX secures its shards with a proof-of-stake variant it calls Secure Proof of Stake, in which a randomly selected group of validators in each shard proposes and confirms blocks using a Byzantine fault tolerant process. Smaller shards are easier to attack than a whole network, because an attacker needs to control fewer nodes. To reduce this risk, the protocol reshuffles a share of validators between shards at the end of each epoch, so that no group stays together long enough to coordinate an attack. Validators must also keep up with the state of the shard they are moving into, which the design addresses by having nodes hold only the data they need.

Sharding raises a network's capacity by letting shards work in parallel, so total transactions per second can grow with the number of shards rather than being limited by a single node's speed. The trade-offs are complexity and latency. Cross-shard payments take longer than those within a shard, and smart contracts that need to interact across shards are harder to write and reason about, because the calls are asynchronous. Throughput figures quoted by projects often come from test conditions and should be read with care.

Ethereum's long-term roadmap moved away from execution sharding towards scaling through rollups and data availability improvements, leaving computation largely to layer 2 networks. Other designs, such as ledger sharding in some enterprise systems, split data without changing the shard count dynamically. Adaptive state sharding keeps everything on the base layer and aims to scale it directly, which avoids reliance on bridges between layers but concentrates protocol risk in one complex system. Critics note that the adaptive splitting and merging of shards has been less visible in practice than the original design describes.

• MultiversX