Timely Vote Credits (TVC) on Solana: SIMD O33

Solana Validator rewards now depend on something new: TIMING.

With the introduction of SIMD 033, timely vote credits ensure validators are incentivized to vote promptly, making the network more efficient and fair.

SIMD 033: Timely Vote Credits on Solana banner design
SIMD 033: Timely Vote Credits on Solana

Already implemented on Firedancer and Anza, this update brings a fresh layer of accountability. But before we look into the specifics of SIMD 033, let’s take a moment to revisit how rewards work on Solana.

Solana Validator Rewards

Validators are the backbone of the Solana network. They are tasked with securing the blockchain, validating transactions, and maintaining network consensus. They earn rewards through protocol-defined inflation-based incentives and transaction fees. This short article will focus on inflation-based remuneration.

At the end of each epoch—approximately two days—$SOL tokens are distributed among validators based on two factors: the number of vote credits they have accumulated and the amount of stake delegated to them.

**Do note that the inflation rate of Solana’s native token, $SOL, gradually decreases over time.

What Are Votes in Solana?

Votes represent a validator’s confirmation that a specific block has been verified and is valid. By casting a vote, validators lock in their support for that block, committing not to vote for any conflicting forks (or chain of transactions) during a specified lockout period. This lockout mechanism ensures consistency and integrity within the network.

What Are Vote Credits?

Vote credits (VC) are used to incentivize validators for their participation in the network. Whenever a block a validator voted on becomes part of the finalized chain (also known as the “root”), the validator earns one vote credit (before TVC). These credits directly influence the inflation rewards validators receive at the end of each epoch, making them a crucial metric for validator performance.

What Happens to Invalid Votes?

If a validator casts votes on blocks that fail to become part of the finalized chain—due to consensus failure or their association with an invalid fork—those votes are rendered invalid and do not earn any vote credits.

What Defines a Timely Vote?

Before TVC, a vote was considered “timely” if it was cast within 500 slots of the block’s production. Beyond this limit, the slot history would no longer be accessible, and vote credits could not be awarded. Additionally, a vote had to be on a slot newer than any previously voted-on slot for that validator.

On average, validators exhibited a vote latency of 4 slots, with the majority voting within 3 to 4 slots of a block’s production. Such votes were classified as timely and qualified for vote credits, reflecting a relatively efficient voting process in most cases.

Challenges in the Previous Vote Credit Allocation Process

Despite Solana’s high speed, inefficiencies existed in the vote credit allocation mechanism due to validators’ behavior. Two key issues undermined the system’s efficiency:

Vote Lagging

Some validators intentionally delayed their votes to observe the consensus behavior of other validators. This practice, known as vote lagging, allowed them to minimize the risk of voting incorrectly and losing credits due to the lockout period.

Backfilling

Validators sometimes attempted to cast votes on missed slots after finalization, a process referred to as backfilling. This does no good for consensus.

Validators who lagged votes had an unfair advantage, as they could strategically wait for additional consensus information while still earning the same rewards as those who voted promptly. Both of these behaviors compromised the timeliness and efficiency of the network.

Primary Motivation Behind Timely Vote Credits

Under the old system, validators who delayed their votes could earn the same amount of credits as those who voted promptly, creating an imbalance in incentives.

The timely vote credit system was introduced to address the above-mentioned inefficiencies. Its primary goal is to incentivize validators to cast their votes as quickly as possible, discouraging deliberate delays and fostering faster block finalization.

Solution

The new system addresses this issue by introducing a latency-based credit adjustment. Therefore, votes cast closer to the relevant block receive higher credits, while those cast later earn progressively fewer credits.

Technical Implementations of Timely Vote Credits

Validators are now rewarded based on how closely their votes align with block production. Votes cast within a defined “grace period” of 2 slots, approximately 1 second, earn the maximum credits.

Flowchart of Solana Timely Vote Credits Process
Flowchart of Solana Timely Vote Credits

This grace period ensures that network latencies and geographical distances do not penalize well-behaved validators unnecessarily. Validators voting beyond this 2-slot grace period experience a gradual reduction in credits, determined by a credit reduction factor that decreases rewards with each additional slot of latency. However, to ensure fairness, a minimum reward of 1 credit is maintained even for delayed votes.

This mechanism prevents validators with extreme latencies, often due to legitimate reasons such as geographical distance, from being completely excluded from rewards.

With Timely Vote Credits delayed votes result in significantly reduced credits, removing the incentive to lag votes. This adjustment promotes active participation by encouraging validators to cast their votes promptly, thereby speeding up block finalization and maintaining the overall health of the network.

New Calculation for Timely Vote Credits (TVC)

Vote latency is calculated based on the difference between the timestamp of a vote and the block it corresponds to. This slot-based calculation ensures that votes cast within the grace period, corresponding to 1-2 slots, receive full credits.

A barchart showcases how timely vote credits (tvc) gets reduced by latency in validator votes on Solana.
Barchart: Vote Credits Awarded by Vote Latency

As the latency increases beyond the grace period, the credits decrease gradually. Importantly, even votes on older blocks, though delayed, still earn reduced credits. This approach acknowledges the effort of validators in contributing to the network, even when faced with high latency or other challenges.

Data Backing

The implementation of these changes leverages historical voting data and empirical analysis to optimize parameters such as the grace period and credit reduction factor. A 2-slot grace period was identified as the optimal threshold to minimize the impact on well-behaved validators while encouraging performance improvements.

Now, the maximum allowable latency for timely votes is 2 slots, or roughly 1000 milliseconds.

Technical Updates

Updates have been made to Solana’s CLI and tooling to support these changes. The CLI now displays vote latencies for each vote, enabling validators to monitor their performance in real-time.

The rollout of these changes follows a phased implementation process to ensure a smooth transition. In the first phase, the new VoteStateVersion is introduced but remains disabled. In the second phase, once the feature is enabled, validators need to update their vote accounts to the new structure, and also have a rent-exempt minimum of 0.0270744 SOL (new requirement). These updates allow validators to record and process vote latency data, which is critical for the new credit calculation mechanism.

Conclusion

Timely Vote Credits encourage timely votes while discouraging vote lagging. By addressing geographical diversity, network latency, and intentional delays, the updated system promotes active validator participation, enhances block finalization, and ensures the long-term health of the network. So, validators who adapt to these changes effectively will benefit from optimized rewards while contributing to the network’s overall performance and stability.

References

Leave a Comment