-
Notifications
You must be signed in to change notification settings - Fork 233
Accidental slashing protection techniques
One of the most dangerous user errors for validators in Eth2 is accidentally reusing the same keystore on multiple machines connected to the network. This may result in conflicting attestations or block proposals being sent which may result in slashing the user. This document discusses techniques for trading this catastrophic risk for more benign failure modes that may still incur a small loss for the user.
While the keystore is in use, add a lock file in the same directory. If a naive user accidentally copies the validator directory from a running node, she will also copy the lock files which will trigger an error when they are loaded or imported on a different machine.
Downsides:
- Software crashes may leave the lock files in place preventing a successful restart of the node
Instead of starting to attest immediately, listen passively for activity on the network from any of the locally attached validators for N
epochs (where N
is user configurable). If no activity is detected, proceed to normal operation.
Downsides:
-
If the user switches to another client not implementing the same strategy, slashing can still occur after the mechanism has been disabled. An alternative would be to rely on the slashing protection database to implement ongoing monitoring for any validator messages that haven't been written to the local database.
-
It's less clear how this would work with a more trivial validator client that is not monitoring the gossip traffic on the network.
Upon detecting a duplicate validator on the network, the client has two possible strategies for handling the problem:
Pros: The user is more likely to notice the problem.
Cons: Upon quitting, a supervisor is likely to restart the process. A naive implementation will go though an amnesia on each restart which requires a detection process with high reliability.
Pros: The users may earn more money if they have other validators on the same node that are not duplicated.
Cons: Notifying the user for the problem requires a custom alerting mechanism to be implemented. One idea would be to execute a system script that can take an arbitrary action.