Merged Mining in Jax.Network
Tags: Jaxnetwork, Blockchain Development, Jaxnetworktech, Blockchain Technology, Merged Mining

Security in a sharded blockchain network

In the past decade, many different approaches to 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 since every sharding design offers advantages and drawbacks. In our previous post we discussed sharding design in JaxNet and its advantages.

One major problem that should be addressed by any scaling solution is security against 51% of attacks in shards. Indeed, the naive approach for scaling the network is to run an independent chain on every shard so that every mining rig can mine only one shard at a time. In this case, the network hash rate has to be split between shards. If there are N shards, then, on average, shard chains will have only an Nth part of the network’s hash rate. So, if there are 100 shards, then the malicious actor who poses only one percent of the network hash rate can take over some shards and conduct double-spend attacks. Such vulnerability is obviously unacceptable.

Researchers consider different approaches to secure a sharded network. Some projects propose security solutions that rely on committees of trusted nodes. A consensus is reached by nodes through voting in these committees. However, such solutions often achieve security by reducing the decentralization of the network.

Another popular approach is to select shard committees of random validators based on the number of coins they lock in stakes. According to this method, whenever the participant locks funds in the stake, a random shard is assigned to this stake. So participants don’t know upfront in which shards will become validators. Thus it’s harder for them to collude for an attack.

This is a standard aspect of protocols developed for projects, such as Ethereum 2.0, Algorand, Cardano, Elrond, and others. Proponents of these solutions claim that randomness is the only thing that could prevent the malicious actor from accumulating a hash rate in one shard. Also, they claim that the Proof of Work consensus used in Bitcoin doesn’t suit their solution, and only the Proof of Stake could provide a degree of randomness that is required for a committee selection resistant to a Sybil Attack.

Interestingly, these claims are not supported by rigorous argument. Researchers often appeal to common sense and intuition in line with our everyday experience. Some researchers stress the fact there are no other known solutions. Others argue that “simply speaking it makes it true.”

However, this PoS approach is imperfect. As we highlighted in one of our previous posts shard committees, from time to time, need to reorganize, which is required to prevent attacks from adaptive adversaries who are able to gain control of the shard committee by corrupting its members. This reorganization is very costly for weak nodes since they have to download the data from other shards. This reorganization requirement greatly reduces or even eliminates the benefits from sharding.

Some researchers claim that sharding based on PoS brings O(N) improvement, in terms of scalability, where N is the number of shards. However, due to reorganization, this estimate is inaccurate and misleading. Other researchers admit the problem and design solutions with a compromise between performance and the frequency of committee reorganization. Although these estimates are not thoroughly optimistic, they are inaccurate and misleading too. The problem is that the concept of “stake” is often conflated with that of “validator.” Obviously, every participant can control many stakes. So the number of stakes is a very confusing parameter for any estimation.

Another issue of PoS sharding is economics. Participants who control many stakes and run full nodes on all shards have a significant advantage over others who can’t afford the maintenance of all shards. Therefore, this flaw contributes to centralization in the network.

The lesson that we have to learn from these proposals is the following: the design that secures shards from a shard take-over attack has to be aligned with proper economics that doesn’t penalize weak nodes in the network. The main achievement of the solution proposed in JaxNet is the balance that doesn’t cause consolidation of power in the network.

Merged mining

In contrast to mainstream sharding proposals, the JaxNet approach is based on a Proof of Work consensus. JaxNet uses the merge-mining technique to secure shards from shard take-over attacks.

The term “merged mining,” or “merge-mining,” often refers to the process of mining two or more cryptocurrencies at the same time. People are familiar with this term thanks to altcoins such as Namecoin, which is merge-mined with Bitcoin, and Dogecoin, which is merge-mined with Litecoin. However, in JaxNet, this term acquires another meaning since merge-mining, in this case, is used for mining multiple shards within the same network.

Observers claim that merged mining is not a good candidate for the creation of proper sharding systems. Indeed, if there is a restriction that every miner has only one shard or a small fraction of shards, then the security of the network dramatically deteriorates. In this case honest miners are unable to support a high hash rate across all shards.

