Eth2 Slashing Protection

Eth2 Minimal Slashing Protection
Share this post
Eth2 Minimal Slashing Protection

Problem Statement

The basic Eth2 phase 0 slashing conditions premise dictates that a validator cannot forget past signed messages without a penalty. It’s a simple rule,

don’t sign the same message twice but with different parameters (double voting) and don’t try to change history by signing a message and “deleting” a previous one (surrounded and surrounding votes).

What is needed for Eth2 slashing protection

For an eth2 validator to perform effective slashing protection it needs 2 things:

1) the spec slashing conditions

2) the historical database 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 number of signed messages can grow rapidly to tens of thousands and even more. A naive implementation would quickly face performance and backup issues, the latter more severe while recovering from seed.

The basic premise 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 or 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

Relying solely on a slasher for slashing protection is dangerous!

An important remark:

Always have a local slashing data db for your validator, if you spin a new validator, make sure the old one is down and copy its slashing data to the new validator.

Relying solely on a slasher for slashing protection is DANGEROUS!

From the above, it’s clear that minimal slashing protection can be achieved by simply having a local copy of the highest source and target signed by a validator. The downside 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 Interchange.


Alon Muroch

Blox Staking CEO