“Difficulty Bomb” Reconsidered by Ethereum Developers Ahead of Hard Fork
- The difficulty bomb was created in 2015 as a piece of code for the Ethereum blockchain, though it has been delayed twice.
- Some developers want to do away with the difficult bomb all together.
The “difficulty bomb” has been a planned part of the Ethereum blockchain for quite a while, but developers are seemingly reconsidering this protocol. According to reports from CoinDesk, the new hard fork could push back a necessary network feature by about two years, in an effort to eliminate the complications with Ethereum’s upgrade to proof-of-stake.
EIP 2387 was developed in November this year, and it would schedule a hard fork to take place on January 6th. In doing so, the difficulty bomb would be delated for about four million blocks, which is approximately 611 days. The new hard fork proposed is called Muir Glacier, named for the retreating glacier in Alaska, which is likely a play on the nickname “Ice Age” for the protocol as well.
The hard fork would be implemented at block 9,069,000, implanting a bridge that connects the current proof-of-work chain with the Beacon Chain. The Beacon Chain is the first phase of the transition to PoS with Eth 2.0.
Developers all voiced concerns last week about the ability to maintain the current health of the chain with the transition to Eth 2.0, especially considering the way that other networks like Binance Chain and EOS are looking to pick off projects. To make matters even more complicated, the Istanbul hard fork is set to hit the blockchain by Saturday. Considering the rough consensus during the developer call, it is unlikely that developers will agree on Muir Glacier, which means that block times will continue to move. The current network’s capabilities are likely to be restricted as the users are crowded with transaction fees.
The difficulty bomb is a piece of code that was developed almost five years ago, and it is one of the two ways that the hashing difficulty of Ethereum’s blockchain is increased. Its purpose is to force the network to migrate to PoS with the changes to come with Serenity, which isn’t planned until 2021. Much like Bitcoin, the difficulty adjustment helps to control the amount of rewards that miners get while they mine on the network.
However, unlike the original cryptocurrency, the difficulty bomb increases how much time the miner needs to spend on the block by 10-20 seconds for every 100,000 blocks mined. The difficulty bomb is directly attached to the timing of the mined blocks, which makes it hard to determine when the network will be faced with the effects.
The bomb has been delayed twice already, and EIP 2387 would make this the third instance. During the first time, the bomb was delayed by 3 million blocks in 2018 with the Byzantium hard fork. In February this year, the developers delayed the bomb by another 2 million blocks, thanks to the Constantinople hard fork. Based on the chart below, the block times reached over 30 and 20 seconds in the Byzantium and Constantinople hard forks, respectively.
Eric Conner, an Ethereum developer, sent a private message on the matter, stating, “It looks like given faster block times since Constantinople, it was a bit underestimated on when [high transaction fees] would hit again. People were under the assumption we had until the next fork after Istanbul, but it’s slowly kicking in now.”
Considering that the uptick is sooner than anticipated, Conner went to work on the draft of the Istanbul/Berlin Difficulty Bomb Delay, which is included in EIP 2387. Within just over six weeks, block times have risen to 14.3 seconds, according to Connor. With this one-second increase, there’s major implications, especially considering that the bomb is a major feature of Ethereum.
Even though the bomb is an original feature, there are some developers that believe it should completely be done away with, instead of simply avoided for a little longer with a hard fork here and there. Every time it has become inconvenient to have it implemented, it’s been pushed back, but there are still some individuals who see the reason for keeping this original plan. After all, Ethereum clients are basically pushed to stay updated in the network.
Micah Zoltu, an Ethereum developer, said privately:
“The strongest argument for keeping some kind of expiry is to ensure that there is no option for ‘do nothing.’” He added,
“The issue is more around stakeholders just simply no longer paying attention and not upgrading their clients. The bomb is about ensuring people have to make a conscious decision to fork in the face of regular network upgrades.”
Presently, Ethereum developers are still able to comment on the EIP 2384. Even though EIP 2387 managed to reach a rough consensus, EIP 2384 must be both finalized and accepted by clients before it is implemented. Zoltu stated,
“I’m on the fence between cutting out the bomb entirely and just changing the way the bomb works. What I’m against is keeping the bomb implemented as it is.”