Meet 0xB0B, an aspiring Ethereum validator who aims to contribute to the network security while earning the most reward possible out of his participation to the beaconchain (Ethereum 2.0 new chain).

0xB0B is represented by two pair of keys:

1. Withdrawal keys (public/private) used to control his wallet
2. Validation keys (public/private) used to participate to the network activity

Becoming a Validator

To join his friends in the network, 0xB0B needs to have 32 ETH to apply to the validator job. He asks his father, an ETH wallet, to deposit this amount to the ETH2 deposit contract. This contract receives the 32 ETH and tells the beaconchain that 0xB0B is applying as a validator. After 2048 slots (2048 * 12s), beaconchain will process the deposit and 0xB0B will receive his 32 ETH that will be used for his activity on the network.

When deposit succeeds, 0xB0B is added to the validator activation queue, waiting to be eligible for activation to start his validator journey. 4 validators are accepted every epoch (384s), looking at the average length of the queue, 0xB0B will have to wait one or two days before being accepted.

But before being activated, 0xB0B has to be setup in an infrastructure fast, to avoid having penalties for inactivity when he will be activated. 0xB0B will first join a validator client, which is a building where multiple validators live in their own flat. He can choose his validator client among multiple open source and well maintained projects: Nimbus written in Nim, Teku in Java, Lighthouse in Rust or Prysm in Go. 0xB0B joins a Teku building (validator-client) with 4 neighbors.

This building is connected to the post office of the neighborhood. Every neighborhood has its own post office connected to the other post offices of the city.

0xB0B has just been activated! He now gets an employee card with a unique id generated by the post office network to recognize his activity on the network. He has to wait 4 epochs (25.6 minutes) to start his job.

He also has what is called an effective balance which is a virtual balance used by the post office network to know how many tokens of 0xB0B are actually used for the consensus. If 0xB0B received 64 ETH from his father, his balance would be 64 ETH but his effective balance will still be 32 ETH. When 0xB0B will earn reward, effective balance will not change, only the balance will. The effective balance value can change following 2 rules:

1. if a validators’ balance falls 0.25 ETH below its effective balance, then its effective balance is reduced by 1 ETH
2. if a validator’s balance rises 1.25 ETH above its effective balance, then its effective balance is increased by 1 ETH

The time unit of the city postal system is the slot (12 seconds), 32 slots compose an epoch (6.4 minutes). For each slot, a block can be added to the beaconchain, the decentralized database (blockchain) of the post office network. The post office of each neighborhood has different jobs:

• send work to its validators
• propagate data to the post office network
• maintain a local beacon chain storage and keep it up to date with the chain updates
• handle deposits, as we are still in the early stage of the beacon chain, every post office is connected to an “ETH1” node to check for new deposits

Submitting attestations

What is an attestation?

To know what is the current state of the beacon chain, the postal network make validators vote, a vote is called an attestation. To collect attestations more effectively, the network groups validators randomly into committees (clubs of 128 validators min) at each epoch, with randomly selected 16 members who aggregate all the votes of the committee. For each slot, the maximum number of committee is 64.

0xB0B is now active, and is chosen by the network to join a cool-kid committee that will participate to the next slot!

The network asks validators of this committee 3 questions:

1. What is the checkpoint source ? (a checkpoint represents a group of H nodes, to represent the chain as a tree. This is standard for Casper FFG, a tool used by Ethereum 2.0 to justify and finalize groups of blocks)
2. What is the checkpoint target ? (checkpoint the chain should move to)
3. What is the head of the beaconchain ? (for consensus with LMD GHOST fork choice rule)

0xB0B writes down his answers, looking at the chaindata of his neighborhood and propagates it to the network to reach his committee’s aggregators. When an aggregator receives attestations of members of the committee, it creates an aggregated attestation and sends it to the post office network to propagate it to the maximum number of validators.

Every slot, a validator is randomly selected by the Post Office network to propose a block. This validator collects all aggregated attestations and include them in the block it proposes.

In order to make the network secure and promote good behavior, validators are rewarded for submitting attestations. Let’s deep dive into the rewards composition to see how 0xB0B can maximize them.

Attestation rewards and penalties

First of all, the rewards are computed from a base_reward which is a percentage of the effective balance value. Then we have what we will call a relative_reward calculated from base_reward * attesting_balance / total_balance where:

• attesting_balance is the sum of all effective balances of unslashed validators participating to this attestation
• total_balance is the sum of all effective balances of validators selected by the network for this attestation (the more offline validators for an attestation, the less the rewards).

0xB0B will be awarded, or will have penalties, according to what he voted for: his values will be judged as correct or not by the node processing his attestation.

Action	Value is Correct	Value is Incorrect
Casper FFG source	+ relative_reward	- base_reward
Casper FFG target	+ relative_reward	- base_reward
LMD GHOST Chain Head	+ relative_reward	- base_reward

N.B: Having a wrong source value means that target will be wrong and head too. So a bad source actually means 3 base_reward penalties. A good source but a bad target means that head is wrong too, so 0xB0B will earn 1 relative_reward and lose 2 base_reward.

