in , ,

Ethereum Developers Delay Berlin Hard Fork to Stem Client Centralization Concerns

ethereum-developers-delay-berlin-hard-fork-to-stem-client-centralization-concerns

Bundestag, Berlin, Germany (Ricardo Gomez Angel/Unsplash)

Ethereum Developers Delay Berlin Hard Fork to Stem Client Centralization Concerns

So many users are dependent on Ethereum client Geth that a bug could temporarily freeze the network – something blockchains aren’t supposed to do, ever. In light of this, Ethereum Core developers decided Friday to postpone work on the Berlin hard fork until at least August in an effort to give other clients a chance to increase their share of the network.

Geth makes up 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 worry that a serious bug could break Ethereum – particularly as rolling updates to Eth 1.x continue before the network transitions 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 said in last Friday’s All Core Developers group call. “It’s super important that we are correct because we cannot afford to not be correct.”

Ethereum languages

Having a diversity of clients is good for the network. It allows different projects to join Ethereum’s developer community – from the tiniest startup to JPMorgan. Ethereum had eight languages in various levels of completeness one year after its 2015 launch. The Ethereum Foundation currently lists clients in five languages including Go, Solidity, Java, JavaScript and Python. 

Yet, like the human tongue, every programming language has its nuances and therefore implementation drawbacks. When Ethereum developers conduct updates those nuances can turn into nasty bugs.

“The main reason [to postpone Berlin] would be to reduce dependency on Geth and allow it to fail without bringing down the whole network,” said independent developer Alexey Akhunov in a private chat. “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 as announced by 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 operates under the name “Open Ethereum.” Since December, the client has lost nearly 60% of its nodes, according to the Web Archive. (Note: Geth has lost some 14% of its nodes since December as well.)

Client diversification

“In an ideal world we would have multiple clients with no client having a higher market share than 33%,” Gnosis founder Martin Köppelmann said in a private message. “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 regardless of Köppelmann’s enthusiasm, however. Getting individuals, exchanges or clients to run anything but Geth has been difficult and that dependency would be fatally exposed if Geth ever encounters technical issues.

This dependency is the very 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 hiccups 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 12 months. 

Geth burnout?

Moreover, 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 become a business question and one unlikely to be resolved by developer initiatives. Projects will choose to work with a minority client because they have acute needs that Geth cannot address, 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 was one option the developers settled on. Still, Szilágyi concluded the 24/7 responsibility of keeping the “world computer” turning 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.

Disclosure

The leader in blockchain news, CoinDesk is a media outlet that strives for the highest journalistic standards and abides by a strict set of editorial policies. CoinDesk is an independent operating subsidiary of Digital Currency Group, which invests in cryptocurrencies and blockchain startups.

https://www.coindesk.com/ethereum-developers-delay-berlin-hard-fork-to-stem-client-centralization-concerns

Leave a Reply

Your email address will not be published. Required fields are marked *

blockchain-bites:-digital-dollars,-ethereum’s-gas-and-asx’s-blockchain-‘lacks-clarity’

Blockchain Bites: Digital Dollars, Ethereum’s Gas and ASX’s Blockchain ‘Lacks Clarity’

crypto-vc-chiefs-talk-covid-19-recovery,-bitcoin-upside-at-real-vision-conference

Crypto VC Chiefs Talk COVID-19 Recovery, Bitcoin Upside at Real Vision Conference