Rework DepositDelegatorRewards to only include VAT paying vote accounts

[joncinque]

Problem

SIMD-0123 originally included a new instruction that anyone could call to deposit delegator rewards into a vote account. Lamports deposited with this instruction are included during the block revenue sharing mechanism described in SIMD-0123.

This instruction will be removed as part of the Alpenglow adaptations.

All vote accounts with pending delegator rewards must be swept during the first block of a new epoch, requiring an update to all vote accounts with pending delegator lamports.

It's possible for an attacker to create many vote accounts and deposit small amounts of lamports into them, causing the runtime more work at epoch rollover.

Proposed Solution

Keep the instruction as is, but add one more requirement: the target vote account must have paid VAT for the current epoch.

We can achieve this behavior by passing the RewardEpochDelegatedStakes account, which is updated at every epoch boundary during Alpenglow's reward payout process.

The instruction must check that the target vote address is present in the RewardEpochDelegatedStakes account. If it isn't, return InstructionError::InvalidArgument.

Alternatives Considered

Instead, check that the target vote account is present in the leader schedule for the current epoch.

This option, however, requires having the leader schedule in the runtime, which requires more extensive plumbing for both Agave and Firedancer.

Also, since SIMD-0123 uses VAT payment as a required criterion for block reward distribution, it's more consistent to also gate the DepositDelegatorRewards instruction on VAT payment.

cc @0x0ece @topointon-jump @buffalojoec

[buffalojoec]

All vote accounts with pending delegator rewards must be swept during the first block of a new epoch, requiring an update to all vote accounts with pending delegator lamports.

The RewardEpochDelegatedStakes approach is elegant, so I won't block, but I'm curious why we can't just change this on the sweep side? Couldn't we just leave the program instruction alone and only do sweeps and distributions to VAT-paying accounts?

[joncinque]

It's definitely an option, but there's a few drawbacks in my mind.

There's a potential footgun -- if I create a vote account and call DepositDelegatorRewards on it, it becomes impossible for me to close that account without paying the VAT, so that the runtime sweeps those lamports. Since the VAT is higher than the rent exempt lamports, I'll just end up leaving the account.

Next, we run into the issue we discussed during the SIMD-0123 sweep implementation. It's possible to stack up some amount of delegator lamports in the vote account, that aren't touched until the VAT is eventually paid. Those would get burned, or distributed to whoever happens to be staked at the time.

I think the proposed approach makes it easier to keep the chain clean, since all vote accounts still get swept, and removes a footgun, since people can't accidentally strand lamports in vote accounts.

[buffalojoec]

There's a potential footgun -- if I create a vote account and call DepositDelegatorRewards on it, it becomes impossible for me to close that account without paying the VAT, so that the runtime sweeps those lamports. Since the VAT is higher than the rent exempt lamports, I'll just end up leaving the account.

Yeah I thought about this case, too, but I didn't think it was a big deal.

Next, we run into the issue we discussed during the SIMD-0123 sweep implementation. It's possible to stack up some amount of delegator lamports in the vote account, that aren't touched until the VAT is eventually paid. Those would get burned, or distributed to whoever happens to be staked at the time.

This is probably the more annoying one IMO - the wrong distributions of stakers getting rewards meant for other stakers.

I'm fine with the suggested approach!