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.
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.
fork_choice weight is given to active validators who have been slashed, except those included in
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
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.
The proposed changes aim to prevent slashed validators from becoming proposers. To achieve this, modifications are made to two functions in the existing code:
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.
get_beacon_proposer_index: This function returns the beacon proposer index for the current slot. The change proposed is to read 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
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
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.
- EIP-4844 ready for Multi-Client Devnets
- Verkle Trees Research Progress
- Exploring EVMMAX Proposals & BLS12-381
- Why Ethereum Clients prefer SSZ over RLP?
- Partial SSZ Migration in the Cancun Upgrade
- Mega EOF Endgame Specification
- '0-Blob Txns' Omitted from EIP-4844 in Cancun Upgrade
- 4844 Specs includes KZG multi verify function
- Upcoming Changes to Ethereum Blockchain
- Transient Storage for Beginners: EIP-1153 Explained
- How Layer 3 in Future will look like?
- An Overview of Beacon Chain API
- The Future of Ethereum Goerli Testnet
- ETH Withdrawals: Everything You Need to Know
- Client Diversity
- Reth: Ethereum Execution Layer Client Written in Rust
- Sign-In with Ethereum: EIP-4361
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 email@example.com.
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!