Ethereum 2.0: The First Slash, A Retrospective
--
The very first Ethereum 2.0 validator slashing occurred at Epoch 208 for Slot 6668 of the Beacon Chain. As we can see here in Slot 6669’s proposer slashings, Validator 20075 proposed two conflicting blocks for the same slot in 6668.
This proposer violation resulted in a slashing of 0.24 ETH and an exit (Epoch 213 for Validator 20075). Validator 11313 (one of ours!) received the propagated proposer violation message from the whistleblower and appropriately proposed it in Slot 6669, thereby receiving the entire slashing reward of ~0.06 ETH.
But How?
How did this happen? The likely explanation is that Validator 20075 was running another instance of their validator. As some in the community suspected (and anecdotally confirmed¹), Validator 20075 was running another instance of their validator which involved running the same validator keys in two locations (whether this was part of a redundant failover strategy remains to be seen).
Sleuthing from the community confirmed the existence of both a NUC and a Pi setup by identifying a matching deposit address and the correlating graffiti sgiewnait-nuc and IewnaitSG-Rpi4.
Validator 20075 used sgiewnait-nuc (as seen in Slot 6668 that caused the slashing event), and Validator 19151 used IewnaitSG-Rpi4 (as seen in Slot 4712). The connection here is that both tags are simple anagrams of each other with a trailing -tag of NUC or Rpi4. The final confirmation comes from the fact that both validators shared the same ETH1 deposit address (20075; 19151).
Let’s back up a bit and talk about why the system slashed specifically for a proposal violation, which occurs when a validator proposes and officially signs two different blocks for the same slot.
There are three ways a validator can be slashed² on the Ethereum 2.0 Beacon Chain:
- Proposer Violation (double proposal): When a validator engaging in a block proposal signs two different blocks for the same slot
- Attestation (vote) Violation (FFG double vote): When a validator engaging in an attestation signs two different attestations for the same target in the same epoch
- Surround Vote Violation (FFG surround vote): When a validator signs an attestation that “surrounds or is surrounded by a prior attestation” (more information here)
Slashing as a dedicated security guarantee for the Proof of Stake ecosystem both raises the cost of attack and, perhaps relevant here, helps control for robust validator operation (or as Vitalik has termed it, the “validator’s dilemma” of laziness being a consequential form of validator misbehavior).
This slashing event resolves to setup robustness. A similar event occurred in the Cosmos ecosystem in 2019 when a Cosmos Pool validator proposed two different blocks at the same height. In his Serenity Design Rationale³, Vitalik used this situation in his defense of our particular slashing parameters. For this specific case, he described the potential attack vector of a malicious actor purposefully partitioning the network to target primary and backup (failover) nodes to sign and finalize conflicting blocks. He further argued that not penalizing such behavior would allow for trivial chaos to ensue in forks.
What does this all mean for you?
This dive into the Beacon Chain’s very first slashing event gives us a moment to consider an important aspect of the rationale for PoS slashing and careful validator setup. It has been by no means a trivial accomplishment to see such massive and successful coordination to get to Ethereum 2.0’s Beacon Chain launch. We’ve seen participation across the spectrum of service providers (custodial and non-custodial), pools, and independently set-up validators, all taking part in “lighting the Beacon” for the Ethereum 2.0 Beacon Chain. The carefully defined specification for slashing provides for a robust security guarantee that is uniform across the network.
However, this also highlights an important distinction between the types of guarantees we see in different service providers, pools, and independent set-ups. While it is likely that Validator 20075’s actions were not malicious, the slashing specifications on the Beacon Chain operated as it should, and the event should serve as a warning for other validators. As the community continues to develop and improve the security of Ethereum’s transition to Proof of Stake, we’ll continue to learn lessons that will help guide us down this path.
If you’re staking with us, you’re in safe hands! stakefish does not utilize automatic back-up setups but rather takes a close, hands-on approach to make sure it does not make the same class of double proposal mistakes.
We have been validating for some of the earliest Proof of Stake networks from their inception and are committed to continuing our strong track record for securing the infrastructure (and future) of the Eth2 development roadmap. To date, we have been a committed participant in the growth, development, and security of Ethereum 2.0’s continuing development and have provided dedicated non-custodial and globally distributed validation services with one of the highest unique delegator counts in the industry.
About stakefish
stakefish is the leading validator for Proof of Stake blockchains. With support for 10+ networks, our mission is to secure and contribute to this exciting new ecosystem while enabling our users to stake with confidence. Because our nodes and our team are globally distributed, we are able to maintain 24-hour coverage.
Website | Telegram | Twitter | Instagram | LinkedIn | Reddit
[1]: https://twitter.com/phil_eth/status/1334227606359699456
[2]: These definitions were primarily sourced from the Consensys Codefi Rewards and Penalties article and the Ethos Beacon Chain article. For those more technically inclined who want to do your their “don’t trust, verify”, you can see check out the specifications in the code for proposer slashing and attester slashing.
[3]: https://notes.ethereum.org/@vbuterin/rkhCgQteN?type=view#Slashing
