By: Thomas Jay Rush
This article is an exercise in predicting the impact of EIP 4345. This EIP proposes to delay the difficulty bomb in December 2021. Our goal is to see if we can help determine when and how much should be delayed so that the difficulty bomb is expected to explode again in May 2022.
Preliminary knowledge
I have written many articles on this topic before:
About the difficulty calculation method: It's Not the Difficult (Chinese translation)
For how to delay the difficulty bomb: A Method to Diffuse the Difficulty Bomb
See some older articles here and here
The calculation of the difficulty bomb consists of two parts: Part A, which is used to adjust the difficulty and stabilize the fluctuation of the block generation time; part B, which is the difficulty bomb body (see the first article above for a detailed explanation).
The adjustments in Part A occur block by block, ensuring block times fluctuate around 13.5 seconds. This part of the tweak works really well and would keep block times pretty much constant if there wasn't a difficulty bomb. We're interested in Part B.
The bomb in part B is a step function that doubles the value every 100,000 blocks. No one will notice it until it "explodes", but once it starts to explode, the value will rise very fast (same as 2^n.
Notice
Notice
I am alone. It is with a growing weary heart that I write this article, using publicly available data. Everything I say here is open to discussion, but I am no longer prepared to take any responsibility for it. Please view and use everything in this article with suspicion and caution.
Actual Data vs. Theoretical Data
I'm an engineer, not a mathematician, so I'm more interested in actual data than mathematical predictions. In the following, I predict how the data will change. My forecasts are based on the formulas above, but all in simple, straightforward Excel spreadsheets.
My discussion is based on three simple observations:
Part A worked really well, making block times steady at an average of 13.3.
Part B also works very well, it is independent of part A and only improves block times.
If we ignore the bomb part, our forecast will be conservative.
In other words, if our forecast ignores the effects of the bomb, our forecast will be "earlier" than the actual time. This way, even if our forecast is wrong, there will be an extra buffer time.
The first table uses the current block number (1339 1127 at the time of writing) and extrapolates the time to block height 1400 0000 at 13.3 seconds per block:
Taking a closer look, we see that the average block time has been increasing since block 1200 0000 (although it decreased in August and September). Of course, the average block time will increase faster and faster as the bomb explodes.
Again, in order to be conservative, we choose a block generation time of 13.3 seconds to predict the specific time of future block digging, and we ignore the effect of the difficulty bomb for the time being. When the difficulty bomb explodes, the average block time increases; so, the result of ignoring the difficulty bomb is that our predicted time will be earlier than the actual mining time. (For our example, block 1400 0000 will be mined "no earlier than" January 10, 2022.)
when to fork
The first question we consider is, "When should we fork?"
In my opinion, the answer depends entirely on the value of fake_period. Ask: "Which block number should we fork at? 1370 0050, 1380 0050, or 13900 0050?" (add a 50 to make sure there is no off-by-one error - why this matters , it is left as an exercise for the reader—should the calculation of the formula use the greater than sign, or the greater than or equal sign?)
The table below shows the fake_block calculation.
Here we juxtapose the prediction of the exact time each block will be mined, with the calculation of the pseudo-block number (subtract the offset from the real block number, get the pseudo-block number, and derive the pseudo-period Number).
The pseudo-period number is what we are interested in, because the value of the difficulty bomb depends entirely on the value of the pseudo-period number. From my previous work, we think that the effect of the difficulty bomb will start to appear when the pseudo-period number reaches between 41 and 42, and it will not be obvious before that. In other words, when the pseudo-period number becomes 41, the effect of part B will override the effect of part A.
I don't want to explain here why the effects of the difficulty bomb don't manifest until the pseudo-period number reaches 41. All I'm trying to say is that the bomb would only increase the block time, and without the bomb, part A would keep the block time around 13.3 seconds. In other words, the average time between block generation will be higher than 13.3 seconds. If it is too low (the speed of block generation is too fast), part A will adjust the difficulty and bring the block generation time back—to put it bluntly— — This is how part A works.
Given the above analysis, I suggest forking at any time later than block 1380 0000. Around mid-December. I would recommend targeting a specific block number (rather than a date), say block number 1385 0000. The "pain point" (that is, when block times slow down significantly) will come around mid-January. So this goal also has room for error.
How many pseudo blocks should we defer?
Another question we need to consider is, "How much pseudoblock do we need to offset?"
As mentioned above, the offset determines the pseudo-block number, which in turn determines the pseudo-period number, which in turn determines the value of the bomb. So, in what follows, we'll focus on offsets and see what we can learn.
Values proposed by EIP 4354
First, let's take a look at the offset proposed by this EIP. Here we generate a simple graph based on an average block time of 13.3 seconds. Likewise, we ignore the effect of the bomb, since we know that the bomb will only increase the block time, thus making the actual occurrence of the corresponding block number later than our prediction. We will schedule "Arrow Glacier" (codename for the next fork) to occur at block 1380 0050 and use this EIP proposed offset of 1050 0000.
This graph seems to indicate that if we (as suggested by this EIP) set an offset of 1050 0000, the difficulty bomb will start to explode as early as mid-April (when the pseudo-period number reaches 41 again). By mid-May, blocks will start to slow down significantly (pseudo-period number reaches 43).
The largest pseudo-cycle number we have encountered before is 43, before the "Byzantine" fork. The increase in block time is noticeably visible - on the order of seconds.
Early or late fork time
For fun, I'm going to see what happens if we fork earlier or later.
The table below shows the estimated results - to my surprise - the timing of the fork has no effect on the final result. But, thinking back a bit, I think it makes sense. Because, the only quantity that determines the pseudo-period number is the offset. In addition to making the block production slower before the current fork, postponing the time of the fork has no effect on the time of the next difficulty bomb explosion (that is, between April and May).
You can see from the picture above that whether we implement the "Arrow Glacier" hard fork sooner or later, as long as we use an offset of 1050 0000, it has no effect on the timing of the next difficulty bomb explosion.
So how much should we offset?
This question depends on how much pressure you want to put on the Ethereum core developers in May. If you want to put a lot of pressure on them—so that in May the whole world will be complaining that ethereum blocks are slow—set the offset lower. If you just want to give them a slight nudge -- something like "we'd better act now, but in no rush" -- favor larger offsets.
If you're using an offset of 1050 0000, you're probably stressing them a lot. You can expect to see a significant slowdown in block production (by a second or so) by the end of April. But the trouble with the difficulty bomb is that once it starts to explode, there is no respite.
It only took 4-6 weeks to go from "significantly (slower)" to "very noticeable" to "disturbing" to "what the hell" to "death to Ethereum". I'm not kidding, because every 100,000 block cycle will get longer and longer (because every cycle, the bomb value will double, and the block time will increase very fast), and as long as it starts to explode, it will explode faster and faster. See my article above about the explosion before the "Byzantium" fork. The difficulty bomb came very slowly, but after the explosion, it was a different scene.
In the last table, I recommend using an offset of 1070 0000. I also suggest a fork after block 1380 0050. This will give us time to rest now and push the expected next explosion to mid-May. This is a conservative estimate, but it is also a realistic consideration.
Summarize
Summarize
Decide how much pressure you want to put on the core developers. If you want to give them a hard push, set the offset to 1050 0000; if you want to spare yourself, set it to 1070 0000. Fluctuating, you can take a value between these two.
The decision "when" to activate the fork has no effect on the timing of the next detonation (ie, the bomb will go off in May). The only thing that this decision affects is how long the block times will be before the “Arrow Glacier” hard fork. This is because only the offset affects the pseudo-period number, and only the pseudo-period number affects the value of the difficulty bomb.
support our work
TrueBlocks is a project backed entirely with our personal funds, with small bonuses from the Ethereum Foundation (2018), Consensys (2019), Moloch DAO (2021) and most recently Filecoin/IPFS (2021).
If you enjoyed this article, or would like to support our work, please see our GitCoin home page: https://gitcoin.co/grants/184/trueblocks. Please donate to the next round of matching. We get the added benefit of a bigger matchmaking reward. Even a small amount can have a big effect.
Alternatively, you may prefer to donate directly to us.
Original link:
https://medium.com/coinmonks/adventures-in-difficulty-bombing-837890476630
