After Ethereum Classic was attacked by 51%, foreign experts used mining pools to make the attacker pay the price

As we all know, in the blockchain, only when most people are driven by interests (mining rewards, etc.) and behave honestly can the entire blockchain operate normally. However, if the benefits of honest behavior are lower than those of cheating, some people will take risks. If those who take risks account for the majority, various problems will arise in the entire blockchain, the most typical of which is the 51% computing power attack.

So the question is, decentralization achieves the decentralization of power, but how can power be checked and balanced after decentralization to ensure that it does not do evil?

Inspired by mining pools, Tomaz Kariz, a foreign expert, proposed to use the "prince" mining pool in the blockchain as an influencing factor when selecting a blockchain, introduce a blockchain scoring mechanism and a punishment mechanism, and combine rewards and punishments to make the cost of 51% attacks higher.

So, how do mining pools and blockchains combine? What are the results? Let’s follow the experts to find out!

Some time ago, the Ethereum Classic (ETC) blockchain suffered a 51% computing power attack, which caused me to think deeply.

Theoretically, I think a 51% computing power attack is not a failure in the design of the blockchain network, but is there a way to make these 51% computing power attack attackers pay a higher price?

When a blockchain node client finds that there are multiple blockchains at the same time, it must decide which blockchain to choose. At this time, the node client will calculate the score chainScore of each blockchain separately, and then select the blockchain with the highest score.

In the PoW consensus blockchain, the rule for selecting a blockchain is often called the "longest chain rule", where the score of a blockchain, chainScore, is equal to the sum of the amount of work done on that blockchain. The benefit of selecting a blockchain based on score is that it is completely objective.

An example of subjective scoring is where a blockchain node client scores a blockchain not only based on how much work has been done on that blockchain, but also takes into account how many blocks would be deleted from your locally maintained blockchain if you switched to that blockchain, i.e., it is biased towards blockchains that might require you to change your locally maintained blockchain.

A subjective blockchain score based on the number of blocks that will be removed from the locally maintained blockchain

Another example of a subjective chain selection rule is to calculate the chainScore as usual, but only switch to a chain with a higher score if switching to it requires removing no more than 20 blocks from the local chain (this rule is often called maximum reorg cover, max reorg cap).

Not only does this rule cause the “new node problem” (as shown in the figure above), but it can also cause hard forks even if all nodes are running the same version of the client program.

So we want to avoid subjectively scoring blockchains, because doing so will make our blockchain selection logic difficult to explain and may lead to hard forks even if every client node follows the same rules.

Blockchain selection rules

The blockchain selection rule used by Ethereum Classic is to choose the blockchain with the most work completed. Suppose an Ethereum Classic client named Bob is connecting to the Ethereum Classic network for the first time. Bob must choose between multiple blockchains, but this is not a problem. All he has to do is calculate how much work has been done on each blockchain and choose the blockchain with the most work completed.

Even if we have any number of new Ethereum Classic clients like Bob, they will calculate exactly the same score chainScore for each blockchain.

Given N nodes in a blockchain system, which form a complete graph (each node is connected to all other nodes), the blockchain selection rule should have the following properties:

Every node should consider the same blockchain as the best choice.

The blockchain selection rule should also provide the same score chainScore for blockchain C at any point in time and at any height H, which means that the score chainScore should only depend on the data on the blockchain we are evaluating.

These properties ensure that Bob and the long-lived nodes agree on which blockchain to follow, and that they gradually converge to the same blockchain over time.

It is important to note that, as we mentioned above, the blockchains with the largest chainScore in Ethereum Classic are those that have completed the most work.

Blockchain Mining

For a solo miner, it is unlikely that he will mine a block unless he controls a considerable amount of hash power.

Mining pools were invented to solve this problem. Mining pools draw on the idea of ​​"many hands make light work". A large number of miners who originally mined alone come together to keep each other warm, mine together, and share the profits together. Therefore, even if some miners may not mine a block, they can always get a stable return on their work.

Suppose there are multiple mining pools in a blockchain network, which together account for most of the hash power in the network.

Each block contains a value called coinbase / etherbase, which is used to refer to the miner who mined the block and indicates the address that should receive the mining reward.

