Polkadot Release Analysis v1.1.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.1.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.
Help us improve the release analysis by filling out this 6 question survey.
Summary
In the following report we are featuring some of the changes included in the polkadot node release 1.1.0. All the 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.
Runtime Migrations
pallet-contractsto v13 in substrate#14079pallet-contractsto v14 in substrate#14020pallet-contractsto v15 in substrate#14589
Tooling Section
High Impact
[S] Frame: Agile Coretime Broker pallet (RFC-1)
PR: https://github.com/paritytech/substrate/pull/14568
Why is this important?
This pallet is the brokerage tool for managing Polkadot Core scheduling. It is the implementation of polkadot-fellows/RFCs#1.
How does this impact the Polkadot builders?
As we prepare to migrate from slot auctions to core scheduling, it is recommended to start to become familiar with how Polkadot Core scheduling works.
The best way to start is by reading RFC-0001 Agile Coretime.
Medium Impact
[C] Asynchronous-backing compatible Aura, not plugged in
PR: https://github.com/paritytech/cumulus/pull/2573
Why is this important?
This PR is part of a series of PRs to prepare Cumulus collators for more advanced parachain protocol features such as asynchronous backing, elastic scaling, and blockspace regions. This PR in particular preps AURA for asynchronous backing compatibility according to what was laid out in issue #2476. It is meant to be backwards compatible to the already existing collation logic and it is still dependent on some updates on how the Polkadot node receives collation in order for it to go fully live.
How does this impact the Polkadot builders?
If you’re not familiar with asynchronous backing, elastic scaling, and blockspace regions, it is a good time to start familiarizing yourself with these more advanced parachain protocol features so that you’re ahead of the curve when these changes land in Cumulus and Polkadot.
Related Issue: #841
[S] Contracts Add deposit for dependencies
PR: https://github.com/paritytech/substrate/pull/14079
Why is this important?
As a part of this PR, some changes have been made in pallet-contracts to prevent a contract to be removed when it’s invoked via delegate_call.
This PR introduces the following changes:
- Two new runtime functions:
add_delegate_dependency: ensures that the delegated contract is not removed while it is still in use and also charges a fraction of the code deposit, which is configured in CodeHashLockupDepositPercent.
remove_delegate_dependency: This is the counterpart of the above function and refunds the deposit that was charged by add_delegate_dependency.
- Two new configuration fields:
type MaxDelegateDependencies: Get<u32>;
type CodeHashLockupDepositPercent: Get<Perbill>;
How to use?
If you are using this pallet, you have to add these two new type parameters in the runtime otherwise compilation would fail.
To avoid compilation failure:
pub CodeHashLockupDepositPercent: Perbill = Perbill::from_percent(30);
impl pallet_contracts::Config for Runtime {
// .. snip
type MaxDelegateDependencies = ConstU32<32>;
type CodeHashLockupDepositPercent = CodeHashLockupDepositPercent;
}
For more details, please check the PR description.
Cumulus Companion: #2913
[S] Pallets: Asset Rate - Rename AssetId to AssetKind, Introduce AssetKindFactory Trait
Why is this important?
Asset Rate Pallet provides means of setting conversion rates for some asset to native balance. As a part of this PR, AssetId type parameter has been renamed to AssetKind to avoid naming collisions. This type parameter presents types for asset kinds for which the conversion rate to native balance is set.
Apart from this change, AssetKindFactory trait has also been introduced specifically for benchmarks.
How does this impact the Polkadot builders?
If you are using this pallet, you have to add these two new type parameters in the runtime otherwise compilation would fail.
To avoid compilation failure:
impl pallet_asset_rate::Config for Runtime {
// .. snip
type AssetKind = u32;
#[cfg(feature = "runtime-benchmarks")]
type BenchmarkHelper = ();
}
For more details, please check the PR description.
[S] change HashFor to HashingFor
PR: https://github.com/paritytech/substrate/pull/14483
Why is this change interesting for builders?
At the moment, Header trait has two types:
/// Header hash type
type Hash: HashOutput;
/// Hashing algorithm
type Hashing: Hash<Output = Self::Hash>;
For extracting the hashing type for a block, we are using
pub type HashFor<B> = <<B as Block>::Header as Header>::Hashing;
To avoid confusion and improve this naming, HashFor has been replaced with HashingFor.
For more details, please check the PR description.
Related Issue: #10386
Cumulus Companion: #2828
Polkadot Companion: #7465
[S] Don’t use fixed nominator count for report_equivocation weight calculation
PR: https://github.com/paritytech/substrate/pull/14471
Why is this change interesting for builders?
Substrate Babe pallet and Grandpa pallet both have an extrinsic report_equivocation to report authority equivocation/misbehavior.
As a part of this PR, a new config type MaxNominators has been introduced in both pallets. This new type will be used for weight calculation so that weights can be calculated on the basis of the runtime configured maximum number of nominators per validator, rather than using a constant value.
How does this impact the Polkadot builders?
If you are using Babe or Grandpa pallet, you have to add this new type parameter in runtime otherwise compilation would fail.
To avoid compilation failure:
impl pallet_babe::Config for Runtime {
// .. snip
type MaxNominators = ConstU32<0>;
}
impl pallet_grandpa::Config for Runtime {
// .. snip
type MaxNominators = ConstU32<0>;
}
Polkadot Companion: #7432
[S] Cross-contract calling: simple debugger
PR: https://github.com/paritytech/substrate/pull/14678
Why is this change interesting for builders?
As a part of this PR, a simple debugger has been introduced in pallet-contracts.
This will help to debug complex multi-contract execution traces. This PR is well documented. For more details, please read PR description.
A new config type Debug has been introduced with unsafe-debug feature. However this feature flag has been removed as a part of this #14789
How does this impact the Polkadot builders?
If you are using pallet-contracts, you have to add this new type parameter in runtime otherwise compilation would fail.
To avoid compilation failure:
impl pallet_contracts::Config for Runtime {
// .. snip
type Debug = ();
}
Cumulus Companion: #3035
[S] Contracts: migrate to fungible traits
PR: https://github.com/paritytech/substrate/pull/14020
Why is this important?
Following substrate#12951 this PR include changes to adapt for holds, moving away from reserves, which requires a migration aside from what is described in the following section.
How does this impact the Polkadot builders?
The modifications done to pallet-contracts are the following:
- Inclusion of the overarching hold reasons
#[pallet::composite_enum]
pub enum HoldReason {
/// The Pallet has reserved it for storing code on-chain.
CodeUploadDepositReserve,
}
-
deposit_heldanduploaderfields added toCodeStoredevent, now being fired instead ofpallet_balances::Event::Reserved. In the same way,deposit_releasedandremoverfields have been added toCodeRemovedevent which is fired instead ofpallet_balances::Event::Unreserved. -
ExistenceRequirementenum is replaced byPreservationenum
- /// Simple boolean for whether an account needs to be kept in existence.
- #[derive(Copy, Clone, RuntimeDebug, Eq, PartialEq)]
- pub enum ExistenceRequirement {
- /// Operation must not result in the account going out of existence.
- ///
- /// Note this implies that if the account never existed in the first place, then the operation
- /// may legitimately leave the account unchanged and still non-existent.
- KeepAlive,
- /// Operation may result in account going out of existence.
- AllowDeath,
- }
+ /// The mode by which we describe whether an operation should keep an account alive.
+ #[derive(Copy, Clone, RuntimeDebug, Eq, PartialEq)]
+ pub enum Preservation {
+ /// We don't care if the account gets killed by this operation.
+ Expendable,
+ /// The account may not be killed, but we don't care if the balance gets dusted.
+ Protect,
+ /// The account may not be killed and our provider reference must remain (in the context of
+ /// tokens, this means that the account may not be dusted).
+ Preserve,
+ }
- Users of
pallet-contractsneed to satisfy the new type required in itsConfig
impl pallet_contracts::Config for Runtime {
...
type RuntimeHoldReason = RuntimeHoldReason;
...
}
- And so does
construct_runtimeneedpallet_contracts::HoldReason
construct_runtime!(
pub enum Runtime where
...
{
...
// Smart Contracts.
Contracts: pallet_contracts::{Pallet, Call, Storage, Event<T>, HoldReason} = ...,
...
}
)
[P] 98.6% OF DEVELOPERS CANNOT REVIEW THIS PR!
Why is this important?
Polkadot node functionality has been separated in three different binaries, polkadot and the two new ones polkadot-prepare-worker and polkadot-execute-worker binary, which are not intended for any user interaction and are only run by the node software itself. The auxiliary binaries are actually only required if the node runs as a validator.
If you are a validator please consider the following.
-
The binaries are free to be placed anywhere in the filesystem as long as the location allows for binary execution and all three are in the same directory.
-
New
--workers-pathcommand line option is provided for those requiring to place the auxiliary binaries into a different location. That option also allows users to specify the binary itself, in which case it will be used for both preparation and execution jobs, but it is only intended for testing and development. -
When the node starts, if the location of the auxiliary binaries is not specified explicitly with --workers-path, it searches for them in the directory where the main binary resides and then in /usr/libexec. If not found, it falls back to executing them from $PATH.
-
These new executables need to be at the same version than the polkadot binary.
Users running more sophisticated configurations may need some handwork to make things run.
Cumulus Companion: #2929
[S] Set StateBackend::Transaction to PrefixedMemoryDB
Why is this important?
This PR has a number of refactors including the removal of Transaction associated type from sp_state_machine::Backend. The transactin is then fixed to PrefixedMemoryDB. Another change is moving the “storage transaction cache” into OverlayedChanges. For the reasoning behind these changes please refer to the PR description.
How does this impact the Polkadot builders?
The following are the downstream changes:
- Everywhere where things like
TransactionFororStateBackend::Transactionwas used in where bounds or similar can just be removed to make the code compile again. BlockImportParamswas also changed to only take one generic argument, the block type and not anymore the transaction type as the second generic parameter.DefaultImportQueueis also only taking one generic argument after this PR, the block type.
Related Issue: #27
Polkadot Companion: #7536
Cumulus Companion: #2923
Low Impact
[S] add doc-only substrate entry point crate
PR: https://github.com/paritytech/substrate/pull/14581
Why is this important?
This PR is meant to be an entry point crate for Substrate documentation:
How does this impact the Polkadot builders?
In this PR, there has been a separation of concerns, to use Substrate node features you must now explicitly specify node-cli in your command:
cargo run -p node-cli --features try-runtime ...
[P] Put HRMP Channel Management on General Admin Track
Why is this important?
This PR makes it so that the GeneralAdmin track now has permissions over HRMP channel management.
How does this impact the Polkadot builders?
This creates a ChannelManager for HRMP channel management and therefore streamlines the HRMP channel flow by having a more “relaxed” track specifically for HRMP channel operations.
Why is this change interesting for builders?
This PR is one example of how OpenGov is already an improvement over Gov v1.
How to use
You will need to make the following change to your runtime config:
impl parachains_hrmp::Config for Runtime {
// .. snip
type ChannelManager = frame_system::EnsureRoot<AccountId>;
}
[S] Refactor the asset-conversion-tx-payment pallet
Why is this important?
The SwapNative trait in fungibles has been moved to the asset-conversion pallet along with its methods and renamed to Swap.
Some code duplication has been removed.
And methods inside the Swap trait now accept a path param which is a Vec<MultiAssetId> where path[0] is one asset and path[1] is the second asset in the swap.
Check the PR for further details.
[S] Introduce Pallet paged-list
PR: https://github.com/paritytech/substrate/pull/14120
Why is this important?
This pallet is a thin wrapper around paged_list::StoragePagedList. In fact, this pallet contains no Calls, Errors or Events!
The paginated storage list in this pallet is meant to replace StorageValue<Vec<V>> in situations where only iteration and appending is needed. There are a few places where this is the case.
The motivating force here is that a paginated structure reduces the (runtime) memory usage when storage transactions need to be rolled back.
You can read more here:
How to use
You can see an example of using the PagedList pallet in the fuzzer that is in this PR.
[S] changes to nfts pallet for xcm integration
PR: https://github.com/paritytech/substrate/pull/14395
Why is this change interesting for builders?
Substrate NFT pallet has a storage NextCollectionId, which gets calculated and stored, when a new collection is created.
If we want to integrate NFT pallet with XCM, we would need to represent a CollectionId as a MultiLocation, which is not possible with current structure. To make this possible, a new function create_collection_with_id has been introduced to allow for non incremental collection ids.
Related Issue: #14349
[S] Encryption support for the statement store
PR: https://github.com/paritytech/substrate/pull/14440
Why is this change interesting for builders?
Statement store is an off-chain data-store for signed statements accessible via RPC and OCW.
As a part of this PR a simple encryption scheme has been implemented that uses ed25519 key exchange and AEAD for the statement store.
Related Issue: #3
Cumulus Companion: #2876
[S] [FRAME Core] New pallets: safe-mode and tx-pause
PR: https://github.com/paritytech/substrate/pull/12092
Why is this change interesting for builders?
As a part of this release, two new pallets safe-mode and tx-pause have been introduced. Both pallets can be used in emergency situation in different way.
SafeMode pallet put the chain in safe-mode by providing a big STOP button and only allows those calls which are whitelisted.
TxPause pallet can be used to pause specific calls.
Both pallets have a config type WhitelistedCalls where we can configue those calls which can bypass the safe-mode pallet and cannot be paused by the tx-pause pallet.
This PR is very well documented which includes a brief description. For more details, please go through PR description and related issues.
[S] grandpa: avoid importing unnecessary justifications
PR: https://github.com/paritytech/substrate/pull/14423
Why is this change interesting for builders?
At the moment, block import process is slow because we process two types of justifications. One is GRANDPA justification and another one is served by peer for every block. If block import includes GRANDPA justification, it will always be processed. On the other hand, if it is a peer served justification, it has to go through two levels. First the verification will happen and after that it will be imported. This is applicable for every block which can lead to a significant slowdown in block import speed.
This PR fixes this issue and will allow only import GRANDPA justifications every 512 blocks.
Related Issue: #13
Polkadot Companion: #7484
[S] Get rid of Peerset compatibility layer
PR: https://github.com/paritytech/substrate/pull/14337
Why is this important?
This PR gets rid of Peerset completely. PeerStore and ProtocolController replaces Peerset.
This PR also fixes a bug in Protocol with peer counting: self.peers contains only peers on the default (sync) protocol The entries are not removed when peers are disconnected on non-default protocols.
Polkadot Companion: #7355
Cumulus Companion: #2739
[S] chainHead_storage: Iterate over keys
PR: chainHead_storage: Iterate over keys by lexnv · Pull Request #14628 · paritytech/substrate · GitHub
Why is this important?
This PR adds support for iterating over key-values and key-hashes for chainHead_unstable_storage.
Related Issue: #14548
[P/C] Rename polkadot-parachain to polkadot-parachain-primitives
Why is this important?
polkadot-parachain defines primitive types for creating or validating a parachain. As a part of this PR, polkadot-parachain has been renamed to polkadot-parachain-primitives.
If you are a parachain builder, you may be using this. To avoid compilation error, please rename this.
For more details, please check the PR.
[S] Asset conversion get_pool_id fix (Ord does not count with is_native flag)
Why is this important?
This PR brings several changes to asset-conversion pallet, not only fixing get_pool_id for is_native but also a new definition to the BenchmarkHelper type:
- type BenchmarkHelper: BenchmarkHelper<Self::AssetId>;
+ type BenchmarkHelper: BenchmarkHelper<Self::AssetId, Self::MultiAssetId>;
A new field within the PoolCreated event
pub enum Event<T: Config> {
/// A successful call of the `CretaPool` extrinsic will create this event.
PoolCreated {
/// The account that created the pool.
creator: T::AccountId,
/// The pool id associated with the pool. Note that the order of the assets may not be
/// the same as the order specified in the create pool extrinsic.
pool_id: PoolIdOf<T>,
+ /// The account ID of the pool.
+ pool_account: T::AccountId,
/// The id of the liquidity tokens that will be minted when assets are added to this
/// pool.
lp_token: T::PoolAssetId,
},
...
}
And a new error has been added
pub enum Error<T> {
/// Provided assets are equal.
EqualAssets,
/// Provided asset is not supported for pool.
+ UnsupportedAsset,
...
}
Along with improvements to MultiAssetIdConverter.
Cumulus companion: #2860
[S] contracts: Expose environment types for offchain tooling
Why is this important?
This PR exposes all runtime configurable types passed between pallet contracts and deployed contracts. This is useful to check whether before a contract is uploaded/instantiated, if its types match the types from the node (pallet contracts). Since these types are configurable, they can vary between chains that are using pallet contracts and therefore this PR makes it so the type metadata can be consumed by offchain tooling.
Cumulus Companion: #3036
Related Issue: #1167
[S] pallet-aura: add feature-flagged explicit slot duration type
Why is this important?
This PR adds a feature flagged exlicit slot duration type for AURA that should be enabled for runtimes which plan to upgrade to asynchronous backing. The feature flag is there for backwards compatibility.
[S] [NPoS] Implements dynamic number of nominators
PR: https://github.com/paritytech/substrate/pull/12970
Why is this important?
This PR refactors the implementation of the ElectionDataProvider bounds and implements a dynamic nomination quota per voter, based on the account’s balance and an arbitrary curve.
An implementor of NominationsQuota returns the maximum number of votes per nominator. FixedNominationsQuota implements an instance of a fixed number of nominations, similar to the current implementation when set to 16.
Also, two new events have been added to pallet-staking:
SnapshotVotersSizeExceeded: emitted when the election snapshot was exhausted due to the voters size limit.SnapshotTargetsSizeExceeded: emitted when the election snapshot was exhausted due to the targets size limit.
A new runtime API is also implemented to allow clients to query the nominations quota for a given balance.
Polkadot Companion: #6807
[S] Contracts remove deposit accounts
PR: https://github.com/paritytech/substrate/pull/14589
Why is this important?
Move contracts’ reserved balance from the deposit_account to be held in the contract’s account instead. Since Currency trait has been deprecated, deposits need to be handled by the frame_support::traits::fungible traits instead. This PR inclused a migration to tackle this.
The deposit account is not needed anymore and we can get rid of it.
Cumulus companion: #2973
[P] Rename squatted crates
PR: Rename squatted crates by Morganamilo · Pull Request #1241 · paritytech/polkadot-sdk · GitHub
Why is this important?
As a part of this PR, staging- prefix has been added to below squatted crates so that they can be published to crates.io.
- Polkadot
- kusama-runtime
- xcm
- xcm-executor
- xcm-builder
- staking-miner
If you are a parachain builder, you may be using this. To avoid compilation error, please rename this.
Your friendly neighborhood Polkadot Release Analysis team,
@alejandro @ayush.mishra @bruno