# Dev Update #3
Hi,
Since my [last update](https://hackmd.io/@lODlsf2CR9uWlyIyEdjjPQ/SkSBLnG7i), I have focused mainly on *two* things:
1. **Visualizing data** on [my dashboard](https://kevinbogner-data-analysis-consensus-clients-app-lz484x.streamlitapp.com/).
2. Optimizing the **data fetching process**.
However, since it’s a dashboard based on consensus clients, it would only be logical to display the rewards paid on the consensus side. Today there is no resource to access the consensus client block rewards. Therefore, I will work on *reward calculation APIs* to the [beacon-APIs standard](https://ethereum.github.io/beacon-APIs/). The design and implementation will be done on the consensus client, [*Lighthouse*](https://github.com/sigp/lighthouse).
[Michael Sproul](https://github.com/michaelsproul) already created an [*issue*](https://github.com/sigp/lighthouse/issues/3661) regarding this topic. *This* development update will be based on the issue, so if you want to grasp everything, check out the issue first.
The source for the information about rewards is [Ben Edgington's](https://twitter.com/benjaminion_xyz) excellent book [Upgrading Ethereum](https://eth2book.info/bellatrix/). *This* development update is not meant to be complete but only highlights the relevant areas for continuing to work on the issue. I aim to provide some background information about validator rewards for people struggling with the terminology, like me.
*Quick overview of my EPF journey so far:*
## Beacon API
The [Ethereum beacon-APIs](https://github.com/ethereum/beacon-APIs) is a collection of RESTful APIs and aims to *enhance interoperability* across beacon node implementations.
## Incentivize validators through rewards
In the beacon chain, validators are rewarded for behaving according to the protocol. [*Altair*](https://github.com/ethereum/consensus-specs/tree/dev/specs/altair), the first upgrade of the beacon chain, redefined the way of allocating rewards and penalties. There are *three* main activities for validators:
1. Making **attestations**, which consist of three votes, each vote can be rewarded if they are subject to the conditions:
- voting for a *source* checkpoint,
- voting for a *target* checkpoint,
- voting for a chain *head* block.
2. **Proposing blocks** in the beacon chain.
3. Participating in **sync committees**.
A validator can expect to gain rewards for the attestations *regularly* because they happen every epoch. In contrast, the proposed block and participation in sync committees are selected randomly. *Long-term*, the reward distribution for a validator looks like the following.
```vega
{
"$schema": "https://vega.github.io/schema/vega-lite/v5.json",
"description": "Validator rewards distribution",
"height":500,
"width":630,
"data": {
"values": [
{"Name": "Source - Attestation 21.9%", "Percentage": 21.9},
{"Name": "Target - Attestation 40.6%", "Percentage": 40.6},
{"Name": "Head - Attestation 21.9%", "Percentage": 21.9},
{"Name": "Sync reward 3.1%", "Percentage": 3.1},
{"Name": "Proposer 12.5%", "Percentage": 12.5}
]
},
"encoding": {
"theta": {"field": "Percentage", "type": "quantitative", "stack": true},
"color": {"field": "Name", "type": "nominal", "legend": null}
},
"layer": [{
"mark": {"type": "arc", "outerRadius":180}
}, {
"mark": {"type": "text", "radius":250},
"encoding": {
"text": {"field": "Name", "type": "nominal"}
}
}]
}
```
Additionally, block proposers can be further rewarded if they *report violations* of the slashing rules. This rarely happens and isn't included in the pie chart, but it is still relevant for building the API. Now that I've broken down the validator rewards, I want to look into the reward's parts in detail and later bridge the gap for the API. I *won't* be looking into proposer rewards because the API is from the perspective of a proposer.
### Attestations
Making attestation is the most significant portion of validators' rewards, with 84.4%. Active validators are selected to make *one* attestation per epoch.
Attesting validators are rewarded when they fulfill the following *two* conditions:
1. *Correctness* - In this context, correct means that the attester has the same view of the blockchain as the block proposer.
2. *Timeliness* - Head votes older than one slot, target votes older than 32 slots, and source votes older than five slots are *not* rewarded.
As mentioned earlier, Altair also redefined the penalty mechanics. Attestations are penalized for missing, being late, or being incorrect.
### Sync committees
Once every 256 epochs, 512 validators are selected to form the sync committee. The group gets rewarded for signing every beacon chain header.
With 500,000 validators, the expected interval between being part of the sync committee is around 36 months. [Pintail](https://twitter.com/pintail_xyz) offers in an article about the [impact of Altair](https://pintail.xyz/posts/modelling-the-impact-of-altair/#sync-committees) a handy formula for calculating the probability of being selected for the sync committee.
```python
SECONDS_PER_SLOT = 12
SLOTS_PER_EPOCH = 32
EPOCHS_PER_COMMITTEE = 256
COMMITTEE_SIZE = 512
SECONDS_PER_YEAR = 31556952
seconds_per_committee = SECONDS_PER_SLOT * SLOTS_PER_EPOCH * EPOCHS_PER_COMMITTEE
committees_per_year = SECONDS_PER_YEAR / seconds_per_committee
print(f"{committees_per_year:.1f} sync committees are selected each year")
NUM_VALIDATORS = 500000
expected_committee_selections_per_year = committees_per_year * COMMITTEE_SIZE / NUM_VALIDATORS
print(f"with a validator set of {NUM_VALIDATORS} validators, on average each validator will be assigned "
f"to a sync committee {expected_committee_selections_per_year:.2f} times per year")
```
output:
```
321.0 sync committees are selected each year
with a validator set of 500000 validators, on average each validator will be assigned to a sync committee 0.33 times per year
```
Sync committee members are penalized for signing the *wrong* head block (in this context, wrong from the proposer's view) or not showing up at all.
### Reporting a slashing
The evidence to verify slashings and take action is included in a beacon block. Therefore validators are incentivized to have such proofs in a block. Mainly there are *two* slashing violations that validators can report and earn rewards for:
1. *Proposer slashing* is a report of a proposer slashing violation that slashes only one validator.
2. *Attester slashing* is a report of an attestation slashing violation that can simultaneously slash up to an entire sync committee.
Now that we have covered the reward structure, we want to apply the knowledge to the API issue.
## Current State
Currently, there are *three* Lighthouse APIs that are somewhat related to reward data:
1. [`/lighthouse/validator_inclusion/{epoch}/{validator_id}`](https://lighthouse-book.sigmaprime.io/validator-inclusion.html#individual)
2. `/lighthouse/analysis/attestation_performance/{validator_id}`
3. [`/lighthouse/analysis/block_rewards`](https://lighthouse-book.sigmaprime.io/api-lighthouse.html#lighthouseanalysisblock_rewards)
In the following, I'm looking more into the three APIs to analyze the information they provide.
### [`/lighthouse/validator_inclusion/{epoch}/{validator_id}`](https://lighthouse-book.sigmaprime.io/validator-inclusion.html#individual)
```bash
curl -X GET "http://localhost:5052/lighthouse/validator_inclusion/0/42" -H "accept: application/json" | jq
```
```bash
{
"data": {
"is_slashed": false,
"is_withdrawable_in_current_epoch": false,
"is_active_unslashed_in_current_epoch": true,
"is_active_unslashed_in_previous_epoch": true,
"current_epoch_effective_balance_gwei": 32000000000,
"is_current_epoch_target_attester": false,
"is_previous_epoch_target_attester": false,
"is_previous_epoch_head_attester": false
}
}
```
The relevant data from this API is information about the attestation but *only* about the matching of *target* and *head* votes. There is no information about the third attestation component, source votes, and reward amounts.
### `/lighthouse/analysis/attestation_performance/{validator_id}`
```bash
curl "http://localhost:5052/lighthouse/analysis/block_rewards?start_slot=10&end_slot=10"
```
```bash
[
{
"total": 1466675,
"block_root": "0x1e9fba478d3993e5ba1e06e5b27a9596f492906285aa8fac4a39eb38f06bde17",
"meta": {
"slot": "10",
"parent_slot": "9",
"proposer_index": 2268,
"graffiti": ""
},
"attestation_rewards": {
"total": 1466675,
"prev_epoch_total": 0,
"curr_epoch_total": 1466675,
"per_attestation_rewards": [
{
"3585": 2465,
..
"16133": 2465
},
{
"14723": 2465,
..
"17531": 2465
},
{
"4175": 2465,
..
"6407": 2465
},
{
"9532": 2465,
..
"20436": 2465
},
{},
{
"3920": 2465,
..
"2809": 2465
},
{
"16068": 2465
},
{},
{
"2303": 2465
}
]
},
"sync_committee_rewards": 0
}
]
```
Compared to the API before, this one *includes source* votes information but still lacks data about reward amounts.
### [`/lighthouse/analysis/block_rewards`](https://lighthouse-book.sigmaprime.io/api-lighthouse.html#lighthouseanalysisblock_rewards)
```bash
curl "http://localhost:5052/lighthouse/analysis/block_rewards?start_slot=1&end_slot=32" | jq
```
```bash
[
{
"block_root": "0x51576c2fcf0ab68d7d93c65e6828e620efbb391730511ffa35584d6c30e51410",
"attestation_rewards": {
"total": 4941156,
},
..
},
..
]
```
The last API currently *includes attestation* and *sync committee rewards*. However, it is missing the reward for reporting a slashing. Furthermore, the data might be slightly incorrect when validators get slashed.
## To be continued
There is still more information in the [issue](https://github.com/sigp/lighthouse/issues/3661), namely *two design questions* and *implementation considerations*. However, those are more technical, and I will focus on these in the future dev update once I dig deeper into the code.
Sign in with Wallet
Connect another wallet