Most blocks are mined by mining pools, and each pool typically designates an address to receive mining rewards.

Below are 16 consecutive blocks mined on the Ethereum Classic blockchain from height 7283680 to height 7283695, and the addresses of the miners who received their mining rewards:

Blocks from height 7283680 to height 7283695 on the Ethereum Classic blockchain, and the addresses of the miners who received their mining rewards

As expected, the vast majority of blocks were mined by mining pools operating in the Ethereum Classic network, with Ethermine mining 5 blocks, MiningPoolHub mining 4 blocks, and NanoPool mining 3 blocks.

In the grey blocks mining rewards are sent to addresses whose owners I don’t know, but they are most likely mining pools as well.

This seems to give us some inspiration...

Using mining pools to reduce 51% attacks? Really!

Assuming we have a mining pool that can continuously mine new blocks, we should be able to see the output of blocks frequently. When an attacker conducts a 51% computing power attack, he usually mines N blocks offline continuously, and then publishes a blockchain that is longer than the current consensus chain, resulting in the reorganization of the current consensus chain.

The blocks mined by the attacker do not generally use addresses from mining pools that we have observed in the past.

If we penalize mining pools for inconsistency, we can greatly increase the cost of an attack while keeping the consensus rules roughly the same , thus protecting us from a 51% attack.

Here, we need to first clarify how a 51% computing power attack occurs:

• Use a hashrate rental service such as NiceHash to perform the attack (assuming NiceHash is not a mining pool).

• Some mining pools secretly colluded to carry out the attack.

• A combination of the above two: mining pools colluding secretly + computing power leasing services executing attacks.

• The attack is performed using an Application Specific Integrated Circuit (ASIC).

Mining pool consistency index

The blockchain selection rule can take into account not only the amount of work completed, but also the consistency of the mining pool. We can include the influence of the mining pool by changing the definition of chainScore to the following formula:

chainScore = parentChain.score + ( block.PoW_score * PCI )

Where parentChain.score is the score of the previous blockchain, block.PoW_score is the amount of work done by the blockchain, and PCI (Pools Consistency Index) is a value between 0 and 1.

Here PCI stands for mining pool consistency. Let’s look at an implementation that uses mining pool information to assess the “health” of a blockchain.

Example of using a sliding window over the last 3000 blocks to measure the consistency of the work.

The code implementation of the chainScore function is as follows:

Reference implementation of consistent increments for sliding window mining pools

When multiple blockchains coexist in the network, we believe that the most likely consensus chain will be the blockchain that miners continue to mine. This statement is not 100% correct, but it is true for most cases, unless there is a rebellion by a mining pool that controls more than 51% of the hash power .

This approach of combining information from mining pools can predict what the future of the blockchain will look like and punish malicious actors in a way that was not possible in the past. When we set very high penalties for inconsistency in mining pools, two things happen:

1. There is only one blockchain in the network, and some mining pools stop mining. Since all miners will see a corresponding decrease in their PoW value, this does not matter to miners, because a low blockchain score does not affect their mining income.

2. Multiple blockchains coexist in the network. In this case, the blockchain with low consistency in the mining pool (usually a 51% computing power attack) will be punished.

So, how effective is this method in the face of the 51% computing power attacks mentioned above?

Using a computing power rental service (e.g. NiceHash) to perform the attack

Since other mining pools will not continue to mine on his blockchain, the attacker will be penalized by the mining pool's inconsistency over time.

Two mining pools that together control 60% of the network’s hash rate jointly carried out the attack

To solve this problem, we need to consider not only the hash power of the mining pool, but also the number of mining pools mining on the blockchain. If we have more than 10 mining pools with roughly the same hash power, then this problem becomes easier to solve.

A combination of both

For example, a mining pool that controls 40% of the hash power of the entire network rents 30% of the hash power of the entire network to carry out an attack.

Over time, the attacker will be penalized for inconsistency in the mining pool. It is worth noting that even if the attacker sets the miner address of the rented hash power to the original mining pool address, it will not help because we will look at the past data of the mined blocks.

Attacks performed using Application Specific Integrated Circuits (ASICs)

