Abstract

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.

Motivation

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.

Specification

Consensus Layer

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.

Execution Layer

This specification does not require any changes to the Execution Layer.

Rationale

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.

Backwards Compatibility

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

Test cases are work-in-progress within the standard Consensus Layer tests.

Security Considerations

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:

• the reuse of a validator index overwrites the previous validator's pubkey from the beacon state.
• AttesterSlashings include validator indices to reconstruct signature pariticipants.

Details of attack

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.

Mitigation

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.

Alternative

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

Copyright and related rights waived via CC0.