Slashings from accidental double starts

[unixpi]

Problem

Dankrad: Starting a validator client for the same validator twice is of course a user error. However, it's probably the most common user error that leads to slashing. If the two clients are started at the same time, there is no way to catch this error; however, in all other cases, the second client being started can detect that the last attestation made by the validator does not match its local storage, and refuse operation (without an override flag).

Possible solution(s)

Dankrad: add a BN API endpoint to query for the latest attestation by a given validator index VC queries this endpoint on startup, if it does not match local storage, stops with warning

Benjaminion: The idea is not to rely solely on a validator's own journal of its history. The beacon node it is attached to sees what's on the network and will know if there is some other validator out there using the same public key by looking at what gets into blocks.

Paul: Another approach would be to wait n epochs and only start signing messages if no other message has been seen.

Paul's proposal is simpler but forces the validator to be offline for n epochs on reboot. Dankrad likes the idea because it also protects against double starts.

References

Original issue

See the discussion in this issue too.

[paulhauner]

My preference is to introduce the "concurrency prevention" on the keys. For example, if reading validators from EIP-2335 keystores I recommend creating a lock-file next to the keystore (e.g., my-keystore.json gets a my-keystore.json.lock file).

[stefantalpalaru]

my-keystore.json gets a my-keystore.json.lock file

You risk leaving it behind after a crash, with no easy way to declare it invalid and delete it on the next run.

[paulhauner]

You risk leaving it behind after a crash, with no easy way to declare it invalid and delete it on the next run.

You can easily delete it (rm or --ignore-lockfile flag on VC), but you're right it does get left over after a crash. I'm not sure there's a perfect solution here, though.

EDIT: including the PID in the lockfile is another option for a less-strict lockfile. You can ignore the lockfile if the PID doesn't exist. Still not perfect, though.