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
SIGTERMinstead ofSIGKILLon 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: https://github.com/paritytech/substrate/pull/12951
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.
-
FreezingandHolds:Freezingis similar toLocking, except that they overlap withHolds.Holdsare similar toreserves but are now explicitly designed to be infallibly slashed.Holdsare also named, ensuring that different holds do not accidentally slash each other’s balances. ED do not apply on any balance onholds. BothHoldsandFreezesrequire an identifierHoldIdentifierandFreezeIdentifier, which is configurable. -
New dispatchable function
upgrade_accounts: To upgrade the dormant accounts that use the oldCurrencytrait and ensure that funds are instead placed on hold/frozen. -
Two dispatchables have been renamed:
Balances::set_balance—>Balances::force_set_balanceBalances::transfer—>Balances::transfer_allow_deathNote here that the index of
transferbefore the change was0, where now we havetransfer_allow_deathusing that index. Though, this is only a name change, as the function signature stays untouched. So, this does not require atransaction_versionbump.transferdispatchable can be found with index7, although, it is DEPRECATED and is only there for name compatibility reasons. If your tooling is using this extrinsic, please move over to usingtransfer_allow_deathwithin 3 months from now at which point thetransferalias will be removed. -
Existential Depositwill 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 unpermissionedframe_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
MaxHoldsandMaxFreezesparameters can be set toConstU32<0>andHoldIdentifierandFreezeIdentifiercan 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:
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: https://github.com/paritytech/substrate/pull/13655
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: NFTs 2.0 on Statemine by jsidorenko · Pull Request #2314 · paritytech/cumulus · GitHub
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:
[Fix] Bump tuple element number in frame-support.
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:
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: https://github.com/paritytech/cumulus/pull/2133
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