This looks like a long-term 51% attack. The attacker will be penalized by the inconsistency of the mining pool over time, but if he can keep it up, he may become the "mining pool of the past" that we refer to. In this case, the question becomes what if a mining pool rebels.

While this approach does not solve the 51% attack, it makes it more expensive for an attacker to attack, as the attacker will continue to be punished for a long period of time (many block times).

If several mining pools suddenly stop mining, the monitoring system can detect this and the community will have some time to react, such as starting to mine themselves (but they have to be careful because of the penalty mechanism) or just wait for more subsequent blocks to be confirmed when this happens.

Based on these circumstances, we first made the following assumptions:

• The mining pool is included as part of the network to enhance the security of the blockchain. Of course, if a mining pool can control 51% of the hash power of the entire network through various means, then it can still perform a 51% computing power attack, but this is not a new problem we have caused. As far as I know, the industry has not yet solved this problem.

• Once Pool A mines a block, all the next 29 blocks will receive Pool A's consistency reward regardless of who mined them, so Pool A does not gain any advantage over others.

• Fence-sitters are still welcome, but if they suddenly start mining a lot of blocks, they might get penalized. If they are somewhat consistent, we won't penalize them a lot, and they can mine new blocks easily. Some might say that this reduces security, but my hunch is that the benefits you gain from getting a pool consistency index far outweigh the revenue you lose from not having fence-sitters.

• As long as each new block is guaranteed to add some positive value to the blockchain, mining can continue to operate without the existence of mining pools.

• Since it is very difficult for a solo miner to mine a block, the penalty will have basically zero impact on them. I think most of them would like to participate in a mining pool.

• New, larger mining pools will have to gradually join the blockchain, otherwise they will be penalized for inconsistencies in their mining.

• There are many ways to define the pool consistency formula (PCI) and the blockchain score chainScore.

• This approach works better for blockchains with lower block times, since they can gain more information about the consensus of the mining pool over the same period of time.

Next, we need to use game theory to verify this hypothesis. It should be noted that it is possible to consider not adjusting the value of PoW, but using PCI as an additional value to keep PoW consistent.

Results of the sliding window mining pool consistency increment test

I simulated an ideal blockchain to test the idea of ​​the mining pool's consistency over a series of consecutive blocks.

Although the results show that the cost of a 51% computing power attack is more expensive when using the sliding window mining pool's consistent increments compared to the longest blockchain mechanism (currently adopted by most blockchains), it should be noted that due to possible flaws in the testing process, errors in the code, or the simulated environment being too ideal/simple/wrong, such conclusions may be problematic , and therefore may still be a long way from actual use on the blockchain.

In this experiment, I created about 5500 blocks (the process lasted 5500 * 14 seconds), and the attacker forked at block height 4850. By default, the interval between blocks is about 14 seconds. I made a lot of simplifications in the code, which does not fully conform to the logic used in the current blockchain (for example, the calculation of block time is different, and there is no uncle block).

Despite the differences, I think this experiment is enough to test our ideas. The experimental results are shown below. The Ratio in the results represents the ratio of the blockchain score chainScore between the main chain and the forked chain generated by the attacker at block height 4850. If this ratio is lower than 1.0, it means that the sum of the blockchain score chainScore of the main chain is lower than the sum of the attacker's forked chain.

We can also see from the graph the heights reached by the two blockchains.

Experimental Results

From the figure we can see that compared with the traditional longest chain method, the sliding window mining pool consistent incremental method is easier to select the main chain. However, even though this method wins a lot, the effectiveness of this method in a real blockchain environment remains to be tested.

From the results table above we can see that in all cases the forked chain eventually mined more blocks, but the score chainScore of the forked chain never exceeded the main chain in the sliding window scoring method (this is not entirely true, because it may have a higher score at the beginning, but in this test, the forked chain was at least 30 blocks ahead of the main chain and had a higher score).

If the attacker can persist long enough, he may become part of the "pool history", and over time the chainScore of the forked chain will exceed that of the main chain.

Of course, this code has not been reviewed by anyone but me. If you find any issues with the code, please report them to me.

Known attack vectors

51% Hash Attack

Still, the cost of an attack could be much more expensive.

Mining pool impersonation attack

