Skip to content

Accidental slashing protection techniques

zah edited this page Jan 18, 2021 · 2 revisions

Background:

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.

Guard each keystore with a lock file

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

Wait N epochs before activating the local validators

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.

Slashing counter-measures

Upon detecting a duplicate validator on the network, the client has two possible strategies for handling the problem:

1. Terminate the client

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.

2. Disabling the affected validator locally

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.