Ethereum Developers Postpone Berlin Hard Fork
So many users depend on Ethereum (ETH) client Geth that a bug could temporarily stop the network — something blockchains aren’t supposed to do, ever. With regard to this, Ethereum Core developers decided on June 26 to delay work on the Berlin hard fork at least August attempting to give other clients a chance to increase their share of the network.
Geth is only one of 11 client specifications, but 79% of Ethereum nodes run on it, according to Ether Nodes. That percentage is also up 5% since December. Developers are concerned about the possibility that a serious but could break Ethereum — particularly as rolling updates to ETH 1.x continue before the network transition to a Proof-of-Stake (PoS) consensus algorithm under ETH 2.0.
“Geth is the majority of the network,” Geth team leader Péter Szilágyi stated in June 26 All Core Developers group call. “It’s super important that we are correct because we cannot afford to not be correct.”
Yes, similarly to the human tongue, every programming language has its nuances and thus implementation drawbacks. When Ethereum developers run updates those nuances can become nasty buts.
Alexey Akhunov, an independent developer, said in a private chat:
“The main reason [to postpone Berlin] would be to reduce dependency on Geth and allow it to fail without bringing down the whole network. Currently the burden is too high since Geth correctness is so critical, and they end up doing most of the work on ensuring everything works correctly.”
This has been accelerated by the deprecation of the Parity Ethereum client according to the announcement from Parity Technologies in December 2019. “Parity is increasingly unable to dedicate the level of resources required for even simple maintenance of this project,” the Parity team wrote in a blog post at the time.
That project’s codebase was handed off to a decentralized autonomous organization (DAO) of developers funded by ConsenSys spinout Gnosis. It now works under the name “Open Ethereum.” Since December, the client has lost around 60% of its nodes, as indicated by the Web Archive. (Note: Geth has lost approximately 14% of its nodes since December as well).
Client diversification before Berlin hard fork
Gnosis founder Martin Köppelmann said:
“In an ideal world we would have multiple clients with no client having a higher market share than 33%. While it is true that Open Ethereum has not reached the number of nodes running [that] the Parity client had, we don’t see that as a decline. Quite the opposite. When Gnosis effectively took over the responsibility for Open Ethereum we started at a market share of 0.”
Szilágyi’s concerns remain valid despite Köppelmann’s enthusiasm, however. Getting individuals, exchanges or clients to run anything besides Geth has been difficult and that dependency would be fatally exposed if Geth ever encounters technical issues.
This dependency is the key reason ETH 2.0 is so slow to launch. ETH 2.0 researchers have agreed to wait until a diversity of clients can launch in concert to prevent any issues if one or more goes down.
Comparatively, Bitcoin and most other cryptocurrencies don’t hard fork as often or have as many applications running on them. Ethereum faces something of a bind: loads of projects depending on it for 100% uptime but rolling hard forks every six to twelve months.
Furthermore, how to get other clients to catch Geth’s lead remains an open question.
Ethereum developer Greg Colvin said in the developer call that it has turned into a business question and one unlikely to be resolved by developer initiatives. Projects will opt for working with a minority client because they have acute needs which cannot be addressed by Geth, such as code not being open-sourced. That being said, Colvin said Geth should hire more staff, if possible.
Suspension of testing Ethereum Improvement Proposals (EIPs) slated for Berlin hard fork was one variant the developers agreed with. Still, Szilágyi stated that the 24/7 responsibility of keeping the “world computer” running is burning out his team.
“If we are wrong, and for example, [Ethereum client] Nethermind is correct, then it doesn’t matter that Nethermind’s code was correct and ours was wrong, because the network went off on the wrong chain,” he said.