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. )
- Supervision and oversight of regulatory oversight have paved the way for the healthy development of the blockchain industry
- ECB policy maker: Libra may challenge the dollar status and support the establishment of the international central bank digital currency
- The 18 millionth bitcoin will be dug out this week, and the remaining 3 million bitcoins will still need 120 years.
- Interpretation: What is the nature of the technology based on the blockchain supply chain?
- Global Blockchain Private Equity Financing Overwhelming Winter, November Dec. 66.4% MoM
- Central Bank: Supports Pioneering Pilot Fintech Innovation Supervision Pilot in Beijing
The following are the specific contents of the EIP 2387 and EIP-2384 proposals related to this hard fork:
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
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.
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.
- Update mechanisms to make behavior predictable;
- Completely remove the ice age mechanism;
Codename: Muir Glacier
- Ethereum main network block number> = 9,200,000;
- Ropsten test network block number> = 7,117,117;
- Kovan test network block number> = N / A;
- Rinkeby test network block number> = N / A;
- Görli test network block number> = N / A;
- 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)
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).
???_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.
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.
Adjust difficulty with fake block numbers
calc_difficultypurposes, 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
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.
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.