Polkadot Release Analysis v1.3.0

Polkadot Release Analysis v1.3.0

:warning: 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.

:hammer_and_wrench: Tooling Section


:exclamation: 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.


:warning: 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*
  • ExportMessage
  • InitiateReserveWithdraw
  • InitiateTeleport
  • DepositReserveAsset
  • TransferReserveAsset
  • LockAsset
  • RequestUnlock

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 payout
  • check_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

PR: expose the last relay chain block number as an API from parachain-system by rphmeier · Pull Request #1761 · paritytech/polkadot-sdk · GitHub

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

PR: Cumulus: Allow aura to use initialized collation request receiver by skunert · Pull Request #1911 · paritytech/polkadot-sdk · GitHub

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 */ }
...


:information_source: Low Impact

Trading trait and deal with metadata in Mutate trait for nonfungibles_v2

PR: Trading trait and deal with metadata in Mutate trait for nonfungibles_v2 by AlexD10S · Pull Request #1561 · paritytech/polkadot-sdk · GitHub

Why is this important?

The following methods have been added to nonfungibles Mutate trait:

  • set_metadata
  • set_collection_metadata
  • clear_metadata
  • clear_collection_metadata

A new Trait has been added to nonfungibles too, Trading, wit the following methods:

  • buy_item
  • set_price
  • item_price

Allow Locks/Holds/Reserves/Freezes by default when using pallet_balances TestDefaultConfig

PR: Allow Locks/Holds/Reserves/Freezes by default when using `pallet_balances` `TestDefaultConfig` by liamaharon · Pull Request #1880 · paritytech/polkadot-sdk · GitHub

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

PR: fix: GoAhead signal only set when runtime upgrade is enacted from parachain side by Daanvdplas · Pull Request #1176 · paritytech/polkadot-sdk · GitHub

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

PR: Make CheckNonce refuse transactions signed by accounts with no providers by zdave-parity · Pull Request #1578 · paritytech/polkadot-sdk · GitHub

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

PR: archive: Implement height, hashByHeight and call by lexnv · Pull Request #1582 · paritytech/polkadot-sdk · GitHub

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

PR: Add `MaxTipAmount` for pallet-tips by AurevoirXavier · Pull Request #1709 · paritytech/polkadot-sdk · GitHub

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_voting
  • pallet_referenda
  • pallet_ranked_collective
  • pallet_custom_origins
  • pallet_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

7 Likes

@alejandro - thank you for continuing to provide a detailed account of major changes in each polkadot SDK release.

However, just as a point of feedback, as I read through these, as a lay person, I do not come away with any real understanding of “why this is important”.

For example - the first item talks about a new configuration parameter to pallet_balances named “RuntimeFreezeReasons”:

But what is the purpose of “RuntimeFreezeReasons” what capabilities does it unlock?

Perhaps I’m looking in the wrong place. Is this detailed elsewhere? Github does not offer any additional insight.

I am quite confident that there is much value packed into each Polkadot SDK release but I am finding it difficult to understand this value in a meaningful way and thereby relay it to other stakeholders in the ecosystem.

Thanks in advance if I’m just stupidly looking in the wrong spot. :slight_smile:

3 Likes

Hey @aaron2048! Thanks so much for your comment.

As you mention the release analysis it might not do the best job describing every change for each kind of audience. It has always been more focused on covering breaking and other relevant changes for builders maintaining their own code bases.

I do agree that it would be valuable having such a coverage for changes! Though, I would argue that has never been the exact focus of these posts.

Hopefully the reports have served you and the rest of the community well enough on their purpose.