This book contains the Polkadot Fellowship Requests for Comments (RFCs) detailing proposed changes to the technical implementation of the Polkadot network.
polkadot-fellows/RFCs
(source)
Table of Contents
This RFC proposes a new pallet_inflation to be added to the Polkadot runtime, which improves -inflation machinery of the Polkadot relay chain in a number of ways:
pallet_inflation
The existing inflation logic in the relay chain suffers from a number of drawbacks:
Event
This RFC, as iterated above, proposes a new pallet_inflation that addresses all of the named -problems. However, this RFC does not propose any changes to the actual inflation rate, but -rather provide a new technical substrate (pun intended), upon which token holders can decide on the -future of the DOT token's inflation in a more clear and transparent way.
We argue that one reason why the inflation rate of Polkadot has not significantly change in ~4 years -has been the complicated process of updating it. We hope that with the tools provided in this RFC, -stakeholders can experiment with the inflation rate in a more ergonomic way. Finally, this -experimentation can be considered useful as a final step toward fixing the economics of DOT in JAM, -as proposed in the JAM graypaper.
Within the scope of this RFC, we suggest deploying the new inflation pallet in a backwards -compatible way, such that the inflation model does not change in practice, and leave the actual -changes to the token holders and researchers and further governance proposals.
-While mainly intended for Polkadot, the system proposed in this RFC is general enough such that it -can be interpreted as a "general inflation system pallet", and can be used in newly onboarding -parachain. -
While mainly intended for Polkadot, the system proposed in this RFC is general enough such that it -can be interpreted as a "general inflation system pallet", and can be used in newly onboarding -parachain.
This RFC is relevant to the following stakeholders, listed from high to low impact:
First, let's further elaborate on the existing order. The current inflation logic is deeply nested -in pallet_staking, and pallet_staking::Config::EraPayout interface. Through this trait, the -staking pallet is informed how many new tokens should possibly be minted. This amount is divided -into two parts:
pallet_staking
pallet_staking::Config::EraPayout
pallet_staking::Config::RewardRemainder
As it stands now the implementation of EraPayout which specifies the two amounts above lives in -the respective runtime, and uses the original proposed inflation rate proposed by W3F for Polkadot. -Read more about this model here.
EraPayout
At present, the inflation always happens at the end of an era, which is a concept know by the -staking system. The duration of an era is recorded in pallet_staking as milliseconds (as recorded -by the standard pallet_timestamp), is passed to EraPayout as an input, as is measured against -the full year to determine how much should be inflated.
pallet_timestamp
-The naming used in this section is tentative, based on a WIP implementation, and subject to change -before finalization of this RFC. -
The naming used in this section is tentative, based on a WIP implementation, and subject to change -before finalization of this RFC.
The new order splits the process for inflation into two steps:
In very abstract terms, an example of the above process can be:
i
A proper configuration of this pallet should use pallet_parameters where possible to allow for any -of the actual values used to specify Sourcing and Distribution to be changed via on-chain -governance. Please see the example configurations section for more -details.
pallet_parameters
Sourcing
Distribution
In the new model, inflation can happen at any point in time. Since now a new pallet is dedicated to -inflation, and it can internally store the timestamp of the last inflation point, and always inflate -the correct amount. This means that while the duration of a staking era is 1 day, the inflation -process can happen eg. every hour. The opposite is also possible, although more complicated: The -staking/treasury system can possibly receive their corresponding income on a weekly basis, while the -era duration is still 1 day. That being said, we don't recommend using this flexibility as it brings -no clear advantage, and is only extra complexity. We recommend the inflation to still happen shortly -before the end of the staking era. This means that if the inflation sourcing or distribution is -a function of the staking rate, it can reliably use the staking rate of the last era.
sourcing
distribution
Finally, as noted above, this RFC implies a new accounting system for staking to keep track of its -staking reward. In short, the new process is as follows: pallet_inflation will mint the staking -portion of inflation directly into a key-less account controlled by pallet_staking. At the end of -each era, pallet_staking will inspect this account, and move whatever amount is paid out into it -to another key-less account associated with the era number. The actual payouts, initiated by stakers, -will transfer from this era account into the corresponding stakers' account.
-Interestingly, this means that any account can possibly contribute to staking rewards by -transferring DOTs to the key-less parent account controlled by the staking system. -
Interestingly, this means that any account can possibly contribute to staking rewards by -transferring DOTs to the key-less parent account controlled by the staking system.
A candidate implementation of this RFC can be found in -this -branch of the polkadot-sdk repository. Please note the changes to:
polkadot-sdk
substrate/frame/inflation
substrate/frame/staking
substrate/bin/runtime
The following are working examples from the above implementation candidate, highlighting some of the -outcomes that can be achieved.
First, to parameterize the existing proposed implementation to replicate what Polkadot does today, -assuming we incorporate the fixed 2% treasury income, the outcome would be:
#![allow(unused)] -fn main() { -parameter_types! { - pub Distribution: Vec<pallet_inflation::DistributionStep<Runtime>> = vec![ - // 2% goes to treasury, no questions asked. - Box::new(pay::<Runtime, TreasuryAccount, dynamic_params::staking::FixedTreasuryIncome>), - // from whatever is left, staking gets all the rest, based on the staking rate. - Box::new(polkadot_staking_income::< - Runtime, - dynamic_params::staking::IdealStakingRate, - dynamic_params::staking::Falloff, - StakingIncomeAccount - >), - // Burn anything that is left. - Box::new(burn::<Runtime, All>), - ]; -} - -impl pallet_inflation::Config for Runtime { - /// Fixed 10% annual inflation. - type InflationSource = - pallet_inflation::FixedRatioAnnualInflation<Runtime, dynamic_params::staking::MaxInflation>; - type Distribution = Distribution; -} -}
In this snippet, we use a number of components provided by pallet_inflation, namely pay, -polkadot_staking_income, burn and FixedRatioAnnualInflation. Yet, crucially, these components -are fed parameters that are all backed by an instance of the pallet_parameters, namely everything -prefixed by dynamic_params.
pay
polkadot_staking_income
burn
FixedRatioAnnualInflation
dynamic_params
The above is a purely inflationary system. If one wants to change the inflation to -dis-inflationary, another pre-made component of pallet_inflation can be used:
impl pallet_inflation::Config for Runtime { -- /// Fixed 10% annual inflation. -- type InflationSource = -- pallet_inflation::FixedRatioAnnualInflation<Runtime, dynamic_params::staking::MaxInflation>; -+ type InflationSource = pallet_inflation::FixedAnnualInflation< -+ Runtime, -+ dynamic_params::staking::FixedAnnualInflationAmount, -+ >; -} -
Whereby FixedAnnualInflationAmount is the fixed absolute value (as opposed to ratio) by -which the chain inflates annually, for example 100m DOTs.
FixedAnnualInflationAmount
The following drawbacks are noted:
The new pallet_inflation, among its integration into pallet_staking must be thoroughly audited -and reviewed by fellows. We also emphasize on simulating the actual inflation logic using the real -polkadot state with Chopsticks and try-runtime.
The proposed system in this RFC implies a handful of extra storage reads and writes "per inflation -cycle", but given that a reasonable instance of this pallet would probably decide to inflation eg. -once per day, the performance impact is negligible.
The drawback section above noted some ergonomic concerns.
The "New Order" section above notes the compatibility notes with the existing staking -and inflation system.
This proposes to require a slashable deposit in the broker pallet when initially purchasing or renewing Bulk Coretime or Instantaneous Coretime cores.
Additionally, it proposes to record a reputational status based on the behavior of the purchaser, as it relates to their use of Kusama Coretime cores that they purchase, and to possibly reserve a proportion of the cores for prospective purchasers that have an on-chain identity.
There are sales of Kusama Coretime cores that are scheduled to occur later this month by Coretime Marketplace Lastic.xyz initially in limited quantities, and potentially also by RegionX in future that is subject to their Polkadot referendum #582. This poses a risk in that some Kusama Coretime core purchasers may buy Kusama Coretime cores when they have no intention of actually placing a workload on them or leasing them out, which would prevent those that wish to purchase and actually use Kusama Coretime cores from being able to use any at cores at all.
Reputation. To disincentivise certain behaviours, a reputational status indicator could be used to record the historic behavior of the purchaser and whether on-chain judgement has determined they have adequately rectified that behaviour, as it relates to their usage of Kusama Coretime cores that they purchase.
The slashable deposit if set too high, may result in an economic impact, where less Kusama Coretime core sales are purchased.
Lack of a slashable deposit in the Broker pallet is a security concern, since it exposes Kusama Coretime sales to potential abuse.
Reserving a proportion of Kusama Coretime sales cores for those with on-chain identities should not be to the exclusion of accounts that wish to remain anonymous or cause cores to be wasted unnecessarily. As such, if cores that are reserved for on-chain identities remain unsold then they should be released to anonymous accounts that are on a waiting list.
No implementation pitfalls have been identified.
It should improve performance as it reduces the potential for state bloat since there is less risk of undesirable Kusama Coretime sales activity that would be apparent with no requirement for a slashable deposit or there being no reputational risk to purchasers that waste or misuse Kusama Coretime cores.
The solution proposes to minimize the risk of some Kusama Coretime cores not even being used or leased to perform any tasks at all.
The mechanism for setting a slashable deposit amount, should avoid undue complexity for users.
Updates to Polkadot.js Apps, API and its documentation and those referring to it may be required.
No prior articles.
None
This RFC proposes a new pallet_inflation to be added to the Polkadot runtime, which improves +inflation machinery of the Polkadot relay chain in a number of ways:
This RFC, as iterated above, proposes a new pallet_inflation that addresses all of the named +problems. However, this RFC does not propose any changes to the actual inflation rate, but +rather provide a new technical substrate (pun intended), upon which token holders can decide on the +future of the DOT token's inflation in a more clear and transparent way.
We argue that one reason why the inflation rate of Polkadot has not significantly change in ~4 years +has been the complicated process of updating it. We hope that with the tools provided in this RFC, +stakeholders can experiment with the inflation rate in a more ergonomic way. Finally, this +experimentation can be considered useful as a final step toward fixing the economics of DOT in JAM, +as proposed in the JAM graypaper.
Within the scope of this RFC, we suggest deploying the new inflation pallet in a backwards +compatible way, such that the inflation model does not change in practice, and leave the actual +changes to the token holders and researchers and further governance proposals.
+While mainly intended for Polkadot, the system proposed in this RFC is general enough such that it +can be interpreted as a "general inflation system pallet", and can be used in newly onboarding +parachain. +
While mainly intended for Polkadot, the system proposed in this RFC is general enough such that it +can be interpreted as a "general inflation system pallet", and can be used in newly onboarding +parachain.
First, let's further elaborate on the existing order. The current inflation logic is deeply nested +in pallet_staking, and pallet_staking::Config::EraPayout interface. Through this trait, the +staking pallet is informed how many new tokens should possibly be minted. This amount is divided +into two parts:
As it stands now the implementation of EraPayout which specifies the two amounts above lives in +the respective runtime, and uses the original proposed inflation rate proposed by W3F for Polkadot. +Read more about this model here.
At present, the inflation always happens at the end of an era, which is a concept know by the +staking system. The duration of an era is recorded in pallet_staking as milliseconds (as recorded +by the standard pallet_timestamp), is passed to EraPayout as an input, as is measured against +the full year to determine how much should be inflated.
+The naming used in this section is tentative, based on a WIP implementation, and subject to change +before finalization of this RFC. +
The naming used in this section is tentative, based on a WIP implementation, and subject to change +before finalization of this RFC.
A proper configuration of this pallet should use pallet_parameters where possible to allow for any +of the actual values used to specify Sourcing and Distribution to be changed via on-chain +governance. Please see the example configurations section for more +details.
In the new model, inflation can happen at any point in time. Since now a new pallet is dedicated to +inflation, and it can internally store the timestamp of the last inflation point, and always inflate +the correct amount. This means that while the duration of a staking era is 1 day, the inflation +process can happen eg. every hour. The opposite is also possible, although more complicated: The +staking/treasury system can possibly receive their corresponding income on a weekly basis, while the +era duration is still 1 day. That being said, we don't recommend using this flexibility as it brings +no clear advantage, and is only extra complexity. We recommend the inflation to still happen shortly +before the end of the staking era. This means that if the inflation sourcing or distribution is +a function of the staking rate, it can reliably use the staking rate of the last era.
Finally, as noted above, this RFC implies a new accounting system for staking to keep track of its +staking reward. In short, the new process is as follows: pallet_inflation will mint the staking +portion of inflation directly into a key-less account controlled by pallet_staking. At the end of +each era, pallet_staking will inspect this account, and move whatever amount is paid out into it +to another key-less account associated with the era number. The actual payouts, initiated by stakers, +will transfer from this era account into the corresponding stakers' account.
+Interestingly, this means that any account can possibly contribute to staking rewards by +transferring DOTs to the key-less parent account controlled by the staking system. +
Interestingly, this means that any account can possibly contribute to staking rewards by +transferring DOTs to the key-less parent account controlled by the staking system.
A candidate implementation of this RFC can be found in +this +branch of the polkadot-sdk repository. Please note the changes to:
The following are working examples from the above implementation candidate, highlighting some of the +outcomes that can be achieved.
First, to parameterize the existing proposed implementation to replicate what Polkadot does today, +assuming we incorporate the fixed 2% treasury income, the outcome would be:
#![allow(unused)] +fn main() { +parameter_types! { + pub Distribution: Vec<pallet_inflation::DistributionStep<Runtime>> = vec![ + // 2% goes to treasury, no questions asked. + Box::new(pay::<Runtime, TreasuryAccount, dynamic_params::staking::FixedTreasuryIncome>), + // from whatever is left, staking gets all the rest, based on the staking rate. + Box::new(polkadot_staking_income::< + Runtime, + dynamic_params::staking::IdealStakingRate, + dynamic_params::staking::Falloff, + StakingIncomeAccount + >), + // Burn anything that is left. + Box::new(burn::<Runtime, All>), + ]; +} + +impl pallet_inflation::Config for Runtime { + /// Fixed 10% annual inflation. + type InflationSource = + pallet_inflation::FixedRatioAnnualInflation<Runtime, dynamic_params::staking::MaxInflation>; + type Distribution = Distribution; +} +}
In this snippet, we use a number of components provided by pallet_inflation, namely pay, +polkadot_staking_income, burn and FixedRatioAnnualInflation. Yet, crucially, these components +are fed parameters that are all backed by an instance of the pallet_parameters, namely everything +prefixed by dynamic_params.
The above is a purely inflationary system. If one wants to change the inflation to +dis-inflationary, another pre-made component of pallet_inflation can be used:
impl pallet_inflation::Config for Runtime { +- /// Fixed 10% annual inflation. +- type InflationSource = +- pallet_inflation::FixedRatioAnnualInflation<Runtime, dynamic_params::staking::MaxInflation>; ++ type InflationSource = pallet_inflation::FixedAnnualInflation< ++ Runtime, ++ dynamic_params::staking::FixedAnnualInflationAmount, ++ >; +} +
Whereby FixedAnnualInflationAmount is the fixed absolute value (as opposed to ratio) by +which the chain inflates annually, for example 100m DOTs.
The new pallet_inflation, among its integration into pallet_staking must be thoroughly audited +and reviewed by fellows. We also emphasize on simulating the actual inflation logic using the real +polkadot state with Chopsticks and try-runtime.
The proposed system in this RFC implies a handful of extra storage reads and writes "per inflation +cycle", but given that a reasonable instance of this pallet would probably decide to inflation eg. +once per day, the performance impact is negligible.
The "New Order" section above notes the compatibility notes with the existing staking +and inflation system.