Attester effectiveness
Validators are called to attest once in every epoch. These attestations are important consensus material. When attesting, validators vote on their version of the perceived state of the chain, which is described by a handful of distinct variables. These variables are also known as a validator's duties.
When validators perform their duties appropriately, they earn rewards; if they don't they are penalized. The core duties that validators are called to perform are:
Getting a vote (1) included; this is equivalent to submitting a the Casper FFG source checkpoint vote that is correct.
Getting a (2) correct vote included. Correctness is described by:
Head vote: submitting an attestation that correctly identifies the head of the chain, by GHOST rules
Target vote: submitting an attestation that correctly identifies the Casper FFG target checkpoint of the chain
Getting a correct vote included (3) with minimal delay.
Every validator is assigned a slot “n” to attest to in every epoch, and the earliest their vote could be included is on slot n+1. For every slot greater than n+1 that the vote gets included, the validator earns increasingly less rewards.
You can refer to Rewards and Penalties on Ethereum 2.0 [Phase 0] for more context on how rewards are distributed in eth2 pre-Altair.
Phase 0 attester effectiveness model
We measure (1) as participation rate, (2) correctness and (3) as inclusion delay. These are calculated as:
Participation rate: total amount of attestations included over the number of epochs active.
Correctness: amount of correct head and target votes over the sum of votes included.
Inclusion delay: aggregate slot distance between the attestation slots attributed and the actual slots the votes were included in.
Given the above, we compute attester effectiveness as follows:
The premise in the above calculation is that we can it captures equally all the important elements in evaluating how well a validator's consensus duties are being performed, accurately, while at the same time shielding the methodology from unnecessary complexity.
Altair upgrade
The Altair upgrade brought on a few significant changes in how rewards and penalties tied to attestation duties are distributed in eth2. More specifically, the rules governing the timing that the vote material gets included on-chain and rewards/penalties relationship, become stricter. In Rated v0 terms:
Participation rate: in order for an attestation to be included the source vote must still be correct. There are now additional penalties for cases when the attestation does not get included in a timely manner; namely within
sqrt(EPOCH_LENGTH)
or 5 slots. This however does not affect how we calculate participation.Correctness: the target and head votes must not only be correct, but also need to be included in a timely manner; namely within
EPOCH_LENGTH
or 32 slots and 1 slot respectively. We also bundle source vote lateness (by the above criteria) in the correctness calculation. In this case we look at events in a binary way (prompt, late) and do not modulate for "how late" in the calculation.Inclusion delay: The concept of moderating rewards downwards the more delayed the attestations are is not valid any longer on its own accord, and is rather feeding directly into participation and correctness
We have updated the Rated v0 model to reflect the new rules that underlie participation and correctness. However, we haven't changed the way the overall attester effectiveness calculation is computed, in the spirit of maintaining the design goals we initially set.
We welcome the community's feedback on whether or not the inclusion delay moderating factor should be removed from the model post-Altair.
Join the discussion here
While the way the components are computed and attributed value, the base formula for attester effectiveness post-Altair remains the same:
Bellatrix & Merge upgrades
No significant changes have been introduced to the spec that would warrant revisiting the attester effectiveness methodology.
Last updated