Compensation and punishment

Can proof of stake Ethereum reward good behaviour and identify accidental mistakes?

Over 500k Validators with >99% participation uptime amongst them.

Ethereum’s proof of stake protocol is designed to maximise the number of Validators who can participate in an open and permissionless manner. It allows anyone, at home with commercially available hardware, to register and participate as an active Validator.

Given the sheer size, openness, and pseudonymity of the Validator set, we need to consider the financial incentives which encourages a Validator to honestly participate in the protocol. As well, we need to consider how to detect and deal with Validator who try to disrupt the proof of stake protocol.

On-chain protocol transcript

A protocol transcript for the proof of stake protocol is recorded in the beacon blockchain. Any observer, including the proof of stake protocol, can evaluate the transcript in real-time. Most of the transcript is made up of actions performed by the Validators.

The transparency and real-time availability of the transcript allows a set of rules to be defined and enforced — ultimately constraining the Validator’s action space by restricting what they are allowed to do and definitely not allowed to do:

• Breaks the rules. If a Validator performs an action that is detectable and breaks the rules, then the proof of stake protocol can decide to eject them immediately and serve a punishment.

• Nudge good behaviour. If a Validator deviates from the rules in a non-detectable and non-desirable manner, then the reward system can be used to nudge the Validator in the right direction towards honest behaviour.

Of course, there are certain behaviours, like extracting MEV — which is potentially a non-desirable action that the proof of stake protocol may just need to learn how to handle. But that is outside the scope of this article. The key takeaway is that we can reward/punish a Validator in real-time based on their observable actions.

Scaling rewards and punishments

One of the odd, yet interesting aspects of proof of stake Ethereum, is that it attempts to scale rewards and punishments based on the quantity of Validators acting in concert to perform the same action.

Scaling rewards. The rewards are scaled as Validators cast the same attestations and converge on the same blockchain fork. If all Validators work together, then they will receive the maximum reward possible. Note, it is not necessarily that they are making the correct decision according to the protocol specification, but they are all in agreement with each other.

Scaling punishments. In most blockchain protocols, if a participate deviates from the protocol specification, then they are assumed to be acting malicious and the maximum penalty is issued. Proof of stake Ethereum is unique in its attempt to distinguish between an accidental mistake or malicious behaviour by a Validator.

It is achieved by scaling the severity of a punishment based on the quantity of Validators who performed the same invalid action. For example, the minimum punishment of ~0.5ETH is issued if only a single Validator breaks the rules, whereas if a significant number break the rules, then they will potentially forfeit all their staked ETH.

Penalty != Slashing. Before we dive more into the details, it is important not to equate a penalty with a slashing event.

• Penalty. Punish an action that may hold up the protocol, but it does not change its trajectory. For example, if the Validator is temporarily offline or their attestation is late to arrive.

• Slashing. It is triggered when a Validator has deliberately broken a sacred law of the proof of stake protocol with the intention to deceive/trick the other Validators.

A penalty acts as a deterrent and it reduces a portion of the staked ETH. Most of the time, only a tiny portion of funds are forfeited, especially for accidental mistakes. On the other hand, a slashing event will immediately eject the Validator and potentially forfeit the entirety of their staked ETH.

Ejection from protocol. There are two scenarios in which a Validator will immediately be ejected from the proof of stake protocol:

• Slashing event. A Validator is immediately ejected if they break one of the sacred laws of the proof of stake protocol.

• <16 staked ETH. Issued penalties have slowly dwindled their staked ETH.

A Validator can and will survive if they receive penalties for quite awhile — as we will see — in most cases a penalty is simply the inverse of the rewards a Validator should have received.

Sources of Validator income

We need to consider the rewards and income for a Validator. There are two immediate sources:

• Network issuance. New coins are minted and issued as rewards to Validators who are actively participating.

• Transaction fees. Fees collected when a user-generated transaction is included in a beacon block.

Thanks to EIP-1559, most of the transaction fee is burnt and the Validators only receive a small tip for including a transaction. The vast majority of a Validator’s reward is expected and should come from network issuance.

