Abstract
After launching our Ethereum Proof of Stake (PoS) validator node a few weeks ago, in our first detailed look at the PoS system, we catalog and examine each type of reward and penalty that validators can obtain. We provide examples for many of the scenarios based on the live system and comment on the interrelationship between some of these rewards and Ethereum’s supply. We conclude by explaining that PoS systems have an evolutionary design philosophy and that many of the complex parameters and constants discussed in this report are likely to be continually refined over time, as developers learn from the experience of observing the network.
Overview
Back in May 2020 we gave an overview of the mechanics and the main processes in Ethereum’s proposed PoS system. We explained how the voting for block proposals is conducted, in separate committees of validators. We also explained concepts such as target blocks, source blocks, justification, finalisation, and slashing conditions. In this piece we will go into more detail on the rewards and punishments validators can receive for good or bad behaviour, respectively. We will try to cover all of the main rewards and punishments and will perform example calculations for each type of scenario.
This is the first part in our planned series on PoS, following our decision to become a validator on 31 August 2021. As a reminder Ethereum 2.0 (The Beacon Chain) is currently live, operating in parallel to Ethereum 1.0. The Beacon Chain is currently a proof of concept system and the plan is to eventually merge the two chains together, before turning off the old Proof of Work system (PoW).
Rewards
The below table is a summary of the main rewards validators can earn on the Ethereum 2.0 network. We will go on to look at each reward in detail.
Figure 1 – Summary table of rewards
| Event | Typical reward per validator per event (Based on current network conditions) |
| Block proposed | 0.005 ETH |
| Correct attestation | 0.00002 ETH |
| Timely attestation | 0.000005 ETH |
| Whistleblower | 0.0625 ETH |
Proposer rewards
As we mentioned in our previous post, on 31 August 2021 the BitMEX Research validator produced its first block in slot 1,964,794. Each validator is randomly allocated a slot in which it has the privilege of producing a block and this is expected to occur around once per month. Two Epochs after our block was produced (when the slot became finalised) our validator received its reward, around 0.0052 ETH. The reward for producing a block is perhaps the most basic incentive in the PoS system and it is therefore the one we will look at first. This reward is not fixed, but varies depending on several factors, namely the total number of Ethereum staked and the number of active validators.
The first component to calculate in the equation is something called the “base reward”. This is a constant value across the network for any particular moment in time. The base reward can be calculated by using the below formula.
The constants 4 and 64 are values set by the protocol. 64 is called the BASE_REWARD_FACTOR and 4 is known as BASE_REWARDS_PER_EPOCH. We do not cancel these two numbers out in the formula above to get 16, because these constants are also used elsewhere in the protocol.
The total active balance in the network is currently around 7.1 million ETH and the effective balance is the average balance for each validator. This average number is normally around 32 ETH. It can never be larger than 32 ETH, since it is capped at this level and it is not likely to be much smaller than 32 ETH, since the minimum initial staking balance is 32 ETH. However, the average effective balance can be a bit less than 32 ETH, if some validators have been punished or slashed and these punishments are greater than the rewards. For simplicity, in the below calculations we have used a value of 32.
Plugging the above numbers into the formula and using numbers from the current network, we get a base reward as follows.
After the base reward has been calculated, one can then calculate the reward attributable to each proposer, based on the formula below. The number 8 in the formula is another constant from the protocol, called the PROPOSER_REWARD_QUOTIENT. The number of attestors is the number of validator attestations included inside the proposed block, this incentivises block producers to include votes in their blocks. Another way of thinking of this is that block proposers get a share of the rewards for all the attestations in the block they produced. Assuming 100% participation this should be 1 in 32 of all the validators voting in each block.
Based on the above formula, this results in a reward per block proposer as follows.
This is 0.0053 ETH, pretty close to the 0.0052 ETH we saw in the live network. An example of this is shown in the image below. A validator proposed a block and two epochs later, the validator received a reward of approximately 0.005 ETH.
Figure 2 – Proposer rewards
Source: beaconcha.in
Interpreting the formula
Combining the two formulas above to work out the rewards per block producer can be helpful in trying to understand what is going on.
In most scenarios the number of attestors will increase with the total active balance, therefore in some ways these two terms cancel each other out. However, the total active balance is square rooted. Therefore, as more Ethereum moves over to the Beacon chain and starts to validate, rewards per block producer increase, but at a diminishing rate. This is because the number of block producers can never be higher than 32 per epoch, therefore this reward can increase as the total amount of stake increases, without resulting in too much Ethereum being produced. This is in contrast to other rewards, for instance attestor rewards, which decline per attestor as the total amount at stake increases. (We will talk more about this later). This therefore achieves one of the objectives of the Beacon chain, it ensures that inflation is approximately proportional to the square root of the number of coins at stake.
Attestor rewards
The next reward we will examine are attestor rewards. Attestation is the process of voting for the proposals from the block producers.
An attestation consists of the following:
- The block hash of the block you are voting on
- The height of the block you are voting on (i.e. the chaintip at the time of voting)
- A source – normally the block hash of the first block in the previous epoch
- A target – normally the block hash of the first block in the current epoch
The reward for a correct and perfect attestation is calculated as follows:
Please note the above formula is an oversimplification. There are three categories for a correct attestation and the reward for each is the same. We have simplified them all together and multiplied by three instead of considering each scenario. As with the proposer rewards, payments are typically received two epochs after the attestation.
Performing the above calculation, using the 6,064 Gwei Base reward above, assuming 100% attestor participation, one gets a reward of 23,498 Gwei per attestor. This is approximately 0.00002 ETH and matches what one can see on the network. The value of this reward is approximately 225x smaller than the proposer reward per validator. In contrast, aggregate attestor rewards are typically around 32x larger than aggregate proposer rewards.
An example of a correct attestation is shown below in Figure 3. In slot 1,972,825 our BitMEX Research validator attested to block 1,972,824 (the previous block) and received a reward of 22,469 Gwei for a perfect attestation, reasonably close to the calculated value above.
Figure 3 – Correct attestation
One can see the above attestation on beaconcha.in below:
Figure 4 – Example of a correct attestation
Source: https://mainnet.beaconcha.in/block/1972825#attestations
As mentioned above and as Figure 3 shows, there are three criteria to consider when evaluating an attestation and calculating the attestor rewards:
- Voting for the correct source block
- Voting for the correct target block
- Voting for the correct head block (the chaintip)
An example of failing to get all three criteria correct is shown below. At block height 1,972,769 the BitMEX Research validator attested to block 1,972,768 (the previous block). However, two of the three criteria failed, resulting in two punishments and one reward. Overall this resulted in a net punishment of 813 Gwei.
Figure 5 – Partly incorrect attestation
One can see the above attestation on beaconcha.in below:
Figure 6 – Example of a partly incorrect attestation
Source: https://mainnet.beaconcha.in/block/1972769#attestations
Analysing the attestation, one can see the main features:
- The source block was correctly voted on. The hash of the first block in the previous epoch, block 1,972,736 in epoch 61,648 ended in …bfab, just as the above attestation illustrates
- The target block was incorrectly attested. The target block hash ends ..6e26 and this was the last block in epoch 61,648, not the first block in epoch 61,649 which it should have been.
- The BitMEX Research validator voted for the block hash ending …6e26 as the head (block height 1,972,768), when this was incorrect. This was the block hash of the previous block, with height 1,972,767.
Our validator chose a target block and head as the previous block, rather than the tip. In most of the cases we were punished, this was the cause. Our node made this error several times. The reason for this error appears to be that our node had not had time to receive, download and verify the latest block by the time the attestation was due. Therefore the node voted as if the most recent block producer missed their slot and used the previous block instead. Poor network propagation caused this error, however it is only considered a minor and common error and therefore the punishment was small.
Incentive to ensure a faster vote
There is also an additional incentive, which has a value of at most seven eighths of the base reward. This incentive is designed to ensure a faster vote and the reward here declines the greater the delay in the vote. If the attestation is included in the next slot, then the full reward is received, seven eighths of the Base reward. For each block the vote is delayed, the lower this element of the reward is. For example if the attestation occurs two blocks late the reward is halved and if the attestation is three blocks late, the reward is divided by three, etc. etc. .
The BitMEX Research node always voted in a timely manner and has always voted in the next slot. However, we found examples of late votes from other validators. An example of this is validator 38,570. As the image below shows, the attestation for block 2,018,822 was included in block 2,018,826, a delay of three blocks. Therefore the total reward paid was only 18,990 Gwei, rather than the normal 22,000 Gwei, due to the time delay.
Figure 7 – Late attestations
Source: https://mainnet.beaconcha.in/validator/38570#attestations
Aggregate reward & coin issuance
Incorporating all of the above analysis, we can now estimate the total Ethereum coin issuance associated with these rewards. This is illustrated by Figure 8. As the chart shows, the bulk of new issuance is awarded to attestors, with block producers receiving around 32x less than attestors. The chart also illustrates the complexities of Ethereum issuance; if one wants to have a comprehensive view of Ethereum supply, one needs to understand many of the intricacies within the PoS system.
Figure 8 – Ethereum Annual Issuance Related To Staking (Assuming Perfect Network Conditions)
Source: BitMEX Research
The above various types of rewards then approximately add up to the maximum PoS related Ethereum annual issuance, desired by Vitalik Buterin in his April 2019 comment on GitHub. Our chart above essentially breaks down the components of Ethereum inflation into three rewards. In addition to the above, there are also penalties and slashings, which could reduce the issuance of new Ethereum. Other factors which could impact the supply are inactivity. Therefore the above should be considered as the maximum issuance.
As another reminder, to understand new Ethereum inflation there are essentially three key components to it:
- The PoW issuance for Ethereum 1.0, resulting in new issuance
- The coin burn on Ethereum 1.0, due to EIP-1599, resulting in reductions in coin supply (Or “buybacks”)
- The rewards and punishments in the Ethereum 2.0 staking system, resulting in new issuance
There is one big change planned to the above three components in the next few years. Component one, the PoW related issuance, is expected to be turned off. At this point, the new issuance of Ethereum is expected to be much more constrained and the fee burn could even be larger than the staking rewards. Assuming fee demand remains strong, it seems likely that the coin supply could decline after this point. If one evaluates Ethereum from a monetary perspective this is deflation, or if one looks at it like a stock, a reduction in share count.
Penalties
Inactivity Penalties & Incorrect Attestations
There are two types of penalties. The first category of penalties are for an incorrect attestation, which can happen in three ways as described in the attestor voting section above. The second category of penalties is for individual validator inactivity. Missing an attestation is treated in the same way as an incorrect attestation, the penalty is 3x the base reward. This exactly the same penalty as a totally incorrect attestation (Assuming no slashing occurs)
In order to test the inactivity penalties, we deliberately turned our validator node off for one epoch. The BitMEX Research validator deliberately missed the attestation in epoch 63,657. As the below image illustrates, we received a fine of 17,841 Gwei for our misbehaviour. This is just the normal penalty for an incorrect attestation for all three characteristics (i.e. three times the base reward).
Figure 9 – Inactivity penalty
There are also network wide penalties for inactivity, if the entire network is unable to finalise a block for 4 epochs, then every validator receives a penalty.
Slashing
Slashing is different from punishments, in that the offense is considered far more severe and therefore the punishment is greater. There are slashing conditions for the two types of actors in staking: i. Block producers and ii. Attestors.
With respect to block producers, the slashing conditions are reasonably simple – if a block producer makes two different valid proposals in the same slot, it is slashed. An example of this is shown below in Figure 10.
Figure 10 – Example of block producer slashing – Producing two blocks in the same slot
Source: https://beaconcha.in/block/476904#proposer-slashings
In Figure 10 above, the block producer proposed two conflicting heads for slot 476,903. It is not known what caused this error. It could be malicious, a software bug, or perhaps the computer crashed and booted up again at an unfortunate time.
With respect to attestor voting, the slashing conditions are more complex. There are two categories of slashing: i. Double voting and ii. Surround voting.
Double voting is any different vote, using the same target epoch. It can be explained with the formula below.
data_1 != data_2 and data_1.target.epoch == data_2.target.epoch
Source: https://github.com/ethereum/eth2.0-specs/blob/dev/specs/phase0/beacon-chain.md#slash_validator
Figure 11 is an example of a double vote. Validator 45,276 produced two conflicting votes, for different chaintips, using the same target and the same source.
Figure 11 – Example of block attestor slashing – Voting for two blocks in the same slot
Source: https://beaconcha.in/block/2029833#attester-slashings
As for the surround slashing condition, we explained the rule in our May 2020 piece on Ethereum 2.0. We could not find an example of this violation on the Beacon Chain and to the best of our knowledge, no such violation has ever occurred.
Slashing Penalties
Regardless of the type of offence caused, the slashing penalty is the same for all slashable offences. There are four ways an offender is punished.
- The validator is removed from the validation set, a process that can take 36 days. After removal the validator is inactive and any remaining balance just sits on the account unable to do anything or earn any rewards. Once Ethereum 2.0 gets more features, the funds may be accessible again.
- There is an initial penalty of 1/128 of the effective balance – This is normally around 0.25 ETH. This fine is imposed immediately once the offence has been identified.
- A recurring penalty for each epoch of 3 * the base reward, this is the same value of the reward that a validator can earn from a correct attestation, except its a penalty not a reward. i.e. this is exactly the same as inactivity. This penalty occurs until the validator is removed from the validation set.
- A “special penalty” – the severity of this penalty depends on the number of validators who committed a slashable offense during the same epoch. The more validators are slashed, the worse the penalty per validator. This measure is designed to incentivise decentralisation, because the more validators committed the offence the larger the penalty. This incentivises validators to run on different hardware or computer networks.
Figure 12 below illustrates the daily income for a slashed validator. Prior to the offence the validator earns 3x the base reward each epoch. As the offence is committed the validator receives a large fine and then a recurring fine of 3x the base reward is incurred each epoch. Eventually, after 36 days, the validator becomes inactive and the penalties stop.
Figure 12 – Validator slashing penalties
Whistleblower rewards
If a block proposer includes a special type of attestation in the block, an attestation which proves another validator has violated a rule, in particular if another validator has performed a slashable offence, then the block producer is given a special reward. This reward is called the whistleblower reward and is calculated by dividing the offender’s effective balance by 512. This will normally result in an award on 0.06 ETH. This reward is not inflationary, since the offender is likely to be fined at least 0.25 ETH for committing the offence. Therefore, slashings contribute to deflation and reduce the coin supply.
Figure 13 below shows the daily income of a validator, which recently earned the whistleblower reward. As the chart below illustrates, when the validator produced a block, its earnings were over 0.07 ETH, due to the inclusion of the whistleblower reward.
Figure 13 – Whistleblower rewards
Source: https://beaconcha.in/validator/204685
Conclusion
If you have read this far into the note, you may have two key takeaways, i. There is a lot of arbitrary complexity here and ii. How does anyone know if all this will work? The main issue here is understanding the philosophy of those that designed the PoS system, principally and evolutionary philosophy. There have been many iterations of PoS systems over the years, most of which were very weak and fundamentally flawed. Due to the lessons learned, the proposals have become stronger and stronger over time. This is very much different to when Satoshi launched Bitcoin. Bitcoin’s core consensus system is reasonably simple and has never changed and it is almost “set in stone”. Most PoS advocates appear to have no ambition of finding a perfect PoS system that can be robust for decades, instead they seek a strong system that can be upgraded and refined.
As far as we can tell there are plans in place to change some of the constants and parameters in the reward and punishment formulas discussed in this report. For example plans to split the whistleblower rewards up, with 7/8 going to the attestor who found the offence and 1/8 going to the block producer who included the relevant attestation in their block. Currently all of this reward (8/8) goes to the block producer. We have also seen larger changes discussed, such as increasing the share of rewards attributable to block producers compared to attestors. Currently attestors earn in aggregate around 32x that of block producers, while some want to change this to 8x in a later upgrade. Lessons can be learnt as the network grows. Perhaps staking systems will never reach a final state and some of the parameters may always require constant tweaking and refinement.
Therefore the above PoS system should not be thought of as a final system design, it is only an experiment and it may change. We remain sceptical of PoS systems, however we cannot ignore or hide from the fact that iterations of these systems do seem to have improved considerably over time. We doubt the rewards and penalties outlined in this report will be robust enough as a base architecture for a censorship resistant unstoppable network, however, it is likely to improve in the years ahead.
