Ethereum developers to decide on difficulty bomb delay by April 29

Galaxy Digital researcher Christine Kim shared some details about the Ethereum all-core developer meeting that took place on April 15.

During the meeting, ETH developers discussed the next phase of pre-merge testing and the Shanghai upgrade, with plans to conduct the fourth Goerli testnet shadow fork on Tuesday and the second mainnet shadow fork on Saturday.

In addition to this, ETH core developers will no longer accept proposals for Shanghai, the first hard fork of the merged network. As for the timing of the merger, no updates were reported, but Q3 2022 remains the target.

Therefore, developers have until April 29 to decide how long they want to delay the difficulty bomb schedule.

According to previous news, the Ethereum difficulty bomb is expected to arrive in June.

Ethereum difficulty bomb delays:

The first difficulty bomb delay

In March 2017, the block height reached 3.7 million, the difficulty bomb was activated for the first time, and the block time increased rapidly. During this period, the difficulty was adjusted 6 times until it was extended to 30 seconds in October. At this time, if the difficulty bomb is not stopped as soon as possible, it will seriously affect the Ethereum ecosystem. After discussion by the development team, Ethereum launched a hard fork at a block height of 4.37 million - the Byzantine upgrade. The upgraded version includes the EIP-649 proposal, which delays the start time of the difficulty bomb by subtracting 3 million from the current block height as the pseudo block height used in the formula.

The real block height at this time is 4.37 million, but the pseudo block height used to activate the difficulty bomb is 1.37 million (437-300). A simple calculation shows that when the pseudo block height reaches 3.7 million again, that is, after 2.33 million (370-137) blocks - that is, the real block height reaches 6.7 million (437+233), the difficulty bomb will be activated again.

Second Delay of Difficulty Bomb

On January 15, 2019, Afri Schodeon, the coordinator of the Ethereum Constantinople upgrade, discovered that Ethereum's difficulty bomb had been activated as scheduled at a block height of 6.7 million, and "exploded" at a block height of about 7 million. The next day, Eric Conner, a core developer of Ethereum (the developer who launched EIP-1559), pointed out on Twitter that after the difficulty bomb exploded, the average block time had increased from 14 seconds to 15.5 seconds, and would accelerate.

In mid-February, the Ethereum block time rose to 20 seconds, and the problem once again faced Ethereum developers. The only way was to fork and upgrade to deal with the impact of the difficulty bomb. On February 28, the Constantinople upgrade completed the fork at a block height of 7.28 million, and the difficulty bomb crisis was once again temporarily resolved. The EIP-1234 included in the Constantinople upgrade not only postponed the difficulty bomb, but also an important change was to reduce the block reward to 2 ETH. The method of delaying the explosion this time is the same as the Byzantium upgrade, that is, simply reducing the pseudo-block height in the difficulty factor by 5 million. After the adjustment, the real height is 7.28 million and the pseudo-height is 2.28 million (728-500). When the pseudo-height returns to 3.7 million, that is, the real height reaches 8.7 million (370-228+728), the difficulty bomb will be activated again. This time, only 1.42 million blocks are needed, so the time is shorter than the previous time.

The third delay of the difficulty bomb

On October 5, 2019, the difficulty bomb was triggered ahead of schedule at block height 8.6 million, and in mid-December, the block time rose to 17 seconds. Ethereum developers had to hard fork again at height 9.2 million shortly after the Istanbul upgrade. This is the Muir Glacier upgrade, which has only one improvement proposal (named after the glacier because the upgrade only targets the difficulty bomb, and after the bomb fully explodes, the block reward will be "frozen", and the fifth postponement considered recently may also be named in this way), namely EIP-2384, which aims to postpone the difficulty bomb by another 4 million blocks, that is, 13.2 million height, which is about 611 days.

There is another sentence in the proposal that attracts attention: it is best to postpone the difficulty bomb again until the expected release date of the final version of the ETH2.0 tool (finality gadget).

The fourth delay of the difficulty bomb

This time, the Ethereum development team did not wait for the difficulty bomb to explode. On August 5, 2021, Ethereum launched the London upgrade at a height of 12.965 million, and the difficulty bomb was postponed again. This upgrade includes EIP-3554, which reduces the pseudo-block height in the difficulty factor by 9.7 million, or 2.77 million, from about 12.47 million (this height is not the current actual height, but an estimated height set when the protocol was proposed). Therefore, the difficulty bomb will be activated again after about 930,000 (370-277) blocks, which takes about 4.7 months (officially estimated to be launched in the first week of December) based on a block time of 13 seconds.

The fifth time EIP is proposed to postpone the difficulty bomb?

In July 2021 , Ethereum core developer Tim Beiko said: Assuming we have a non-merge upgrade (author's note: assuming that the Shanghai upgrade in December cannot complete the 2.0 merge, in fact this assumption is likely to happen), we need to decide whether to include anything other than another difficulty bomb delay (author's note: if other upgrade protocols are included, then keep the name "Shanghai", otherwise consider using the "Glacier Theme" naming, for the same reason as the Muir Glacier upgrade).

On August 20, 2021 , Tim Beiko said in a review of the Ethereum core developer conference call that basically all teams agreed that in addition to the consensus changes for the merger of Eth1 and Eth2, there are other important things that need to be done in the next few months, most of which are client performance optimizations for the merger, better separation of consensus engines, etc. In view of this, the participants agreed not to perform a feature fork in December, which means that the difficulty bomb may be postponed and other small changes (one line) will be added, but no new EIP will be generated before the merger.