Metric: Validator Efficiency
Efficiency, a metric to measure validator performance
Last updated
Was this helpful?
Efficiency, a metric to measure validator performance
Last updated
Was this helpful?
The validator Efficiency metric is a comprehensive measure of validator performance, integrating multiple components:
This metric is designed to provide a holistic view of a validator's effectiveness. \
Validator efficiency can be calculated over an arbitrary timeframe. The longer the timeframe, the closer it is expected to approach the duty weighting as defined in the consensus layer specification. For shorter timeframes however (down to a single epoch), these values can vary significantly: A block proposal or sync committee participation can completely dominate the resulting efficiency in these cases.
In order to calculate the efficiency over multiple epochs correctly, the respective effective balance has to be factored in. To accomplish this, each individual value gets aggregated before calculating the percentage efficiency, instead of calculating the percentage for each epoch and averaging that.
Components of Efficiency\
84.4% (= 54/64) of validators' rewards come from attestations. Every epoch (~6.4 minutes), a validator proposes an attestation (vote) to the network.
These attestations contain valuable information about the consensus layer and are rewarded based on their correctness and inclusion delay.
An attestation consists of three votes:
- Head vote
- Source vote
- Target vote
If a validator votes correctly on all three and is included in the block with the best inclusion delay (1), the reward will be 100%, as good as it can be.
Block proposals are purely luck-based, but over the long run, 12.5% (8/64) of validators' rewards come from block proposals. Blocks include execution rewards (transaction rewards + MEV rewards) and scale with the number of attestations and sync committee outputs included in a block.
Comparing validator performance based on MEV rewards (which highly depend on market volatility) would not provide meaningful context. Thus, proposer efficiency solely depends on CL rewards. To remove some volatility from the result, the received proposal-related rewards are compared to the median proposal-related reward of surrounding proposals. Specifically, the surrounding 32 proposals (missing skipped, 0 if none) of each proposal are considered to be the the median proposal reward.
Primary reasons for using median instead of a calculated max:
Proposals can include attestations originally meant for other proposers, so the actual max reward attainable through attestation inclusion is higher than the one attainable during normal operation (which would be including attestations only meant for your slot)
It prevents offline/slashed validators from influencing the proposals efficiency. Long term (multi-block) sync committee or attester participation is mostly out of the control of the proposer, and by using the median we effectively remove participants that fail to vote more than 50% of the time. This leads to the following formula:
Every 256 epochs, 512 validators are elected to be part of the sync committee. Like block proposals, being part of a sync committee is purely luck-based. However, over the long run, 3.1% (2/64) of validators' rewards come from sync committee duties. With 500,000 validators, the expected time between being selected for sync committee duty is approximately 37 months. During this period, the rewards for sync committee members are significantly higher.
Compared to attestations, which occur once per epoch, sync duties occur in every slot for 256 epochs, totaling 8192 duties per sync committee member.
Since sync duties need to be included in a block by the block proposer, we ignore missed blocks that occurred during this period to avoid penalizing the sync committee member. Penalties from missed sync participation are also not counted towards sync_actualReward.
This leads to the following formula
When a validator has attestations, block proposals, and sync committees, the efficiency is calculated as:
When a validator did not participate in a sync committee and/or did not propose a block, the respective rewards & ideal rewards are set to 0
Conveniently, the returns the idealReward for a given epoch. The idealReward represents the maximum potential rewards based on optimal performance, which allows us to calculate attester efficiency. Negative rewards (penalties) from any of the 3 attestation components do not count towards attester_actualReward.