Polkadot Release Analysis v1.3.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.3.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.3.0. All the runtime changes that are part of this release will be included in the corresponding runtime release done by the polkadot technical fellowship.
Tooling Section
High Impact
Ensure correct variant count in Runtime[Hold/Freeze]Reason
PR: https://github.com/paritytech/polkadot-sdk/pull/1900
Why is this important?
This PR includes a breaking change for pallet_balances, it introduces a new item to pallet_balances::Config:
trait Config {
++ type RuntimeFreezeReasons;
}
How does this impact the Polkadot builders?
In all contexts, you should pass the real RuntimeFreezeReasons generated by construct_runtime to type RuntimeFreezeReasons. Passing () would also work, but it would imply that the runtime uses no freezes at all.
Medium Impact
Make IdentityInfo generic in pallet-identity
PR: https://github.com/paritytech/polkadot-sdk/pull/1661
Why is this important?
This PR includes a breaking change for pallet_identity, it introduces a new item to pallet_identity::Config:
trait Config {
++ type IdentityInformation;
}
Another change in this PR is that while the additional field in IdentityInfo stays for backwards compatibility reasons, the associated costs are still present in the pallet through the additional function in IdentityInformationProvider. This function is marked as deprecated as it is only a temporary solution to the backwards compatibility problem.
Introduce XcmFeesToAccount fee manager
PR: https://github.com/paritytech/polkadot-sdk/pull/1234
Why is this important?
This PR introduces a new XcmFeesToAccount struct which implements the FeeManager trait, and assigns this struct as the FeeManager in the XCM config for all runtimes.
The struct simply deposits all fees handled by the XCM executor to a specified account. In all runtimes, the specified account is configured as the treasury account.
XCM delivery fees are now being introduced (unless the root origin is sending a message to a system parachain on behalf of the originating chain).
How does this impact the Polkadot builders?
After this change, instructions that create and send a new XCM, being:
Query*Report*ExportMessageInitiateReserveWithdrawInitiateTeleportDepositReserveAssetTransferReserveAssetLockAssetRequestUnlock
will require the corresponding origin account in the origin register to pay for transport delivery fees, and the onward message will fail to be sent if the origin account does not have the required amount. This delivery fee is in addition to what we already collect as tx fees in pallet-xcm and XCM BuyExecution fees!
Wallet UIs that want to expose the new delivery fee can do so using the formula:
delivery_fee_factor * (base_fee + encoded_msg_len * per_byte_fee)
where the delivery fee factor can be obtained from the corresponding pallet based on which transport you are using (UMP, HRMP or bridges), the base fee is a constant, the encoded message length from the message itself and the per byte fee is the same as the configured per byte fee for txs (i.e. TransactionByteFee).
Treasury spends various asset kinds
PR: https://github.com/paritytech/polkadot-sdk/pull/1333
Why is this important?
This PR allows for the Treasury to spend different types of assets managed by the treasury, not only the ones living in the native treasury account. It also enables this in Rococo and Westend. This is achieved by the new features to pallet-treasury in conjunction with pallet-asset-rate.
This mean that the relay treasury could spend some USDT on asset hub as long as these assets are under treasury control.
How does this impact the Polkadot builders?
New types in pallet-treasury Config trait:
/// Type parameter representing the asset kinds to be spent from the treasury.
type AssetKind: Parameter + MaxEncodedLen;
/// Type parameter used to identify the beneficiaries eligible to receive treasury spends.
type Beneficiary: Parameter + MaxEncodedLen;
/// Converting trait to take a source type and convert to [`Self::Beneficiary`].
type BeneficiaryLookup: StaticLookup<Target = Self::Beneficiary>;
/// Type for processing spends of [Self::AssetKind] in favor of [`Self::Beneficiary`].
type Paymaster: Pay<Beneficiary = Self::Beneficiary, AssetKind = Self::AssetKind>;
/// Type for converting the balance of an [Self::AssetKind] to the balance of the native
/// asset, solely for the purpose of asserting the result against the maximum allowed spend
/// amount of the [`Self::SpendOrigin`].
type BalanceConverter: ConversionFromAssetBalance<
<Self::Paymaster as Pay>::Balance,
Self::AssetKind,
BalanceOf<Self, I>,
>;
/// The period during which an approved treasury spend has to be claimed.
#[pallet::constant]
type PayoutPeriod: Get<BlockNumberFor<Self>>;
/// Helper type for benchmarks.
#[cfg(feature = "runtime-benchmarks")]
type BenchmarkHelper: ArgumentsFactory<Self::AssetKind, Self::Beneficiary>;
New dispatchables for pallet-treasury
spend(AssetKind, AssetBalance, Beneficiary, Option<ValidFrom>)- propose and approve a spend;payout(SpendIndex)- payout an approved spend or retry a failed payoutcheck_payment(SpendIndex)- check the status of a payout;void_spend(SpendIndex)- void previously approved spend;
Note that the existing spend dispatchable renamed to spend_local.
The AssetKind parameter contains the asset’s location and it’s corresponding asset_id, for example:
USDT on AssetHub,
location = MultiLocation(0, X1(Parachain(1000)))
asset_id = MultiLocation(0, X2(PalletInstance(50), GeneralIndex(1984)))
the Beneficiary parameter is a MultiLocation in the context of the asset’s location, for example
// the Fellowship salary pallet's location / account
FellowshipSalaryPallet = MultiLocation(1, X2(Parachain(1001), PalletInstance(64)))
// or custom `AccountId`
Alice = MultiLocation(0, AccountId32(network: None, id: [1,...]))
the AssetBalance represents the amount of the AssetKind to be transferred to the Beneficiary. For permission checks, the asset amount is converted to the native amount and compared against the maximum spendable amount determined by the commanding spend origin.
This change adds new events and error to pallet-treasury together with the relevant XCM configurations. Please have a look at the original PR for all the nits.
expose the last relay chain block number as an API from parachain-system
Why is this important?
As a follow up to the forum thread: Blocknumber vs Timestamps. This change exposes the LastRelayChainBlockNumber storage member of cumulus-pallet-parachain-system with a getter and alters the behavior of this storage item to only be updated in on_finalize to ensure a consistent value throughout on_initialize and within transactions.
Its author also gives a heads up to avoid using the parachain block number as a clock, especially with features such as asynchronous backing and agile coretime.
Cumulus: Allow aura to use initialized collation request receiver
Why is this important?
This PR modifies Aura to let it optionally take an already initialized stream of collation requests.
How does this impact the Polkadot builders?
Parachain maintainers need to add the new collation_request_receiver to Aura parameters in their node service file.
increase MAX_ASSETS_FOR_BUY_EXECUTION
PR: https://github.com/paritytech/polkadot-sdk/pull/1733
Why is this important?
As reported on issue #1638 having an unbounded limit of assets for Buy Execution might be a concern, though a hard limit of 1 might not be desired.
This change bumps MAX_ASSETS_FOR_BUY_EXECUTION to 2 as this might be helpful with backwards compatibility with some parachain programs.
Though, it is important to mention that indeed this limit is applied to Buy Execution, this constant value doesn’t restrict in any way the number of assets in holding.
When composing XCM programs consider the following way of tackling the mentioned scenario via a construction like:
WithdrawAsset { /* 1 asset for fees */ }
BuyExecution { .. }
WithdrawAsset { /* other assets to use in the program */ }
...
Low Impact
Trading trait and deal with metadata in Mutate trait for nonfungibles_v2
Why is this important?
The following methods have been added to nonfungibles Mutate trait:
set_metadataset_collection_metadataclear_metadataclear_collection_metadata
A new Trait has been added to nonfungibles too, Trading, wit the following methods:
buy_itemset_priceitem_price
Allow Locks/Holds/Reserves/Freezes by default when using pallet_balances TestDefaultConfig
Why is this important?
Users of pallet_balances TestDefaultConfig like the minimal runtime now feature locks, holds, reserves and freezes.
#[derive_impl(pallet_balances::config_preludes::TestDefaultConfig as pallet_balances::DefaultConfig)]
impl pallet_balances::Config for Runtime {
type AccountStore = System;
}
Being the default values:
type MaxLocks = ConstU32<100>;
type MaxReserves = ConstU32<100>;
type MaxFreezes = ConstU32<100>;
type MaxHolds = ConstU32<100>;
fix: GoAhead signal only set when runtime upgrade is enacted from parachain side
Why is this important?
As stated in issue #641 pallet registrar call registerar.schedule_code_upgrade would prematurely set the GoAheadSignal for a certain parachain upgrade, bricking it in the process of the upgrade as a result.
This fix solves this issue including a flag such that the GoAhead signal will only be set when a runtime upgrade is enacted by the parachain (enact_authorized_upgrade).
How does this impact the Polkadot builders?
Parachain managers are safe to call registerar.schedule_code_upgrade for parachains that don’t have a manager lock.
Make CheckNonce refuse transactions signed by accounts with no providers
Why is this important?
This change accommodates for signed validation on chains that might not have balances and transaction fees. So that these users don’t require a custom SignedExtension.
Remove kusama and polkadot runtime crates
PR: https://github.com/paritytech/polkadot-sdk/pull/1731
Why is this important?
This change removes Polkadot and Kusama runtime crates from polkadot-sdk repository. Some emulated integration tests depending on these crates have also been removed.
Additionally it also removes the CLI command hostperfcheck as it became a duplicate of the hardware benchmark that runs at node start up.
archive: Implement height, hashByHeight and call
Why is this important?
Adds and implements the following unstable rpc calls for archives:
/// These methods are unstable and subject to change in the future.
/// Get the height of the current finalized block.
///
/// Returns an integer height of the current finalized block of the chain.
#[method(name = "archive_unstable_finalizedHeight")]
fn archive_unstable_finalized_height(&self) -> RpcResult<u64>;
/// Get the hashes of blocks from the given height.
///
/// Returns an array (possibly empty) of strings containing an hexadecimal-encoded hash of a
/// block header.
#[method(name = "archive_unstable_hashByHeight")]
fn archive_unstable_hash_by_height(&self, height: u64) -> RpcResult<Vec<String>>;
/// Call into the Runtime API at a specified block's state.
#[method(name = "archive_unstable_call")]
fn archive_unstable_call(
&self,
hash: Hash,
function: String,
call_parameters: String,
) -> RpcResult<MethodResult>;
Add MaxTipAmount for pallet-tips
Why is this important?
A new parameter has been added to pallet-tips Config trait.
/// The maximum amount for a single tip.
#[pallet::constant]
type MaxTipAmount: Get<BalanceOf<Self, I>>;
Declaring a ceiling value for how big a tip can be.
Add some events for pallet-bounties
PR: add some events for pallet-bounties by xlc · Pull Request #1706 · paritytech/polkadot-sdk · GitHub
Why is this important?
The following events have been added to pallet-bounties:
#[pallet::event]
#[pallet::generate_deposit(pub(super) fn deposit_event)]
pub enum Event<T: Config<I>, I: 'static = ()> {
// -- snip --
/// A bounty is approved.
BountyApproved { index: BountyIndex },
/// A bounty curator is proposed.
CuratorProposed { bounty_id: BountyIndex, curator: T::AccountId },
/// A bounty curator is unassigned.
CuratorUnassigned { bounty_id: BountyIndex },
/// A bounty curator is accepted.
CuratorAccepted { bounty_id: BountyIndex, curator: T::AccountId },
}
OpenGov in Westend and Rococo
PR: OpenGov in Westend and Rococo by al3mart · Pull Request #1177 · paritytech/polkadot-sdk · GitHub
Why is this important?
This PR adds OpenGov to Rococo and Westend networks. Now the following pallets are available in said networks:
pallet_conviction_votingpallet_referendapallet_ranked_collectivepallet_custom_originspallet_whitelist
And pallet_treasury has also been added to Westend.
The curves for the different tracks have been adjusted so the wait times are sensible with the test environments. Please refer to the source for the concrete values.
Your friendly neighborhood Polkadot Release Analysis team,
@alejandro @ayush.mishra @bruno
