Until recently, the market has been paying attention to the troubles of the Solana network, which repeatedly experienced problems that brought its operations to a halt. A similar situation just happened to Ethereum, which failed to process transactions for 25 minutes.
Ethereum experiences surprising problems
On Thursday, May 11, the Ethereum Beacon Chain experienced a transaction finality problem that lasted nearly half an hour. The discovery of the unidentified glitch caused concern among Ethereum core developers, who noted that despite proposing new blocks, transactions were unable to complete.
However, this is not the first incident of this type. A similar situation occurred on March 15, when low validator participation rates affected the delay of the Ethereum “Shapella” update, on a test version of Goerli. Eventually, however, the mainnet’s April 12 update completely eliminated the disruption-causing problem.
It is worth recalling that Beacon Chain is Ethereum’s original proof-of-stake blockchain, which was first launched in 2020. It initially ran in parallel with the proof-of-work network, to allow the ecosystem to completely transition to a faster and greener staking-based consensus mechanism over time.
Causes of Ethereum’s troubles
Although the new problem caused many users of the network to hold their breath, 25 minutes after it occurred, Ethereum began finalizing blocks again, and Preston Van Loon, Ethereum core developer and co-founder of Prysmatic Labs, proudly announced that “finality has been restored.”
According to data from Beaconcha.in, a site that analyzes Ethereum, epochs from 200,552 to 200,554 experienced a sudden drop in credentials.
An epoch is a period of 32 slots during which validators propose and certify blocks. It typically lasts about six minutes and 24 seconds.
Although the cause of the problem remains unclear, Ethereum developers assure that they are investigating the incident to prevent it from recurring in the future.
Differentiation the best solution
Following the Ethereum crash, a well-known consultant going by the pseudonym Superphiz pointed out that “client diversity” was a key factor in quickly restoring finality. However, he also noted that the problem could have been completely avoided if each client had only up to 33% control of the network.
Client diversity refers to the number of different client software available to validators on the network. The greater the diversity, the safer and therefore more stable the network for validators becomes.
