Two Ethereum 2.0 consensus clients, Prysm and Teku, have released new upgrades to address current Beacon Chain finality problems.
The Ethereum network encountered finality problems twice in 24 hours, the first lasting 25 minutes and the second lasting more than an hour.
According to an announcement on the Ethereum Foundation blog, on May 11 and 12, there were two different occurrences where the proof-of-stake (PoS) consensus mechanism for the Ethereum network’s Beacon Chain failed to reach finality for 3 and 8 epochs, respectively.
However, end-user transactions were unaffected due to client diversity because not all client implementations were impacted 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 triggered by an “exceptional scenario” may have caused the issue.
Prysm, Teku announce upgrades
In the meantime, Prysm and Teku have released new updates that include modifications to prevent beacon nodes from consuming excessive amounts of resources during such exceptional scenarios.
The Prysm update, dubbed 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 is urging Ethereum node administrators to make upgrades to their nodes if significant resource use occurs.
On the other hand, Teku’s v23.5.0 update removed outmoded, problematic attestations from the Ethereum mainnet. The update also included several changes and enhancements designed to prevent similar attestation flooding issues in the future.
Other Ethereum clients, such as Nimbus, claimed they required no essential upgrades for their customers. However, they have indicated that they will continue monitoring the issue and provide fixes if it worsens.
For their part, Lighthouse and Lodestar have experienced a tolerable load due to their unique architecture. While other ETH 2.0 clients consumed a large amount of resources, the two kept the network alive by verifying 40–50% of blocks until the other clients recovered and started validating blocks.
