Chain independence in Jax.Network
by Iurii Shyshatskyi, Chief Scientist at Jax.Network
Introduction
Blockchain sharding is often considered as the most promising approach to solving the blockchain scalability problem. Proof-of-Stake (PoS) sharding proposals often attract much attention in the media and in academic papers.
In our previous post, we discussed how proponents of PoS exploit the Parallel Chain Model in order to confuse the community and make misleading assertions about scalability properties of their proposals. In contrast to their claims, shards in their solutions are deeply interconnected. As a result, such solutions lose almost all benefits predicted by the Parallel Chain Model. In contrast, sharding design in Jax.Network enjoys these benefits. This matter has been discussed in one of our previous posts.
Cross-chain data dependency and its impact rarely come into the sight of observers. It rarely becomes a subject of independent third-party studies. One of the main reasons here is the absence of proper documentation on this issue. As a result, casual people can only rely on overviews of influencers who never cast doubt on ambiguous assessments of network performance.
In contrast to popular PoS solutions, Jax.Network is based on Proof-of-Work sharding. This approach allows Jax.Network to build a truly modular design, where shard chains can work in parallel without negative impact on each other. However, shard chains rely on some portion of data taken from the beacon chain. Nevertheless, we claim that this link doesn’t cause a negative effect on shard chain performance.
The primary purpose of this paper is to provide an explicit list of all cross-chain links in Jax.Network. It could serve as a reference for the in-depth analysis of the JaxNet protocol so that researchers can determine whether shards in Jax.Network are eligible for being treated within the Parallel Chain Model.
Principles of Chain Independence
Before we proceed to the description of our algorithms, let’s describe the motivation behind our design. We set a mechanism that allows full nodes in Jax.Network to synchronize on two key parameters: shard count and K-coefficient.
The primary goal is to make this synchronization efficient and reliable. In our design, all data required for the synchronization is stored only on the beacon chain. Thus full shard nodes have no need to download or rely on data from other shard chains. Another important goal is to avoid unnecessary forking and unnecessary orphan blocks. In order to achieve these goals we set the following requirement:
- There is no block arrival event on one shard chain which could affect block production, block validity, or chain forking on another shard chain or the beacon chain.
Let’s call this property the first principle of chain independence.
The first principle is a rather strong and useful property. However, we can highlight another important property. Similar to Bitcoin, Jax.Network works in the asynchronous setting. It means that every node has a certain level of flexibility. The clocks on the miner’s computer might be inaccurate and the miner might write inaccurate timestamps in his blocks. However, as long as these timestamps belong to a certain timestamp window, other nodes in the network will tolerate this issue and accept his blocks.
In the asynchronous setting, some miners might have temporary issues with keeping their beacon chain updated. It might increase the likelihood of orphan blocks in shard chains that rely on it. We believe that flexibility is needed here too. A slightly outdated state of the beacon chain shouldn’t cause any penalty for shard chain mining.
Therefore the following property should be achieved:
2. A failure of a miner to perfectly synchronize his network clocks and timely update the state of the beacon chain with his peers in Jax.Network doesn’t affect his mining on shard chains in any form.
We call it the second principle of chain independence.
The ability of Jax.Network to work in the asynchronous setting is a great advantage over PoS networks. A typical PoS sharding proposal is very restrictive and requires all block producers to perfectly synchronize their network clocks.
We have formulated two key principles of chain independence in Jax.Network. However, there is one important question that falls out of the scope of this post: hard forks. In our future posts, we will describe a mechanism of hard forks which allows the network to smoothly update protocol rules without breaking the aforementioned principles.
Shard count in Jax.Network
The shard count in Jax.Network is determined by the shard expansion protocol. It is recorded into the beacon chain header so that all nodes, which have synchronized to the latest beacon chain header, share the same value of the parameter “shard count”.
Whenever Jax.Network requires more capacity, nodes might agree on increasing shard count and opening new shard chains. It’s important to highlight that shard chains in Jax.Network can’t get closed. So shard count can only increase. Nodes can learn when shard count gets incremented and new shards become open for mining by studying the data from the beacon chain.
Some miners might fail to timely synchronize the state of the beacon chain and miss the opportunity to mine new shards. However, shard block rewards in Jax.Network are designed in such a way that it doesn’t really matter how many shards are merge-mined by the miner. The new shard doesn’t make a difference for his revenue. So there is no risk for the second principle of chain independence in Jax.Network.
Nevertheless, there is another instance when shard count is used. In order to execute merge-mining, miners construct a Merged Mining Merkle Tree (MMMT). The size of this tree depends on the shard count since the miner has to reserve a slot for every opened shard in the network.
As shard count in Jax.Network grows, miners have to construct bigger MMMTs. However, some miners might have an outdated state of the beacon chain and the outdated value of the shard count. Nevertheless, we want to provide them an opportunity to mine shard blocks despite this issue. Moreover, they should be able to accept blocks generated by miners who already have the latest value of the shard count.
The naive approach is to compare MMMT leaf count with a shard count recorded into the latest beacon chain block. In this naive design, the validity of the block depends on the real-time state of the beacon chain. It’s clear that this approach will break the second principle of chain independence. Moreover, it becomes impossible to verify MMMT size in historical blocks. That’s completely unacceptable.
The approach chosen by Jax.Network is a bit more tricky. It is similar to the way the Bitcoin network handles blocks with timestamps that are put more than two hours in the future.
Jax.Network nodes don’t reject a shard block if the MMMT size doesn’t match the current shard count. However, for the purpose of data sanity, if the MMMT size is bigger than the maximum threshold allowed by the current shard count retrieved from the beacon chain, shard nodes, and shard miners will ignore this block for a while. Miners will try to mine a competitive block with a proper MMMT size. If they succeed, the inappropriate block will become an orphan. However, it’s possible that they will fail to mine a new block for a long time. Meanwhile, the shard count and the threshold for MMMT size can increase so that the inappropriate block will become valid.
This rule works properly both for new blocks and historical blocks which have been mined a long time ago. Moreover, it gives miners some flexibility so that our second principle of chain independence is preserved.
K-coefficient
Besides shard count, there is another parameter required for the proper work of shards in Jax.Network. It is what we call the K-coefficient.
K-coefficient is a conversion coefficient of miners’ work to JAX coins. Whenever a miner computes a hash in order to find a valid one, the mathematical expectation of JAX coin reward that he gets is equal to K. Hence, the K-coefficient setting regulates the cost of production of JAX coins. You can read more about the block reward function in our post.
The value of K-coefficient and the production cost of JAX should be the same for all shards in Jax.Network. K-coefficient is required for calculation of shard block rewards. Thus participants require a reliable source for this parameter. Obviously, only the beacon chain can qualify for this data source.
In Jax.Network, K-coefficient is determined by miners’ votes recorded into the beacon chain. The relevant value of K-coefficient is recorded into every beacon chain block. Let’s determine how this data should be retrieved from the beacon chain and applied to shard chains.
Again we have a naive approach here. Some people may suggest using the value recorded into the latest beacon chain header. However, as we have already learned, this approach is a real-time consensus that breaks the second principle of chain independence and can’t be applied to historical blocks.
Some developers might suggest another naive approach inspired by the way we treat MMMT size in the previous section.
Every shard block contains a BC-container or BCaux header. This data chunk is formed from the header of the beacon chain block-candidate composed by the miner who has successfully merge-mined this shard block. This data chunk contains K-coefficient and shard count asserted by the miner. One may suggest using this data in order to verify the size of the shard block reward.
The problem with this approach is that the K-coefficient record in BC-container can be manipulated by miners and can significantly deviate from the beacon chain value. In contrast, miners can’t forge their proof-of-work and increase their revenue through the modification of the shard count record. So this approach is insecure and very fragile.
In Jax.Network, we use a more sophisticated approach. Every chain is sliced into intervals of predefined lengths, which we call mining epochs. Every mining epoch has a K-coefficient which works during this epoch. The value of this coefficient is determined by the beacon chain data from blocks that are already buried deep in the beacon chain. This design is rather robust and works properly both for new blocks and historical blocks.
Block arrival events
A careful reader may cast a doubt that our first principle of chain independence could be completely achieved. The argument here is the following: block arrival on one shard chain can affect block propagation on another shard chain and a slight delay in block propagation might slightly increase the probability that an orphan block will be mined. This problem was discussed in this post.
A good illustration here is an event when many shard blocks are simultaneously mined by the same miner. This event might cause some short-term network congestion and propagation of these blocks will be delayed.
Although such a scenario can’t be completely eliminated, we can make the probability of this event negligibly small. We call this fix “hash sorting”. This technique is not new for the blockchain space. The history of this idea could be traced back to the paper by Garay et al, who introduced it under the name “2-for-1 pow”.
Conclusions
The reader might wonder why these two principles of chain independence are important and why we pay so much attention to the orphan block percent.
The aforementioned principles of chain independence are attributes of truly parallel, modular design. We are proud to highlight that Jax.Network has them while many competitive projects can only speculate about these concepts.
The ability of the network to preserve low orphan block percent, despite a heavy workload and a large number of block producers, is a property of the truly scalable solution.
One may notice that occasions, when shard count and K-coefficient get modified, are rather rare. Shard count can increase only once a week and K-coefficient could be adjusted once every 4 weeks. Nevertheless, the JaxNet protocol is well designed so that even these rather rare transitions are performed smoothly.
Don’t miss any announcement by subscribing to our social media accounts:
Official Website: https://jax.network
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
