ayush.mishra
Thu, 11 May 2023 12:13:42 +0000
Ecosystem

Polkadot Release Analysis v0.9.41 + v0.9.42

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.42. 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

This report contains information about release v0.9.41 and the release v0.9.42. It is important to mention that release v0.9.41 is a client only release that addresses some networking issues observed after nodes started upgrading to v0.9.40.

As for v0.9.42 we have very interesting changes like introducing OpenGov to Polkadot runtime, updates to pallet balances, and deprecating Currency in favour of fungible traits.

The following is an extra section covering only release v0.9.41.

Release v0.9.41

Prior to this release we have seen multiple reports of nodes falling out of sync. The assumption is that this was related to the sync refactoring that changed the way the syncing code communicates with the networking code. Before the refactoring the communication was done synchronously as part of the networking code. With the refactoring, networking communicated via an asynchronous channel with the syncing code. The metrics indicated that this channel was growing significantly.

The following Polkadot commits should prevent the dispute issues we have seen some weeks ago on Kusama and Polkadot.

4499829: should improve the polling behavior of the channel to speedup the communication between the networking and the syncing code.

5766265: get the correct number of peers.

7dea636: reverts polkadot#6854, these are the versions of the relevant dependencies after the change:
orchestra = "0.0.4"
metered = "0.2.0"
rayon = "1.5.1"

bc7dcf2: bumps orchestra version to orchestra = "0.0.5" as well as adjusting queue sizes in overseer

1fe1702: upgrading node binary in place without restart may lead to weird behavior and produce disputes, this commit adds checks the spawned worker version vs the node version before PVF preparation.

632f1ee: Use SIGTERM instead of SIGKILL on PVF worker version mismatch.

Release v0.9.42

Runtimes built on release v0.9.42

Rococo v9420

Westend v9420

Kusama v9420

Polkadot v9420

Tooling Section

TxWrapper Core - v6.0.0 - PR adding transferAllowDeath compatiblity

Substrate Sidecar API - v16.0.0

Polkadot JS API - v10.6.1

High Impact

Deprecate Currency; introduce holds and freezing into fungible traits

PR: Deprecate `Currency`; introduce holds and freezing into `fungible` traits by gavofyork · Pull Request #12951 · paritytech/substrate · GitHub

Why is this change interesting for builders?

This PR introduces breaking changes in pallet balances. The PR is detailed, we will be highlighting some of the changes, however we recommend developers to read the PR themselves as it has a wealth of information including notes on upgrading.

1. Freezing and Holds: Freezing is similar to Locking, except that they overlap with Holds. Holds are similar to reserves but are now explicitly designed to be infallibly slashed. Holds are also named, ensuring that different holds do not accidentally slash each other’s balances. ED do not apply on any balance on holds. Both Holds and Freezes require an identifier HoldIdentifier and FreezeIdentifier, which is configurable.

2. New dispatchable function upgrade_accounts: To upgrade the dormant accounts that use the old Currency trait and ensure that funds are instead placed on hold/frozen.

3. Two dispatchables have been renamed:

Balances::set_balance —> Balances::force_set_balance

Balances::transfer —> Balances::transfer_allow_death

Note here that the index of transfer before the change was 0, where now we have transfer_allow_death using that index. Though, this is only a name change, as the function signature stays untouched. So, this does not require a transaction_version bump. transfer dispatchable can be found with index 7, although, it is DEPRECATED and is only there for name compatibility reasons. If your tooling is using this extrinsic, please move over to using transfer_allow_death within 3 months from now at which point the transfer alias will be removed.

4. Existential Deposit will be required in addition to any amount to be reserved, in other words, held/reserved balance does not contribute to the ED any longer. As stated in PR description, this is the biggest BREAKING CHANGE because test-cases and benchmarking may result in failure. If you need to allow any account to have a zero balance and retain associated account data, you must introduce a pallet which allows an unpermissioned frame_system::Pallet::<Runtime>::inc_providers().

How to use

The following are some notes to take into account when applying this change, but please, don’t stop reading the Upgrading section and Important Notes in the description of the PR.

As mentioned above, four new config parameters have been added, so if you are using pallet balances you need to do the following update in your runtime, otherwise compilation will fail.

impl pallet_balances::Config for Test {
	// Existing parameters
	type HoldIdentifier = ();
	type FreezeIdentifier = ();
	type MaxHolds = ConstU32<0>;
	type MaxFreezes = ConstU32<0>;
}

Until you introduce pallets which use holds and freezes, the MaxHolds and MaxFreezes parameters can be set to ConstU32<0> and HoldIdentifier and FreezeIdentifier can be set as() like in the above example.

After introducing a runtime with this change in it, chains should ensure that all accounts are upgraded by repeatedly calling update_accounts giving it account IDs which are not yet upgraded. A script which does this shall be provided.

Pallets which use the existing set of Currency traits should be refactored to use the fungible traits. Aside from the actual code change, a gateway function (ensure_upgraded) should be introduced and called prior to any mutating operations to ensure that any accounts using the old Currency traits are unreserved/unlocked and said funds are instead placed on hold/frozen. A permissionless fee-free dispatchable should also be introduced (upgrade_accounts), similar to that of the Balances pallet, which is able to do this for dormant accounts.

Eventually Currency traits, Locks and Reserves will be deprecated and removed, so it is important to apply this changes in a timely manner.

