A number of slashing events have occurred since Ethereum’s monumental transition from Proof of Work consensus to the launch of Eth2 Phase 0 and the Beacon Chain, many of which have been due to technical errors rather than mal intent. What leads a validator to be slashed and how do I make sure that my validator isn’t one of them? Read on for a light recap of how to protect Ethereum 2.0 validators from slashing penalties.
The Premise of Eth2 Slashing
In Eth2, a balance of rewards and penalties dictates the behavior of validators contributing to Proof of Stake (PoS) consensus and the amount of ETH they will find themselves earning (or losing) after some time participating. Slashing = punishment for behavior that goes against the best interests of the network.
The ultimate goal of slashing is to make sure that all transactions are in fact valid, and there is no disruption to the integrity of the network. Hence, slashing is critical to ensure that the network continues to operate effectively and reach honest, distributed consensus.
Whether a slashing event occurs due to a malicious attack or not, there are a few possible scenarios that lead to such an event:
In each case, conflicting blocks lead to an incorrect rendition of reality being voted on by an active validator on the Beacon Chain, which ultimately results in said validator being forcibly removed from the network along with a number of penalties up until the ejection occurs.
Who Slashing Effects
Not to be mistaken for inactivity penalties, slashing should only occur to those who have maliciously intended to defy the system, but may also occur to validators that have performed technical misconfigurations.
A good example of one such misconfiguration is when multiple validators run identical validator keys. Many of the slashing events that occurred to date were to do errors of this nature, and the team agrees that they should most definitely be avoided, but more on that a little later on.
🚨 PSA 🚨
— Ben Edgington ⟠ benjaminion.eth (@benjaminion_xyz) December 4, 2020
Three separate slashing events have occurred already on the Eth2 beacon chain, including to a staking service.
Each of them was caused by funky set-ups: two or more validators sharing a key.
DO NOT DO THIS!!!
For the love of Mike, please just be boring.
What happens when a validator is slashed
A block proposer guilty of a slashing offense needs to be caught by a whistleblower in order to be penalized. Whistleblowers receive nominal rewards (±0.1 ETH) for identifying and proposing a block that contains a message detailing the validator’s offense.
Thereafter, the slashed validator is assigned an epoch 36 days in the future, at which time they will be ejected from the network (a process that is irreversible). Until then, the validator will incur a number of additional penalties:
1. A penalty at the time of whistleblower message (minimum penalty).
2. A penalty at the beginning of each epoch for missing duties leading up to forced withdrawal from the network.
3. A penalty halfway to the withdrawal date (special penalty) – the severity of this penalty depends on the number of validators who committed a slashable offense during the same epoch*
*This is where one of the important features of non-custodial staking comes into play. As we’ve detailed in other blog posts, this is a mechanism that punishes validators for ‘acting together’ in malicious activity. Whether a group of malicious validators is caught, or if a centralized staking service on accident partakes in a slashing event, the special penalty received grows exponentially with the number of validators involved, up to a validator’s entire stake!!
Best practices for slashing prevention
Losing up to 32 ETH sounds pretty bad, but there are a number of ways that slashing can be avoided:
- Local slashing protection database – a history of past signing events that checks incoming messages and does not sign those considered slashable as a part of the validation process.
- Remote slashing protection – utilization of a remote ‘slasher’ that holds the validator’s attestation history (and in some implementations holds the attestation history of ALL validators) which is cross-referenced for slashable messages and does not allow signing if detected.
- Minimal slashing protection – reducing the footprint of a slashing database significantly by just holding the highest source and target attestations ever signed, preventing a validator from submitting a slashable attestation.
- 1 set of keys = 1 validator – don’t fall to the same fate as those before you! Make double sure to always run your validator keys using one validator at a time.
- Migrating slashing protection history – if migrating your validator to a new client or service, always make sure that you’ve brought its slashing data with you.
Blox Staking slashing protection implementations
At Blox, securing your keys and ETH are our top priorities. Each user’s personal instance of KeyVault remote signer maintains a local database that implements minimal slashing protection and checks if a new request violates protocol rules; if it could get you slashed, KeyVault will not sign it. This implementation was developed by our team but was originally discussed by Michael Sproul from the Lighthouse team, and was eventually merged into the Prysm slasher 🦾.
Additionally, we’ve implemented a mechanism into KeyVault called far slashing protection which protects against signing attestations with an incorrect slot set far in the future.
Finally, we also ensure that all public keys in our system are unique to avoid accidents involving running multiple instances of the same set of keys. Please make sure that when you import a validator to Blox Staking, you have closed out the instance from your previous implementation or service provider!
Safe Staking,
Team Blox
