RAVER v1.0
Applicable to Phase 0 of the Ethereum Beacon Chain spanning from epoch 1 to epoch 74239.
Components of RAVER
Validator performance in Ethereum PoS is largely described by 2 core activity centers. These are:
Proposal effectiveness
Attestation effectiveness
In the following sections, we examine those one-by-one and then synthesise them together in what constitutes the RAVER.
Proposer effectiveness
A block proposer is a validator that is chosen to pack the attestation information together and commit the block to the chain. There is one proposer per slot and 32 per epoch. Given their work is critical, the reward that they earn for successfully proposing a block is disproportionate to any given attester’s reward in an epoch.
Being elected as a proposer has a much lower probability attached to it (32/active_validators), compared to a validator’s attestation duties (which is 100%).
The RAVER does not penalize effectiveness for orphaned blocks. This type of outcome is not controlled by the validator operator.
Proposer effectiveness formula
We calculate proposer effectiveness simply as the ratio that expresses how many times a validator has successfully proposed a block out of the times that they were awarded proposer duties:
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 do not, they are penalized. The core duties that validators are called to perform are:
Getting a vote (1) included; this is equivalent to submitting a Casper FFG, which makes the final decision on which blocks are and are not a part of the chain.
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
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.
Attester effectiveness formula
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 it equally and accurately captures all the important elements in evaluating how well a validator's consensus duties are being performed while at the same time shielding the methodology from unnecessary complexity.
Effectiveness rating
In order to come up with a unified validator effectiveness score, we combine proposer and attester effectiveness in a weighted average. We attribute the following weights to each, guided by the longer term expectation of rewards distribution between the two duties:
Proposer effectiveness: 1/8
Attester effectiveness: 7/8
Attributions of proposer slots are much rarer than attestation duties but bear a significantly higher reward if performed correctly. On average and over a long time period, a validator’s consensus layer rewards will be split between proposer and attester rewards at a ratio of 1:7. We have selected the respective probability weights to reflect that distribution.
Given the above, we calculate validator effectiveness as:
RAVER across time
The base unit of account in terms of time in the Rated DB is the “day”. What we have defined as “day” is the 24 hour increment post Beacon Chain genesis, which is further defined as X MANY epochs.
While Rated also produces an “hourly” effectiveness calculation (definition of the “hour” follows similar form to that of “day”) to power different features, the “day” is the main unit of account.
In order for the hourly and daily effectiveness of a given validator index to be computed, we aggregate the sum of duties a validator index has been allocated and apply the RAVER methodology, as outlined in the sections above.
Thereafter, in order to calculate validator effectiveness over periods that span multiple days (e.g. a month), we average across the “daily” effectiveness scores produced. This implies that for any given 30 day period, we would compute the RAVER off the sum of duties for the 30 discrete daily increments in that window, and then average across those.
RAVER at the operator level
As mentioned earlier in the documentation, the RAVER for Ethereum PoS is computed at the validator index level. In aggregating upwards to the operator level (defined as a group of validator indices), we simply compute the average RAVER of those keys, such that:
While this produces a robust enough outcome and has clear benefits in the simplicity that it comes with, the approach was chosen for practical purposes and has been bound to some path dependency.
Content on this page is subject to License described in the Content License.
Last updated