How to Stop Your Ethereum 2.0 Validator From Getting Slashed

With the launch of Ethereum (ETH) 2.0 “Phase 0” on December 1, users were introduced to a bunch of new features and nuances that the proof-of-stake (PoS) consensus mechanism has brought with it. One of them is “slashing”—a network protection mechanism that punishes validators if they don’t fulfill their task correctly.

Raul Jordan, Ethereum protocol developer at Prysmatic Labs, published a comprehensive blog post on November 30, explaining how to avoid getting slashed.

What is slashing?

On the simplest level, slashing is a form of law enforcement on Ethereum 2.0.

This mechanism is designed to detect and suppress any validators’ activity that can be harmful to the network. This includes, for example, proposing or attesting to two different conflicting blocks in the same slot or casting a vote which “surrounds” or is “surrounded” by a previous one.

When an active validator gets slashed, the system begins to gradually destroy portions of its ETH stake (essentially burning money) over the course of 36 days, after which the guilty actor is booted from Ethereum 2.0’s Beacon Chain. Notably, slashing is irreversible, meaning that users will have to generate new validator keys and deposit new stakes if they want to continue validating after being slashed.

However, some common user mistakes can also result in slashing—even if there was no ill intent.

How to avoid being slashed?

According to Jordan, one of the biggest mistakes that can lead to slashing is when a user inputs the same validating keys into two or more servers (keeping one of them as a backup, for example).

“This is the EASIEST way to get yourself slashed. If your failover system has a false positive your first node is down, you can find yourself in a situation where you commit slashable offenses,” Jordan explained.

To avoid this, users should never run identical validating keys in two or more places at the same time. Especially since most of the slashing protection instruments won’t help in this specific case.

Another common mistake is when a user migrates his validator to a different machine or ETH 2.0 client—but forgets to also relocate the slashing protection history—a database that contains a local signing history.

“This database ensures the validator does not sign a message that would be considered a slashable message according to its own history; more simply, the validator sees the database as its sole source of truth when deciding if a message should be signed,” Jordan noted, adding, “This approach ensures the single validator does not perform duplicative actions.”

He also explained that slashing protection history is currently one of the most effective and easiest ways to safeguard your validators from being slashed. Thus, users should always migrate it as well when switching to new hardware or software—and avoid losing it altogether.

Another way to easily get slashed is by using a containerized or cloud environment that doesn’t have persistent volumes.

“You need to setup persistent volumes for your validators, such that if a pod or container is restart, (sic) the slashing protection history will not be erased,” Jordan added.

Finally, the worst—although “very unlikely”—scenario involves bugs in implementations. To avoid them, it is critical that users understand how to set up, configure, upgrade, and troubleshoot any installed software.

Ultimately, slashing protection history is the first and foremost line of defense that should protect honest validators in most scenarios. But it’s best to double-check.