Integrate Inflation Model with MASP Burn and Mint

[murisi]

MASP burn and mint currently distributes rewards to stakeholders that are a constant proportion of their asset holdings. These constant proportions are given in a function called masp_rewards in shared/src/types/address.rs. We now need to distribute rewards in accordance with the formulas in: https://github.com/anoma/specs/blob/9f30359d39f77487e02ea021c9815785026c1d1b/src/architecture/economics/inflation-system.md . Modifying masp_rewards to return computed proportions instead of constants might be one way to achieve this.

If the masp_rewards function is modified to achieve this goal, then note that for a given asset type its denominator must not change otherwise certain values in the rewards computations won't cancel properly. Also note that the current code assumes that the reward for an interval is the sum of the rewards of its parts and that historical reward conversions won't be changed in future.

[cwgoes]

@mariari I think you're doing this already?

[mariari]

@mariari I think you're doing this already?

Yes I'm handling it in the https://github.com/anoma/namada/tree/mariari/inflation-rewards branch

It's based on the work by @brentstone in #714

[cwgoes]

If the masp_rewards function is modified to achieve this goal, then note that for a given asset type its denominator must not change otherwise certain values in the rewards computations won't cancel properly. Also note that the current code assumes that the reward for an interval is the sum of the rewards of its parts and that historical reward conversions won't be changed in future.

OK; then we should use a very high denominator, so that we can start with a high numerator and decrease it in the case of reward rates decreasing. We should pick a fixed range of ratios which we can cover with a specific fixed denominator.

Historical reward conversions will not be changed in the future, and the reward for an interval is indeed the sum of the rewards of its parts (the only thing the PD controller changes anyways is the current reward rate).

[murisi]

@cwgoes Exactly - relatively high denominators will work. Note also that we can only give rewards when the client owns a quantity of an asset that exceeds the denominator (because AllowedConversions are more like ratios than fractions). So we must not make the denominator so large that a client cannot get rewarded for owning non-large quantities of assets. I do not believe this will be a problem in practice because we internally use micro-units: 2BTC is stored internally as 2*(10^6).