Polkadot Release Analysis v1.14.0
The following report is not an exhaustive list of changes included in the release, but a set of changes that we felt deserved to be highlighted due to their impact on the Polkadot ecosystem builders.
Please do not stop reading the release notes v1.14.0. This report is complementary to the changelogs, not a replacement.
Highlights are categorized into High Impact, Medium Impact, and Low Impact for ease of navigation.
Also there is a section related to all note worthy changes related to tooling integration.
Summary
In the following report, we are featuring some of the changes included in the polkadot node release v1.14.0. Runtime changes that are part of this release will be included in the corresponding runtime release done by the fellowship.
Next to every PR name you can find the code base related to these changes. The notation is as follows:
- [S]: Changes related to Substrate
- [P]: Changes related to Polkadot
- [C]: Changes related to Cumulus
- [S/P/C]: Changes related to a combination of the noted code bases.
Tooling Updates
- Sidecar - v19.0.2
- TxWrapper - v7.5.1
- PolkadotJS - v12.2.1
- Asset Transfer Api - v0.3.1
- Refactor: parachain template: In this release, parachain template has been updated with the latest Polkadot-SDK changes such as construct runtime V2.
Medium Impact
[C,P] [XCM] Runtime api for LocationToAccount conversions
Why is this important?
This PR adds a new runtime API xcm-runtime-apis to convert XCM Location to the local AccountId on-chain for easier verification.
How does this impact Polkadot builders?
This PR also merges xcm-fee-payment-runtime-api module into this new api. If you are using xcm-fee-payment-runtime-api, this would be a breaking change for you. To avoid this breaking change, please make following changes:
- Make the similar change in the other part of
Cargo.toml.
- xcm-fee-payment-runtime-api = { workspace = true }
+ xcm-runtime-apis = { workspace = true }
- Replace
xcm_fee_payment_runtime_apiwithxcm_runtime_apis.
- use xcm_fee_payment_runtime_api::*;
+ use xcm_runtime_apis::*;
Related Issue: #4298
[S] [FRAME] Remove storage migration type
PR: https://github.com/paritytech/polkadot-sdk/pull/3828
Why is this important?
As a part of this PR, a new migration type RemoveStorage has been introduced, which will remove a storage item from a pallet during migration. This migration type can be used to clean the data from the removed storage items, that are not used anymore.
How does this impact Polkadot builders?
At the moment, there is already a migration type RemovePallet, to clean the storage but this will remove all storage items associated with a specific pallet. However, RemoveStorage will remove only a specific storage item.
During runtime upgrade, this will clean the storage from the specified storage. If try-runtime feature is enabled, the pre_upgrade and post_upgrade will verify the storage before and after the upgrade.
Here is an example:
construct_runtime! {
pub enum Runtime
{
System: frame_system = 0,
TemplatePallet: pallet_template = 1,
}
};
parameter_types! {
pub const TemplatePallet: &'static str = "TemplatePallet";
pub const StorageSomething: &'static str = "Something";
pub const StorageSomethingCount: &'static str = "SomethingCount";
}
pub type Migrations = (
RemoveStorage<TemplatePallet, StorageSomething, RocksDbWeight>,
RemoveStorage<TemplatePallet, StorageSomethingCount, RocksDbWeight>,
);
pub type Executive = frame_executive::Executive<
Runtime,
Block,
frame_system::ChainContext<Runtime>,
Runtime,
Migrations
>;
Related Issue: #3820
[S] Use real rust type for pallet alias in runtime macro
Why is this important?
As a part of #1378, Construct Runtime v2 was introduced, which provides outer-macro approach for defining construct_runtime. But the pallet assignment type was not a valid Rust syntax. This PR fixes this issue and allows to use of a real rust type for pallet aliases.
How does this impact Polkadot builders?
This PR doesn’t contain any breaking changes because it will continue supporting the current syntax. However, if you want to use real rust type for pallet alias in runtime macro, please make following changes in your runtime:
- pub type System = frame_system;
+ pub type System = frame_system::Pallet<Runtime>;
[S] Implement pallet-assets-freezer
Why is this important?
As a part of this PR, a new pallet pallet_assets_freezer has been introduced, which:
- is an extension of pallet-assets
- implements both fungibles::freeze::Inspect and fungibles::freeze::Mutate
- handles freezing fungibles from pallet-assets
How does this impact Polkadot builders?
At the moment, pallet_balances has the functionality to lock/freeze on a specified amount of an account’s free balance until a block number due to some use cases like staking, voting, etc. However, there are some other use cases like multi-governance where locks are needed to be implemented on pallet-assets. This pallet provides the functionality to freeze balance and fetch the frozen balance for an account on a given asset.
To implement this pallet:
// Allow Freezes for the `Assets` pallet
pub type AssetsFreezerInstance = pallet_assets_freezer::Instance1;
impl pallet_assets_freezer::Config<AssetsFreezerInstance> for Runtime {
type RuntimeFreezeReason = RuntimeFreezeReason;
type RuntimeEvent = RuntimeEvent;
}
impl pallet_assets::Config<Instance1> for Runtime {
// Other config...
type Freezer = AssetsFreezer;
}
Related Issue: #3342
Low Impact
[S] Remove deprecated Treasury pallet calls
Why is this important?
As a part of this PR, all deprecated methods(propose_spend, reject_proposal, and approve_proposal) of Treasury Pallet have been removed. These methods were marked as deprecated as a part of #14538.
This PR also includes:
- Removal of associated config parameter types:
ProposalBond,ProposalBondMaximum,ProposalBondMinimum. - Removal of relevant deprecated code in
pallet-tips,pallet-bountiesandpallet-child-bounties. - Removal of related weight functions and test cases.
How does this impact Polkadot builders?
The functionality of these deprecated methods has been replaced by spend_local(for native token) and spend(for using any other asset) dispatchables. This PR also contains a breaking change since a few config parameter types have been removed. If you are using Treasury Pallet for managing pot of funds and spending proposals, you need to remove the following parameters from your runtime.
impl pallet_treasury::Config for Runtime {
\\ Other config
- type ProposalBond = ProposalBond;
- type ProposalBondMinimum = ProposalBondMinimum;
- type ProposalBondMaximum = ();
}
Related PR: #15438
Related Issue: #3800
[S] Treasury Pallet: Remove unused config parameters
Why is this important?
This release includes one more important change related to Treasury Pallet. As a part of this PR, two unused config parameters ApproveOrigin and OnSlash have been removed. This PR also adds OnSlash to the Bounties and Tips pallet for handling imbalanced decreases.
How does this impact Polkadot builders?
This PR includes breaking changes. If you have included Treasury, Bounties, or Tips pallets in your runtime, you will need to make the following changes in your runtime:
impl pallet_treasury::Config for Runtime {
// Other config...
- type ApproveOrigin = EitherOfDiverse<EnsureRoot<AccountId>, pallet_collective::EnsureProportionAtLeast<AccountId, CouncilCollective, 3, 5>,>;
- type OnSlash = ();
}
impl pallet_bounties::Config for Runtime {
// Other config...
+ type OnSlash = Treasury;
}
impl pallet_tips::Config for Runtime {
// Other config...
+ type OnSlash = Treasury;
}
Related Issue: #3800
[S] Add set_partial_params dispatchable function
Why is this important?
Substrate’s Core-Fellowship pallet contains logic specific to the salary, registers activity, and promotion. It is coupled with Salary pallet. This pallet has storage item Params, which stores information about active/passive salary and about member’s promotion and demotion periods.
As a part of this PR, a new dispatchable function set_partial_params has been added to the Core-Fellowship pallet, which will help update Params only with those fields, which need to be updated.
How does this impact Polkadot builders?
Currently, the Core-Fellowship pallet has a dispatchable set_params, which requires all parameters of Params, whether they need to be updated or not. This duplicates the fields that don’t need to be updated. After this PR, builders will have the option to selectively set these parameters.
Related Issue: #3617
[S] Pallet Assets: optional auto-increment for the asset ID
Why is this important?
A new optional auto-increment setup for the IDs of new assets has been added in Pallet-Assets. With this change, builders will have the option to use auto-incremented asset IDs.
How does this impact Polkadot builders?
This feature is completely optional until we set NextAssetId. It won’t impact existing asset storage items. If NextAssetId is set in pallet-assets, then the asset ID provided during new asset creation, must be equal to current value in NextAssetId.
[S] Chain-Spec-Builder: Add support for Code Substitutes
Why is this important?
As a part of this PR, a new AddCodeSubstitute subcommand has been added to the chain spec builder command. With this feature, builders will be able to use new runtime from a given block onwards. This feature is helpful if a chain halts due to any runtime bug and stops producing blocks.
How does this impact Polkadot builders?
After enabling codeSubstitutes, builders can run following command to provide a runtime WASM that they want to use from a given block onwards.
chain-spec-builder add-code-substitute chain_spec.json my_runtime.compact.compressed.wasm 1234
Note: It is important for parachains to update the validation function on the relay chain accordingly, otherwise codeSubstitute subcommand will be rejected.
Related PR: #4600
[S] Pallet ranked collective: max member count per rank
Why is this important?
Substrate’s Ranked-Collective pallet is a pallet for managing memberships for collectives, which could be used in use-cases like Governance, Salary, Promotion/Demotion, etc. Each member has its rank. At the moment, there is no limitation on either the number of members at a rank or the number of ranks in the system.
As a part of this PR, a new config type MaxMemberCount has been added to this pallet to control a number of members for a given rank.
How does this impact Polkadot builders?
Builders will have the option to either assign the value for MaxMemberCount or keep it as () for no limit. If you are using a Ranked-Collective pallet in your runtime, this would be a breaking change. To avoid breaking change, please add the following code in your runtime:
impl pallet_ranked_collective::Config for Runtime {
// Other config...
type MaxMemberCount = ();
}