Check duplicate attestations at Validator launch to avoid unnecessary slashing

# Check duplicate attestations at Validator launch to avoid unnecessary slashing **Author(s):** Ash Haddad, Prysmatic Labs *Last Updated: Apr 21, 2021* [TOC] ## Background In case of using the same keystore for multiple validators slashing will occur unintentionally (non-malicious attempts). This is most likely happening when users are coping keystore files during migration between machine or Eth2 client implementations. The aim of this feature is to prevent this accidental event from happening by implementing a check at the launch of the validator. A number of epochs will be monitored for duplication against the pubKeys before starting to attest; this way the user is saved running a doppelganger and getting slashed in the process. ## Solution The validator should check **N=2** number of epochs before it starts attesting. The validator will check that the beacon-chain attestation for its keys matches that of the validator.db; otherwise this fatal message is thrown to the user and the validator exits. > Validator key 0x****** seems to be running elsewhere. This process will exit, avoiding a proposer or attester slashing event. Please ensure you are not running your validator in two places simultaneously. N epochs is equal to the maximum number of slots during which an attestation can be propagated ATTESTATION_PROPAGATION_SLOT_RANGE (32) divided by the SLOTS_PER_EPOCH(32)= 1 epoch ( [Nimus](https://github.com/status-im/nimbus-eth2/pull/2244) ). We then add to 1 epoch for more certainity. :::info Statistically, it is important to note that 2 or even 4 missed attestations, at the launch of the validator is very minuscule compared to a potential slashing: * 4 Missed attestation ~ 4 * 3 * BaseReward which is a mere 4*10^4 Wei * Slashing Penalty = effective.balance//MIN_SLASHING_PENALTY_QUOTIENT = 0.25 ETH for new-stacker(32 Eth) first time offenders. Refer to [Rewards&Penalties](https://benjaminion.xyz/eth2-annotated-spec/phase0/beacon-chain/#rewards-and-penalties). * Assume the probability of slashing by mistakenly duplicating keys across validators processes happens roughly 30 times for every 1000 new installs(reported discussions on discord). The expected outcome (EV) for missed attestation due to the extra guard check vs duplicate-keys slashing happening is as below; demonstrating that the extra check's incurred cost is less than 10 magnitude of power and is worth the implementation. * EV (missed attestation) = 100% * 4 * 10^4 Wei = 4*10^4 Wei * EV (slashing due to duplicate keys) = 0.3% * 0.25 Eth = 0.0075 Eth = 7.5 * 10^15 Wei ::: The following changes to the validator will take place: 1. Validator starts up and loads the relevant keys. The current flow of waiting for the beacon synch is still respected , however before the runner starts looping we do our check. 2. Loops through for N epocks from the current slot plus N-epochs-worth of slots. 3. At every slot, Validator performs rpc call to the beacon node to retrieve its signed blocks. There are two types of Block data we check: one for the proposals and another for the attestations. 4. For Proposals, the ID of the proposer is compared against the validator's keys. For the Attestations,the committee ids are checked against the validator's keys. 5. If any match is found log a fatal error(see above) and exit validator. ## Benchmarking The above new feature should be tested with 1, 200 and 2000+ Keys to benchmark the added check on the startup of the validator. ## Work estimates 4 days for 1 SWE ## Other implementations Other client Eth2 implementation are implementing this feature: * [Lighthouse](https://github.com/sigp/lighthouse/pull/2230) * [Nimus](https://github.com/status-im/nimbus-eth2/pull/2244) #### Nimus implementation A gossipSlashingProtection flag is added. It is set to 'warn' the user by default, which will become 'stop' in the future after further testing/experimentation.The N epochs to check is chosen to be ATTESTATION_PROPAGATION_SLOT_RANGE (32) div by the SLOTS_PER_EPOCH(32) and referred to as GUARD_EPOCHS . Nimus even safeguards against the possibility of having two clients starting at the same time. The probability of trigging a slashable condition is 1/n where n is the # of epochs one waits before proposing or attesting. Nimus implements a broadcast starter epoch and a probe epoch. The broadcast is equal to the current beacon chain own slot, plus + 2(set value in the code). Also a probEpoch which check future attestation for duplicates, equal to the current slot + 1 + random(1 or 2) . The validator duplicate deduction becomes if ``` current beacon epoch < broadcastStartEpoch && probeEpoch <= current beacon epoch <= probEpoch + GUARD_EPOCHS ``` The one note to keep in mind is the slight delay in waiting for the current slot of the validator to reach the 'future' prob epoch. However a missed N attestations #### Lighthouse implementation The validator waits for 2 epochs . "By default, Lighthouse will delay startup for two epochs and monitor for attestations on the network by any of the validators managed by this client." Ligthouse implements this by scanning the list of own validator attestation indices with that of the beacon's attestations for 2 epochs. It then gets the validators doppelganger; if found throws an error and exits. Also Lighthouse added a standard endpoint [eth2 API](https://github.com/ethereum/eth2.0-APIs/pull/131) request.