Sharding in Jax.Network
by Iurii Shyshatskyi, Chief Scientific Officer at JAX.Network
In the past decade, many different approaches for solving the Blockchain Scalability problem have been proposed. Sharding is considered to be one of the most promising approaches. However, there is no common vision that establishes how sharding should be implemented. Every sharding design brings forth some advantages, and also some drawbacks. In this post, we will discuss the sharding design used within the Jax.Network system, and the advantages that it achieves compared to concurrent proposals.
The term “sharding” came from the theory of databases. Literally, it means splitting a large database into smaller chunks that can be easily managed, and distributed between nodes. Sharding techniques are very useful for carrying out database scaling. However, blockchains have major structural differences from databases, and as a result, blockchain sharding within these systems is not straightforward.
Jax.Network is a novel approach for solving the Blockchain Scalability problem based on the three considerations of Proof of Work consensus, sharding, and merge-mining. Sharding in Jax.Network uses pure state sharding. This means that accounts, transactions and validators are distributed between shards, so that verification of a certain transaction doesn’t require any knowledge of the preceding transaction history in other shards.
The Jax.Network blockchain consists of multiple parallel chains. Every shard maintains a shard chain that is independent from the state of all other shards. Besides shard chains, there is one special chain maintained by all nodes. It’s called the Beacon Chain (BC). Jax.Network does not use any schemes to anchor newly formed shard states into the BC.
The sharding design used in Jax.Network has multiple advantages. It reduces the storage and network traffic requirements for nodes in the network. It also eliminates the bottleneck of block propagation delay (you can read more about block propagation delay in our previous article) and decreases the volatility of mining rewards. All together, these features have a positive effect on the network scalability and decentralization. Let’s next discuss them in detail.
For regular nodes that don’t participate in mining, sharding reduces storage and traffic requirements. In Jax.Network, there is no need to manage the data of the whole blockchain. Every participant chooses the subset of shards that are relevant for him. If some participant wants to verify somebody’s account balance, or review transaction history without third-party assistance, he can do that without downloading and synchronizing the full blockchain.
This sharding feature simplifies the process of setting the convenient and reliable hardware infrastructure for nodes within the network. With sharding, it’s possible to split the blockchain data between different hardware pieces. Different operations could be fulfilled by different threads, and different processing units.
It’s well known that complex systems that consist of many hardware pieces have a high risk of failure, due to hardware issues. Also, internet packets often get lost within the internet. Single chain blockchains are very vulnerable to such failure. If they can’t complete some particular step, then they can’t move further. Fortunately, in Jax.Network, the temporary issues that occur within one shard won’t affect other shards, since all shard chains are kept independent from each other.
Aforementioned features are very useful for miners. In Jax.Network, miners are able to choose the subset of shards that they want to mine. As a result, they can manage their workload according to their particular capabilities. It is not a secret that a fast, broad, stable internet connection is expensive, and is not available to all miners who participate within the network. It’s a very constraining limitation for the single-chain blockchains, in which all nodes have to manage nearly the same workload.
Sharding is a very convenient approach to address the Block Propagation Problem.
In single-chain blockchains, internet traffic is not distributed uniformly. At some moments, when a new block is generated, the number and size of internet packets present within the network dramatically increases. In this case, the bandwidth of network channels becomes a bottleneck. Within a sharded blockchain, it’s possible to make the data flow more smoothly. Although within the Jax.Network shard, blocks are mined through merged mining, the specific “hash sorting” scheme is implemented in a way that makes shard block arrival times uncorrelated.
Hash sorting has one side effect that is valuable for miners. The well-known reward for mining that it offers, occurs within the single-chain blockchains as a random variable which occurs with a high volatility. Thus, miners with low hash-rates join mining pools in order to hedge their risks. The consequence of this fact is a tendency to generate centralization. Within Jax.Network, the reward for mining on multiple shard chains comes in small portions, and occurs more often. It happens every time a shard block is mined. Thus, the volatility of block rewards within Jax.Network is less than on single chain blockchains. This property of Jax.Network contributes to its decentralization.
Here we have to highlight the fact that not all blockchain sharding proposals comprise the full blockchain state of sharding. Some blockchain networks are similar to Zilliqa, and provide sharding only at the transaction level. Thus, all nodes have to maintain the whole blockchain data, in order to process transactions. Therefore, they need to download it somewhere. As a result, small nodes in Zilliqa have nearly the same network traffic as full nodes.
Algorand, Ethereum 2.0, and some less famous proposals, all introduce the full state sharding that is secured by random committees of validators. However, these committees need periodic reorganization. As a result, nodes have to acquire the state of other shards. As we discussed in one of our previous posts, due to this issue, the main benefits of sharding get lost.
Blockchains experts are aware that sharding brings not only benefits. Any sharding proposal should also address the problems of cross-shard transactions, and of shard take-over attacks. Jax.Network addresses the first problem by employing a super-light client, and through the use of the decentralized transfer protocol. Shard take-over attacks are addressed with a merged-mining scheme, and via the specific block reward function. These parts of the Jax.Net protocol will be discussed in our subsequent posts.
Don’t miss any announcement by subscribing to our social media accounts:
Twitter: https://twitter.com/CommunityJax
Facebook: https://www.facebook.com/network.jax/
Telegram Channel: https://t.me/jax_network
Official Group: https://t.me/jax_chat
