Now that The Merge is complete, miners are out and validators are in. Instead of needing a powerful mining rig to participate in network governance and earn block rewards, all that’s needed to activate your own validator is 32 ETH to stake and three separate pieces of software: an execution client, a consensus client, and a validator.
But staking alone does not guarantee automatic rewards. There are a variety of nuances to consider when operating a validator, such as the potential to lose part of your staked ETH via penalties. While most of these penalties are minor, some actions may result in a validator being slashed—a process where a validator is forcefully removed from the network resulting in an associated loss of their staked ether.
In this blog, we’ll cover the roles that validators play, how penalties and the risk of slashing incentivize validator behavior, how to prevent yourself from being slashed, and future developments that may expand the scope of slashing.
How validators make money
On PoS Ethereum, a single validator is randomly chosen to be a "block proposer" for each slot. As a result, that validator is issued a block reward for their proposal and receives any associated priority fees in the block.
Ethereum’s protocol design also incentivizes validators to align their interests with other validators. As such, validators will receive a reward when they make attestations (votes) that are consistent with the majority of other validators or when they participate in sync committees. Additional rewards are given for rapid attestations.
Lastly, block proposers will receive a reward if they include evidence of slashable offenses in their block.
The value of the rewards given in each epoch depends on the current base_reward—the base unit that all rewards are calculated from.
A validator can continue to earn rewards as long as it is active. A validator will stay active until:
- It voluntary exits
- Its balance drops below 16 ETH (often due to penalties)
- It gets SLASHED
You can use our Ethereum staking ROI calculator to see the average return that validators are currently receiving.
How validators can lose money
Ethereum validators that make incorrect or missing attestations will receive penalties. These penalties are assigned at the beginning of each epoch.
Examples of incorrect attestations include:
- Voting for the incorrect source block
- Voting for the incorrect target block
- Voting for the incorrect head block (the chaintip)
In each of these scenarios, the penalty is equal to the rewards the attestor would have received had they submitted their attestation correctly.
There are also inactivity penalties that validators must consider. If a validator misses an attestation opportunity, the network treats it in the same manner as an incorrect attestation, as depicted above.
While these penalties are not insignificant, they are far more lenient than the penalties incurred to a validator via slashing. At worst, these penalties will slightly decrease a validator's balance. But validators who commit slashable offenses will receive far steeper penalties and be forced to withdraw from the chain completely.
Unfortunately, some of the most common slashing offenses thus far have been the result of stakers over-engineering their setup to ensure that they do not have downtime (and therefore avoid inactivity penalties). It is always more desirable to incur minor penalties vs risking slashing due to poor validator engineering.
Finally, validators that enable MEV-Boost must be diligent regarding the relays that they connect to for block builder delivery. If the relay you are utilizing fails to deliver a block after you have already signed and sent the blinded beacon block to the relay, there is no ability to fall back on Geth to propose a different block locally. Proposing a different block at this point would be considered double signing, which is a slashable offense.
While proposers are not penalized by the network for failing to propose a block, they will miss out on any priority fees they could have received by proposing. Blocknative's open-source MEV Relay Dreamboat is engineered to ensure reliability in serving blocks above all else.
What is slashing on Ethereum?
Slashing describes the process whereby other network participants forcibly eject an offending validator from the Beacon Chain while continuously draining their balance. In the most extreme cases, a slashed validator may lose their entire stake in the network.
Because validators do not want to lose their investment in resources and infrastructure, slashing ensures that network actors act in a fashion that does not harm the network.
Slashing is a mechanism put in place to enforce good behavior. It is an irreversible punishment that ‘slashes’ a percentage of an offending validator's current stake. It results in a steady loss of ETH over time until the network forcibly evicts the validator and labels them “slashed.”
Its main purpose is to reward validators who keep the network running smoothly while penalizing those who do not maintain their validation responsibilities. Slashing prevents low-effort attacks like creating contradictory forks of validators attesting to past checkpoints.
Besides misbehavior or suspicious acts, penalties can occur due to misconfigurations that could obfuscate or undermine the system's integrity.
How does slashing work?
To start the slashing process, other network actors must catch the offending validator. This requires that another validator act as a “whistleblower”— a validator that monitors for slashable events.
The whistleblower must create and disseminate a specific message outlining the infraction, which a proposer then adds to a block. To compensate the block proposer for slashing the bad validator, they are rewarded with the offender’s effective balance divided by 512 (e.g. roughly 0.06 ETH if the offender's balance is 32 ETH). The whistleblower themself does not receive a reward.
The reward is purposefully small since these acts are meant to be a selfless gesture, not a means to profit.
Meanwhile, the offender (the slashed validator) will receive the following slashing penalties:
- Be scheduled to irreversibly exit the network during an epoch 36 days in the future
- Receive a minimal penalty at the point a proposer transmits a block containing the whistleblowing message
- Receive a penalty at the start of each epoch assigned for missing duties during the lead-up to their scheduled network withdrawal
- Receive a special correlation penalty halfway between the point at which a block includes a whistleblower message and the point at which the violator can withdraw. This penalty reflects the number of other validators slashed over the same period. The maximum applicable amount can be as high as the total effective balance of the offender. This penalty is in place to severely punish validators who act together in malicious activity.
Note, point number four in the section above is extremely important to understand when participating as part of a staking pool. Generally, users consider staking with a pool to be a “safer” option because it is assumed that the organization providing staking services is knowledgeable regarding the technical process and will avoid incurring slashing penalties.
However, in the situation where a pool operator fails in their duties and incurs slashing penalties, they are at an elevated risk of triggering maximum penalties because it is likely that they will have multiple validators being slashed at once. In such a situation, the ETH depositor will be at the whims of the pool operator to reimburse them, because there’s a potential for the maximum penalty to be as high as the offender’s entire balance. This exact scenario played out in February of 2021 when the staking pool Staked triggered a slashing penalty and had to repay users independently.
Slashed validators will not be able to rejoin the validator set since slashing is permanent. If users wish to continue validating after being slashed, they must produce new validator keys and deposit fresh stakes.
Slashing results in a gradual loss of ETH staked and a substantial loss at the midpoint. After 36 days, the offending validator will be able to depart the beacon chain and withdraw any remaining ETH stake.
What are slashable offenses?
A whistleblower will trigger the slashing of a validator when the validator acts against expectations or misleads others in some way that breaks consensus rules or causes harm to the Ethereum network. Technically, there are only three specific actions that can trigger slashing:
- When a proposer signs two different beacon blocks for the same slot.
- When an attester signs an attestation that “surrounds” another one. This would cause a situation where the attester is contradicting what a validator already said was finalized in a previous attestation.
- When an attester signs two different attestations with the same target.
However, malicious behavior alone does not result in slashing. Common technical mistakes can easily result in penalties as well. Below are a few examples:
When a user runs identical validating keys into two or more servers simultaneously
If the user tries to run the same validating keys on two servers to serve as a backup or a failover, they may risk committing slashable offenses. If a user’s failover system detects a false positive that the other node is offline, subsequent accidental double-signing can result in slashing.
Ugh. A genesis validator was slashed. Slashing is EXTREMELY rare and has only occurred when people run the same validator keys in two instances. It looks like this operator missed a proposal a few weeks ago and tried to harden by adding redundancy (?)https://t.co/nTdReINf8H pic.twitter.com/ZtRUbpX6Cl
— superphiz.eth 🦇🔊🐼 (@superphiz) July 20, 2022
When a user migrates their validator from one machine or client to another without also moving their slashing protection history
The validator slashing protection history is a database that contains a local signing history. Using it ensures that the validator will not sign a message considered slashable according to its known history. If a user fails to migrate this database, they are at risk of performing duplicative actions.
Using a cloud or containerized environment without persistent volumes
If a user utilizes cloud environments like Kubernetes without configuring persistent volumes, their slashing protection history may get erased, resulting in an offense.
Having implementation bugs
This is rare but comes as a result of bad setup and configuration. Implementation bugs have caused mass slashing events on testnets. These include problems with time server failures and incorrect processing of block IDs.
How to prevent slashing
Understandably, no one wants a penalty, so preventing slashing is the right and easy thing to do. Plus, slashing only applies to suspicious activity that violates protocol. It does not include inactivity.
Here are the best practices for preventing slashing:
Local slashing protection database
A local signing history database helps ensure that a validator does not sign messages that would trigger a slashing penalty based on its history.
The validator relies on this database to ensure that it doesn't carry out duplicate tasks.
However, only the signing events of the validators in that local instance are tracked. If the user changes the client or hardware configuration of their validator, they must also migrate the signing history database to guarantee that the history of previous activities is retained.
Avoid over-engineering validator setups and accept downtime
Slashing occurrences can result from over-engineering validator setups. Some users will set up backup validators running in parallel to their main validator to prevent appearing inactive should their main validator run into technical issues. In theory, this helps validators retain profitability, but it’s not worth it because you are constantly at risk of submitting two conflicting votes.
Because it is hard for PoS consensus to distinguish between a deliberate network attack and a user merely seeking to maximize their profits as a validator, the best way to avoid slashing is to tolerate downtime.
Downtime encompasses any period during which validator operations are not actively running or connected to the internet and hence not generating rewards.
The possibility of social slashing
Recently, there have been discussions regarding utilizing PoS slashing penalties to prevent “censorship” by validators that consider censoring specific types of transactions:
The threat of social slashing will keep centralized staking providers from censoring transactions.
— RYAN SΞAN ADAMS - rsa.eth 🦇🔊 (@RyanSAdams) August 23, 2022
Imagine telling your depositors all their ETH is gone on the real Ethereum.
Imagine the lawsuits.
There's a fiduciary responsibility to stop staking if OFAC tells them to censor.
I believe that a credible threat of "social slashing" is enough to act as a deterrent under most circumstances.
— sassal.eth 🦇🔊 (@sassal0x) August 22, 2022
Though when push comes to shove and social slashing is truly the only option left, we better be ready as hell to use it.
While it appears that there is clear support from many members of the Ethereum community to proceed with the process of social slashing should the need arise, it’s important to know that social slashing is not a process that is built into the protocol following the migration to Proof-of-Stake.
As we covered earlier in this blog, Ethereum restricts slashing offenses to three very specific actions. Any movement to implement protocol-level standards for additional slashing offenses would need to take place via further upgrades to Ethereum.
Nonetheless, this does not mean that social slashing is not possible. Instead, it would have to be coordinated via a user-activated soft fork (UASF) as outlined in this blog post from Vitalik: “For other, harder-to-detect attacks (notably, a 51% coalition censoring everyone else), the community can coordinate on a minority user-activated soft fork (UASF) in which the attacker's funds are once again largely destroyed (in Ethereum, this is done via the "inactivity leak mechanism"). No explicit "hard fork to delete coins" is required; with the exception of the requirement to coordinate on the UASF to select a minority block, everything else is automated and simply following the execution of the protocol rules.”
If you would like to learn more, this blog by Eric Wall outlines arguments for and against social slashing.
Blocknative's tools for Ethereum
Blocknative and our suite of pre-chain web3 developer tools are here to help you thrive in the world of Proof-of-Stake. Our Mempool Explorer and Mempool API offer unmatched visibility into Ethereum’s Dark Forest with individual wallet, protocol, and liquidity pool monitoring features.
If you're a validator looking to get the most out of your staking, you should also consider utilizing our MEV-Boost relay. Blocknative's Dreamboat MEV-relay is open source, reliable, and helps increase block builder diversity in PoS Ethereum. If you still need to get started as a solo staker, we recommend our Lighthouse/Geth setup guide.
We also offer Web3’s most accurate gas fee estimation to help ensure that your transactions are in the next block no matter what. If you’re interested in learning more about how we can help you trade or build on Ethereum, contact us today to request a demo.
Further reading:
Observe Ethereum
Blocknative's proven & powerful enterprise-grade infrastructure makes it easy for builders and traders to work with mempool data.
Visit ethernow.xyz
.png)