To maximize his chances to get correct votes, the only thing 0xB0B can do is to ensure that his post office local chain data is up to date, poor network propagation can make 0xB0B do a mistake as he won’t have all the data to answer the questions correctly, this can be mitigated by making the post office connected to enough varied peers on the network.

Those rewards and penalties are summed and then added to a reward computed from the inclusion distance of the attestation.

The inclusion distance is the number of slots between the minimum slot when attestation can be included and the slot when attestation is included. Example: if attestation made by 0xB0B could have been included at slot 1237 but is actually included at slot 1239, the inclusion distance is 2. The maximum inclusion distance is 32, after that the attestation is not included. This inclusion rewards is shared between the attester (0xB0B here) and the proposer.

• The attester earns (7 / 8) * (base_reward / inclusion_distance)
• The proposer earns (1 / 8) * (base_reward / inclusion_distance).

Therefore 0xB0B should optimize his inclusion distance by reducing

1. attestation production time to be as fast as possible, by having an up-to-date chain data in his post office and enough resources to create the attestation structure
2. attestation propagation time to aggregators, by having a post office connected to enough varied peers

There are also outside factors that can impact the inclusion distance: aggregated attestation generation, aggregated attestation propagation and block proposal failure.

If 0xB0B starts to be inactive and does not submit attestations asked by the network, he gets the source, target and head penalties and 0 inclusion reward.

To help 0xB0B optimize those parameters and see their impact on his rewards, we can compute some data across time to help him understand how to maximize his rewards.

Monitoring rewards metrics

To monitor effectively attestation rewards, we should collect every submission made by 0xB0B and compute average value for each group of rewards.

1. Attestation Effectiveness can be computed for each attestation with (earliest_inclusion_slot - attestation_slot) / (actual_inclusion_slot - attestation_slot) and then average the result over the studied timelapse. The obtained percentage will give an idea of the global inclusion score of 0xB0B (and therefore an average of the inclusion attester reward he receives).
2. Attestation Correctness can be computed by looking for wrong source / tail / head attestations and averaging it: (correct_head_count - incorrect_head_count + correct_target_count - incorrect_target_count + correct_source_count - incorrect_source_count ) / expected_attestation_count

Checking for those two metrics (as time series or averages) during 0xB0B’s work can be a good insentive to understand which part of his activity reduces his attestation rewards.

Proposing blocks

Another part of the validator job is to propose blocks. This is a less common part of the job, as only one validator is chosen randomly at every slot to produce a block. The goal is to collect all votes of participating committees and choose the new head of the beaconchain.

As we saw in the last part, an attester only wins ⁷⁄₈ of the base_reward for its inclusion rewards, and 1/8 of the base_reward is for the proposer.

Therefore if 0xB0B proposes a block in time, he will earn number_of_attestors * base_rewards / 8.

Whistleblowing and Slashing

What is Slashing ?

To avoid malicious activities on the post office network, the network has mechanisms to avoid 3 types of bad activity from a validator:

1. If a proposer sign two attestations with a different head
2. If an attester surrounds another attestation with his attestation
3. If an attester submits two attestations with the same target

A malicious validator can be detected by a specialized fraud-detection post office, called whistleblower or slasher, that will report a wrong behavior to the network by propagating a message that will be included in the next block.

When a validator is slashed, the network tells him that he has 8192 epochs to get offline and stop his activity.

Penalties

First, when a validator is slashed, it gets a penalty of effective_balance / 128. Then, while the slashed validator does not exit, he gets a sort of “forced inactivity” penalty at each slot of 3 * base_reward.

Finally, a special penalty is applied and is bigger when the number of slashed validators gets higher during this period. It can be computed as follow effective_balance * (3 * sum_of_all_slashed_balances) / total_balances_slashed. This is used to incentivize the network to behave in the best possible manner.

Those penalties are high and often cause the effective balance to be reduced. Even if somehow the validator is not forced to exit the beaconchain, his rewards (which are all computed from a percentage of its effective balance) will be lower. Therefore being slashed mean being pushed toward the exit by the beaconchain.

Rewards

0xB0B can win special rewards if he, when he is selected as a block proposer, includes a slashing attestation. This reward is computed from the effective balance of the slashed validator and shared between the whistleblower and the block proposer.

• The whistleblower earns (7 / 8) * (slashed_validator_effective_balance / 512)
• The block proposer that includes the slashing attestation earns (1 / 8) * (slashed_validator_effective_balance / 512)

The End

Well, technically this is not the end of 0xB0B story as we are still in early phases of Ethereum 2.0, some changes will happen as Ethereum evolves to a 100% PoS network.

For example at the end of October 2021, the Altair hard fork will change various parameters of 0xB0B job:

• inactivity and slashing penalties will be set to higher values, before that penalties were “reduced” to encourage early participation to the network
• block proposer selection will be fairer, 0xB0B should expect to have 12.5% of his rewards from block proposal, whereas it is currently around 3% of his total rewards

Here are some useful links I used to write this post:

• Paper: Combining GHOST and Casper

• Ben Edgington’s notes on Attestation Data

• Ben Edgington’s notes on Attestation Deltas

• Beaconcha.in glossary

• Bitmex post on Ethereum PoS Rewards and Penalties

• Consensys post on Rewards on Phase 0