Amend simd-0123

[jstarry]

In the case of additional rewards, we move amounts from the vote account to the stake accounts. By the way, this will lead to writing all vote accounts every block (assuming the partition reward distribution is uniformly distributed), right?

I think it’s better to follow the approach of SIMD-0118, but we’ll have to use a sysvar for that (since capitalization is not increased). That is, in the first block of the epoch, record the reward distribution amounts by vote accounts into the sysvar data, and move that amount to the sysvar.

Originally posted by @dimandotsol in #123 (comment)

[jstarry]

@dimandotsol can you take a look now and see if the distribution section is easier to understand?

[dimandotsol]

@dimandotsol can you take a look now and see if the distribution section is easier to understand?

Looks great! Thank you!

[dimandotsol]

I noticed that lamports will remain on the sysvar balance due to integer division. Maybe it’s worth explicitly mentioning this?

In general, it’s fine, and how to handle it can be addressed later. But while reading, I had the following idea:

SysvarData {
  total_rewards: u64, // sum of all P
  total_distributed: u64,
  validators: [
    ValidatorRewardParams {
      vote_account: Pubkey,
      rewards: u64,       // P
      active_stake: u64,  // A
    }
  ]
}

And on each distribution block, increase total_distributed by the actual amount deducted.
At the end of the distribution, burn total_rewards - total_distributed.
(Technically, total_rewards isn’t necessary here, since it’s the sum of rewards in the validators array.)

[HaoranYi]

The idea sounds good to me intuitively. However, there are a few more details that need to be fleshed out.

1. If we clear pending_rewards from the vote accounts and only store the sum in sysvar in the 1st block, how do we recover the payout for each stake delegation later when distribution?
2. How do we handle restart during reward distribution? We need to recompute the payout for each delegation but the orignal pending_rewards on the vote accounts is not available?
3. If we store ValidatorRewardParams in sysvar, it will be too big ~hundreds of Mega bytes. That will be too big for a sysvar data. It seems like this is not a good option.
4. Have we considered the impact of computing all the stake delegation at the first block. Will this make the already-busy first bock even more busy?
5. If we do in the original way, pending_rewards in the vote account may change before we distribute the payout, because new block are played and rewards between first_epoch block till distribution block will be accumulated into pending_rewards. When we distribute, we will include the new rewards for current epoch?

[dimandotsol]

1. We’re adding this to the partitioned inflation rewards distribution algorithm that’s already working (SIMD-118):
   active_stake_from_stake_account * this_validator_reward_from_sysvar / this_validator_active_stake_from_sysvar
   (where active_stake_from_stake_account / this_validator_active_stake_from_sysvar is the share of a specific stake account in the additional rewards of the given validator)

2. We don’t need to do anything directly in this SIMD. SIMD-118 will continue to function, and so will we alongside it.

3. Only for ~2000 validators: 2000 * (32 + 8 + 8) + 8 (array length) (+ 8 or 16 with my idea above). So it's about 100 kilobytes.

4. Only a “transfer” of the amounts for distribution from vote accounts to the sysvar.

5. I’ve already forgotten, but I think the second field was proposed to be used there.