feat: limit allocations to targeted supply inflation

[aliXsed]

The mint curve limiter is just an upper bound enforced for security and commitment to Nodle's tokenomics. The actual mint depends on the allocation oracles and the community's growth and participation.

Note 1: to find out what does Perbill::from_perthousand(1) as an inflation rate step for Eden mean, you need to do the following calculation:
Suppose the total issuance at the beginning of that quarter is around 8.4B NODLs. Then the allowed increase on the supply would be as follows 8.4B * 0.001 = 8.4M. Since the fiscal period for Eden's configuration is based on 90 days. Then 8.4M increase is for that period. The actual limit is applied on a session period which is now configured as 1 day. This means on a 24 hr window, the allocations shouldn't exceed 8.4M / 90 = 93,333

Note 2: Time periods are configured based on the relay chain block numbers and an assumption that they come around every 6 seconds.

Note 3: The starting block of the curve will be the relay chain block number right after the runtime upgrade. It means right after the upgrade we will be at the beginning of the fiscal period 0. However with a root permission, it's possible to set the starting block number in a way that the chain fiscal period aligns with an external fiscal period. This also allows the curve to go in a different inflation step. Obviously it's a sensitive config that's only granted to Root.

Note 4: When the curve starting block is configured to a be a block in the future, then the very first inflation step will be used for calculations before that time.

Note 5: Regardless of how we configure the inflation steps, the limiter wouldn't allow the total issuance to exceed 21B coins.

Note 6: The supply inflation rate after the configured steps would simply follow the last step or lower when approaching the 21B maximum supply. which with the current configuration means, we'd approach the 21B maximum supply with a rate equal or lower than 0.1%.

[codecov]

Codecov Report

Merging #667 (784a4a5) into master (cc8122d) will decrease coverage by 0.36%.
The diff coverage is 83.33%.

❗ Current head 784a4a5 differs from pull request most recent head 738ca0c. Consider uploading reports for the commit 738ca0c to get more accurate results

@@            Coverage Diff             @@
##           master     #667      +/-   ##
==========================================
- Coverage   89.96%   89.60%   -0.37%     
==========================================
  Files          33       33              
  Lines        6181     6515     +334     
==========================================
+ Hits         5561     5838     +277     
- Misses        620      677      +57     

Impacted Files	Coverage Δ
runtimes/eden/src/constants.rs	87.50% <ø> (ø)
runtimes/eden/src/pallets_nodle.rs	0.00% <0.00%> (ø)
pallets/allocations/src/lib.rs	86.27% <86.15%> (-1.54%)	⬇️
pallets/allocations/src/benchmarking.rs	96.42% <100.00%> (+3.09%)	⬆️
pallets/allocations/src/tests.rs	98.55% <100.00%> (+4.70%)	⬆️

Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.

[ETeissonniere]

One minor comment. I am also curious as to when would the fiscal period start (date wise). Would it make sense to make it follow the fiscal quarters? If so, we might need to enforce it when deploying.

[aliXsed]

One minor comment. I am also curious as to when would the fiscal period start (date wise). Would it make sense to make it follow the fiscal quarters? If so, we might need to enforce it when deploying.

@ETeissonniere the very first fiscal period starts at block number 0. With the current configuration it would actually follow the fiscal quarters (takes about 90 days or 648000 blocks). The first time we'd see the event SessionQuotaCalculated would be in the block right after the upgrade (because it's enforced for the case there hasn't been any previous calculations). Then the next time we will see that would be in the block 1296000.

[ETeissonniere]

@aliXsed so I think we are looking at about a month difference from a chain fiscal quarter VS a company fiscal quarter. Correct?

[aliXsed]

@aliXsed so I think we are looking at about a month difference from a chain fiscal quarter VS a company fiscal quarter. Correct?

@ETeissonniere correct. Now I see your point. Do you want a root level extrinsic to bring the start of a quarter forward?

[ETeissonniere]

@aliXsed yeah, unless we can make it follow our own quarters as we deploy the upgrade

[aliXsed]

@aliXsed yeah, unless we can make it follow our own quarters as we deploy the upgrade

@ETeissonniere I have added a root level extrinsic that allows the root to set the curve starting block number. We should however remember that for Eden the relay chain block number should be used for this purpose.

[ETeissonniere]

@aliXsed after checking the code I am wondering if it wouldn't be cleaner to simply set it during the migration that would be called when we deploy the upgrade?

[aliXsed]

@aliXsed after checking the code I am wondering if it wouldn't be cleaner to simply set it during the migration that would be called when we deploy the upgrade?

@ETeissonniere there is a warning in the doc for on_runtime_upgrade which says:

This function will be called before we initialized any runtime state, aka on_initialize wasn't called yet. So, information like the block number and any other block local data are not accessible.

We need to know the block number to set the curve starting block. That made me uncomfortable to take that approach. I think we can do some optimisations later without breaking anything.