Why did Ethereum delay the "glacial period" three times? The new hard fork is coming again!

In the recent Ethereum developer conference, the topic of the difficulty bomb (or ice age) has become the focus of discussion. According to the rules, after the ice age, the difficulty of the Ethereum network will increase once every 100,000 blocks. Going forward, we will see more than 30 seconds of Ethereum block time in February 2020. To this end, Ethereum developer James Hancock proposed that an emergency hard fork called Muir Glacier (Muir Glacier) be held when the height of the Ethereum mainnet block reaches 9,200,000 (expected around January 6 next year) to delay the ice age .

( Note: The so-called ice age is a mechanism included in the Ethereum difficulty adjustment algorithm. Its initial main design goal was to smoothly achieve ETH1.0 (PoW chain)-> ETH2.0 (PoS chain) Transition, but because the progress of ETH2.0 has been repeatedly delayed, the ice age has been postponed twice. At present, the difficulty bomb of Ethereum is triggered again, and the launch time of ETH2.0 is still far away. Therefore, the Ethereum network needs Make a hard fork again. )

The following are the specific contents of the EIP 2387 and EIP-2384 proposals related to this hard fork:

• QKL123 Blockchain List | Domestic media enthusiasm declines, some mining machines lose money (201911)
• Read Monero's Fair Mining Algorithm RandomX
• Seven years after its birth, the number of r / Bitcoin subscribers on Reddit exceeds 1.2 million

EIP 2387: Hard Fork Muir Glacier

Author: James Hancock

Status: Last time for comments ( review deadline: 2019-12-12) Type: Meta Creation date: 2019-11-22 Requirements: EIP 1679, EIP 2384

Summary

This EIP specifies the changes contained in the Ethereum hard fork named Muir Glacier. This hard fork resolves the upcoming ice age of the Ethereum mainnet and incorporates a commitment designed to address the fundamental problems of the ice age.

motivation

Ethereum achieves a consistent block time due to its difficulty adjustment algorithm. If the block time is greater than 20 seconds, the network difficulty will decrease, and if the block time is less than 10 seconds, the difficulty will increase. This mechanism makes the average block time of Ethereum generally maintain at about 13-14 seconds. And in this mechanism, there is a mechanism called "difficulty bomb" or "glacial period", which artificially increases the difficulty of the network, so that the difficulty adjustment mechanism cannot adapt to this growth at a certain point, we will See that the block time of the entire network will increase. The ice age will increase every 100,000 blocks, and this change is not obvious at first, and once we can observe this change, it will have a huge negative impact on the network.

The main problem of the ice age is that it is included in the complex mechanism of the target block time. What's worse, because it is intertwined with the algorithm, it is difficult to simulate or predict its impact on the network. To predict the impact of the glacial period, it is necessary to make assumptions about the difficulty of the mainnet in the future, as well as the impact of the change in difficulty on the glacial period and the block time.

This hard fork will delay the glacial period as reasonably as possible and give us time to update the glacial period, and we will no longer face this design problem.

Within this time frame, there are two solutions for the community to consider.

1. Update mechanisms to make behavior predictable;
2. Completely remove the ice age mechanism;

specification

Codename: Muir Glacier

Activation time:

1. Ethereum main network block number> = 9,200,000;
2. Ropsten test network block number> = 7,117,117;
3. Kovan test network block number> = N / A;
4. Rinkeby test network block number> = N / A;
5. Görli test network block number> = N / A;

Included EIP

1. EIP-2384: Istanbul / Berlin difficulty bomb delayed

EIP 2384: Istanbul / Berlin difficulty bomb delayed

Author: Eric Conner

Status: Last time for comments ( review deadline: 2019-12-12)

Type: Core

EIP creation time: 2019-11-20

A brief summary

Due to the difficulty bomb (also known as the "Ice Age") and the slow acceleration mechanism, the average block time of Ethereum is increasing, and this EIP proposal will delay the difficulty bomb by another 4,000,000 blocks (about 611 days).

Summary

Starting from ???_FORK_BLKNUM , the client will calculate the difficulty based on a fake block number. The time of this difficulty bomb will be adjusted to 9 million blocks later than the Homestead fork and 7 million blocks later than the Byzantine fork. And 4 million blocks later than the Constantinople fork.

motivation

On October 5, 2019, after the height of the Ethereum block reached 8,600,000, the difficulty bomb problem became noticeable again. The previous average block time was about 13.1 seconds, and after the block height reached 8,900,000, the average block time was about 14.3 seconds. After every 100,000 blocks, the block interval time will show an exponential increase. If the difficulty bomb continues, we will see a block time of about 20 seconds at the end of December 2019, and starting in February 2020, we will face a block time of 30+ seconds. This will make the Ethereum blockchain congested, and the cost of use will become higher.

Therefore, we had better postpone the difficulty bomb again.

specification

Adjust difficulty with fake block numbers

For calc_difficulty purposes, simply replace the block.number used in the Ice Age component with the following formula:

  fake_block_number = max(0, block.number - 9_000_000) if block.number >= ???_FORK_BLKNUM else block.number 

Theoretical basis

This will delay the Ethereum Ice Age by 52 million seconds (about 611 days), so the blockchain will recover to a 20-second block time around July 2021. It should be noted that this is to delay the ice age from the network height to 8,800,000 and then delay 4,000,000 blocks, instead of calculating from the impending hard fork time point.

Backward compatibility

This EIP is not forward compatible, so it should be included in a predetermined hard fork of a block number. It is recommended to include this EIP shortly after Istanbul's hard fork.

Relevant information:

1.https: //eips.ethereum.org/EIPS/eip-2387

2.https: //eips.ethereum.org/EIPS/eip-2384

We will continue to update Blocking; if you have any questions or suggestions, please contact us!