Image Source
More details on Medalla - The latest Ethereum 2.0 testnet , Medalla , was deployed on August 4. After 10 days of good operation, a severe bug appeared on the beacon chain . A malfunction of the nodes created a multitude of forks which were difficult to control.
Back to the future on the beacon chain
The alert was issued when, on the night of Friday, August 14, around 80% of the validator nodes in the test network suddenly disappeared .
All of these nodes were using Prysm client software (the most widely used client software on Ethereum 2.0 testnets). The problem arose because of the timing synchronization of these Prysm nodes.
Indeed, the latter use the Cloudflare certificate system ( Roughtime ) as a clock. For a reason, Roughtime began to move 4 hours for a little over 1 hour. As a result, the Prysm nodes timestamped their blocks with a timestamp that did not yet exist.
This was not a problem at first, as the remaining nodes were rejecting the “blocks of the future” . However, a few hours after the incident, things got more complicated.
These failed blocks have started to be accepted by the network. Additionally, Prysm nodes that reconnected were rejected again because of conflicting injunctions they sent back to other validators. The protection mechanism dedicated to the EPOS Ethereum (the slashing ) began to take effect.
It had unfortunate consequences. The beacon chain found itself divided into a multitude of forks . The mess became such that the nodes could no longer even analyze the data.
After days of hard work on the part of the developers, the beacon chain is starting to return to normal operation .
Lessons to be learned from this Ethereum 2.0 bug
Ben Edgington reminds us that, despite these inconveniences, there was no problem of consensus between the various client software of Ethereum 2.0.
The time synchronization of the different clients will need more attention . This is a subject that has been widely studied , notably by Alex Vaslov (Consensys).
It is also important to have a wide variety of client software on Ethereum 2.0. If the nodes using one of them have a problem, a large proportion of the network will be able to do the work for them. Likewise, a dynamic system is needed so that validator nodes can switch from one client software to another in the event of a problem.
The developer concludes by reminding Ethereum 2.0 stakers that it is their responsibility to stay up to date. They should perpetually enrich their knowledge of how the network works and run their own validator node. Wise words that apply to all distributed systems.
Please feel free to subscribe to CryptoPlanet360 on Youtube to get the latest videos about Crypto projects and Blockchain
Subscribe here: https://bit.ly/2NSkrOU
