The Explosion and Dismantling of the Ethereum Difficulty Bomb

Editor's Note: This article comes fromEthereum enthusiasts (ID: ethfans)Editor's Note: This article comes from

Ethereum enthusiasts (ID: ethfans)

Ethereum enthusiasts (ID: ethfans)

, Author: Thomas Jay Rush, translation & proofreading: Zeng Mi & A Jian, reprinted by Odaily with authorization.

Whenever Ethereum’s time bomb goes off, there are always two problems that come up in front of us. The first question (and arguably the more important one) is: "When will block production slow down, that's unbearable." The second question is, "This time, how long should we delay the bomb?"

In this short essay, I propose a trivially simple answer to the second question. How long should the difficulty bomb be delayed? My suggestion is: "Given a hard fork needs to be performed at block height N, defer the difficulty bomb by N blocks (or less for added security)."

I'm not going to explain how difficulty should be calculated in this article (see my previous article if you want to know). The picture below has already appeared in my last article, which lists the calculation formula of difficulty.

(Text in the picture: The current difficulty value dc is obtained by adding the previous difficulty value dp and the two parts. The first part adjusts the difficulty level based on the time interval between the current block and the previous block. Let s = tsc- ts, when s < 10, the factor max(x) in the above formula evaluates to 1 (assuming a divisibility method). In this case, producing blocks too quickly will increase the difficulty and thus slow down the block production speed. If 10<= s < 20, the factor max(x) will become 0, thus ensuring that when s is close to the target time of 14 seconds, the difficulty will no longer be adjusted. And if s>=20, the value of the factor max(x) will become The factor is gradually reduced to -99, which causes the difficulty to decrease, thereby increasing the speed of block production. The second part of the equation is based on the block number of the previous block. By dividing 100,000 in the exponent, a 100,000 blocks as a periodic step function. The second part is what we often call the difficulty bomb. Without the second part, the difficulty bomb is impossible to talk about.)