In the opposite scenario, where each miner mines nearly every shard in the network, every node executes nearly the same amount of work as a full node. In this edge case scenario, there is no benefit from sharding. Moreover, a single chain with large blocks can do the job better than this network.

If we track the history of the usage of merged mining, we see that merged mining often went through one of these two edge scenarios. The additional income from merge-mining Namecoin or other small coins is often negligible compared to the basic income from Bitcoin mining. So miners can ignore this merged mining option.

In contrast, the additional profit from the merged mining of Litecoin with Dogecoin is significant. So, in this case, miners often take advantage of the merge-mining option. As a result, Dogecoin gains nearly 91% of the hash-rate from Litecoin. However, in this case, the unified network of these two coins can do the job better than merged mining.

Therefore, the creation of a proper sharding system based on a Proof of Work and merged mining is a rather tricky task. The sensible blockchain solution should be attractive to both big mining pools and small mining farms with limited resources. The main feature of the sharding implementation in JaxNet is the proper system of incentives that reward participants according to their effort in network maintenance. As a result, Jax.Network preserves the high level of decentralization, even on a global scale.

The Solution implemented in JaxNet

We have described the purpose of merged mining in JaxNet. For many people, it’s often a mystery how merged mining works and how it is possible to merge-mine multiple coins simultaneously. Let’s discuss step by step how it is actually implemented in JaxNet.

First, the miner chooses the subset of shards for mining. Then he constructs block candidates for every shard chain. The structure of these block candidates is rather similar to the one used in Bitcoin: they have a block body with transactions and a small block header that includes important data for constructing the ledger.

Then the miner puts these block headers into the leaves of the Merkle tree. It is a commonly used data structure that ensures the immutability of data in its leaves. Nobody can modify these block headers without the Merkle tree root modification. In JaxNet we call this instance of the Merkle tree the Shard Merkle Tree (MMT).

Once the Shard Merkle Tree root is calculated, the miner puts it into the data container that we call the BC container. This container holds the nonce field. The task of the miner is to pick up a value of the nonce so that the hash will be “good.” Mining in JaxNet is somewhat similar to mining in Bitcoin, as it is a repetitive process of grinding possible values of the nonce field.

However, there is a difference with Bitcoin mining. Every shard in JaxNet has its own subset of “good hashes.” Hash can be good enough to sign the block candidate for one shard, and it could be bad to sign the block candidate for another shard. Moreover, in JaxNet, subsets of good hashes are disjointed. So the hash that is good for the one shard is always bad for all other shards.

Once the miner has found a good hash for a particular shard block candidate, he can broadcast it to the network along with the proof of his work. The miner’s Proof of Work includes the header of the shard block candidate, the BC container, and the inclusion proof. This inclusion proof is the Merkle proof that the shard block header is associated with the target BC container.

If a malicious actor attempts to counterfeit the shard block after the mining, his malicious actions will affect the validity of the MMT root that is included in the BC container. The immutability of the BC container is guaranteed by the Proof of Work in the form of its good hash.

As a result, the miner is able to mine multiple shard chains simultaneously. It remains to determine how he is rewarded for his work.

As we know from the first part of the paper, if the reward for the mining is issued regardless of how the merge-mining was executed, there will be a negative impact on blockchain economics. Therefore, the block reward in JaxNet is always adjusted based on the number of shards that were mined by the miner who crafted the Proof of Work for the given block. The question is how other nodes learn how merge-mining was executed by the particular miner.

The answer to this question is Merged Mining Proof (MMP). The miner broadcasts it along with his block candidate. This data record could be treated as a sort of Zero-Knowledge Proof since it demonstrates the evidence of the fact without disclosing the whole mining process. From a technical viewpoint, it’s a compressed part of MMT that we call orange subtree. The immutability of this record is guaranteed by the MMT root.

Thanks to MMP, it becomes possible to reward miners proportionally to the actual Proof of Work that was executed, and, therefore, to fix the blockchain economics. The block reward function in JaxNet will be discussed in the next post.