hectorb
Thu, 30 Mar 2023 10:12:37 +0000
Ecosystem

Polkadot Release Analysis v0.9.40

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 v0.9.40. 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 this release we can find a variety of very interesting changes, barriers within XCM configuration will now leverage a new Matcher API, pallet-nfts is receiving a new permission model along with new features for assets and nomination pools among other changes.

Runtimes built on release v0.9.40

Rococo v9400

Westend v9400

Kusama v9400

Polkadot v9400

Tooling Section

TxWrapper Core - v5.0.1

Substrate Sidecar API - v14.5.1

Polkadot JS API - v10.1.4

High Impact

Introduce XCM matcher for writing barriers

PR: https://github.com/paritytech/polkadot/pull/6756
Related PR: XCM: Use matcher API in DenyReserveAssetTransferToRelay by KiChjang · Pull Request #2290 · paritytech/cumulus · GitHub
Related Issues:
Consider a declarative API to describe XCM barrier conditions · Issue #4276 · paritytech/polkadot · GitHub

Why is this change interesting for builders?

With XCM, Polkadot enables secure cross-chain exchange of any type of data. However a cross-chain message needs to be whitelisted in the receiver end to be accepted. The whitelisting happens in a place called the Barrier. Barriers are a set of filters to statically accept or reject XCM messages.

This PR introduces a new API fn matchers() for &mut [Instructions<Call>] that is similar to iterators: it can advance the current instruction to the next while ensuring the current instruction matches/fulfills a certain condition; it can assert the remaining number of instructions left to process; and it can also skip instructions while a condition is being evaluated as true.

The main purpose of creating a Matcher API instead of using iterators is that of purpose and clarity – it is much easier to maintain, audit and write matchers over iterators, as they are intended to be declarative in nature.

Here is an example for how the matcher can be implemented on Statemint/e where it should filter reserve transfer from the relay chain:

// See issue <https://github.com/paritytech/polkadot/issues/5233>
pub struct DenyReserveTransferToRelayChain;
impl ShouldExecute for DenyReserveTransferToRelayChain {
	fn should_execute<RuntimeCall>(
		origin: &MultiLocation,
		message: &mut [Instruction<RuntimeCall>],
		_max_weight: Weight,
		_weight_credit: &mut Weight,
	) -> Result<(), ()> {
		message.matcher().match_next_inst_while(
			|_| true,
			|inst| match inst {
				InitiateReserveWithdraw {
					reserve: MultiLocation { parents: 1, interior: Here },
					..
				} |
				DepositReserveAsset {
					dest: MultiLocation { parents: 1, interior: Here }, ..
				} |
				TransferReserveAsset {
					dest: MultiLocation { parents: 1, interior: Here }, ..
				} => {
					Err(()) // Deny
				},
				// An unexpected reserve transfer has arrived from the Relay Chain. Generally,
				// `IsReserve` should not allow this, but we just log it here.
				ReserveAssetDeposited { .. }
					if matches!(origin, MultiLocation { parents: 1, interior: Here }) =>
				{
					log::warn!(
						target: "xcm::barrier",
						"Unexpected ReserveAssetDeposited from the Relay Chain",
					);
					Ok(ControlFlow::Continue(()))
				},
				_ => Ok(ControlFlow::Continue(())),
			},
		)?;

		// Permit everything else
		Ok(())
	}
}

Medium Impact

[NFTs] Rework permissions model

PR: [NFTs] Rework permissions model by jsidorenko · Pull Request #13482 · paritytech/substrate · GitHub

Why is this important?

This PR introduces changes to the permissions model in the pallet-nfts, a collection of non-fungible tokens. The Admin account will no longer be able to transfer or burn items it doesn’t own, and to destroy the collection, there should be zero items left. Some actions were moved from one role to another to simplify accounts management, particularly for complex collections where each role represents a separate service with its own responsibilities.

The Owner can destroy the collection, redeposit, set the team, set the collection max supply, and lock the collection. Admin can set attributes and metadata, lock item properties, and perform actions that were moved from the Owner role. Freezer can lock and unlock item transfer. Issuer can mint tokens, force mint with custom item configuration, update mint settings, and perform actions that were moved from the Owner role.

Why is this change interesting for builders?
The changes introduced in this PR are interesting for builders because they make it easier to create complex non-fungible token collections with multiple roles and responsibilities. The improved security and account management features provide builders with more flexibility and control over their collections.responsibilities.

