EIP-5133 Difficulty bomb delayed to mid-September 2022 (Delaying Difficulty Bomb to mid-September 2022)
Final · Consensus & staking · EIP status Final · created 2022-06-01
Replaces the block number used in the difficulty calculation with a fake block number lowered by 11,400,000 blocks, which pushes the point at which the difficulty bomb becomes noticeable to mid-September 2022.
Why it is needed
The difficulty bomb is a mechanism that raises proof-of-work (PoW) mining difficulty exponentially as the block number grows, gradually lengthening block times. If the bomb kicks in earlier than planned, blocks slow down and the network becomes harder to use. When this proposal was written in June 2022, leaving things as they were would have made the bomb appear too early. If the effect of the bomb is misjudged, users have to live with longer block times than expected until the next hard fork ships. In particular, if the network hashrate dropped sharply ahead of The Merge, the point at which the bomb is felt could move even earlier. So this EIP lowers the block number used in the difficulty calculation by 11,400,000 blocks, delaying the bomb so that it starts to appear gradually from around mid-September 2022.
What changes
Today
- The real block number is used as is in the difficulty calculation, so the bomb grows too early
- If the bomb is felt early, block times get longer until a hard fork ships
After EIP-5133
- From FORK_BLOCK_NUMBER on, the bomb term is computed with a fake block number, which is the real block number minus 11,400,000
- The point where the bomb starts to be noticeable moves to around block 15530314, mid-September 2022
Who is affected
- Users: While the bomb is delayed, block times do not rise sharply, so the network can be used as usual
- Client teams: The change that replaces the block number with the fake block number in calc_difficulty must be applied in line with FORK_BLOCK_NUMBER
- Miners: Avoids, for the time being, the burden of the bomb switching on early and block production gradually slowing down
In depth
Delaying the bomb with a fake block number
In the exponential ice age term of the difficulty calculation function calc_difficulty, a fake block number is used instead of block.number. The formula is fake_block_number = max(0, block.number - 11_400_000) if block.number >= FORK_BLOCK_NUMBER else block.number. After the fork block, clients compute the bomb as if they were 11,400,000 blocks earlier than the actual height, so the bomb takes effect that much later. Thanks to max(0, ...), the subtraction never produces a negative result.
Predicted onset: block 15530314
The EIP text defines a predict_bomb_block function that predicts the block at which the bomb starts to become noticeable. The formula is the rounded value of block_adjustment + 100000 * (2 + log2(diff_adjust_coeff * current_difficulty // 2048)). Plugging in the difficulty of 13891609586928851 as of June 1, 2022, a coefficient of 0.1 (the level at which the bomb has historically started to be noticeable), and a delay of 11400000 gives block 15530314, which was expected to be mined around mid-September.
Expected increase in block time
It is very hard to predict exactly how much block time will increase once the bomb becomes noticeable. Based on past cases where the bomb showed up, the EIP text states that delays of about 0.1 seconds in mid-September and 0.6 to 1.2 seconds in early October can be expected.
Security considerations: hashrate variability
If the effect of the bomb is misjudged, users will experience longer block times than expected until a hard fork ships. If difficulty swings widely, this timing can shift considerably, and block time changes from long-term difficulty adjustment also affect the timing of the bomb epochs. The EIP text sees this as a network usability problem and considers it unlikely to lead to a security problem. In this case, the network hashrate could drop sharply before The Merge and bring forward the schedule on which the bomb is felt in block times, and the text states that the 11,400,000 offset was chosen with this in mind.
Backwards Compatibility and Status
There are no known backward compatibility issues. This EIP is in the Core category of Standards Track, and its status is finalized as Final.