Weekly Commentary: Finally, we have Finality

For the first time ever, the Beacon chain entered a state called inactivity leak. This is when Beacon chain blocks remain un-finalized for more than four consecutive Epochs. However, the Beacon chain was able to autonomously resolve the issue shortly after, and transactions sent to the chain during this period were not affected.

ETH’s Finality Issues

Figure 1 Twitter user @0xMert_’s tweet showcasing finality issues experienced by the Beacon Chain. Source: Beaconcha.in

• On May 11th and 12th, the Ethereum network experienced issues with finality, resulting in blocks being unfinalized for 3 and 8 epochs, respectively.
• Finality is achieved when a supermajority of validators (66%) cast votes (attestations) towards a block, permanently adding it to the history of the canonical chain.
• Despite these issues, the submission and processing of transactions remained unaffected.
• In both cases, the chain was ultimately able to reach finality on its own, without requiring any external intervention from developers.

The Problem

• The issue occurred due to memory overload on Beacon chain clients Prysm and Teku. When validators attest that a Beacon block is final, other validators must recreate the state of the block in order to validate it.
• However, the chain was flooded with attestations for earlier blocks, causing a backlog.
• This led to some validators using Prysm and Teku clients having to replay and recreate multiple states from past blocks while trying to confirm new attestations.
• These circumstances overloaded their CPUs and memory and rendered them unable to validate incoming attestations.

The Solution

• The quick fix introduced by Prysm and Teku tries to solve this problem by introducing heuristics to determine which attestations are worth listening to, and which ones to ignore.

Figure 2 The distribution of Ethereum Client implementations across active validators on the network. Source: Clientdiversity.org

• The issue did not affect all Beacon chain validators, as different validators use different client implementations.
• This allowed the Beacon chain to regain Finality.
• Validators running other clients handled the processing of older attestations differently. For instance, the Lighthouse client applies a rate limit to how many old states it can process within a given period of time.
• This approach prevented their CPUs from being burdened with the task of creating and simulating all the earlier blocks these attestations were pointing to.