Version 2.0 [current]
Applicable from after the implementation of Timely Vote Credits from Epoch 703 (November 26, 2024) to present.
Components of Effectiveness
Proposer Effectiveness
Voting Effectiveness
In the following sections, we examine those one-by-one and then synthesize them together in what constitutes the effectiveness rating.
Proposer Effectiveness
Validators are expected to produce blocks of transactions. On Solana, the primary unit of time is an epoch which consists of 432,000 slots. Each slot has a target duration of around 400 milliseconds, which puts one epoch at 48 to 52 hours currently.
It is important to understand that in Solana, a slot presents an opportunity for a block to be produced by the selected leader (i.e. proposer) for that slot. A block is a batch of transactions produced by said leader. When blocks are not produced in slots, these slots are considered missed as the validator has failed to fulfill its duty to produce a block and advance the chain.
Another thing to note is that consensus messages by validators on Solana (i.e. votes) are propagated through transactions as well. These vote transactions are important when it comes to confirming the latest state of the chain, which we go deeper into in Voting Effectiveness. Given these are transactions as well, it is entirely possible for proposers to build blocks only containing vote transactions. These are perfectly valid blocks however this means that no user transactions were confirmed/executed for the time being which degrades the experience of end-users, and arguably goes against the main purpose of the chain.
Given this, we attribute scores to a validator’s proposer effectiveness based on the following:
A.1
Has end-user transactions
1
A.2
Only vote transactions
0.25
B
Missed
0
Case A.1
In this case, a block was produced, containing both end-user and vote transactions, in which case a full point is given for the proposer effectiveness ratio.
Case A.2
In this case, a block was produced but it only contains vote transactions (i.e. Vote Only Blocks). End-user transactions are not proposed which degrades the experience of the user.
Case B
Lastly, in this case no block is produced and the proposer has completely missed their block production duty. This gets no point.
Thus we compute the proposer effectiveness for a validator as:
Voting Effectiveness
Validators are called to vote for every observed block that is on the correct fork or what they perceive to be the correct state of the chain.
Forking occurs frequently on Solana due to the fast-paced nature of the network. When a validator is slow to produce a block X, the next validator may begin their allocated slot X+1 before it has received the previous block, therefore assuming it does not exist and building its block on top of the prior block X-1. This causes two competing forks both building on the ancestor X-1. The validator at X+2 will then determine which to continue building upon based on when it receives them. Most likely it will receive X first and continue on that and X+1 will end up being a dead fork and those slots will appear as skipped (i.e. missed).
A validator can only correctly vote for a slot with a block, and a confirmed fork means a slot that has more than ⅔ of stake voting on it. For every successful vote on a valid fork, the validator receives one credit which is used to compute the voting rewards at every epoch.
The second aspect of voting effectiveness is vote latency. As mentioned earlier, voting on Solana occurs through onchain transactions. The earliest a validator can vote for a slot is immediately the slot after and the latest they can do so is 512 slots after.
Vote latency is the slot distance between the slot being voted for and the slot where the vote transaction lands. This impacts the speed of achieving consensus as it affects the time it takes to reach the ⅔ stake threshold needed to confirm a block. To incentivize timeliness, the protocol rewards validators based on latency accordingly.
A validator that correctly votes within two (2) slots for the slot it is voting for will get the maximum 16 vote credits. For every slot that a validator delays its vote, it gets one (1) less vote credit, until such that it can only the minimum of one (1). This means that at 18 slots of worth of latency or more, as long as a validator's vote is correct and is no later than 512 slots, it gets the minimum vote credit.
As such we assign a vote_score for every correct vote based on the vote credits it receives. We then multiply the total number of confirmed blocks by 16 to get the maximum possible vote credits such that the voting effectiveness rating is:
Effectiveness Rating
In order to come up with a unified validator effectiveness score, we combine proposer effectiveness and voting effectiveness in a weighted average. We attribute the following weights to each component based on the distribution of rewards using the most recent data from Solana:
Proposer Effectiveness: 30%
Voting Effectiveness: 70%
Such that the formula becomes:
If a particular validator has not been assigned a particular duty for a given time period, we only take the effectiveness of whatever duty they were assigned with and had a chance to fulfil. Example is when a validator has not been assigned a block production duty for a given period. In this case, effectiveness == voting effectiveness.
We remain open to inputs from the community on how to best capture the effectiveness of a validator on Solana. Head on over to our forum to share your thoughts.
Last updated