Yieldable queues for pallet MessageQueue

PR: Yieldable queues for pallet `MessageQueue` by ggwpez · Pull Request #13424 · paritytech/substrate · GitHub

Why is this important?

Introduces a new variant to ProcessMessageError enum, with it a queue hints the message processor to cease servicing this queue and proceed to the next one.

A new implementation for ServiceQueues, NoopServiceQueues that will service queues by doing nothing. We can see the reason for this in the PR description itself.

ServiceQueues cannot be implemented for () due to its associated type.

Lastly, fn process_message in pub trait ProcessMessage sees its signature changed, using now a &mut WeightMeter instead of Weight, and only returning whether the message was processed.

fn process_message(
    message: &[u8],
    origin: Self::Origin,
-   weight_limit: Weight,
+   meter: &mut WeightMeter,
- ) -> Result<(bool, Weight), ProcessMessageError>;
+ ) -> Result<bool, ProcessMessageError>;

Why is this change interesting for builders?

The changes made to ProcessMessageError and ProcessMessage are breaking changes, we have not being able to identify any usage of this pallet downstream and that is why these changes come with no migrations, but if you do, please migrate consequently.

Low Impact

Assets pallet: Giving the asset owner the ability to set minimum balance

PR: https://github.com/paritytech/substrate/pull/13486

Why is this change interesting for builders?
At the moment, there is no way to set minimum balance of an asset by asset owner. However there is a workaround by setting through force_asset_status extrinsic but this requires ForceOrigin.

As a part of this PR, Asset pallet has introduced a new extrinsic set_min_balance to set minimum balance by asset owner. This extrinsic still has some limitations. This extrinsic will only be allowed if:

If there is no account holding the asset

If new min balance is less than the old one

If the asset is not marked as sufficient

Does this change have a related companion PR?
Cumulus companion PR: Companion for #13486 by Szegoo · Pull Request #2253 · paritytech/cumulus · GitHub

Related Issues:

github.com/paritytech/substrate

Allow to update `min_balance` by asset owner for non-sufficient assets in assets pallet

opened 08:28AM - 17 Feb 23 UTC

closed 10:16AM - 02 Mar 23 UTC

IkerAlus

J2-unconfirmed

### Is there an existing issue? - [X] I have searched the existing issues …### Experiencing problems? Have you tried our Stack Exchange first? - [X] This is not a support question. ### Description of bug Once an asset is created with `create` the value assigned to `min_balance` can't be modified again by the asset owner (It can be done with `force_asset_status` but this requires `ForceOrigin`, aka root origin on Statemint/e). On the other hand, the number of decimals, `decimals`, can be always modified by the asset owner with the `set_metadata` call. For external tools, UIs and end users there is a correspondence between minimum balance and number of decimals of an asset. If one of these is modified, the other one should be adapted accordingly. Hence, assets pallet should allow updating `min_balance` of an asset together with the number of decimals. This is particularly interesting soon after the asset is created and its owners are still in the process of deploying the new asset class. Otherwise, they are forced to destroy the asset (two steps process) and create it again. Note that the possibility of updating `min_balance` parameter of an asset should be allow as long as it has no impact in the network. If the asset is made sufficient, then `min_balance` should be only modified by `ForceOrigin`. ### Steps to reproduce Create a new asset class with `create` call and try to change `min_balance` as the asset owner afterwards.

Related PR:

github.com/paritytech/substrate

Assets pallet: Don't allow `set_min_balance` when sufficient

master ← Szegoo:min-balance-fix

opened 01:58PM - 02 Mar 23 UTC

Szegoo

+169 -189