Transaction fees are sent to the Validator via the execution layer and network rewards are only issued on the consensus layer after a new checkpoint has finalised. Once withdrawals are enabled, it is expected that periodic sweeps will automatically occur to send the issued network rewards from the consensus layer. The sweep should be available as long as the Validator’s balance is >32 ETH.

Rise of MEV as income

We mentioned the majority of transaction fees are burnt thanks to EIP-1559, but it is crucial to understand how transaction fees work and there are two types:

• Intended and overt. A user has specified a tip in their transaction that is paid directly to the Validator.

• Non-deliberate and covert. The execution of the user’s transaction was changed to allow another party to extract value from it.

Nearly all blockchain protocols, including Ethereum’s proof of stake, is designed for intended and overt fees. By publicly disclosing fees, it helps establish a transparent fee market and provides enough information to help users decide an appropriate bid to submit, especially during times of congestion. If all transaction fees are public, then Validators can simply order transactions based on the largest fee first.

As well, EIP-1559 helps establish a minimum bid that all users must pay and due to the elastic block-size, a small tip on top will work most of the time.

Courtesy of https://mevboost.pics

In recent years, the rise of non-deliberate and covert fees — MEV— has led to exceedingly large profits for Validators. It empowers an actor to extract any excess profit from user generated transactions and take that as the fee for including it. For example, if a user’s transaction has a 1% slippage tolerance for a swap, the Validator can simply take any positive slippage from the transaction.

The proof of stake protocol was not designed with MEV in mind, but we need to be concerned about it as MEV represents a significant source of income for Validators — thanks to Flashbots and their implementation of a semi-trusted block-proposer separation (BPS) scheme.

Again, the exact mechanics of MEV is outside the scope of this article — but it is a very fun topic to discuss and its impact on income is substantial.

Minimum Viable Issuance

A core concept in Ethereum is to avoid overpaying the Validators and protect the network’s security budget.

Issuing coins is not free as it inflates the currency’s supply and ultimately harms all coin holders. It is crucial to pick an issuance rate that makes it profitable to run a Validator, but not exceedingly profitable to the point it has a negative impact on coin holders.

Additionally, the network reward should cover, as much as it can, the capital cost and operational cost to run a Validator:

• Capital costs. The loss of potential income by locking the stake in the proof of stake protocol as opposed to earning yield elsewhere.

• Opportunity cost. The on-going compute, bandwidth and storage costs associated with running a Validator.

Thankfully, the capital cost to purchase the hardware is minimal. Validators just need a modest ~$1-2k machine like a dappnode. The on-going operational cost is minimal — just electricity to run a single machine alongside a good internet connection.

In contrast to proof of work — there is no zero sum game to solve computational puzzles and the network reward does not need to subsidise the cost of it. It just needs to focus on the profit and yield curve for encouraging Validators to sign up.

Quirky Effective Balance

Before we discuss how the network reward is computed, we need to consider two special concepts which are implementation details of the proof of stake protocol, but important to compute the actual rewards:

• Effective balance. It is close, but not exactly, the actual balance of the Validator. It will range between 16 ETH to a cap of 32 ETH. It lags behind the actual balance due to the frequency in which it is updated.

• Increments. A Validator’s ETH balance without any decimals. For example, if the Validator’s effective balance is 31.5 ETH, then they have 31 increments.

The motivation for an effective balance is to reduce the computation required to work out the balance of all Validators per epoch and reduce the data sent to light clients.

Computing network rewards

The main reward for a Validator is the base reward — not to be confused with the base fee of EIP-1559 — as it is the basis for computing all payments to Validators during an epoch.

The base reward is revised on a per-epoch basis:

BASE_REWARD_FACTOR = integer_squareroot(get_total_active_balance(state))

The square root aims to auto-balance the Validator population size by increasing (or decreasing) the base reward based on the total number of registered Validators. The yield curve should eventually plateau once a target quantity of Validators are actively participating and reached a desired size.

The total reward a Validator will receive is a multiple of the base reward. It is calculated using the Validator’s effective balance (increments) and the base reward:

total_reward = EFFECTIVE_BALANCE_INCREMENT * BASE_REWARD_FACTOR

A Validator’s reward is a multiple of the base reward depending on their increments. For example, if a Validator has an effective balance of 32 ETH, then they’ll be paid 32*BASE_REWARD_FACTOR.

