Two Ethereum 2.0 consensus clients, Prysm and Teku, have released new updates to address current Beacon Chain finality issues.
The Ethereum network encountered finality issues twice in 24 hours, the first lasting 25 minutes and the second over an hour.
According to an announcement on the Ethereum Foundation blog, on May 11 and 12, there were two different events where the Proof-of-Stake (PoS) consensus mechanism for the Ethereum network’s Beacon Chain failed to achieve its intended purpose. during 3 and 8 epochs, respectively. .
However, end-user transactions were not affected due to customer diversity because not all customer implementations were affected by the occurrence.
The exact cause of the problem is still being investigated; however, it appears that heavy loads on some of the Consensus Layer clients caused by an “exceptional scenario” may have caused the issue.
Prysm and Teku announce updates
Meanwhile, Prysm and Teku have launched new updates which include modifications to prevent beacon nodes from consuming excessive amounts of resources during such exceptional scenarios.
The Prysm update, called v4.0.3-hotfix, contains the necessary optimization to prevent the Beacon Chain node from consuming too many resources during tumultuous periods.
The ETH 2.0 client encourages Ethereum node administrators to make upgrades to their nodes if significant resource usage occurs.
On the other hand, the v23.5.0 Teku update removed outdated and problematic certifications from the Ethereum mainnet. The update also included several changes and improvements designed to prevent similar attestation flood issues in the future.
Other Ethereum clients, such as Cloud, stated that they did not require essential updates for their clients. However, they have indicated that they will continue to monitor the problem and provide solutions if it worsens.
For their part, Lighthouse and Lodestar have experienced a tolerable load due to their unique architecture. while another ETH 2.0 the clients consumed a lot of resources, the two kept the network alive by verifying 40-50% of the blocks until the other clients recovered and started validating the blocks.