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%).
Rated v0 does not penalise effectiveness for orphaned blocks. This type of outcome is not controlled by the validator operator. Update [Epoch: 96750]: 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).
Phase 0 proposer effectiveness model
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:
Post-Merge adjustment
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 are introducing 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 behaviour. We have decided to penalise 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.
The calculation for proposer effectiveness therefore becomes:
Last updated