Skip to content

Commit 454b33a

Browse files
committed
add eip
1 parent 2bde10b commit 454b33a

File tree

1 file changed

+78
-0
lines changed

1 file changed

+78
-0
lines changed

EIPS/eip-9999.md

Lines changed: 78 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,78 @@
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

Comments
 (0)