Adventures in Difficulty Bombing

Published in

Coinmonks

8 min readOct 10, 2021

An exercise in predicting the future for the Arrow Glacier fork

This article is an exercise in predicting the effect of EIP 4345. That EIP sets back the difficulty bomb at an as-yet-undetermined point in December of 2021. Our goal is to see if we can help identify when and how far back to set the bomb so we can expect it to explode again in May of 2022.

Some Preliminaries

I’ve written a lot about this subject previously:

An article about the difficulty calculation called It’s Not the Difficult,
An article about diffusing the difficulty bomb called A Method to Diffuse the Difficulty Bomb,
And some other, older articles here and here.

The difficulty calculation consists of two parts as explained in the first article: Part A (for adjustment) and Part B (for bomb).

The adjustment or Part A is the every-block adjustment that keeps block times hovering around 13.5 seconds. This part works perfectly and would, in the absence of the bomb, keep block times constant. We’re not interested in Part A.

The bomb or Path B is a step-function that doubles every 100,000 blocks. It lies mostly unnoticed until it starts to ‘explode’ and once it starts to explode, it explodes rapidly (as 2^n tends to do). We’re interested in the bomb.

The value of bomb depends solely on fake_period (called n_sub_p in the second part of the equation above). fake_period depends solely on fake_block which depends solely on the current block, called real_block below, and offset.

A Note of Caution

I am but one person. I’ve written this article using publically available data and my own increasingly tired mind. What I say here is obviously open for discussion, but I disclaim any responsibility for what is presented here. Use the following with caution and treat everything I say with skepticism.

Actual vs. Theoretical Data

I’m an engineer, not a mathematician, therefore I’m much more interested in the actual data than I am in what the math predicts. In the following, I present a prediction of how the data will change. My prediction is based on the equations, but it is just a simple, straightforward Excel spreadsheet.

My discussion is based on three simple observations:

Part A works perfectly and produces, on average, 13.3-second blocks.
Part B (the bomb) also works perfectly; is independent of Part A, and only increases block times.
If we ignore the bomb, our prediction will be conservative.

In other words, if we make a prediction ignoring the effect of the bomb, our prediction will be “early.” This leaves additional breathing room if we’re wrong.

The first spreadsheet takes the current block (13,391,127 at time of writing) and extends it forward by 13.3 seconds per block until block 14,000,000:

Looking more closely, we see the average block times since block 12,000,000 has been increasing (notwithstanding the decreases in August and September). Of course, average block times increase more quickly as the bomb explodes.

Again, in an effort to be conservative, we’ve chosen 13.3 seconds to estimate future blocks and, remember, we’re ignoring the bomb. When the bomb starts to show, average block times increase, therefore this estimate produces dates earlier than what will actually happen. (In other words, block 14,000,000 will happen “not earlier than” January 10th, 2022.)

When to Fork

The first question we need to consider is, “When should we fork?”

This decision depends, in my opinion, only on the fake_period. The question is, “Should we fork at block 13,700,050, 13,800,050 or 13,900,050?” (Adding ‘50’ here ensures there are no off-by-one errors — I’ll leave it as an exercise to the reader to figure out of this matters — does the calculation use greater than > or greater than or equal to ≥?)

This next spreadsheet shows the fake_block calculation.

Here we’ve taken the estimates of when each real_block occurs and subtracted offset (i.e. the setback from previous forks) to arrive at fake_block and, by simple division, fake_period.

Fake_period is what we’re interested in since bomb depends solely on that value. From previous work (see the articles above), we believe the bomb starts to show when fake_period gets to 41–42, but not earlier. In other words, Part B starts to dominate Part A around fake_period 41.

I won’t explain why I say “but not earlier” in the previous paragraph. Suffice to say that the bomb only increases block times and, in the absence of the bomb, Part A keeps block times hovering at 13.3 seconds. In other words, average block times stay above 13.3 seconds, and if they go below, Part A adjusts them to bring them back up— said more succinctly — Part A works.

Given the above, I suggest that we fork any time after block 13,800,000. That is, around the middle of December. I would target a specific block as opposed to a date, say 13,850,000. The “pain point” (that is, noticeably slower block times) will start around mid-January, so there’s some room for error.

