Sync Committee Rewards

Since the Altair hard fork, the Ethereum network has introduced the idea of sync committees, a group of 512 randomly selected validators who sign new block headers every slot. These headers can be used by light clients to trust which blocks have been validated without the need to fully download and process the beacon chain.

During the 256 epochs (8192 slots) a validator is participating in a sync committee, it receives an extra reward: the sync committee reward. Like the Proposer Reward, it is added at the state transition  of every slot, not at the epoch processing. After 256 epochs, the list of validators in the sync committee is refreshed.

For every slot in which a validator correctly participates in the sync committee (by signing the new block headers and sharing this information with the other participants of the sync committee), its balance will be immediately updated at that slot. However, if the validator does not participate correctly it will suffer a penalty.

Obtained Sync Cpmmittee Reward

As previously explained, sync committee rewards are applied at state transition. Therefore, if we are measuring sync committee rewards for epoch 10, we can calculate the balance difference of validators between the last slot of epoch 9 and the last slot of epoch 10. For example, if we calculate the balance difference between the last slot of epoch 10 and the last slot of epoch 11, we would see:

• Attestation rewards referring to epoch 9.

• Proposer rewards referring to epoch 11.

• Sync Committee rewards referring to epoch 11.

Maximum Sync Cpmmittee Reward

Sync committee rewards are applied by slot. As the reward is fixed during the whole epoch, it is easy to think that the maximum sync committee reward in an epoch for a given validator can be computed by multiplying the slot reward by 32 (slots in an epoch)However, before doing any calculations we must first:

• Ensure that the validator is included in the sync committee for the given epoch.

• Do not count missed blocks in the epoch

• If there is a missed block then no sync aggregate would be processed in that slot, thus, the validator would not get the fixed reward for this slot. Once again, we are trying to understand the best possible scenario for the tasks that a single validator is responsible for, not any external dependencies (like the block proposer).

So, in order to calculate the maximum sync committee reward for a validator in a given epoch, we must first calculate how many missed blocks there were in the epoch. To do this, we can use the array of block roots contained in the   beacon state.

The Block Roots array  contains the list of hashes for the last 8192 blocks. When a block is missed, there is no hash to add to the list and, therefore, the previous one is duplicated. This means that, if the block hash in slot 5000 is the same as the one in slot 4999, then we can say that no validator proposed a block at slot 5000. Otherwise, there would be a different hash as a result of a new block. Once we have the list of proposed blocks we can calculate the maximum sync committee reward by applying the following computation (See Sync Committee Reward Details  to find out how to calculate the participant_reward):

max_sync_committee_reward = (32 - len(missed_blocks)) * participant_reward