Hard limit reward allocations according to a piecewise linear curve

[aliXsed]

Design

Enforcing Nodle's tokenomics which dictates there should ever be 21B NODLs minted at a rate that is not going to exceed the following curve here, we need to embed a piecewise linear throttle into our allocations pallet. Initially we wouldn't need to make this curve configurable and potentially we may decide we never do that. However even if we make it configurable, this configuration would be through an extrinsic limited to a root level privileged entity.

Implementation Notes

• We would need a pretty reliable notion of time. The relay chain's block number is an option on which the vesting schedules pallet is relying. The advantage of that approach is simplicity and relative stability. Polkadot relay chain has been very well stable around 6s for a block. However the disadvantage is that in the case, Polkadot adjust their pace, it would impact our plans too. Here we may need to do some research to see if we could have a better option.
• To put a cap on the number of the configuration points for the curve we can go with yearly linear pieces and plan for say 20 years.
• We can allow up to a day volume of allowed mint to happen in one allocation batch.
• If the network hasn't minted enough according to the curve, we should still limit how much it can be minted in a single day. This is a security consideration. To achieve this, any quota for minting that hasn't been fulfilled for more than a day should be considered as lost.

[ETeissonniere]

This is great, a few questions below:

• I am assuming we'd have a rolling window to ensure we never allocate more than we should over 24hrs. Is that correct?
• The last bullet is very important, I'd be very much interested in @nodlflow7's thoughts here. Would we do this, we'd need to track it since it would effectively decreased our maximum supply, which is a stat we need to keep our eyes on.

[nodlflow7]

My views here:

• On 1) the notion of time, it seems to me that it is the best approach. This is the approach chosen by the two largest blockchains if I am not mistaken. PoW chains use this and while it is not 100% accurate, over many years, this is reasonably good. I personally like this approach because it is not based on anything external to the chain.
• On 4) I believe the network should mint until the supply has reached its maximum. Every attempts to mint above should be rejected by the network participants (invalid reward).

[ETeissonniere]

On 1) the notion of time, it seems to me that it is the best approach. This is the approach chosen by the two largest blockchains if I am not mistaken. PoW chains use this and while it is not 100% accurate, over many years, this is reasonably good. I personally like this approach because it is not based on anything external to the chain.

Agreed, using the relay chain's blocks is probably the most stable solution at this stage. Our Parachain blocks suffer too much latency right now, other parachains had similar issues.

[aliXsed]

My views here:

• On 1) the notion of time, it seems to me that it is the best approach. This is the approach chosen by the two largest blockchains if I am not mistaken. PoW chains use this and while it is not 100% accurate, over many years, this is reasonably good. I personally like this approach because it is not based on anything external to the chain.
• On 4) I believe the network should mint until the supply has reached its maximum. Every attempts to mint above should be rejected by the network participants (invalid reward).

@nodlflow7 the suggested limitation in point 4 is for the case, our allocations oracle has been minting lower than what it was allowed to do for a while. the suggestion is for extra security and to contain any adversary we don't allow the quota to be accumulated and usable in short period of time.