MultiversxMultiversx sharding
Updated ยท
MultiversX uses adaptive state sharding to distribute account data and transaction processing, allowing separate node groups to work in parallel. Operations involving accounts in different shards still require coordinated state updates and messages between those groups.
- Network sharding
- Nodes are grouped into shards for communication.
- Transaction sharding
- The protocol assigns transactions to shards for processing.
- State sharding
- Each shard maintains a portion of network state, including the accounts that belong to it.
- Consensus
- Secure Proof of Stake coordinates validation alongside the sharding architecture.
Transfers within and between shards
Two hypothetical EGLD transfers connect ordinary accounts on the MultiversX network. For one, both accounts belong to the same shard; the other connects accounts in different shards.
The first transfer debits the sender and credits the recipient within one transaction shard. The protocol groups cross-shard transactions into miniblocks by sender and receiver shard. In the Andromeda (v1.9.6) flow, the sender's shard validates the second transfer and debits the sender if validation succeeds. The Metachain notarizes the source block and includes its header, miniblock hashes and consensus proof. The receiver's shard verifies that proof before crediting the recipient.
Separate shards can process independent work in parallel. In that flow, a receiving shard that cannot process an entire miniblock applies none of that miniblock's transactions locally and retries it in the next round.
Routing and shard reconfiguration
| Sharding parameter | Behavior and scope |
|---|---|
| Destination shard calculation | Deterministic calculation avoids extra communication rounds for locating the destination; cross-shard execution still requires messages between affected shards. |
| Validator reshuffle timing | At the end of each epoch, for a controlled proportion of eligible validators. |
| Synchronization after reshuffling | One full epoch in the destination shard's waiting list before a moved node can become eligible there. |
| Shard count inputs | Processing load and the upcoming node population, including nodes joining or leaving the network. |
Capacity and validator readiness
Adaptive state sharding supports adding or removing shards as processing load and the node population change. Adding shards distributes work and state across more node groups, provided each shard has enough verifying nodes.
Regular reshuffling discourages collusion by changing shard membership. Moving only a controlled proportion of eligible validators limits the synchronization work that relocation creates. The Metachain selects nodes using randomness from the preceding Metachain block, making future assignments difficult to anticipate.
A shuffled node spends an entire epoch resynchronizing in its new shard's waiting list.
Token transfers across shards
ESDT transfers use the same cross-shard handling mechanisms as EGLD. The protocol handles the coordination, so users do not have to manage the shards involved in their transfers. ESDT covers fungible, semi-fungible and non-fungible tokens, extending this handling beyond transfers of the native network asset.