Shard expansion protocol
Motivation
The key feature of this scalable solution is the ability to effectively address the problem at any scale. However, in each particular case some choice of parameters may work better than another. It is easy to choose parameters if there is a central authority that knows well the current state of the system. However, setting such parameters in the distributed network is not straightforward.
The key parameter in JaxNet is the number of shards N. When the number of users in the system and transaction count is limited, the most efficient solution is to maintain only a few shards. One chain solutions could perform even better. Besides efficiency, having too many shards can trigger a security risk. If there are too many shards then there will be little incentive to merge mine them for powerful nodes. Thus, the hash rate in many of them could plummet. So the selection of parameter N is a rather big responsibility.
Initial shard chains
Conditions for opening shards
Hashrate majority condition
It's simple consensus on the value based on the hash rate. Block headers on the Beacon Chain contain a specific field... Miners set this flag to indicate their opinion.
A flag with value '1' signals that miner who mined this block votes to increase the number of shards in the system and '0' signals about the opposite. On each mining round miners count the number of '1' in previous blocks on the Beacon chain. If number of ones in the previous 1024 blocks on BC is greater than 768 then this condition is satisfied.