EIP-2384 Muir Glacier difficulty bomb delay

Final · Consensus & staking · EIP status Final · created 2019-11-20

As the difficulty bomb begins to lengthen block times again, this replaces the actual block number used in the difficulty calculation with a fake number that subtracts 9,000,000, pushing the bomb back by 4,000,000 blocks (about 611 days).

Why it is needed

Ethereum has a built-in mechanism called the difficulty bomb. It is code that exponentially raises mining difficulty as blocks accumulate, progressively lengthening block creation time; it is also called the ice age. The effect of this bomb started becoming noticeable again around block 8,600,000 on October 5, 2019. The average block time, which had been 13.1 seconds, rose to about 14.3 seconds by block 8,900,000, and this effect grows exponentially every 100,000 blocks. According to estimates in the original text, block times of 20 seconds are expected by late December 2019, and over 30 seconds from February 2020 onward. Slower blocks bloat the chain and raise the cost of writing to it. This is why the proposal is to delay the bomb once more, to around the time Eth2's finality gadget is expected to launch.

What changes

Today

After EIP-2384

Who is affected

In depth

How the bomb resurfaced

The effect of the difficulty bomb began to be observed again starting at block 8,600,000 on October 5, 2019. The average block time, which had been about 13.1 seconds, rose to about 14.3 seconds by block 8,900,000, and accelerated exponentially every 100,000 blocks thereafter. The original text estimated the bomb's further impact, projecting block times of 20 seconds by late December 2019 and over 30 seconds from February 2020 onward. If this continued, the chain would bloat and usage costs would rise, so it was judged better to delay the bomb until around the expected launch time of the Eth2 finality gadget.

Fake block number formula

The specification is a single line. In calc_difficulty, the block.number used in the exponential ice age term is replaced with the following formula: fake_block_number = max(0, block.number - 9_000_000) if block.number >= MUIR_GLACIER_FORK_BLKNUM else block.number. In other words, from the Muir Glacier fork block onward, the chain is treated, solely for the difficulty bomb calculation, as if it were 9,000,000 blocks younger than it actually is. Before the fork block, the actual block number is used as before.

The 9,000,000 reference point

From MUIR_GLACIER_FORK_BLKNUM onward, clients compute as if the difficulty bomb's adjustment were delayed by 9,000,000 blocks relative to the Homestead fork. This is 7,000,000 blocks relative to the Byzantium fork, and 4,000,000 blocks relative to the Constantinople fork. The structure is a cumulative total of 9,000,000, built from the two prior delays (3,000,000 in EIP-649, 5,000,000 in EIP-1234) plus an additional 4,000,000 blocks.

Calculating the 611 days and its reference point

This delay pushes the ice age back by 52,000,000 seconds, about 611 days. As a result, the point at which the chain reaches 20-second block times again becomes roughly July 2021. However, the reference point for the 4,000,000 blocks is not the block at which the EIP's fork activates, but roughly block 8,800,000. In other words, the 4,000,000 blocks are pushed from the point where the bomb's effect started being felt, not freshly counted from the activation point.

Backward compatibility and fork schedule

This EIP is backward-incompatible and introduces a backward incompatibility into the difficulty calculation. This is because different difficulties are computed for the same block depending on whether it is before or after the fork block. It must therefore be included in a hard fork scheduled for a specific block number, with all clients switching over together. The original text recommends including it immediately after the Istanbul fork. Test cases were to be created once developers accept the specification or clients implement it.

Implementation: same logic as the prior delays

The implementation logic is no different from EIP-649 for Byzantium and EIP-1234 for Constantinople. Only the number of blocks subtracted changed, to 9,000,000; the method of rolling back the bomb term using a fake block number is the same. The Parity-Ethereum implementation is in pull request parity-ethereum#9187. This EIP has status Final, a finalized specification included in the Muir Glacier fork.

Original EIP · ← EIPs