{"id":7736,"date":"2025-01-25T03:43:14","date_gmt":"2025-01-25T02:43:14","guid":{"rendered":"https:\/\/wsj-crypto.com\/?p=7736"},"modified":"2025-01-25T03:43:14","modified_gmt":"2025-01-25T02:43:14","slug":"maximizing-rewards-the-incentives-of-staking-on-ethereum-2-0","status":"publish","type":"post","link":"https:\/\/wsj-crypto.com\/index.php\/2025\/01\/25\/maximizing-rewards-the-incentives-of-staking-on-ethereum-2-0\/","title":{"rendered":"Maximizing Rewards: The Incentives of Staking on Ethereum 2.0"},"content":{"rendered":"\n
\n

Appreciation to Joseph Schweitzer and Danny Ryan for their review.<\/em><\/p>\n

<\/p>\n

Greetings again! After examining eth2’s design philosophy previously<\/a>, our topic today is the incentives of eth2 through the perspective of that philosophy. Specifically, we will investigate the incentives influencing eth2 and how they are expressed in terms of rewards, punishments, and slashing.<\/p>\n

<\/p>\n

Next, we will explore how and why validators are motivated to stay online, why you won’t<\/strong> face slashing for being offline, and much more. Let\u2019s delve deeper.<\/p>\n

<\/p>\n

If not due to being offline, when do slashing events happen? \u2694\ufe0f<\/h2>\n

<\/p>\n

Slashing serves two main objectives: (1) to create a significant financial barrier against attacking eth2, and (2) to deter validators from negligence by ensuring they fulfill their responsibilities. Slashing a validator involves confiscating (part of) their stake if they act in a provably<\/strong> harmful way. The primary malicious behaviors that could lead a validator to be slashed in eth2 phase 0 include double voting and surrounding voting (refer to the original document<\/a> for a detailed explanation of the Casper FFG):<\/p>\n

<\/p>\n

Double voting<\/em><\/strong> occurs when a validator endorses two separate blocks within the same epoch, indicating support for two conflicting realities. A straightforward illustration of why this is not permitted is a validator transmitting transaction a<\/mi><\/mrow>a<\/annotation><\/semantics><\/math><\/span>a<\/span><\/span><\/span><\/span><\/span> in block A<\/mi><\/mrow>A<\/annotation><\/semantics><\/math><\/span>A<\/span><\/span><\/span><\/span><\/span> and b<\/mi><\/mrow>b<\/annotation><\/semantics><\/math><\/span>b<\/span><\/span><\/span><\/span><\/span> in block B<\/mi><\/mrow>B<\/annotation><\/semantics><\/math><\/span>B<\/span><\/span><\/span><\/span><\/span> where a<\/mi><\/mrow>a<\/annotation><\/semantics><\/math><\/span>a<\/span><\/span><\/span><\/span><\/span> and b<\/mi><\/mrow>b<\/annotation><\/semantics><\/math><\/span>b<\/span><\/span><\/span><\/span><\/span> utilize the same ETH. This represents the Proof of Stake variant of the traditional double-spend assault<\/em>.<\/p>\n

<\/p>\n

Slashing due to surround votes<\/em><\/strong> also hinders the finalization of two different chain versions by penalizing validators who cast votes that present multiple contradictory realities simultaneously. More explicitly, attestations (votes for blocks) are classified as surrounding votes when a validator attests to one reality and subsequently attests to another, without clarifying their disbelief in the first.<\/p>\n

<\/p>\n

Double and surround voting are the sole methods by which validators may be slashed in phase 0, yet additional regulations are incorporated in subsequent phases to guarantee that validators properly retain and provide access to the shard data they endorse (to prevent laziness or withholding information).<\/p>\n

<\/p>\n

A validator that adheres correctly to the protocol will never produce a slashable vote during standard operations<\/strong>. Unless a deliberate malicious act is involved, generating a slashable message typically results from an error or mishap. To reduce the repercussions of such mistakes, the amount of stake forfeited correlates with the number of other validators slashed at the same time. If a limited number of validators engage in a slashable infraction, it’s improbable they are attempting to attack eth2 since a successful attack necessitates numerous validators. Therefore, slashing events involving only a few are presumed to be honest errors and receive a minor penalty (at least 1 ETH). Conversely, if many validators commit an infraction simultaneously, a significant portion of their stake can be forfeited (up to their entire balance) since it is assumed to be an assault on the network.<\/p>\n

<\/p>\n

Validators subjected to slashing are barred from further participation in the protocol and are forcibly removed. In cases of honest mistakes, this protects offending validators from incurring further penalties by being slashed again; whereas in cases of malign intent, it eliminates harmful validators from the protocol.<\/p>\n

<\/p>\n

So, what transpires with validators who go offline? \ud83d\udeab\ud83d\udc69\u200d\ud83d\udcbb<\/h2>\n

<\/p>\n

Validators that are offline when they are expected to participate in the protocol face penalties, but under normal circumstances, these validators only risk losing the rewards they would have earned had they participated appropriately in the protocol<\/strong>. This indicates that validators who are online more than 50% of the time will still observe growth in their stake over time.<\/p>\n

<\/p>\n

As a consequence of this system, validator clients that require going offlinefor upkeep etc., are typically better off if they simply go offline for a brief duration rather than exiting and re-entering the protocol (both of which incur delays)<\/em>.<\/p>\n

<\/p>\n

This implies that validators need not exert themselves excessively with supplementary clients or redundant internet connections since the consequences of going offline are not overly harsh. In fact, any system where two parties can authenticate messages can be counterproductive as primary and backup clients could both remain online simultaneously and produce slashable votes (through the double voting mechanism described previously) as occurred with the initial Cosmos slashing<\/a>.<\/p>\n

<\/p>\n

This scheme of offline penalties remains valid as long as blocks are being finalized (2\/3 of validators (weighted by stake) are online and their votes are being tallied). This is the anticipated condition of eth2 during standard operation. If fewer than 2\/3 of nodes are online, then a significant failure has occurred within the eth2 ecosystem. The consensus protocols’ family to which Eth’s Casper belongs can no longer achieve consensus under these circumstances.<\/p>\n

<\/p>\n

What does eth2 do if > 1\/3 of validators are offline? \ud83d\udca3<\/h2>\n

<\/p>\n

This is where the inactivity leak mentioned at the outset of the article becomes relevant. The inactivity leak<\/em> diminishes the balances of the offline nodes over time so that the ratio of active validators to total validators (weighted by stake) can once again surpass 2\/3, allowing eth2 to persist in making decisions as a protocol.<\/p>\n

<\/p>\n

Inactivity leaks represent one of the methods eth2 has been engineered to endure a WW3-like scenario. Should such an event incapacitate more than 1\/3 of all validators, then the offline validators would discover that their balances diminished to the extent that their involvement was no longer necessary for eth2 to maintain its chain.<\/p>\n

<\/p>\n

Anti-correlation and decentralization<\/h2>\n

<\/p>\n

Both the slashing mechanism and the inactivity leak motivate validators to make choices that lead to their nodes failing in ways that differ from others<\/em>. In other words — to minimize the potential for slashing and to avert inactivity leaks, a validator should aim for their clients to fail in manners distinct from those of others.<\/p>\n

<\/p>\n

This compels all validators to decentralize every facet of their validation process because, for instance, validators who depend on the same data source like Infura or utilize AWS to host their clients will suffer more if an issue arises.<\/p>\n

<\/p>\n

With all the numerous ways to be penalized, why would anyone want to be a validator? \ud83d\udcc8<\/h2>\n

<\/p>\n

As mentioned in the initial article, “validators will be negligent, accept bribes, and they will attempt to compromise the system unless they are otherwise incentivized not to.” The penalties addressed thus far dissuade negative conduct, yet incentives are essential to motivate validators to take actions that benefit eth2.<\/p>\n

<\/p>\n

There are three primary categories of rewards:<\/p>\n

<\/p>\n

Whistleblower rewards \ud83d\ude93<\/h3>\n

<\/p>\n

A validator who raises an alert regarding another validator by presenting evidence that leads to their slashing is compensated for their efforts in maintaining the integrity of eth2.<\/p>\n

<\/p>\n

Proposer rewards \u2b1c\ufe0f\u26d3\u2b1b\ufe0f\u26d3\u2b1c\ufe0f<\/h3>\n

<\/p>\n

Validators are randomly designated with the responsibility of generating a block; the selected validator is termed the proposer<\/em>. A proposer is rewarded for their contributions in the following manners:<\/p>\n

<\/p>\n