Is there a bug in the ETH2.0 test network? For Ethereum, it’s just a small wind and a small wave
Author | Qin Xiaofeng
Editor | Mandy Wang Mengdie
Produced|Odaily
Produced|Odaily
This past weekend, the Ethereum 2.0 testnet has another moth.
To put it simply, the root cause of the testnet this time is that the Roughtime time server of the Prysm client was interrupted, and the clock skew occurred, which caused the verifiers and block headers to be out of sync, and ultimately affected the normal operation of the testnet Medalla.
secondary title
(1) Accident retrospective
The so-called clock skew is the deviation between the block time and the normal time.
Time is crucial to Eth2.0, and each block contains a timestamp; once the time is out of sync, the network cannot function normally.
In order to prevent the system time from being inaccurate, Prysm uses Roughtime, the time server of Cloudflare in the United States, to correct it. And, in order to prevent the failure of a single machine, 6 machines were also selected.
According to a subsequent diagnosisReportReport
The end result is that the "clock skew" on the Prysm client exceeds 2 seconds for up to 90 minutes; and the overall client time is also 4 hours ahead of the standard time. According to Preston Vanloon's tweet, the clock skew occurred between 1:30 am and 3 am Beijing time on the 15th. As follows:
image description
(clock skew)
After the accident, the Prysm client immediately stopped using the Roughtime server and called on users to switch to other clients.
"We decided to disable Roughtime sync by default. There is definitely some bug in the Roughtime calculations, and we want to catch it as soon as possible. Regardless of the findings, we believe it should be an option to automatically adjust the clock or cancel it altogether. ’ said Preston Vanloon.
A few hours later, the developers completed their investigation and issued a fix.
"While fixing this bug, we inadvertently removed all the critical functionality that Prysm nodes needed to function, which made the problem even worse," said developer Raul Jordan.
secondary title
(2) Consequences
Due to time out of sync, "almost no one is synced to the head of the chain" for verification via the Prysm client. This also means that their data is invalid, and they cannot participate in verification, receive staking rewards, etc.
Although Eth2.0 is still in the testnet stage at present, these rewards are not real—including the ETH that users participate in the verification pledge is also the testnet version, which does not have real circulation.
Since the prysm client accounts for more than 64% of the entire network, after the incident, the ratio of the number of validators actively voting to the total number of validators in the Medalla testnet dropped from around 75% to less than 5%. This also means that the remaining verifiers cannot reach a consensus on the entire network, and the network cannot operate normally.
image description
(Network Engagement Rate)
Foreign media "Trustnodes" reported that the accident also caused the Ethereum network to stop for a while: when about 30% of the verification process failed, the memory problem began to appear; after about 50%, the problem became bigger; and finally at 70% After that, the network apparently stopped.
This afternoon, the Spark Mining Pool issued a call to all friends who are running the Prysm client to participate in the Medalla testnet, please check whether your client has been upgraded to the alpha.22 version. If you haven't already, please do so as soon as possible to support Medalla testnet recovery from sync failures.
secondary title
(3) thinking
This accident also reflects the importance of multi-client.
If a certain client is used too much, once a problem occurs, the operation of the entire network may be affected.
But in reality, the Prysm client is favored for a reason.
At present, there are 5 clients on Eth2.0, but the teaching provided by Prysm is undoubtedly the best, so the vast majority of verifiers still use Prysm.
Therefore, for the entire Ethereum ecosystem, in order to balance the power of each client, it is necessary to improve the usability of other clients, and this is a long way to go.
Finally, I would like to say that this accident is also an experience for Eth2.0. All problems are fully exposed in the testnet stage to ensure the future usability and security of Eth2.0.
Judging from the development of Ethereum in the past 5 years, compared with a series of challenges such as The DAO attack and forks, the accident that occurred on the testnet this time is only a small problem.