Does this change have a related companion PR?

Polkadot companion PR: #6780
Cumulus companion PR: #2334

Related Issues:
#12918, #12701

Medium Impact

Introduce OpenGov into Polkadot

PR: https://github.com/paritytech/polkadot/pull/6701

Why is this change interesting for builders?

This PR introduces OpenGov into Polkadot. If you’re not familiar with OpenGov which is already live on Kusama then please read this:

Web3 and Polkadot - Polkadot Wiki

Does this change have a related companion PR?

Cumulus companion PR: https://github.com/paritytech/cumulus/pull/2186

Remove deprecated batch verification

PR: Remove deprecated batch verification by bkchr · Pull Request #13799 · paritytech/substrate · GitHub

Why is this important?

Removes signature batching verification from the runtime primitives as this was never activated. Even so, the host functions will be kept to allow backwards compatibility with older runtimes.

How does this impact the Polkadot builders?

This change breaks the API, now runtimes will not be able to call these functions and the host functions have been modified so they won’t do the actual batch verification but will verify the passed signature instead.

At the same time TaskExecutorExt is removed as it only was there to support batch verification. If your code was using this extension, please consider removing its registration.

Why is this change interesting for builders?

For instance, this won’t be able to be called from the runtime anymore
sp_io::crypto::start_batch_verification

Make ED of zero (kind of) work

PR: Make ED of zero (kind of) work by gavofyork · Pull Request #13655 · paritytech/substrate · GitHub

Why is this change interesting for builders?

In the high impact section, we have mentioned that after the Deprecate Currency PR, accounts now require a minimum of ED on top of any reserved funds, as these reserved / held funds do not account any longer for the ED and, as usual, the minimum amount required to keep an account open must be grater than zero. In the above mentioned PR this is highlighted as a BREAKING CHANGE.

There may be scenarios and use cases where we may need an ED of zero to be supported. As part of this PR, ED can be set to zero by enabling the feature insecure_zero_ed. However, it is recommended to keep the minimum amount greater than zero and it is strongly not recommended to enable this feature because if you have multiple sources of provider references, you may also get unexpected behaviour if you set this to zero.

Low Impact

NFTs 2.0 on Statemine

PR: https://github.com/paritytech/cumulus/pull/2314

Why is this change interesting for builders?

This PR adds pallet NFTs to Statemine. This pallet has a number of features in regards to NFTs. If you’re not familiar with pallet NFTs, you can start here:

substrate/frame/nfts at master · paritytech/substrate · GitHub

[Fix] Bump tuple element number in frame-support.

PR: [Fix] Bump tuple element number in frame-support. by ruseinov · Pull Request #13760 · paritytech/substrate · GitHub

Why is this change interesting for builders?

There was an issue brought up in the Substrate StackExchange community where a dev hit the limit of pallets allowed in the runtime:

How to increase the limit of pallet count in runtime? - Substrate and Polkadot Stack Exchange

This PR increases the pallet limit in the runtime by 50% by modifying the following line in the runtime’s Cargo.toml file:

frame-support = { version = "4.0.0-dev", default-features = false, path = "../../../frame/support", features = ["tuples-96"] }

If needed there is also a higher limit which can be found here.

How does this impacts the Polkadot builders?

Your runtime now supports more pallets.

Add Support for Foreign Assets

PR: Add Support for Foreign Assets by joepetrowski · Pull Request #2133 · paritytech/cumulus · GitHub

Why is this change interesting for builders?

As the PR so nicely states, this PR adds support to Statemine and Westmint for foreign fungible assets. This will allow other parachains to represent their assets, as well as bridges to represent assets from other networks, on Statemine. A follow up PR will introduce this to Statemint once it has been audited and in the Kusama coal mines for some time.

How does this impacts the Polkadot builders?

This is part of a broader plan of introducing a DEX to Statemint. Discussion on this topic can be found in the Statemint Update / Roadmap on the Polkadot Forum.

Of note to builders, a ForeignFungiblesTransactor was added and is worthwhile to review.

/// Means for transacting foreign assets from different global consensus.
pub type ForeignFungiblesTransactor = FungiblesAdapter<
	// Use this fungibles implementation:
	ForeignAssets,
	// Use this currency when it is a fungible asset matching the given location or name:
	ForeignAssetsConvertedConcreteId,
	// Convert an XCM MultiLocation into a local account id:
	LocationToAccountId,
	// Our chain's account ID type (we can't get away without mentioning it explicitly):
	AccountId,
	// We dont need to check teleports here.
	NoChecking,
	// The account to use for tracking teleports.
	CheckingAccount,
>;

[Contracts] Overflowing bounded DeletionQueue

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

Why is this change interesting for builders?

Prior to this PR, pallet contracts had DeletionQueueDepth as part of its config.

This config type was set to 128 in the kitchensink runtime meaning that if a malicious actor wanted to prevent a contract from being deleted, they could do a DOS by terminating 128 other contracts and therefore subsequent attempts of terminating contracts would fail. This PR fixes this issue by updating the storage to use a StorageMap instead of the current Bounded Vec used to keep track of contracts marked for deletion.

How does this impacts the Polkadot builders?

If you are using pallet contracts, make sure you also have this properly configured.

Your friendly neighbourhood Polkadot Release Analysis team,
@alejandro @ayush.mishra @bruno

4 posts - 4 participants