Problem:
Due to unreliability in landing transactions in epoch 598 (when chain was super congested), about half of active validators did not get a single ValidatorHistoryEntry created, so their epoch credits were never copied over in future epochs. This is bad for Stakenet scoring, and this issue could happen in the future if congestion gets bad again.
Solution:
In the CopyVoteAccount instruction, when epochs are detected in the vote account that don't exist in the CircBuf, insert those new entries and shift all entries with greater epochs forward by one. This will evict the oldest entries if we are wrapping around. After that, epoch credits are copied to the old entries. We will then be able to retroactively call:
CopyTipDistributionAccount and UpdateStakeHistory on those validators.
Notes:
We are still within the 64 epoch vote credit range, so epoch credits from 598 and any other randomly skipped entries will get added
In the most extreme case possible of 64 entries inserted (max epochs in vote account), this instruction uses ~270k CUs. Most of the time none will be added, and when this first runs, a handful will be added for some validators. Normal CU usage is <30k.
Problem: Due to unreliability in landing transactions in epoch 598 (when chain was super congested), about half of active validators did not get a single ValidatorHistoryEntry created, so their epoch credits were never copied over in future epochs. This is bad for Stakenet scoring, and this issue could happen in the future if congestion gets bad again.
Solution: In the CopyVoteAccount instruction, when epochs are detected in the vote account that don't exist in the CircBuf, insert those new entries and shift all entries with greater epochs forward by one. This will evict the oldest entries if we are wrapping around. After that, epoch credits are copied to the old entries. We will then be able to retroactively call:
CopyTipDistributionAccountandUpdateStakeHistoryon those validators.Notes: