Minimal Slashing protection
Thank you Shay from the Prysm team for reviewing the code changes and enabling this to become a production feature.
Problem statement
The basic eth2 phase 0 slashing conditions premise dictates that a validator can’t forget past signed messages without a penalty. It’s a simple rule, don’t sign the same message but with different parameters (double voting) or try to change history by signing a message “deleting” a previous one (surrounded and surrounding votes).
There are 3 types of slashing events:
For an eth2 validator to perform an effective slashing protection it needs 2 things: 1) the spec slashing conditions and 2) historical db of all signed attestations + proposals.
Under a naive approach this is fairly easy to implement, simply code the slashing conditions into the validator client and write to a local database every time the validator signs any message.
A validator has a duty every 6.4 minutes, the amount of signed messages can grow rapidly to tens of thousands and even more. A naive implementation will quickly face performance and backup issues, the latter more severe while recovering from seed.
The basic promise of a seed managed wallet is that all a user needs to recover fully is the seed. Under eth2 slashing conditions that same user will now need all the historical slashing data as well to stay safe. That’s just not feasible nor convenient.
A re-think of the slashing condition database is needed.
Minimal Slashing protection
A solution can be found in adopting more stringent slashing rules that enable reducing the footprint of a slashing database significantly. Instead of holding the entire past attestation history, we can minimize it to just holding the highest source and highest target attestations ever signed, then force inner validator rules that reference only those 2 pieces of data to validate and ultimately sign an attestation.
The rules are:
- New attestation source epoch must be equal or higher than known highest source.
- New attestation target epoch must be higher than known highest target
Surrounding and Double Votes
Surrounded Votes
An important remark: Always have a local slashing data db for you validator, if you spin a new validator make sure the old one is down and copy its slashing data to the new validator.
Relaying only on a slasher for slashing protection is DANGEROUS!
From the above it’s clear that a minimal slashing protection can be achieved by simply having a local copy of the highest source and target signed by a validator. The down side is the more stringent rules that could lead to skipped attestations in some cases.
This mechanism has been merged into the Prysm slasher and now into the Blox’s remote eth2 signer called KeyVault.
The example below shows how to fetch the data from Prysm’s slasher