// Rewards scale based on Validators in agreement 
percentage = total_staked_ETH_in_agreement(attestation.target);
final_reward = total_reward * percentage;

The final aspect of computing the reward is based on consistency and agreement amongst all Validators. If an X% of the staked ETH have cast the same vote (head, target, source), then the reward for that vote is scaled by the same percentage. For example, if 75% of Validators agree on the same target vote, then their final reward is 75% of the total reward for a target vote.

The motivation to scale rewards based on agreement is to encourage Validators to cooperate and propagate all messages. The more votes included in a beacon block will be to the benefit of all Validators as they will get more rewards as a collective.

As a side note, scaling of rewards may have unforeseen side effects and an interesting research study is to check whether the best strategy for a Validator is to copy the majority’s vote (like SPV mining) as opposed to deciding it independently.

Rewarding and penalising a Validator

Table 1: Reward and penalty table for attestations. H for Head, S for Source and T for target. Inspired by a diagram from the ETH2 book draft.

There is no fixed block reward.

A Validator will only receive rewards for casting an attestation (a Head vote, Source vote, and Target vote) or including attestations from other Validators in their own proposed block.

Attestation rewards. The rewards for an attestation is judged on the following criteria:

• Correctness. All validators are in agreement about the same vote. For example, if a Validator’s source vote is in conflict with the block proposer, then it cannot be recorded in the beacon block. Only source votes that are in agreement with this blockchain fork will receive a reward.

• Timeliness. Takes into account whether the other Validators received the vote on time and if it can be used as part of their decision making process (i.e., applying the fork-choice rule). For example, a head vote cannot be used by the next slot’s committee of Validators if it is not received on time.

Table 1 is a reward table that takes into account the judgements of correctness and timeliness. Let’s take this opportunity to summarise each case:

• All correct. Full reward is issued to the Validator as it was included in the immediate next slot and it is in agreement with the fork-choice rule.

• None correct. An attestation cannot be included if the source is not correct. The Validator is penalised the source and target vote reward.

• Only source correct. The award for a correct source vote is only valid for the next 5 slots. After this time period, the full penalty is issued to the Validator.

• Source and target correct. The award for a correct source vote is only available for the first 5 slots, but the target vote is available for up to 32 sots. An attestation cannot be included after 32 slots and the full penalty is issued.

A keen reader will notice that the penality for an incorrect vote is essentially the inverse of an attestation not being included in the beacon blockchain. For example, the maximum reward is H + S + T and the maximum penalty is -S-T. The above table assumes the proof of stake protocol is not in a state of emergency and it has not entered an inactivity leak.

Inclusion rewards. As mentioned previously, a block proposer is rewarded for including attestations (evidence) in their beacon block.

Let’s take this opportunity to summarise the inclusion rewards:

• Attestations. A block proposer can include attestations for up to 32 slots in the past. The proposer receives 1/8 of the total attestation reward and the remaining 7/8 of the reward is paid to the attesting Validator. It is expected a proposer will include attestations as early as possible in order to maximise their reward

• Whistleblower rewards. Evidence that another Validator has violated the protocol rules and triggered as slashing event. The reward is computed as the offender’s effective balance / 512 with a maximum of ~0.06 ETH.

• Sync committee contributions. There is an additional reward for participating in a sync committee that supports light clients.

It provides a financial motivation as block proposers are rewarded for recording protocol messages in their beacon block. The reward scales, in the sense that, the more Validators in agreement with the block proposer then the more protocol messages that can be included in the beacon block.

Interestingly, there are no rewards for block proposers to include deposit events from the execution layer. They are forced to perform this role as it is enforced by the fork-choice rule. If deposit events are missing, then the block is considered invalid and it is rejected.

Slashing conditions

Checkpoint { 
    Epoch: unit, // Epoch number
    Root: bytes; // Block hash
}

Vote {
   slot: uint, // Vote is tied to slot
   head: bytes, // Head vote 
   source: Checkpoint, // Already justified
   target: Checkpoint // To justify
   signature: bytes // Signature from Validator on the vote
}

Vote a = {..};
Vote b = {..};