As mentioned [here](https://github.com/paritytech/substrate/pull/13486#issuecomm…ent-1451664289) we shouldn't allow asset owners to decrease the `min_balance` when the asset is marked as sufficient.

Pub enum runtime to pub struct runtime

PR: https://github.com/paritytech/substrate/pull/13250

Why is this change interesting for builders?
Even though construct_runtime! macro accepts both structs and enums at the moment, this PR substitutes all pub enum Runtime declarations with pub struct Runtime in the sake of having a clearer code base.
This is not a breaking change, but please understand this change and apply it as a good practice in your runtime.

Nomination Pool Commission

PR: https://github.com/paritytech/substrate/pull/13128

Why is this important?
With these changes nomination pools receive new functionality, commissions.
A pool can optionally have a commission configuration, via the root role, set with set_commission and claimed with claim_commission. A payee account must be supplied with the desired commission percentage. Beyond the commission itself, a pool can have a maximum commission and a change rate.
Importantly, both max commission set_commission_max and change rate
set_commission_change_rate can not be removed once set, and can only be set to more restrictive values (i.e. a lower max commission or a slower change rate) in subsequent updates.

This is how the new elements look like:

pub struct Commission<T: Config> {
	/// Optional commission rate of the pool along with the account commission is paid to.
	pub current: Option<(Perbill, T::AccountId)>,
	/// Optional maximum commission that can be set by the pool `root`. Once set, this value can
	/// only be updated to a decreased value.
	pub max: Option<Perbill>,
	/// Optional configuration around how often commission can be updated, and when the last
	/// commission update took place.
	pub change_rate: Option<CommissionChangeRate<T::BlockNumber>>,
	/// The block from where throttling should be checked from. This value will be updated on all
	/// commission updates and when setting an initial `change_rate`.
	pub throttle_from: Option<T::BlockNumber>,
}


pub struct CommissionChangeRate<BlockNumber> {
	/// The maximum amount the commission can be updated by per `min_delay` period.
	pub max_increase: Perbill,
	/// How often an update can take place.
	pub min_delay: BlockNumber,

}

/// The maximum commission that can be charged by a pool. Used on commission payouts to bound
/// pool commissions that are > `GlobalMaxCommission`, necessary if a future
/// `GlobalMaxCommission` is lower than some current pool commissions.
#[pallet::storage]
pub type GlobalMaxCommission<T: Config> = StorageValue<_, Perbill, OptionQuery>;

The following extrinsics are available for the root role of a nomination pool to dispatch:

set_commission

set_commission_max

set_commission_change_rate

claim_commission

Participate in the discussion on which values should GlobalMaxCommission have in the related Polkadot forum post.

Salary pallet (#13378)

PR: https://github.com/paritytech/substrate/pull/13378

Why is this change interesting for builders?
A new pallet has been released that allows for periodic payments to members of a ranked collective according to rank.

There are some interesting features such as a “budget” (the total budget per cycle) and setting up a “paymaster” (means by which we can make payments to the account). You can see an example configuration here where the budget and paymaster are configured as the following:

parameter_types! {
	pub const Budget: Balance = 10_000 * DOLLARS;
	pub TreasuryAccount: AccountId = Treasury::account_id();
}

impl pallet_salary::Config for Runtime {
	type WeightInfo = ();
	type RuntimeEvent = RuntimeEvent;
	type Paymaster = pallet_salary::PayFromAccount<Balances, TreasuryAccount>;
	type Members = RankedCollective;
	type Salary = SalaryForRank;
	type RegistrationPeriod = ConstU32<200>;
	type PayoutPeriod = ConstU32<200>;
	type Budget = Budget;
}

You can read the code for the salary pallet here.

Return account’s asset balances

PR: https://github.com/paritytech/substrate/pull/13352

Why is this change interesting for builders?

As a part of this PR, Asset pallet has introduced a new RPC end point account_balances which will return all asset ids with their corresponding balance for an associated account.

Does this change have a related companion PR?
Cumulus companion PR: https://github.com/paritytech/cumulus/pull/2180

Metadata V15: Expose pallet documentation

PR: Metadata V15: Expose pallet documentation by lexnv · Pull Request #13452 · paritytech/substrate · GitHub

Why is this important?

This patch adds the functionality to include pallet documentation in the runtime metadata. Pallet documentation can be defined in different ways such as a doc string, including an external file or including the documentation using the pallet_doc attribute. This new feature allows developers to provide a more detailed description of the pallets, making it easier for other developers to understand and use the pallets. The documentation is included in the runtime metadata and is expanded on the pallet module. Unlike the doc attribute, which is inserted at the beginning of the module, the documentation provided to the pallet_doc attribute is not. This new functionality has been added to the final metadata V15 PR and has been tested in unit tests, UI tests, and subxt. This is important for Polkadot builders because it will make it easier for them to understand the functionality of different pallets, reducing development time and increasing the interoperability of different components.

Code Snippets

#[pallet::pallet]
/// Documentation for pallet 1
#[doc = "Documentation for pallet 2"]
#[doc = include_str!("../README.md")]
#[pallet_doc("../doc1.md")]
#[pallet_doc("../doc2.md")]
pub struct Pallet<T>(_);

2 posts - 1 participant