Starting with FORK_BLOCK_NUMBER the client will calculate the difficulty based on a fake block number suggesting to the client that the difficulty bomb is adjusting 11,400,000 blocks later than the actual block number.
To avoid network degradation due to a premature activation of the difficulty bomb.
For the purposes of calc_difficulty, simply replace the use of block.number, as used in the exponential ice age component, with the formula:
The following script predicts the bomb will go off at block 15530314, which is expected to be mined around mid-September.
Precise increases in block times are very difficult to predict (especially after the bomb is noticeable). However, based on past manifestations of the bomb, we can anticipate 0.1s delays by mid-September and 0.6-1.2s delays by early October.
No known backward compatibility issues.
Misjudging the effects of the difficulty can mean longer blocktimes than anticipated until a hardfork is released. Wild shifts in difficulty can affect this number severely. Also, gradual changes in blocktimes due to longer-term adjustments in difficulty can affect the timing of difficulty bomb epochs. This affects the usability of the network but unlikely to have security ramifications.
In this specific instance, it is possible that the network hashrate drops considerably before The Merge, which could accelerate the timeline by which the bomb is felt in block times. The offset value chosen aims to take this into account.
Copyright and related rights waived via CC0.