Polkadot Release Analysis v1.13.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.13.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.13.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.
Noteworthy Storage Migrations
Tooling Updates
High Impact
[S|P|C] Polkadot-SDK Umbrella Crate
PR: Polkadot-SDK Umbrella Crate by ggwpez · Pull Request #3935 · paritytech/polkadot-sdk · GitHub
Why is this important?
This release has come with the most awaited and very powerful feature: Umbrella Crate.
The PR is well documented. However, We would still like to highlight the most important features of this crate.
runtimefeature enables allno-stdcrates.nodefeature enables allstdcrates.- We can use
zepter, which checks that the features of the umbrella are correctly configured. - Each crate can also be enabled selectively.
How does this impact Polkadot builders?
After including this crate, Cargo.toml will become very small, less error-prone, and easy to maintain.
How to use?
For runtime:
polkadot-sdk = { git = "https://github.com/paritytech/polkadot-sdk.git", features = ["runtime"], default-features = false }
For node:
polkadot-sdk = { git = "https://github.com/paritytech/polkadot-sdk.git", features = ["node"], default-features = false }
After adding in Cargo.toml, you need to add use polkadot_sdk::*; to import all dependencies.
Related Link: umbrella_crate.rs
[S] Refactor Nomination Pool to support multiple staking strategies
PR: https://github.com/paritytech/polkadot-sdk/pull/3905
Why is this important?
At the moment, Nomination Pool allows DOT holders to pool their DOT tokens together on-chain to nominate validators and earn rewards. It works by transferring tokens from the delegator to the pool account, and then staking from the pool account as a direct nominator. Before nomination pools, users were directly nominating validators and using their stake of DOT tokens to select validators.
As a part of this PR, a new staking strategy has been introduced. Now individual delegators can delegate the funds to the pool account while the tokens stay locked in delegator account itself. The pool can then delegate the stake to validators.
How does this impact Polkadot builders?
A new StakingStrategy config StakeAdapter has been added in Nomination Pool. With this change, Polkadot builders will have the option to switch to the new staking strategy or stick with the old strategy. If you want to switch to the new strategy, it might require a migration of the storage.
How to use?
In Runtime,
- For switching to the new staking strategy
impl pallet_nomination_pools::Config for Runtime {
// Other config
type StakeAdapter =
pallet_nomination_pools::adapter::DelegateStake<Self, Staking, DelegatedStaking>;
}
You also need to import pallet_delegated_staking in the runtime.
- If you don’t want to switch to the new strategy
type StakeAdapter = pallet_nomination_pools::adapter::TransferStake<Self, Staking>;
This PR is well documented. For more details, please refer to PR description and the following links.
Related Links:
Medium Impact
[S|P|C] Implement CheckMetadataHash extension
Why is this important?
For clients to interact with the chains in the Polkadot Ecosystem, Polkadot-SDK based chains expose metadata about the runtime so that they know how transactions are composed and encoded. This is usually required by wallets, exchanges, custody providers, etc. when they interact with the chains. The metadata is a crucial piece of the transaction and needs to be verified.
At the moment, verification is based on centralized authentication system by trusted authority. This PR makes this verification trustless. As a part of this PR, the new CheckMetadataHash signed extension has been introduced, which can be added in runtime.
How does this impact Polkadot builders?
The metadata hash generation should be enabled only when it is required. Because it adds more overhead, which increases compile time.
Please refer to this guide to enable metadata hash.
Related Issue: #291
[S] Append overlay optimization.
PR: Append overlay optimization. by cheme · Pull Request #1223 · paritytech/polkadot-sdk · GitHub
Why is this important?
OverlayedChanges are the set of changes that are applied to the storage backend when executing transactions. As a part of this PR, storage::append performance has been improved by reducing cloning and copying of data. Before this PR, storage::append was working by appending new data to old storage items after cloning them. After this PR, the new data is kept in a separate field, and cloning is avoided. This allows for improved performance and better transaction throughput.
Related Issue: #30
Low Impact
[C] Remove parameterized-consensus-hook feature
Why is this important?
As a part of Asynchronous backing PR, parameterized-consensus-hook feature was introduced to enable ConsensusHook which is a pluggable component to allow a chain to manage its asynchronous backing backlog.
parameterized-consensus-hook feature is obsolete now and has been removed as a part of this PR.
How does this impact Polkadot builders?
After this PR, all Polkadot-SDK based parachains would need to supply a ConsensusHook. To understand more about the implications of this change, please refer to this section of PR.
How to use?
- cumulus-pallet-parachain-system = { git = "https://github.com/paritytech/polkadot-sdk", default-features = false, features = [
- "parameterized-consensus-hook",
- ] }
+ cumulus-pallet-parachain-system = { git = "https://github.com/paritytech/polkadot-sdk", default-features = false }
[S] Adds MaxRank Config in pallet-core-fellowship
Why is this important?
Core-Fellowship pallet contains logic specific to the salary, registers activity/passivity and promotion. As a part of this PR, a new Config MaxRank has been added to represent the highest possible rank. Before this PR, the maximum ranked member count was set to 9 as constant.
How does this impact Polkadot builders?
If you are using Core-Fellowship pallet for any separate instances of fellowship(s) for your chain ecosystem or use-case scenario, this is a breaking change.
To avoid this breaking change, please implement following changes in your change:
In your runtime:
impl pallet_core_fellowship::Config for Runtime {
.....
type MaxRank = ConstU32<9>;
}
Related Issue: #3315
[S] [Pools] Refactors and Runtime APIs for DelegateStake
Why is this important?
As mentioned above in the analysis of PR 3905, a new staking strategy has been introduced in Nomination Pools to delegate (instead of transfer) fund from delegator to pool account.
As a part of this PR, following runtime apis have been introduced to support integration with dapps and wallets:
fn pool_pending_slash(pool_id: PoolId) -> Balance;// Returns the pending slash for a given pool.
fn member_pending_slash(member: AccountId) -> Balance;// Returns the pending slash for a given pool member.
fn pool_needs_delegate_migration(pool_id: PoolId) -> bool;// Returns true if the pool with `pool_id` needs migration.
fn member_needs_delegate_migration(member: AccountId) -> bool;// Returns true if the delegated funds of the pool `member` needs migration.
How does this impact Polkadot builders?
Apart from the new runtime apis, some refactoring has also been done as a part of this PR. Please refer to PR description for more details. If you have included Nomination pool runtime apis in your runtime, you will need to add the following code in your runtime:
impl pallet_nomination_pools_runtime_api::NominationPoolsApi<Block, AccountId, Balance> for Runtime {
/// existing apis
fn pool_pending_slash(pool_id: pallet_nomination_pools::PoolId) -> Balance {
NominationPools::api_pool_pending_slash(pool_id)
}
fn member_pending_slash(member: AccountId) -> Balance {
NominationPools::api_member_pending_slash(member)
}
fn pool_needs_delegate_migration(pool_id: pallet_nomination_pools::PoolId) -> bool {
NominationPools::api_pool_needs_delegate_migration(pool_id)
}
fn member_needs_delegate_migration(member: AccountId) -> bool {
NominationPools::api_member_needs_delegate_migration(member)
}
}
[S] Add READ_ONLY flag to contract call function
Why is this important?
Ethereum has STATICCALL for smart contract security which can be used to call another contract (or itself) while disallowing any modifications to the state during the call.
As a part of this PR, same strategy has been followed by adding the READ_ONLY flag in the call function in the Contracts pallet.
For more details, please refer PR description.
[S] [Identity] Remove double encoding username signature payload
Why is this important?
Identity-Pallet provides the concept of on-chain identity that allows identities to be added and managed on-chain. The pallet includes functionality for Identity Registration, Identity Verification, Identity Management, and Sub-identities.
At the moment, for registering a username, an additional step is involved for encoding. As a part of this PR, this step has been removed.
Let’s take an example of one of Identity-Pallet tests:
- let encoded_username = Encode::encode(&username_to_sign.to_vec());
- let signature =
- MultiSignature::Sr25519(sr25519_sign(0.into(), &public, &encoded_username).unwrap());
+ let signature = MultiSignature::Sr25519(
+ sr25519_sign(0.into(), &public, &username_to_sign[..]).unwrap(),
+ );
For more details, please refer to PR description.
[S] Bridge: added force_set_pallet_state call to pallet-bridge-grandpa
Why is this important?
pallet-bridge-grandpa is one of the components for building bridges. This is On-Chain GRANDPA Light Client. As a part of this PR, a new extrinsic force_set_pallet_state has been added to this pallet. This new extrinsic is only callable by the root origins (governance or sudo). It could be used in scenarios where an update of authorities set or finalized header are needed.
Related Issue: #2963
[C] Make all storage items in parachain-system public
Why is this important?
cumulus-pallet-parachain-system is a base pallet for Cumulus-based parachains. As a part of this PR, all storage items of this pallet have been made public. Now these storage items can be accessed from other pallets or from runtime itself. For example: latest validation code, latest relay chain block number associated with the last parachain block, can be accessed from another pallet.