Reuse fully withdrawn validator indices after a sufficient safe-to-reuse period has passed to eliminate the unbounded growth of the beacon chain validator list as the validator set churns.
The beacon chain maintains a list of validators and a separate list of balances associated with each validator. When a new deposit for a new validator occurs, the current mechanism only appends, rather than reusing previously fully withdrawn validator indices. As validators fully withdraw and new validators enter, this means the two lists will grow unbounded.
This specification allows for the reuse of validator indices in the event that it is safe to do so, eliminating the concerns around the unbounded validator list growth.
The configuration values and mechanics of the specification can be found in the Consensus Layer specs.
Note that validator indices are reused in the event that the validator has been fully withdrawn and that the validator has been withdrawable for a sufficient safe period.
This specification does not require any changes to the Execution Layer.
The validators and balances lists are currently appended to each time a new Deposit for a new pubkey comes into the beacon chain. Due to the natural mechanics of stakers entering and leaving consensus over long time spans, these lists, thus the state size, will grow unbounded.
Increased state size represents load and/or complexity in client implementations. This comes in the form of client memory footprint, state root calculations, validator set scans, and more. This is a relatively simple clean-up within the state transition that will prevent the unnecessary load and complexity of the otherwise unbounded lists.
This is a backwards incompatible change to the Consensus Layer of Ethereum and must be scheduled with a hard fork.
There are no forwards/backwards compatibility issues with the Execution Layer
Test cases are work-in-progress within the standard Consensus Layer tests.
Validator indices cannot be immediately reused but instead must wait SAFE_EPOCHS_TO_REUSE_INDEX epochs to ensure that attestations cannot be "poisoned" with withdrawn validator signatures -- thus non-slashable -- for at least the weak subjectivity period.
The attestation poisoning attack hinges upon two facts:
AttesterSlashings includes validator indices to reconstruct signature participants.Assume a 1/3 attacker. Attacker exits N validators on the honest chain, where N is a small fraction of the validator set. These validators leave the exit queue and are withdrawable within a few days. Now, N new deposits come in and overwrite the validators and most importantly their pubkeys.
The attacker then constructs an alternative attacker chain from before any of the N voluntary exits, such that the original N validators are not exited and withdrawn. N is large enough such that at least one of the N keys is on average in every committee of the attacker chain. The attacker double-signs in an attempt to finalize the attacker chain but ensures that one of the N keys is mixed into any revealed double-signed aggregate attestation -- the individual attestations are unavailable, only aggregates. These malicious attestations are not includable in the honest chain because AttesterSlashings rely upon mapping validator indices to particular pubkeys, thus breaking accountable safety.
Not overwriting withdrawn validators for SAFE_EPOCHS_TO_REUSE_INDEX epochs (3x the max weak subjectivity period) ensures that attestations cannot be poisoned within the accountable safety security window.
Note that if AttesterSlashings included a list of pubkeys instead of validator indices, then this would not be an issue. However, this would require more breaking changes and would increase the data requirement of an AttesterSlashing, the largest Consensus Layer data type, by a factor of 6.
Copyright and related rights waived via CC0.