How Much Should We Offset

The other question we need to consider is, “How many blocks should we offset?

As we’ve said above, offset determines fake_block, which determines fake_period, which determines bomb. So, in the following, we’ll focus on offset and see what we can learn.

The Suggested Value in EIP 4354

First, we’ll look at the suggested value of offset the EIP. Again, we’ll produce a simple spreadsheet assuming 13.3 second average block times. Also, we will ignore the bomb, with the understanding that the bomb can only increase block times and therefore would shift the calculation into the future. We’ll use 13,800,050 for the ork_block of Arrow Glacier (the name of the next hard fork) and 10,500,000 for the offset.

This seems to say that, if we set back by 10,500,00 blocks (the suggested value), the earliest time that blocks will start to slow down will be the middle of April (fake_period 41). By the middle of May, blocks will start to slow down noticeably (fake_period 43).

The highest fake_periodwe’ve gotten previously was just prior to Byzantium, where we got to fake_period 43. The slowdown at that time was quite noticeable — in the multi-second range.

Speeding Up or Delaying the Date of the Fork

As a short diversion, I was interested to see what happens if we either (a) make the hard fork earlier or (b) make the hard fork later.

The next spreadsheet shows the result of that estimate — I found this a bit surprising —iIt seems to have no effect on the next hard fork. Upon further reflection, it makes sense, though. The only value determining fake_period is offset. Other than the slowing block times prior to the fork if we were to delay, forking earlier or later has no effect on when the next bomb explodes (i.e. the one in April/May).

You can tell from the above chart that doing the Arrow Glacier hard fork earlier or later — if we use an offset of 10,500,00 blocks — has no effect on when the next bomb starts to make itself felt.

Conclusion: We can do the Arrow Glacier hard fork whenever is comfortable.

How Much Should We Offset?

The answer to the next question, “How far back should we make the offset?”, depends on how hard you want to push on the Core Devs in May. If you want a heavy push — so that the entire world is complaining about slow blocks — use a smaller number. If you want a light push — as in “We better do something soon, but we have some time” — use a larger number.

If you use 10,500,00 for offset, you may be creating a heavy push. You can expect to see noticeably slower blocks by late April (on the order of a second). But, the trouble with the bomb is that once it starts to explode, it explodes.

“Noticeable” turns into “Quite Noticeable” which turns into “Concerning” and then “Holy Shit” and then “What the Fuck” in the manner of four to six weeks. It is true that each 100,000 block period takes longer to process (because the bomb doubles, block times increase increasingly quickly), but once the explosions come, they come quickly. See the article mentioned above about the Byzantium bomb. The bomb starts slowly, but then it truly does explode.

In this final spreadsheet, I’ll propose that we use an offset of 10,700,000. I also propose that we fork some time after block 13,800,050. This leaves some room to breathe now and pushes the estimate of the next bomb to the middle of May which, again, is conservative, but realistic.

Conclusion: Set the offset higher than 10,500,000.

Summary

Decide how hard you want to push on the core devs. If you want to push hard, set the offset to 10,500,000. If you want to leave yourselves breathing room, set the offset to 10,700,000. Compromise somewhere in the middle.
The decision about “when” the chain is forked has no effect on the next bomb (that is, it has no effect on the May bomb). The only effect of delaying or speeding up the Arrow Glacier hard fork is how long block times will get before the fork. This is because only offset effects fake_period and only fake_period affects bomb.

Support Our Work

TrueBlocks is totally self-funded from our own personal funds and a few grants such as The Etheruem Foundation (2018), Consensys (2019), Moloch DAO (2021), and most recently Filecoin/IPFS (2021).

If you like this article or you simply wish to support our work go to our GitCoin grant https://gitcoin.co/grants/184/trueblocks. Donate to the next matching round. We get the added benefit of a larger matching grant. Even small amounts have a big impact.

If you’d rather, feel free to send any token to our public Ethereum address at trueblocks.eth or 0xf503017d7baf7fbc0fff7492b751025c6a78179b.

Join Coinmonks Telegram Channel and Youtube Channel learn about crypto trading and investing