The attacker can mine a longer blockchain and insert the addresses of miners from other mining pools into it, thereby adjusting the distribution of mining pools from which the attacker mines blocks to be roughly the same as before the attack.

To protect against this, we need to provide some form of proof of identity for the miner. This can be solved by adding an authentication information called minerSig (miner signature) to the block header. minerSig is the hash value of the previous block parentHash and the random number nonce of the block signed with the miner's private key. In order for the block to be valid, we need to check this verification.

Attacker joins the main network

An attacker can join the main network and mine a few blocks to avoid being identified later as mining in large quantities. This situation can be seen as a case of a mining pool defecting.

Improvement: Get rid of the mining pool assumption

Implementing a mining pool mechanism at the protocol level ensures that mining pools do exist. But even if we don’t have mining pools, the protocol will be able to optimize for this situation accordingly.

For example, we can encourage miners to gather together and form a certain number of mining pools by giving mining rewards based on the hash power of each mining pool, so that there are a total of N mining pools. If we want about 20 mining pools, then the mining pool that accounts for 5% of the total network hash power will have the highest mining reward (4 ETC).

If a pool has more/less hashing power than this value, then the pool gets a lower reward and the remaining reward is distributed among other pools based on their hashing power. Since we ultimately create the same amount of mining rewards per block (4 in this case), it does not change the total currency in circulation as defined in the monetary policy. The incentives need to be done right so that miners cluster as we want.

Developers should be reminded here that even if one person owns 5 mining pools, each of which controls 5% of the hash power of the entire network, this is not a problem because it enhances the consistency of the mining pools, thus providing us with additional security.

If a mining pool already exists, as is the case with Ethereum Classic today, this can also be implemented at a later stage if needed.

Other possible definitions of pool consistency

The pool consistency formula can be performed as follows.

• Linear regression based on mining pool data and similarity analysis.

• Penalizes the growth of hash power (either for individual miners or for the entire network). The idea of ​​the network penalty is that if there is no malicious blockchain, then the penalty is the same for everyone, and if there is a malicious blockchain that wants to get ahead of the curve, then it will be penalized more. Since block timestamps can be forged, it is difficult to give such an objective score from the blockchain data alone.

• If a solo miner or mining pool increases the rate at which they mine blocks within a given block window too quickly, they are given a “speeding ticket”.

• Conduct statistical analysis on the miners’ data.

Example of protocol-level mining pool consistency

Suppose we have a blockchain with built-in incentives for each mining pool to converge to 1% of the hash power of the entire network, resulting in a total of about 100 mining pools.

In order for a pool to contribute to the Pool Consistency Index, it needs to have been mining consistently with approximately 1% of the hashrate over the last 3,000 blocks. The Pool Consistency Index will be the ratio of pools that pass this criterion.

For example, if the last 100 blocks were mined by 50 different mining pools, the pool consistency index would be equal to 0.5, thus contributing 0.5 difficulty.

In this case, if an attacker wants to attack, he needs to mine 50% of the last 3000 blocks with different miner addresses to start getting the same pool consistency index as the main chain. In addition, we can also issue "speeding tickets" to mining pools.

Assuming we have 100 mining pools with the same hash power, we can also do some statistical analysis. All mining pools have the same probability of being "selected", which means that we can calculate the likelihood of the last 100 block states, assuming they were randomly selected, so we can penalize events where the results are unlikely to occur.

Final Thoughts

Having said all that, I am not saying that people should change their consensus algorithms, but there should be a good reason to move forward with improvements to the consensus algorithm and alternatives should be well researched before considering any changes.

These are just some of my thoughts on improving the consensus algorithm. My ideas can reduce the possibility of a 51% computing power attack on the network.

Mining pools will be part of the blockchain network anyway, so why not use them to their full potential to add security to the blockchain?

We can still think of this approach as a longest chain mechanism, the difference is that we change the way we measure the length of the blockchain. I prefer people to use a more general description, such as the maximum blockchain scoring rule.

I hope this article is helpful to you. If you have any ideas about using mining pools to reduce 51% attacks, please leave a message to the battalion commander~

Author | phyro — Tomaz Kariz

Translator | Guoxi

Produced by | Blockchain Camp (blockchain_camp)