It's important that validators vote as quickly as possible, because the delay between a block being produced and being confirmed directly impacts end user experience. An end user submits a transaction to be processed and waits for confirmation. If validators are slow to vote, then this confirmation takes longer to happen, and Solana appears to be slower. Because Solana's primary purpose is to be a high performance transaction processing network, confirmation times are very important, and so validators should be voting as quickly as possible.
Vote latency is measured as the difference between the slot number of the block being voted on, and the slot number of the block in which the validator's vote appears. For example:
If a validator sees a block for slot 100, validates it, and sends out a vote on that block, and then that vote "lands" in the block in slot 103, then the latency of that vote is 103 - 100 = 3.
Note that the minimum possible latency is 1, because the earliest block that a vote can appear in is the one right after the block being voted on.
A validator sends out roughly 375,000 votes per epoch on average. The vote latency of all of those votes
are added together and divided by the total number of votes to compute the average vote latency for that
validator.
Percent Low Latency Votes
A "Low Latency Vote" (abbreviated as LLV) is one that has a vote latency of 1 or 2. This is an arbitrary
threshold that was chosen because data analysis over a large number of epochs shows that most validators can
land votes with latency 1 or 2 most of the time. Therefore, votes with latency 1 or 2 are considered "low
latency votes".
For every validator, the percentage of votes cast which have vote latency 1 or 2 is computed as the "Percent Low Latency Votes".
Percent Consensus Votes
Every vote cast by a validator adds to the sum total of stake weight that has voted for that block. A block
is confirmed at the moment that 2/3 of stake weighted votes on that block have occurred. Any validator that
votes on the block after that is not contributing to consensus on that block, since consensus has already
been achieved.
When a validator votes on a block before 2/3 of stake weight has already voted on it, that vote has real meaning because it's actually pushing the block closer to consensus. A vote that arrives before the block has already been confirmed is called a "Consensus Vote" (abbreviated CV).
On average, with all other factors being equal, about 66% of a validator's votes should be Consensus Votes; if the order that votes arrive is not skewed in favor of any validator, then all validators will have about a 2/3 chance that their votes will arrive before consensus has been reached.
For the purposes of this list, the data collection examines every vote cast by the validator and determines
whether it arrived before or after consensus was achieved on the voted-on block. The percentage of votes
that arrive before consensus was already achieved is computed as the "Percent Consensus Votes" for that
validator.
Vote Only
Validators not only vote on blocks, they also produce blocks during the slots in which that validator is the
leader. Validators should produce high-quality blocks that include user transactions as well as votes.
However, it is possible for validators to be mis-configured in ways that prevent them from including any user transactions in their blocks. This is bad for Solana as it delays all end-user transactions from being processed during those slots. Since leaders get four slots in a row, and a slot takes roughly half a second, every time a Vote Only (abbreviated VO) validator is leader, there is a minimum two second delay in transaction processing in Solana.
Validators who are misconfigured in this way and do not ever include user transactions in their blocks are designated Vote Only validators.
The following thresholds are then computed from these values:
Threshold_VL: Cluster-wide average vote latency + 1/2 standard deviation. If this value is less than 2.5,
then 2.5 is used.
Threshold_LLV: Cluster-wide average percent low latency votes - 1/2 standard deviation. If this value is greater than 85.0%, then 85.0% is used.
Threshold_CV: Cluster-wide average percent consensus votes - 1/2 standard deviation. If this value is less than 50.0%, then 50.0% is used.
Any validator whose computed values violate any one of these thresholds, or is vote-only, is included in the poor performers list.
Rationale for these thresholds:
Data analysis over a long period of time has shown that the "best performing validators" almost always have Vote Latency < 1.5, so giving a full 1 slot grace to establish a minimum of 2.5 average vote latency for this list seems fair.
Similar data analysis shows that the best performers have Percent Low Latency Votes of 94% or higher. So setting a lower limit of 85% for this metric also seems fair.
For Consensus Votes, it has been noted that some validators who otherwise perform well can have CV that dips down into lower values, well into the 50s. The reasons for this are not entirely known but it makes sense that if a validator's votes are just "slightly slow" then CV is the metric that will suffer first. So a maximum of 50% for this metric has been established in order to ensure that no one ends on this list because of very minor performance issues.
Vote-only just isn't tolerable at any time since there is literally no reason for any validator to operate in this mode, so it's always going to be a reason for ending up on the list.
When the cluster as a whole has a large number of poor performing validators, the thresholds will be "less severe" because of the policies described above. As the poor performers improve their performance, the cluster averages will get closer to optimal performance, and the criteria for ending up on this list will become stricter, up to the limits described earlier.