diff --git a/404.html b/404.html index a1e6d22..85ef19d 100644 --- a/404.html +++ b/404.html @@ -91,7 +91,7 @@ diff --git a/approved/0001-agile-coretime.html b/approved/0001-agile-coretime.html index e48ed13..45d1754 100644 --- a/approved/0001-agile-coretime.html +++ b/approved/0001-agile-coretime.html @@ -90,7 +90,7 @@ diff --git a/approved/0005-coretime-interface.html b/approved/0005-coretime-interface.html index 02ae743..6b87f48 100644 --- a/approved/0005-coretime-interface.html +++ b/approved/0005-coretime-interface.html @@ -90,7 +90,7 @@ diff --git a/approved/0007-system-collator-selection.html b/approved/0007-system-collator-selection.html index c8d4c71..43868b5 100644 --- a/approved/0007-system-collator-selection.html +++ b/approved/0007-system-collator-selection.html @@ -90,7 +90,7 @@ diff --git a/approved/0008-parachain-bootnodes-dht.html b/approved/0008-parachain-bootnodes-dht.html index e4aba2f..6b70e7e 100644 --- a/approved/0008-parachain-bootnodes-dht.html +++ b/approved/0008-parachain-bootnodes-dht.html @@ -90,7 +90,7 @@ diff --git a/approved/0010-burn-coretime-revenue.html b/approved/0010-burn-coretime-revenue.html index 6d1f515..0a1bce1 100644 --- a/approved/0010-burn-coretime-revenue.html +++ b/approved/0010-burn-coretime-revenue.html @@ -90,7 +90,7 @@ diff --git a/approved/0012-process-for-adding-new-collectives.html b/approved/0012-process-for-adding-new-collectives.html index c4b25bc..c21e83b 100644 --- a/approved/0012-process-for-adding-new-collectives.html +++ b/approved/0012-process-for-adding-new-collectives.html @@ -90,7 +90,7 @@ diff --git a/approved/0013-prepare-blockbuilder-and-core-runtime-apis-for-mbms.html b/approved/0013-prepare-blockbuilder-and-core-runtime-apis-for-mbms.html index 947e25c..2c0b1a7 100644 --- a/approved/0013-prepare-blockbuilder-and-core-runtime-apis-for-mbms.html +++ b/approved/0013-prepare-blockbuilder-and-core-runtime-apis-for-mbms.html @@ -90,7 +90,7 @@ diff --git a/approved/0014-improve-locking-mechanism-for-parachains.html b/approved/0014-improve-locking-mechanism-for-parachains.html index 77fd7a6..0fe1fab 100644 --- a/approved/0014-improve-locking-mechanism-for-parachains.html +++ b/approved/0014-improve-locking-mechanism-for-parachains.html @@ -90,7 +90,7 @@ diff --git a/approved/0022-adopt-encointer-runtime.html b/approved/0022-adopt-encointer-runtime.html index 1be77b8..f07fb1f 100644 --- a/approved/0022-adopt-encointer-runtime.html +++ b/approved/0022-adopt-encointer-runtime.html @@ -90,7 +90,7 @@ diff --git a/approved/0026-sassafras-consensus.html b/approved/0026-sassafras-consensus.html index f542522..ac32642 100644 --- a/approved/0026-sassafras-consensus.html +++ b/approved/0026-sassafras-consensus.html @@ -90,7 +90,7 @@ diff --git a/approved/0032-minimal-relay.html b/approved/0032-minimal-relay.html index 70ad81e..92279f8 100644 --- a/approved/0032-minimal-relay.html +++ b/approved/0032-minimal-relay.html @@ -90,7 +90,7 @@ diff --git a/approved/0042-extrinsics-state-version.html b/approved/0042-extrinsics-state-version.html index e0fa061..924d644 100644 --- a/approved/0042-extrinsics-state-version.html +++ b/approved/0042-extrinsics-state-version.html @@ -90,7 +90,7 @@ diff --git a/approved/0043-storage-proof-size-hostfunction.html b/approved/0043-storage-proof-size-hostfunction.html index 5052f08..b42d9a6 100644 --- a/approved/0043-storage-proof-size-hostfunction.html +++ b/approved/0043-storage-proof-size-hostfunction.html @@ -90,7 +90,7 @@ diff --git a/approved/0045-nft-deposits-asset-hub.html b/approved/0045-nft-deposits-asset-hub.html index 6adc2bc..370030a 100644 --- a/approved/0045-nft-deposits-asset-hub.html +++ b/approved/0045-nft-deposits-asset-hub.html @@ -90,7 +90,7 @@ diff --git a/approved/0047-assignment-of-availability-chunks.html b/approved/0047-assignment-of-availability-chunks.html index 45c48be..b893f4f 100644 --- a/approved/0047-assignment-of-availability-chunks.html +++ b/approved/0047-assignment-of-availability-chunks.html @@ -90,7 +90,7 @@ diff --git a/approved/0048-session-keys-runtime-api.html b/approved/0048-session-keys-runtime-api.html index 1ebdd0f..477e609 100644 --- a/approved/0048-session-keys-runtime-api.html +++ b/approved/0048-session-keys-runtime-api.html @@ -90,7 +90,7 @@ diff --git a/approved/0050-fellowship-salaries.html b/approved/0050-fellowship-salaries.html index 7120137..301c73a 100644 --- a/approved/0050-fellowship-salaries.html +++ b/approved/0050-fellowship-salaries.html @@ -90,7 +90,7 @@ diff --git a/approved/0056-one-transaction-per-notification.html b/approved/0056-one-transaction-per-notification.html index 0036d35..9b12962 100644 --- a/approved/0056-one-transaction-per-notification.html +++ b/approved/0056-one-transaction-per-notification.html @@ -90,7 +90,7 @@ diff --git a/approved/0059-nodes-capabilities-discovery.html b/approved/0059-nodes-capabilities-discovery.html index 59e9561..79f2f5b 100644 --- a/approved/0059-nodes-capabilities-discovery.html +++ b/approved/0059-nodes-capabilities-discovery.html @@ -90,7 +90,7 @@ diff --git a/approved/0078-merkleized-metadata.html b/approved/0078-merkleized-metadata.html index 03abdf3..49c2838 100644 --- a/approved/0078-merkleized-metadata.html +++ b/approved/0078-merkleized-metadata.html @@ -90,7 +90,7 @@ diff --git a/approved/0084-general-transaction-extrinsic-format.html b/approved/0084-general-transaction-extrinsic-format.html index 102efc1..e2ca057 100644 --- a/approved/0084-general-transaction-extrinsic-format.html +++ b/approved/0084-general-transaction-extrinsic-format.html @@ -90,7 +90,7 @@ diff --git a/approved/0091-dht-record-creation-time.html b/approved/0091-dht-record-creation-time.html index 92d2f29..f66b6c5 100644 --- a/approved/0091-dht-record-creation-time.html +++ b/approved/0091-dht-record-creation-time.html @@ -90,7 +90,7 @@ diff --git a/approved/0097-unbonding_queue.html b/approved/0097-unbonding_queue.html index 273b1d5..94cf83a 100644 --- a/approved/0097-unbonding_queue.html +++ b/approved/0097-unbonding_queue.html @@ -90,7 +90,7 @@ diff --git a/approved/0099-transaction-extension-version.html b/approved/0099-transaction-extension-version.html index dcb015b..130b067 100644 --- a/approved/0099-transaction-extension-version.html +++ b/approved/0099-transaction-extension-version.html @@ -90,7 +90,7 @@ diff --git a/approved/0100-xcm-multi-type-asset-transfer.html b/approved/0100-xcm-multi-type-asset-transfer.html index 9a1574e..0a31f4a 100644 --- a/approved/0100-xcm-multi-type-asset-transfer.html +++ b/approved/0100-xcm-multi-type-asset-transfer.html @@ -90,7 +90,7 @@ diff --git a/approved/0101-xcm-transact-remove-max-weight-param.html b/approved/0101-xcm-transact-remove-max-weight-param.html index 051e47b..325b902 100644 --- a/approved/0101-xcm-transact-remove-max-weight-param.html +++ b/approved/0101-xcm-transact-remove-max-weight-param.html @@ -90,7 +90,7 @@ diff --git a/approved/0103-introduce-core-index-commitment.html b/approved/0103-introduce-core-index-commitment.html index 3eb8c92..d6ab963 100644 --- a/approved/0103-introduce-core-index-commitment.html +++ b/approved/0103-introduce-core-index-commitment.html @@ -90,7 +90,7 @@ diff --git a/approved/0105-xcm-improved-fee-mechanism.html b/approved/0105-xcm-improved-fee-mechanism.html index d6b1aff..e9d9ced 100644 --- a/approved/0105-xcm-improved-fee-mechanism.html +++ b/approved/0105-xcm-improved-fee-mechanism.html @@ -90,7 +90,7 @@ diff --git a/approved/0107-xcm-execution-hints.html b/approved/0107-xcm-execution-hints.html index c1a8f6c..f4e701d 100644 --- a/approved/0107-xcm-execution-hints.html +++ b/approved/0107-xcm-execution-hints.html @@ -90,7 +90,7 @@ diff --git a/approved/0108-xcm-remove-testnet-ids.html b/approved/0108-xcm-remove-testnet-ids.html index a643b32..75b9730 100644 --- a/approved/0108-xcm-remove-testnet-ids.html +++ b/approved/0108-xcm-remove-testnet-ids.html @@ -90,7 +90,7 @@ diff --git a/approved/0122-alias-origin-on-asset-transfers.html b/approved/0122-alias-origin-on-asset-transfers.html index ff53206..9b67698 100644 --- a/approved/0122-alias-origin-on-asset-transfers.html +++ b/approved/0122-alias-origin-on-asset-transfers.html @@ -90,7 +90,7 @@ diff --git a/index.html b/index.html index 545a840..55eb4a5 100644 --- a/index.html +++ b/index.html @@ -90,7 +90,7 @@ diff --git a/introduction.html b/introduction.html index 545a840..55eb4a5 100644 --- a/introduction.html +++ b/introduction.html @@ -90,7 +90,7 @@ diff --git a/new/0126-introduce-xcq.html b/new/0126-introduce-xcq.html index c701b1a..e0ad6a6 100644 --- a/new/0126-introduce-xcq.html +++ b/new/0126-introduce-xcq.html @@ -90,7 +90,7 @@ @@ -519,7 +519,7 @@ extern "C" {

XCM integration

-

XCM usages is considered in XCQ. The integration is acheived by adding a new instruction to XCM, and a new variant is added to the Response type in QueryResponse message.:

+

The integration of XCQ into XCM is acheived by adding a new instruction to XCM, as well as a new variant of the Response type in QueryResponse message.:

@@ -633,7 +633,7 @@ Some strategies to address this issue include:

  • Security:

    • diff --git a/print.html b/print.html index fa9141e..92e7515 100644 --- a/print.html +++ b/print.html @@ -91,7 +91,7 @@ @@ -525,7 +525,7 @@ extern "C" {

    XCM integration

    -

    XCM usages is considered in XCQ. The integration is acheived by adding a new instruction to XCM, and a new variant is added to the Response type in QueryResponse message.:

    +

    The integration of XCQ into XCM is acheived by adding a new instruction to XCM, as well as a new variant of the Response type in QueryResponse message.:

    @@ -639,7 +639,7 @@ Some strategies to address this issue include:

  • Security:

    • @@ -9874,262 +9874,6 @@ Implement call filters. This will allow multisig accounts to only accept certain

    None

    None

    -

    (source)

    -

    Table of Contents

    - -

    RFC-0089: Flexible Inflation

    -
    - - - -
    Start DateMay 6 2024
    DescriptionRevise the inflation logic in the runtime such that it can be parameterized and tweaked in an easier and more transparent way.
    AuthorsKian Paimani
    -
    -

    Summary

    -

    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:

    -
      -
    1. More transparent and easier to understand inflation logic
      2. -
    2. Easier parameterization through governance
      3. -
    3. Decoupled from the staking logic, should inflation and staking happen in two disjoint consensus -systems, as proposed -RFC32.
      4. -
    -

    Motivation

    -

    The existing inflation logic in the relay chain suffers from a number of drawbacks:

    - -

    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.

    -
    -

    Stakeholders

    -

    This RFC is relevant to the following stakeholders, listed from high to low impact:

    - -

    Explanation

    -

    Existing Order

    -

    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.

    -

    New Order

    -
    -

    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:

    -
      -
    1. Sourcing the inflation amount: This step merely specifies by how much the chain intends to -inflate its token. This amount is not minted right away, and is instead passed over to the next -step for distribution.
      2. -
    2. Distributing the aforementioned amount: A sequence of functions that decide what needs to be -done with the sourced inflation amount. This process is expected to transfer the inflation -amount to any account that should receive it. This implies that the staking system should, -similar to treasury, have a key-less account that will act as a temporary pot for the inflation -amount.
      3. -
    -

    In very abstract terms, an example of the above process can be:

    - -

    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.

    -
    -

    Proposed Implementation

    -

    A candidate implementation of this RFC can be found in -this -branch of the polkadot-sdk repository. Please note the changes to:

    -
      -
    1. substrate/frame/inflation to see the new pallet.
      2. -
    2. substrate/frame/staking to see the integration with the staking pallet.
      3. -
    3. substrate/bin/runtime to see how the pallet can be configured into a runtime.
      4. -
    -

    Example Configurations

    -

    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.

    -

    Drawbacks

    -

    The following drawbacks are noted:

    -
      -
    1. The solution provided here is possibly an over-engineering, if we want to achieve the goal of -making the existing formula parameterize-able. In that case, we can merely add an instance of the -pallet_parameters to the runtime and make the existing formula's ratios be provided by -governance-controlled parameters. Although, this shortsighted but simpler solution fails to -decouple the staking and inflation logic. This will be an issue depending on whether staking -lives in AssetHub, or its independent parachain.
      2. -
    2. Some of the interfaces proposed in the draft implementation still leak the implementation detail -of the inflation amount being reliant on eg. the staking-rate. We acknowledge this as a drawback, -but given that many PoS inflationary systems rely on the staking rate, we believe it is a -reasonable compromise. Such parameters can be ignored if the implementation does not need them.
      3. -
    -

    Testing, Security, and Privacy

    -

    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.

    -

    Performance, Ergonomics, and Compatibility

    -

    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.

    -

    Prior Art and References

    - -

    Unresolved Questions

    - - -

    (source)

    Table of Contents

    -

    Drawbacks

    +

    Drawbacks

    The main drawback of adding the additional complexity directly to the broker pallet is the potential increase in maintenance overhead. Therefore, we propose adding additional functionality as a separate pallet on the Coretime chain. To take the pressure off from implementing these features, implementation along with unit tests would be taken care of by Lastic (Aurora Makovac, Philip Lucsok).

    There are potential risks of security vulnerabilities in the new market functionalities, such as unauthorized region transfers or incorrect balance adjustments. Therefore, extensive security measures would have to be implemented.

    -

    Testing, Security, and Privacy

    +

    Testing, Security, and Privacy

    Testing