The first part of the formula, I call "adjustment" (or Part A). This part corrects the deviation of the block generation time of the previous block by adjusting the difficulty of the current block. This adjustment either lowers or increases the difficulty, depending on how long it took to generate the last block. The first bracket in the image above highlights this part. Please take a moment to figure out how it works. The actual effect of part A is exactly the same as the design goal. Its function is to smooth the impact of hash rate fluctuations on network operation (Translator's Note: Hash rate is a unit of computing power, so it is also used to refer to computing power) . From the chart below you can clearly see that part A of the calculation formula works exactly as expected.

Just because part A works as designed to exclude the influence of hash rate, I don't think it is necessary to consider the actual size of computing power when thinking about how to delay the time bomb. In other words, too low computing power will not make the block generation time longer when the difficulty bomb explodes, and too high computing power will not alleviate the effect of the difficulty bomb. Given the above analysis, my conclusion is that part A of the formula has nothing to do with slowing down block times. And the second part of the formula (the B part that causes the bomb) is the culprit that causes all the trouble.

The analysis that follows will convince you that it is quite possible to treat these two parts separately. These analyzes make it easier to see that part A has no effect on block generation, while part B - the bomb - causes the block time to prolong. Besides, you'll know how easy it is to defuse the bomb by simply resetting the epoch to 0 on every fork.

secondary title

Generate data and format

Running the above code, you can generate the following very simple data file in .csv format...

The above data, combined with the daily hash rate list obtained from EtherScan, is more than enough for us to understand the difficulty calculation of Ethereum. We used RStudio and a data programming language called "R" to build the charts below. If you are not familiar with the "R" language, it is highly recommended that you check it out, it is a very good programming language.

Let's take a look at the hash rate of Ethereum first.

Daily Average Hash Rate

The first chart shows the average daily hash rate of the Ethereum mainnet, with data from EtherScan. Since I don't know how the data was collected/created, I can't vouch for its authenticity, but I'm assuming it's correct. You can click on this link to view the relevant data.

Discussion: From the graph above it is evident that the hashrate of Ethereum varies with the price of Ether. This graph reminds me of the price action of Ethereum. In the summer of 2017, the hash rate skyrocketed and peaked in the first quarter of 2018 (exactly the same as the currency price). The fluctuation of the hash rate in October 2016 was due to the notorious DDos attack at that time. The two gray vertical lines in the above figure represent two hard forks—the Byzantine hard fork (October 2017) and Constantinople hard fork (January 2019). This picture is analyzed here for the time being, but we will still mention it when we discuss the difficulty data of the blockchain next.

Raw Difficulty Data

The first graph based on difficulty data shows the data returned by Parity's RPC call get_Block. First, some standard statistics are listed below:

Our first graph is pretty intuitive:

Discussion: The data in the above figure was generated at block 8,920,000. Although processing this many data records is a piece of cake in the "R" language, given the iterative nature of data mining, we sampled 1 record out of every 100, resulting in approximately 9,000 records and presenting the above in the figure. Consistent with the previous article, the gray vertical line in the image above also represents a hard fork.

The height of the red line (y(x) = difficulty at block.x ) represents the difficulty value at the given block. You can easily see the effect of dismantling the difficulty bomb at every fork. Go back to the graph on hash rate in the previous article, in the DDos attack in the fall of 2016, you can see the relationship between difficulty and hash rate.

Assuming the difficulty bomb is not dismantled - actually extending the red line upwards from the height at which the difficulty was activated - do the same for both hard forks, and you will find that this is surprisingly consistent with the graph of the change in hash rate. In other words, hash rate and difficulty are closely linked, which makes perfect sense. Because that's what part A of the difficulty formula is designed for. It exists to directly adjust the difficulty value for different hashrates.

The behavior of miners may not change due to the dismantling of the difficulty bomb. Their mining rigs continued to run equally well before and after the difficulty bomb was defunct. The only change is that the average time to produce a block has become shorter.

Discussion: We divide the graph above by vertical lines in groups of 100,000 blocks. Keep your eyes open and look carefully, the curve representing the difficulty jump exactly coincides with the vertical line (dividing line) we made. Between these dividers, the difficulty continues to rise, but not nearly as fast as the jumps on the divider. The explosive increase in difficulty is consistent with the fact that the hash rate skyrocketed in 2017.

Maybe you've also noticed each successive "explosion" - each time the bomb explodes, the difficulty value increments twice as much as the previous one. It turns out that the periodicity of these jumps is especially important for understanding what's going on in the present moment.

In the diagrams for the rest of this article, our goal is to separate the first part (i.e. part A or "adjustment") and the second part (i.e. part B or "explosion") of the difficulty formula. Thus helping us better understand how to deal with future difficulty bombs.

secondary title

Difficulty changes every block

In the next chart, we look at the change in difficulty between each successive block. Its calculation formula is y(x) = difficulty value of block x - difficulty value of block x-1

For you, this graph may be your first visual representation of the difficulty bomb. Obviously, each explosion is twice as difficult as the previous one.

But in my opinion, this picture is still not clear enough. For example, why didn't the same pattern reappear clearly during Constantinople? In fact, it is because the hash rate has greatly increased. This part of the calculation can maintain the block time at 14 seconds, but the system fluctuates more violently. This also explains why we were unable to identify the difficulty bomb as it approached the Constantinople fork, as it was overshadowed by more violent fluctuations.

So, are there some other measures that can allow us to see more clearly? certainly! This method does exist, and we will reveal it to you in the next chart.

secondary title

Relative Change in Difficulty

The final chart in this section of the article shows the percentage change in difficulty relative to the total block difficulty. The calculation formula is

The previous chart shows the raw change in difficulty. This graph shows the normalized difficulty change, which removes the effect of the increase in hash rate, so that we can more clearly see the two different parts of the difficulty calculation formula - part A and part B.

Discussion: Now, you should understand why I said in the previous article that when discussing the difficulty bomb, worrying about computing power will be counterproductive. From this graph, you can clearly see that block production is not affected by increases (or decreases) in hashrate until the ticking time bomb "raises its head". Part A of the formula keeps the speed and output of block production in a stable state. Difficulty (from the averaged and normalized data) is hardly affected much until the ticking time bomb goes off.

There are two more interesting things to note here: (1) From the image above, you can also see that the bombs start to "look up" on the far right side of the chart, albeit farther up than the distance between Byzantium and Constantinople. (2) the streaks at the bottom of the chart are due to the part of the formula that divides by 10 in part A of the formula; (3) the higher Ha It looks as if the Hitch rate will delay the "head up", as Lane Rettig mentioned before the Constantinople fork, which we also wrote about in the article mentioned above.

I still have a lot more to share about this picture, maybe someday I will come back and continue writing. But then, I'd rather have a better way to defuse bombs in the future.

secondary title

A better way to defuse bombs

First of all, I want to emphasize again that worrying about computing power fluctuations while worrying about time bombs is counterproductive. Part A of the calculation formula has already excluded the impact of the increase (or decrease) of computing power. This is exactly what Part A is about. The near-perfectly flat difficulty increment (relative to the block height at the time) proves that part A works almost perfectly. Apparently, hash rate has no effect on block times - but we already know this - which is what the difficulty adjustment is designed for.

Bombs are defined by an extra value appended to the end of the above formula:

(Translator's Note: floor(x) is a function of rounding down, that is, taking the largest integer not greater than x, for example floor(3.14) = 3)

The above formula is a power function with base 2. Letting p = floor(current block number/100,000), we can rewrite the above formula as 2p. (You may wonder, is the -2 at the end of the formula eaten? No, we just ignore it for the time being, because its function is to make the calculated value smaller.) Finally, we get a long step function.

However, keep in mind that the core developers have reset the bomb twice - yes, literally "reset", they reset the cycle start of the bomb's calculations. This is achieved by using Go code to create a pseudo-block that is used in computations. So far, fake blocks seem to have had the effect of resetting the bomb in the past. The corrected chart below shows what really happened during this period.

The following table lists some information after reset. Did you find anything strange?

The pseudo-block number after the Byzantine fork is 1,370,000, and this value is divided by 100,000 to obtain a period of 13. That is, after the hash rate adjustment, the difficulty of each block is increased by an additional 213. When the Constantinople hard fork occurred, the fake block number was reset to 2,280,000, which means that the period became 22, which means that the difficulty of each block increased by an additional 222. I think that's why the time bomb exploded earlier than we expected. Because we didn't go back far enough when we last reset it.

The recommended value for resetting the time bomb this time is to roll back 69,000 blocks, making the epoch 0. This is the correct amount to reset.

Whenever we have to reset the time bomb, there is a very simple and easy way to reset it to the correct value. In this way, most of the problems associated with difficulty bombs will disappear. Simply set the number of blocks back when resetting the difficulty bomb to be the same as the FORK_BLOCK_NUMBER (fork block number) of the fork (or adjust it slightly). In this way, the fake block number will be set close to 0 and the epoch will also become 0.

in conclusion

Since the slowdown in the block production rate is mainly due to the existence of time bombs, in the above way, the "head up" effect will become completely predictable. The computation of part B completely depends on the pseudo-block number. If we had done this at the time of the Constantinople fork (as shown in the table below), the time bomb would not have exploded so quickly.

secondary title

in conclusion