Just as there is no one-size-fits-all solution for computer infrastructure, there is no static blockchain protocol that can meet the needs of all decentralised applications. Through x-shards, Zilliqa 2.0 offers a dynamic and flexible platform for efficient scaling.

Core to Zilliqa 2.0’s design is a new approach to sharding that delivers better scaling, faster finality, and an improved experience for end-users and developers.

When Zilliqa first launched, it pioneered a sharding system that allowed it to scale linearly to meet growing transaction volumes. This marked a breakthrough in blockchain scaling and serves as the foundation for the more refined and advanced sharding architecture we are introducing in Zilliqa 2.0.

In Zilliqa 2.0, the state of the network is divided into interconnected, application-specific shards called x-shards, which can be customised to suit the needs of the apps built on them.

Parallel Processing Secured by Zilliqa Mainnet

X-shards operate as separate chains and process transactions asynchronously, allowing them to operate independently while communicating with each other.

Each x-shard is run by a subset of nodes and is connected to the Zilliqa 2.0 mainnet. Nodes are able to operate multiple x-shards, and each x-shard runs a separate instance of consensus at its own pace, meaning x-shards do not need to wait for each other to process transactions or compete for block space.

This parallel transaction processing allows the network to scale its throughput as needed by the applications building on its infrastructure while retaining security and communication between apps on the network.

The diagram above shows a network of Zilliqa 2.0 nodes, each operating the mainnet (the main x-shard) in addition to various other x-shards. Each x-shard operated on a node processes transactions from its own mempool and appends new blocks to its chain independently.

Flexible and Customisable Shards

X-shards can be customised to cater to the applications that run on them. Properties including block size, block time, gas fees, and privacy settings can be configured for each x-shard on the Zilliqa mainnet.

X-shards can be set up to use either Proof-of-Stake (PoS) or Proof-of-Authority (PoA) for their consensus mechanism, relying on trustless staking or real-world reputation for validator selection.

These customisable x-shards are seamlessly interconnected to the mainnet and one another, and they can also be set up to use their own native tokens or bridged mainnet tokens, including stablecoins, in lieu of ZIL for transaction fees and validator rewards.

Private and Public X-shards

X-shards can be deployed in public or private configurations. Private x-shards encrypt transactions and limit the availability of this data to approved nodes.

When a node joins a private x-shard, it is verified and issued with the encryption keys required to access the x-shard’s transaction history. When a node leaves a private x-shard, the encryption key is updated for the remaining members.

The block headers of these x-shards are left unencrypted, allowing them to interface with light clients and deliver end-user applications without compromising privacy. Private x-shards can be useful for several applications, capable of securely encrypting the operations of everything from sensitive business transactions to exclusive DAOs.

Intershard and Cross-Chain Communication

A key feature of Zilliqa 2.0 is the built-in communication between x-shards, the Zilliqa mainnet, and other EVM networks.

On Zilliqa 2.0, fungible tokens and NFTs can be natively transacted across x-shards, the mainnet, and other blockchains with minimal friction and expense. 

Thanks to the network’s built-in support for cross-chain EVM transactions, an app can operate and scale efficiently on its bespoke x-shard while supporting tokens bridged from other EVM networks and interfacing with smart contracts on other chains.

In this way, each x-shard acts as a powerful and customisable platform that can operate independently but is connected to both the Zilliqa mainnet and the wider EVM ecosystem.

X-shards on Zilliqa 2.0 can interact by reading each other's state instantly without the need to propagate a transaction through the network. The diagram above shows how intershard state reads are accomplished. Transactions that require state from other x-shards prefetch the state values and their proofs, validators verify and confirm them when voting for the block that contains the transactions, and other nodes execute the transactions with the state values injected when they receive the block.