Enable Doppleganger Detection to reduce the likelihood of slashing

[superphiz]

Description

Stakers with the best intentions are inclined to create redundant staking solutions to reduce the risk of downtime. These redundant solutions may involve copies of validator keys on multiple machines that can lead to accidental slashing.

Version

N/A

Present Behaviour

slashing protection is enabled on client running on a single machine but not to detect attestations from keys being loaded and prepared for validating.

Expected Behaviour

The default behavior of the validator upon start should be to look/listen for attestations from the loaded key indexes for a reasonable period before submitting new attestations. The validator should pause and warn the user if attestations are found that could cause a slashable event.

Steps to resolve

Include doppelganger detection in the default behavior of the validator client.

[djrtwo]

Also suggest that it could be override with a flag --override-doppleganger-detection-UNSAFE

Cool thing is it might promote education. You might wonder why you take a couple of epochs to start making attestations and look it up. You then learn about the flag and about slashing risks

[michaelsproul]

I like the name ;)

I agree this is something we should implement

[paulhauner]

Sounds good to me. I believe @dankrad also proposed a similar (identical?) scheme prior to mainnet but we never found the time to implement.

Some misc points to note:

• By default, BNs don't listen to all the attestation subnets so they're going to be restricted to attestations that are either on-chain or published as aggregates on the beacon subnet. I don't think this is a major issue.
• Lighthouse has the ability to arbitrarily stop/start validators whilst the process is running (via the API). We would need to consider this and perhaps trigger the delay on a per-validator-started basis, rather than per-entire-validator-client-started.
• I'm not certain on the best way to get information about attestations through to the VC.
  • The eventstream API was my first thought, but it provides Attestation not IndexedAttestation. Determining actual validator indices from an Attestation::aggregation_bits in the VC is not feasible, IMO. We could potentially change the API to return an IndexedAttestation, but that's a bit of a reach.
  • We could add a special BN endpoint to say "have you seen this validator at all in the past 2 epochs?". We're well suited to do this already (notably, we can indicate if the validator attested, but not what the validator attested to). There's some edge-cases here with a newly-started BN though.

[djrtwo]

beacon/state/validators/{index}/online
beacon/state/validators/{index}/online?epoch_lookback=3

Something like the above, where "online" is defined as having a message included on chain in the past 2 epochs (attestation, maybe block). Not sure if epoch_lookback is good or not. Arbitrary lookback on this can be expensive.

[m0n5t3r]

Not sure how hard it would be, but the ideal solution would be some sort of communication channel between validators with the same key, so they can either

• fire in a round-robin fashion (the node that goes down will still miss its attestations, but you only lose 1/n instead of n attestations), or
• vote / elect the one that should be active (this would require an odd number of validators for HA, and would still miss attestations when the active node goes down, while a new one gets elected, but this should be fast enough to incur minimal penalties)

Presumably the mode can be selected based on the number of nodes, and the latter can be specified on startup via a parameter.

[dankrad]

communication channel between validators with the same key

There is no guaranteed channel to reach all validators with one key, and I would think trying to construct one would increase the validator privacy problems by multitudes. Not to mention that it would be quite complex.

The solution suggested here can be implemented in a few extra lines of code and already gives a pretty good protection.

[paulhauner]

Resolved via #2230 🎉