Ethereum Developers Find Geth Bug as Byzantium Upgrade Approaches
Ethereum’s Geth Software developers will release a new version just before the Byzantium hard fork, after the discovery of a denial-of-service(DoS) attack vulnerability.
The software release was announced by the team that runs ethereum’s most famous client after discovering the bug, despite data from analytics site related to the blockchain – Ether Nodes showcasing only 1.9 percent of Geth nodes which is a relatively low rate.
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.
The second in-follow as the largest ethereum software client – Parity, on Oct 14 Yesterday, just announced a new software version as an answer to a certain “consensus bug”. As a result of the error, the network could have partitioned during the update/hard fork.
Fuzz tester still finding #Ethereum Byzantium bugs. Parity yday, Geth 2day. Fork should be postponed until 2 w of no bugs, as with Frontier
“The fork is pretty uneventful. Everything went smooth on Ropsten, and it appears like all else is on track for a healthy transition,” said Stephen King, principal and co-founder of Ethereum-based real estate app RexMLS.
Despite the mass optimism around the whole idea, it will be a difficult change for the user to completely grasp it, as it is a very technical update – described by Alex Van de Sande.
The issues unearthed by the tests have been of an unexpected severity, which brought some of the developers to put on question their touch and approach on the whole upgrading 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.
“Updating is not necessarily a quick and easy process for users with extensive infrastructure. 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.” – Detrio