|
| 1 | +--- |
| 2 | +eip: 9999 |
| 3 | +title: Exclude slashed validators from proposing |
| 4 | +description: Modify proposer selection to exclude slashed validators, improving network resilience and performance after mass slashings |
| 5 | +author: Francesco D'Amato (@fradamt) |
| 6 | +discussions-to: TBD |
| 7 | +status: Draft |
| 8 | +type: Standards Track |
| 9 | +category: Core |
| 10 | +created: 2025-10-16 |
| 11 | +requires: 7917 |
| 12 | +--- |
| 13 | + |
| 14 | +## Abstract |
| 15 | + |
| 16 | +This EIP proposes a modification to the beacon chain proposer selection process to exclude slashed validators from being selected as proposers. |
| 17 | + |
| 18 | +## Motivation |
| 19 | + |
| 20 | +Currently, slashed validators can still be selected as proposers, though their blocks are considered invalid by the state transition function, resulting in missed slots. This is in particular problematic after a mass slashing event, at which point there can be a long period with degraded chain performance, until all slashed validators are exited. If mass slashing also comes with general network disruption, the missed slots can also significantly complicate the recovery process. This change filters out slashed validators during proposer selection, reducing disruption and increasing resilience in such scenarios. |
| 21 | + |
| 22 | +## Specification |
| 23 | + |
| 24 | +The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC 2119](https://www.rfc-editor.org/rfc/rfc2119) and [RFC 8174](https://www.rfc-editor.org/rfc/rfc8174). |
| 25 | + |
| 26 | +The `get_beacon_proposer_indices` function in the consensus specifications is modified to exclude slashed validators from the proposer selection process, effectively going from considering all |
| 27 | +active validators to all active and unslashed validators. |
| 28 | + |
| 29 | +```python |
| 30 | +def get_beacon_proposer_indices( |
| 31 | + state: BeaconState, epoch: Epoch |
| 32 | +) -> Vector[ValidatorIndex, SLOTS_PER_EPOCH]: |
| 33 | + """ |
| 34 | + Return the proposer indices for the given ``epoch``. |
| 35 | + """ |
| 36 | + # Modified to exclude slashed validators |
| 37 | + indices = [i for i in get_active_validator_indices(state, epoch) if not state.validators[i].slashed] |
| 38 | + seed = get_seed(state, epoch, DOMAIN_BEACON_PROPOSER) |
| 39 | + return compute_proposer_indices(state, epoch, seed, indices) |
| 40 | +``` |
| 41 | + |
| 42 | +## Rationale |
| 43 | + |
| 44 | +### Why exclude slashed validators? |
| 45 | + |
| 46 | +Slashed validators are already prevented from successfully proposing blocks through the state transition validation. The `process_block` function checks that the proposer is not slashed, and blocks from slashed proposers are considered invalid. Therefore, selecting slashed validators as proposers serves no purpose and only results in missed slots. |
| 47 | + |
| 48 | +### Design decision: upfront filtering |
| 49 | + |
| 50 | +The chosen approach is to simply filter out slashed validators from the candidate pool. An alternative design would be to still use the whole active validator set as the candidate pool, and then only filter out slashed validators once their index has been selected by the shuffle. The behavior is identical, and the complexity low in either design. |
| 51 | + |
| 52 | +## Backwards Compatibility |
| 53 | + |
| 54 | +This EIP introduces a backwards-incompatible change to the consensus rules and MUST be activated as part of a scheduled network upgrade. |
| 55 | + |
| 56 | +## Test Cases |
| 57 | + |
| 58 | +Test cases should verify that: |
| 59 | + |
| 60 | +1. Slashed validators are not selected as proposers |
| 61 | +2. A complete `proposer_lookahead` is generated even in the presence of slashed validators |
| 62 | +3. Slashinigs do not affect the existing `proposer_lookahead` |
| 63 | + |
| 64 | +## Security considerations |
| 65 | + |
| 66 | +Slashed validators are already prevented from successfully proposing blocks through the state transition validation, for good reason, as they are considered to be unreliable participants (malicious or faulty). However, they have historically still been eligible to be selected as proposers in order to ensure stability of the proposer selection mechanism, because excluding them would have severely impacted the stability of the proposer selection mechanism. In fact, any slashing processed on chain would have caused the sequence of future proposers to completely change, even within the lookahead window. However, with [EIP-7970](./eip-7970.md), the proposer selection is fixed in advance by storing in the Beacon state, so it would not be affected by slashings processed after the fact. |
| 67 | + |
| 68 | +### Impact on proposer selection distribution |
| 69 | + |
| 70 | +This change does not affect the randomness or fairness of proposer selection among non-slashed validators. The selection algorithm remains the same, with the only difference being that slashed validators are excluded from the candidate pool. |
| 71 | + |
| 72 | +### Mass slashing scenarios |
| 73 | + |
| 74 | +During mass slashing events, this change is purely beneficial to the resilience of the network, as well as to general quality of service. Instead of having many slashed validators selected as proposers (resulting in many missed slots), the network will continue to operate normally with only non-slashed validators being selected. |
| 75 | + |
| 76 | +## Copyright |
| 77 | + |
| 78 | +Copyright and related rights waived via [CC0](../LICENSE.md). |
0 commit comments