Slashing Protection Hardening #6948
Labels
Discussion
Simply a thread for talking about stuff
Priority: Medium
Medium priority item
Security
Security Related Issues
Tracking
Gotta Catch 'Em All
Milestone
馃拵 Issue
Currently slashing protection for a validator falls into two categories both of which are:
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:
Add a lock file for our wallets so that multiple validators cannot use it at the same time.
Ensure that each key read from a directory is unique. If there are any duplicates we should exit the validator process.
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.
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.
The text was updated successfully, but these errors were encountered: