Slashing Protection Hardening

[nisdas]

💎 Issue

Currently slashing protection for a validator falls into two categories both of which are:

• Local Slashing Protection
• Slasher Based Protection

However for a non-technical user it still difficult to configure both of these solutions correctly. This issue will explore certain mitigation we can add to protect a user better.

Background

In medalla we had a user have all 5 of his validators slashed.
https://discordapp.com/channels/476244492043812875/476588476393848832/742069647523840051

The main reason was that he was running 10 validator instances with the same keys and instead of using the same db instance, the user instead used 10 different validator db instances. A mistake like this is easy enough for a non technical user to make
as unless they were acquainted with how volumes work in docker and how containers need to be explicitly stopped. They would assume that everytime running a new validator would stop all the previous instances.

An immediate action item would be to specify the correct docker volume for a validator in our documentation.

Description

Potential hardening solutions:

1. Add a lock file for our wallets so that multiple validators cannot use it at the same time.

2. Ensure that each key read from a directory is unique. If there are any duplicates we should exit the validator process.

3. Beacon node handles multiple repeated keys on their end too. If multiple validator clients are connected, we ensure that each validator client has distinct validator keys. If any of the keys are common we reject the particular validator client from requesting any data and straight away disconnect from it.

4. This would be a more complex solution, but upon proposing a new attestation, a beacon node checks that it hasn't seen that attestation in a previous block or being propagated in the network. How feasible something like this is would have to be thought carefully as this can have a big negative impact on attestation latency and therefore the validator's resultant inclusion slot.

[shayzluf]

working on adding a lock on wallet

• Add a lock file for our wallets so that multiple validators cannot use it at the same time.

[shayzluf]

working on design for:

• Beacon node handles multiple repeated keys on their end too. If multiple validator clients are connected, we ensure that each validator client has distinct validator keys. If any of the keys are common we reject the particular validator client from requesting any data and straight away disconnect from it.

[stefa2k]

working on design for:

• Beacon node handles multiple repeated keys on their end too. If multiple validator clients are connected, we ensure that each validator client has distinct validator keys. If any of the keys are common we reject the particular validator client from requesting any data and straight away disconnect from it.

I fear this will break my setup in many ways (which worked good and safely!), here are just some:

• The validators are coupled loose to the beacon (by using haproxy and having failovers configured in there). Therefore there is no "connect" request. To talk to a failover the connect-request would be resent.
• Validators can connect to one beacon node (and do so regularly) with the same set of keys. They do this in a safe manner by using external slashing protection.
• Validators can failover via haproxy to another slasher if the primary slasher goes down.

I'm not sure how these new restriction benefit anyone.

[rauljordan]

@nisdas what would be required for successful closure of this issue? We have a few other related ones such as #7076, #7159, and #7161. Would closing those 3 be sufficient for closing this one?

[rauljordan]

Discussed with @shayzluf that only (2) is a reasonable suggestion we can use today. Moreover, it is already solved as our imported keymanager disallows duplicate keystores