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

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

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

C is the highest source, E is the highest Target. Enforcing the rules above will prevent E from being signed, saving the validator from slashing. F is a valid attestation.

Surrounded Votes

C is the highest source, E is the highest Target. Enforcing the rules above will prevent D from being signed, saving the validator from slashing. F is a valid

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

Minimal slashing protection was first discussed by Michael Sproul (lighthouse team) and initially included in the Slashing protection Database Interchang

CEO @ bloxstaking.com and blox.io. Developing trustless staking products for eth2.0.