RAVER v3.0 [current]
Applicable to the Altair upgrade of the Ethereum Beacon Chain spanning from epoch 146875 to present.
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 formula
In post-Merge Ethereum, validators have the responsibility of not only proposing valid blocks that contain all the consensus messages that help advance and finalize the chain, but they also have to facilitate the production of execution layer (EL) blocks that contain user transactions. Validators earn from these proposed blocks through priority fees and MEV.
This transition means that not only has the balance of rewards between proposal duties and attestation duties changed, but also signals a transition to validator “prime-time”, which is really them fulfilling the duty of helping secure value being transacted on the EL.
Given the above, we have introduced a series of changes in the way Proposer Effectiveness is measured at Rated.
For the purpose of the exercise, we look at the world of proposer effectiveness in two parallel tracks (CL and EL), and attribute different scores to different cases. We first provide the summary table that outlines the different cases, with a brief discussion to follow.
| Case | CL | EL | score |
|---|---|---|---|
A.1 | proposed | proposed | 1 |
A.2 | proposed | empty | 0.25 |
B | missed | missed | 0 |
Case A.1
In this case the block is proposed as per usual, containing both transactions and attestations, in which case there is a full marginal contribution to the proposer effectiveness ratio.
Case A.2
In this case the block is proposed “normally” from a consensus layer standpoint, but there are no transactions packed inside it. We have observed about 0.1% of the post-Merge blocks to exhibit this behavior. We have decided to penalize the EL failure disproportionately, as we view this as the reason why validators exist, and have opted for 0.25 points (instead of 0.5).
Case B
In this case the block is wholly missed, yielding 0 points to the validator.
Orphaned blocks are 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: 3/8
Attester effectiveness: 5/8
Post-Merge, proposal duties carry a lot more weight overall. This is not only because there is now a significant proportion of the overall yield that comes from successful proposals, but because missed proposals also mean delaying transaction processing for real users and billions of USD in value (EL), apart from not helping the chain progress (CL).
What we have observed thus far is that on-balance, execution to consensus layer rewards come at a 1:4 ratio. We expect that ratio to become even more balanced over time for the following reasons:
More active validators on the Beacon Chain crowd out CL APR%
More adoption of MEV Relays and out-of-protocol PBS boost overall EL APR%
Given the above, we introduce the following amendments to the weights of the effectiveness rating components, post-Merge:
Proposer effectiveness: 1/8 → 3/8
Attester effectiveness: 7/8 → 5/8
Such that the formula becomes:
If a validator has not been assigned any proposer duties, we only take their attester effectiveness into consideration in calculating their effectiveness rating, such that validator_effectiveness == attester_effectiveness. We do this so that we do not artificially inflate the overall score.
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.
In version 3.1 of the RAVER, we are exploring transitioning to “per duty” fidelity. This implies that while the calculation would be the same, at the multi-day period level, the duties that make up attester and proposer effectiveness would be aggregated, and the completion rate of those duties would be computed in the aggregate, between two arbitrary epoch boundaries. This helps inject more robustness in accounting for varying times of validator index activation, and an easier to replicate methodology.
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.
In version 3.1 of the RAVER, we are exploring transitioning to “per duty” fidelity, at the operator level. This implies that while the calculation would be the same, at the operator level, the duties that make up attester and proposer effectiveness would be aggregated, and the completion rate of those duties would be computed in the aggregate. This helps inject more robustness in accounting for varying times of validator index activation in a larger set.
Content on this page is subject to License described in the Content License.
Last updated