Published in

Coinmonks

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.

1. An article about the difficulty calculation called It’s Not the Difficult,
2. An article about diffusing the difficulty bomb called A Method to Diffuse the Difficulty Bomb,
3. 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`.

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.

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:

1. `Part A` works perfectly and produces, on average, 13.3-second blocks.
2. `Part B` (the `bomb`) also works perfectly; is independent of `Part A`, and only increases block times.
3. 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.)

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.

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.

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_period`we’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.

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.

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.

1. 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.
2. 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`.

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.

--

--

More from Coinmonks

Coinmonks (http://coinmonks.io/) is a non-profit Crypto Educational Publication. Follow us on Twitter @coinmonks and Our other project —  https://coincodecap.com, Email  — gaurav@coincodecap.com

Get the Medium app

Blockchain Enthusiast, Founder TrueBlocks, LLC and Philadelphia Ethereum Meetup, MS Computer Science UPenn