Solana: Consider removing StakeInstruction::RedeemVoteCredits

Created on 16 Jan 2020 · 8Comments · Source: solana-labs/solana

RedeemVoteCredits has a number of problems:

Somebody must issue this instruction every MAX_EPOCH_CREDITS_HISTORY epochs for each stake/vote account or rewards evaporate.
Reward point values are computed based on the latest epoch, which can produce confusing and hard to understand results as this example from TdS DR6 shows:
After the first 24 hours of idling, redeeming votes
using a ~1 SOL stake produced ~6221 SOL in voter rewards. Redeeming
that same stake 12 hours later produced ~54 SOL in voter rewards. The reason
for this huge reward drop is because the total stake increased from 435 SOL to 25695
SOL in those 12 hours, so the credit point value was much smaller.
The stake/vote accounts/programs as well as runtime contains code/data bloat that exists only to enable RedeemVoteCredits in its current form.

The first two points highlight the unintentional game that will be played around RedeemVoteCredits: if you see observe stake decreasing in the cluster than you're better off delaying RedeemVoteCredits if possible to capitalize on the increasing credit point value. But don't delay too long or you'll lost it all. Worse, RedeemVoteCredits can be run by anybody so others can inflict less desirable credit point values on you.

The alternative is to dispense of RedeemVoteCredits entirely, and have banks automatically redeem vote credits at the end of each epoch for all parties.

Source