Dynamic Inflation

[Dinonard]

Pull Request Summary

Introduces a new pallet, pallet-reward-distribution, to provide a dynamic way of distributing block rewards. The idea is to have reward distribution parametrized and configurable via root-only call. This is different from current situation since if we want to modify anything, we need to do an runtime upgrade.

TODO

• [x] initial implementation (for getting feedback)
• [x] benchmarks
• [x] documentation
• [x] unit tests
• [x] initial reward config genesis?
• [x] test with real runtime
• [x] adapt dapps-staking public interface
• [x] merge (or remove?) block-reward pallet

Check list

• [ ] contains breaking changes
• [x] adds new feature
• [x] modifies existing feature (bug fix or improvements)
• [ ] relies on other tasks
• [x] documentation changes
• [x] tests and/or benchmarks are included
• [ ] changed API client type definition or chain metadata

[akru]

In general I feel that this pallet should replace block-reward pallet, we don't need to have many pallet that handle rewards, it's difficult to track reward path. So, instead of distribution on runtime code scope let's delegate distribution to dedicated pallet with fine tuned config.

One suggestion, instead of beneficiary trait why don't use pallet config types for reward beneficiaries, like type DappStakingDevelopers: OnImbalance<Balance>;

[Dinonard]

In general I feel that this pallet should replace block-reward pallet, we don't need to have many pallet that handle rewards, it's difficult to track reward path. So, instead of distribution on runtime code scope let's delegate distribution to dedicated pallet with fine tuned config.

One suggestion, instead of beneficiary trait why don't use pallet config types for reward beneficiaries, like type DappStakingDevelopers: OnImbalance<Balance>;

That sounds ok - I was thinking the same thing but wanted to avoid doing it initially in order to keep the change smaller. Let's have a single pallet for handling block-reward then. :+1:

For the Beneficiaries trait, my main motivation was to avoid having 3 small structs which implement OnImbalanced trait in the runtimes - instead I opted for a single trait which would enforce a single struct to implement all required functions. Do you think it's better to have 3 than 1? I don't really mind tbh, just thought it would look cleaner with 1.