“Unannounced” Ethereum Hard Fork Proves Not All Blockchain Networks Are Built The Same
Earlier today, a change to the underlying Ethereum code made by developers some time ago resulted in an unannounced hard fork, effectively splitting the Ethereum blockchain and creating a new version that is valid for upgraded nodes but seen as invalid by ones that did not upgrade. Obviously, this was a major issue for Ethereum users, but it also offered some lessons in the difference between the two largest blockchain networks.
So What Exactly Happened With Ethereum Today?
“OK, so what happened today on Ethereum: 1. At some point Ethereum developers introduced a change in the code that led today to a chain split starting from block 11234873 (07:08 UTC) 2. Those who haven’t upgraded ([blockchain analytics engine Blockhair, Ethereum infrastructure provider Infura,] some miners, and many others) got stuck on a minority chain,” tweeted Blockchair’s lead developer Nikita Zhavoronkov. “Technically, that was an unannounced hard fork… In my opinion, today’s consensus failure in Ethereum shouldn’t be underestimated and should be considered as the most serious issue Ethereum has faced since the DAO debacle four years ago. An investigation is in order.”
The outage caused significant disruption to the Ethereum ecosystem. Major cryptocurrency exchanges Binance and Bithumb disabled ETH and ERC-20 token withdrawals. Infura, a prominent centralized Ethereum node service, suffered a service outage that led to problems for Ethereum wallet MetaMask and for ETH and ERC-20 token price feeds on other services.
It appears that these problems have stemmed from a reckless (“move fast and break things”) approach that Ethereum developers have for their codebase developments that can lead to hard forks that users don’t see coming.
Like Bitcoin, Ethereum is a decentralized proof-of-work- (PoW) based network. However, unlike in Bitcoin, the Ethereum community and its developers frequently coordinate around non-backwards-compatible hard forks — another practice that emphasizes their centralized control over the network and minimizes the role of individual node participants. Both of these practices are seen by many Bitcoiners as major compromises to the integrity of the network.
In today’s specific case for Ethereum, the upgrade was made to silently fix a bug in the codebase, per Ethereum Foundation Team Lead Péter Szilágyi. The new version of the code was less proven and less “stable” than older versions, which is why some providers didn’t upgrade. Because this upgrade was not announced as a “hard fork,” users felt they had more of a choice to upgrade or just stay on the older version and that failing to upgrade would not result in splitting from those who did (in the case of a preplanned hard fork, users know that they must upgrade prior to a code going live).
This incident makes you ask yourself: What would happen to Ethereum if the developer team was compromised and released code that could harm the network? Would anyone audit it? If it caused a chain split, which version would be the real Ethereum, the old network or the new one?
Bitcoin Core protocol developers take every precaution necessary to never introduce critical bugs and all software is specifically designed to be backwards-compatible. Of course, Bitcoin developers are human and bugs will find their ways into the code. There are many examples of these small bugs throughout Bitcoin’s history, however, the culture is strict about minimizing these issues with fastidious code review and improvement processes.
Upgrading a blockchain has frequently been compared to refilling an airplane while it is flying. Ethereum continues to present examples of what not to do when building and maintaining a reliable and dependably, censorship-resistant cryptocurrency.