RAVER v2.1
Applicable to the Altair upgrade of the Ethereum Beacon Chain spanning from epoch 96750 to epoch 146874.
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%).
Orphaned blocks are now treated as missed proposals. It is quite often the proposer's fault that a block has been orphaned (either the proposer node is out of sync and builds a block on top of an older block, or it produces the new block too late and the next proposer uses an earlier parent).
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
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.
Attester effectiveness formula
The Altair upgrade brought on a few significant changes in how rewards and penalties tied to attestation duties are distributed in the consensus layer. More specifically, the rules governing the timing of when the vote material gets included on-chain and rewards/penalties relationship have become stricter. In RAVER 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 RAVER to reflect the new rules that underlie participation and correctness. However, we have not changed the way the overall attester effectiveness calculation is computed in the spirit of maintaining the design goals initially set.
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.
Sync committees
With the Altair Beacon Chain upgrade, a new role for validator nodes was introduced: attesting to sync committees. These are duties related to enabling light clients to validate the Beacon Chain’s state. A light client only needs to know a previously validated block header and members of the previous, current and next committee to verify the beacon state.
A sync committee is a group of 512 randomly selected validators, chosen anew every 256 epochs. This committee signs block headers for each new slot in the beacon chain so that a light client can trust these headers to represent accurate and validated blocks.
Granted the stochastic nature of sync committee selection and the low probability of a single validator to be selected in a sync committee set, we are not including sync committee performance in the RAVER.
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:
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.
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