Big breath as Beacon Chain stops finalizing... and then recovers

An unidentified issue on Ethereum’s Beacon Chain led to a halt in transactions for nearly half an hour on May 11.

Around 8:15pm on Thursday May 11, a number of Ethereum core developers announced that the Beacon Chain was having issues with confirming transactions. New blocks were able to be proposed but an unknown issue was preventing them from being finalized.

The beacon chain stopped finalizing about thirty minutes ago. I don’t know why yet, but in general the chain is designed to be resilient against this, transactions will continue as usual and finalization will kick in when the problem is resolved. pic.twitter.com/utAS0uAWpG

— superphiz.eth ? (@superphiz) May 11, 2023

A similar issue occurred on March 15, where low validator participation rates caused a delay on the Goerli testnet version of Ethereum’s “Shapella” upgrade, which was successfully executed on April 12.

The Beacon Chain is Ethereum’s original Proof-of-Stake blockchain first launched in 2020. On Sep. 15, 2022, Ethereum’s pre-existing Proof-of-Work chain “merged” with the Beacon Chain, finalizing the network’s transition to a faster and more environmentally-friendly Proof-of-Stake consensus mechanism.

After 25 minutes the mainnet began finalizing blocks once more, with Ethereum core developer and Prysmatic Labs co-founder Preston Van Loon announcing that “finality has been restored.”

Finality has been restored. We do not know the root cause yet, but something happened to cause several client implementations to work really hard to keep up with the chain.

— prestonvanloon.eth (@preston_vanloon) May 11, 2023

According to data from blockchain analytics provider Beaconcha.in, Ethereum epochs 200,552 to 200,554 witnessed a sharp and sudden decline in the number of attestations.

For context, an epoch is a period of 32 “slots” where validators propose and attest for blocks. An epoch typically lasts about six minutes and 24 seconds.

The cause of the issue remains unclear, however Ethereum developers said that the problem is being investigated to prevent it from occurring again.

Following the incident, pseudonymous Ethereum consultant @Superphiz noted that “client diversity” was one of the main reasons that the loss of finality was so short-lived. However, he also pointed out that the loss of finality could’ve been avoided altogether if no client had more than 33% control.

Client diversity refers to the number of software clients available to network validators, and greater diversity among clients means a more secure and robust network for validators.

Magazine: Here’s how Ethereum’s ZK-rollups can become interoperable