// Check both votes are valid before continuing.
require(validateVote(a), "Not a valid vote");
require(validateVote(b), "Not a valid vote");

// Both votes must be different
require (a != b, "Both votes are the same");

// Cannot have two votes for the same target. 
require( a.target.epoch != b.target.epoch, "Not allowed to vote for the same epoch" );

// Casper FFG condition to check for encompassing blockchain forks
// Flip a & b to test the inverse.
require( a.source.epoch < b.source.epoch 
         <
         b.target.epoch < a.target.epoch );

A slashing event is triggered when there is indisputable evidence that a Validator has broke one of the sacred commandments that governs the voting protocols. If detected, they are ejected from the proof of stake protocol and forfeit a portion of their staked ETH.

There are two commandments that can be broken:

• Double-voting. A Validator is only allowed to cast a single vote during an epoch. If they cast two or more different votes in the same epoch, then the rule is broken.

• Surrounding blockchain fork. A Validator cannot vote for a second blockchain fork that fully encompasses another blockchain fork they have already voted for.

The former rule is to combat the nothing-at-stake problem as a Validator is forced to only cast a single vote and avoid confusing all other Validators when they apply the fork-choice rule. The latter fends against long-range attacks where a Validator attempts to replace a blockchain fork (that already has high confidence) with a blockchain fork of their own choosing.

As a side note, most projects implement a slightly different constraint for detecting an encompassing blockchain fork.

Evidence for double-voting is straight forward. A Validator must have signed two attestations for the same epoch. So, to check for fraud, the evidence is simply inspecting the signed epoch number.

On the other hand, evidence to vote for a surrounding blockchain fork is represented as a single condition:

// Casper FFG condition to check for encompassing blockchain forks
require( a.source < b.source < b.target < a.target );

Checking this evidence takes a bit more work as it involves pair-wise evaluations of attestations cast by Validators. There are dedicated slasher clients implemented to handle it. Note, not all consensus clients include a slasher module and will only check the evidence once presented to them.

The pair-wise check is evaluating whether a Validator’s vote for a blockchain fork has fully encompassed another blockchain fork they have voted for. It may be easier to digest in visual form:

Two votes by a single Validator. We can see that Vote A fully encompasses vote B.

As we can see, the blockchain fork in vote B surrounds the blockchain fork in Vote A.

To the best of our knowledge, there is no reason why a Validator should change their source vote to an earlier epoch/slot/block. If there was a large block re-organisation and the Validator was on the wrong blockchain fork, then they should simply start again at the tip of the chain. They will be penalised for missing votes, but they will avoid the slashing event.

Upon discovering a Validator has broken one of the two sacred commandments:

• Immediately ejected from the proof of stake protocol,

• Forfeit 1/6th of effective balance (max 0.5 ETH).

• Placed in jail for 36 days (4096 epochs).

The immediate slashing ensures there is always a financial cost and punishment for breaking the rules. Additional, the Validator will receive the maximum inactivity penalty throughout the 4096 epochs as they are not allowed (and cannot) cast votes in the proof of stake protocol.

Jail provides time for the proof of stake protocol to find other instances of slashing as it takes time for slashing events to be recorded in the beacon blockchain. The quantity of slashing events helps the proof of stake protocol determine whether the incident was accidental by the Validator (only a few slashing events) or if there was a co-ordinated attack on the system (many slashed Validators).

The final punishment is computed based on all slashing events that have occurred 18 epochs before and after the slashing incident.

A second, and the majority penalty, is computed after 18 days (4096 epochs) of the slashing event. It takes into account all slashing events 18 days prior and 18 days after the Validator was placed in Jail.

The major penalty is computed as the following:

PROPORTIONAL_SLASHING_MULTIPLIER = 3; // Set by the protocol
SLASHING_SUM = SUM(slashed validator's effective balances)
TOTAL_BALANCES = SUM(effective balances of all active Validators)

final_penalty = (PROPORTIONAL_SLASHING_MULTIPLIER * SLASHING_SUM) / TOTAL_BALANCES

Depending on the quantity of Validators slashed, the punishment can be minimal to the full effective balance. The hard-coded value for the slashing multiplier has been updated since the merge to enable the full extent of slashing.