Merge 60fef4b into 0eea85e

EIPS/eip-6914.md

@@ -0,0 +1,77 @@
+---
+eip: 6914
+title: Reuse Withdrawn Validator Indices
+description: Reuse fully withdrawn and safe to reuse validator indices for new beacon chain deposits.
+author: Lion (@dapplion), Danny Ryan (@djrtwo)
+discussions-to: https://ethereum-magicians.org/t/eip-6914-reuse-withdrawn-validator-indices/15253
+status: Draft
+type: Standards Track
+category: Core
+created: 2023-04-19
+---
+
+## 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](https://github.com/ethereum/consensus-specs/specs/_features/eip6914).
+
+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.
+* `AttesterSlashing`s 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 `AttesterSlashing`s 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 `AttesterSlashing`s 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](../LICENSE.md).
+