Estimate multiplier points per epoch to account for MP inconsistencies

[0x-r4bbit]

Contents copied from: https://notes.status.im/lNd8kcVmQEWcDYEldpl26Q

On StakeManager, accounts need to be processed every epoch.

When an account is processed, it gets Multiplier Points. An account can get Multiplier Points until it reaches a BOOST_LIMIT. BOOST_LIMIT is _stake * MAX_BOOST

The increase on each account MPs also incrases the total supply of MPs.

To distribute rewards, the formula uses total supply of MPs: ((userBalance + userMultipliers) / (epochTotalBalance + epochTotalMultipliers)) * epochReward

The increase on MPs impact how epochReward is calculated, as for every account processed, the next epoch would have more MPs.

Additionally, the total MPs gets inconstient for future epochs, in a scenario where many accounts didnt processed, it could happen that a past epoch have more MPs than the epoch after it, it would be possible to hard to do in current architecture.

The best solution would be to be able to predict how much MPs would be minted by the end of the epoch.

1. Estimate total MPs generated on epoch, based on total accounts total staked - stake-on-limit reached a) Work on formula which uses (balanceSupply - balanceOnCap ) ((MP_APY / YEAR) epochTimeSize) to predict and use it as epochTotalMultipliers. Add another storage balanceOnCap that is changed when account balance change, which reflects a value used to correct estimation balanceOnCap = "incremented when an account reaches CAP" Passes on the problem further as it would only know when account reaches CAP when is processed. b) use (balanceSupply ) ((MP_APY / YEAR) * timeSinceEpoch0+EPOCH_SIZE) to predict and use it as epochTotalMultipliers. while each account is processed, correct the amount of totalMultipliers, when an account reaches the cap, reduce from epochSupply. Makes incentive to wait to process, as lastest account to process get more2.
2. Change contract requirements: a) Require users to process all accounts before rewarding b) Require users to process all accounts before processing epoch c) Remove MAX_BOOST dynamic d) Similar to a), b), but instead penalize that dont process in time by not giving any MPs. e) give incentives to third-party process late accounts before deadline, needs a) or b). f) Late process would get MPs in latest epoch, but in past epochs it wont count for rewards.

[0x-r4bbit]

@3esmit I've taken the contents of the document you've created (thanks for that btw!) and created this issue here so we can track its state accordingly.

I understand that this is quite a big task, especially considering that we'll need at least some unit/e2e tests that show satisfying scenarios.

We can break this down further if necessary.

[3esmit]

Depends on #51

I started doing the changes as I have in my mind, but then I had the issue #51 as a blocker. This is needed because this changes will update this logic, and it also should be clear what changed. Currently it would be unclear what would be changed because its currently unclear what current behavior is, and if it was working, changing it could break it.

[0x-r4bbit]

Thanks for the update, will have a look at #51