The Ethereum developers are constantly working towards creating a robust Proof of Stake world for validators on the network ever since The Merge upgrade. A proposed change to Consensus specs triggered another possible edge case issue with Slashed Validators as proposer before exiting the chain. After reviewing the PR to remove fork-choice weight of slashed validators, Mikhail Kalinin discovered an issue with the get_beacon_block_proposer function. This creates a contradiction that needs to be addressed to prevent slashed validators from becoming a proposer. Let's take a look at the proposal to prevent slashed validators from becoming proposers.

Background

The slashing rules for Ethereum have been relatively lenient, with the introduction of the Beacon chain in 2020 and some modifications made with Altair in 2021. However, it has always been a known fact that developers would need to revise the validation process in order to encourage honest validators to participate in the network.

Currently, fork_choice weight is given to active validators who have been slashed, except those included in equivocating_indices. Additionally, on_attester_slashing must be called while syncing, and the client must maintain the equivocation set of AttesterSlashings from at least the latest finalized checkpoint. However, in some cases, a validator may have been slashed prior to the latest finalized checkpoint, but not yet exited due to the exit queue being full. In such cases, some validators may count towards fork_choice weight while others may not. To address this issue, Hsiao Wei, an Ethereum researcher, proposed a PR to "Remove fork-choice weight of slashed validators". This proposal would change active_indices to unslashed_and_active_indices, thus removing fork-choice weight from slashed validators.

During the review of this pull request, Mikhail Kalinin discovered an issue with the get_beacon_block_proposer function. This function can return the index of a slashed validator, even though a block from a slashed validator would be rejected. Although the probability of this contradiction taking effect is relatively low, implementing this change would benefit the overall health of the network. This is because if more than 50% of validators are slashed for malicious behavior, they would still be able to propose blocks while being forcefully ejected from the network. To address this issue, Mikhail Kalinin has created a PR.

Proposed Mitigation

The proposed changes aim to prevent slashed validators from becoming proposers. To achieve this, modifications are made to two functions in the existing code:

  1. compute_proposer_index: This function is responsible for selecting a random index from the list of active validators, using their effective balance as a factor. The proposed change will add a condition to check if a validator has been slashed. If a validator is slashed, they will be excluded from being selected as a proposer.
  2. get_beacon_proposer_index: This function returns the beacon proposer index for the current slot. The change proposed is to read the proposer_index from the state.latest_block_header.proposer_index. This modification ensures that the output remains unaffected if the proposing validator gets slashed.

Generating test vectors for the proposed changes is a challenging task. This is because the blocks recommended by slashed validators are already invalidated by the assert not proposer.slashed line in the existing code, regardless of the proposed modification. Moreover, it is essential to create tests for each affected function, namely slash_validator, process_attestation, process_randao, and process_sync_aggregate.

Associated Trade-Offs

One side effect of the proposed fix is that the get_beacon_proposer_index function can no longer be used in the process_block function due to the potential slashing of a validator that proposed a block. A suggested solution is to instead read the proposer_index from state.latest_block_header.proposer_index.

While this modification creates dependencies in block header routines on the process_block_header call, it prevents missed slots when a slashed validator is supposed to propose a block in the next few epochs. Although the likelihood of this happening is small, the fix is still considered significant.

Why implement this change?

The suggested modifications aim to improve network stability by avoiding situations where slashed validators get chosen as proposers, which could result in rejected blocks and missed slots. By preventing such validators from becoming proposers, the network will experience fewer disruptions, thereby maintaining its integrity. Although the probability of such a conflict is low, implementing this change would benefit the overall health of the network. The proposed changes are likely to be scheduled for the Deneb hard fork after thorough testing to ensure that the modifications work as intended and do not introduce new vulnerabilities.

Related Videos

______________________________________________________________________

Disclaimer: The information contained on this web page is for education purposes only. Readers are suggested to conduct their own research, review, analyze and verify the content before relying on them.

To publish press releases, project updates and guest posts with us, please email at contact@etherworld.co.

Subscribe to EtherWorld YouTube channel for ELI5 content.

Support us at Gitcoin

You've something to share with the blockchain community, join us on Discord!

Follow us at Twitter, Facebook, LinkedIn, and Instagram.