The discovery of a denial-of-service (DoS) attack vulnerability led the developers of ethereum’s Geth software to release a new version just days before the Byzantium hard fork.
On finding the bug, the team behind ethereum’s most popular client published a new software release, yet data from blockchain analytics site Ether Nodes shows a relatively low rate – only 1.9 percent of Geth nodes – of adoption at press time.
With Geth comprising about 75 percent of all ethereum nodes, the vulnerability could leave nodes running the previous Byzantium-compatible release more susceptible to DoS attacks after the hard fork.
Explained by ethereum developer Casey Detrio on Reddit, the vulnerability stems from an oversight in one of the new Byzantium features. The risk is that this bug could be exploited by an attacker who wants to take ethereum nodes offline – a form of attack that the ethereum community has dealt with in the past.
Bug fixes have been coming from other ethereum node software groups ahead of next week’s planned fork as well.
Yesterday, the team behind Parity, ethereum’s second largest software client, issued a new release of its software (the fourth iteration) that corrected a “consensus bug” – an error which could have caused the network to partition during the hard fork. Currently, less than 20 percent of Parity nodes have updated to the new release, according to Ether Nodes.
Hard forks are hard
The issues unearthed by the tests have been of an unexpected severity, leading some ethereum developers to question their approach to the hard fork release process.
Internal discussions are also underway about the possibility of postponing Byzantium, but this approach also poses risks. This strategy would require all nodes to update their software so that the software change is triggered at a later time – a complicated prospect with such little time before the fork.
Indeed, the Parity team tweeted out that, in their view, the fork should be delayed given the recently discovered issues.
Speaking to , Detrio explained that “updating is not necessarily a quick and easy process for users with extensive infrastructure,” such as exchanges or mining pools, and requires ample time to be done correctly.
“The second concern is that there may be more undiscovered consensus bugs that could be found after the activation block, which would then result in needing to perform emergency client updates.”