# Polkadot Release Analysis v0.9.41 + v0.9.42 **URL:** \ **Category:** Ecosystem\ **Tags:** release-analysis\ **Created:** [May 11, 2023, 12:13pm UTC](https://forum.polkadot.network/t/polkadot-release-analysis-v0-9-41-v0-9-42/2828 "2023-05-11T12:13:42Z")\ **Posts on this page:** 1\ **Showing post:** 1
**Author:** ![ayush.mishra](https://avatars.discourse-cdn.com/v4/letter/a/f14d63/32.png) [@ayush.mishra](https://forum.polkadot.network/u/ayush.mishra)\ **Post date:** [May 11, 2023, 12:13pm UTC](https://forum.polkadot.network/t/polkadot-release-analysis-v0-9-41-v0-9-42/2828/1 "2023-05-11T12:13:42Z")
# 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](https://github.com/paritytech/polkadot/releases/tag/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.](https://forms.gle/gKtXbmZ97a8myQGp7) # 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`](https://paritytech.github.io/substrate/master/frame_support/traits/tokens/fungible/index.html) 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](https://github.com/paritytech/substrate/commit/44998291834b3a36a11c8dede63ce60362f1a3a5): should improve the polling behavior of the channel to speedup the communication between the networking and the syncing code. - [5766265](https://github.com/paritytech/substrate/commit/5766265306d104b4a5d7cf1082bcae78986dfff0): get the correct number of peers. - [7dea636](https://github.com/paritytech/polkadot/pull/6916): reverts [polkadot#6854](https://github.com/paritytech/polkadot/pull/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](https://github.com/paritytech/polkadot/commit/bc7dcf2136eedae65064e8d6772be9a987dd0820): bumps orchestra version to `orchestra = "0.0.5"` as well as adjusting queue sizes in overseer - [1fe1702](https://github.com/paritytech/polkadot/commit/1fe1702508f24b96b136f696fc180d6b27145c8b): 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](https://github.com/paritytech/polkadot/commit/632f1ee1d940027bb17ebf3fb38c3ccae0a3e5a0): 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](https://github.com/paritytech/txwrapper-core) - [v6.0.0](https://github.com/paritytech/txwrapper-core/releases/tag/v6.0.0) - [PR adding transferAllowDeath compatiblity](https://github.com/paritytech/txwrapper-core/pull/299) - [Substrate Sidecar API](https://github.com/paritytech/substrate-api-sidecar) - [v16.0.0](https://github.com/paritytech/substrate-api-sidecar/releases/tag/v16.0.0) - [Polkadot JS API](https://github.com/polkadot-js/api) - [v10.6.1](https://github.com/polkadot-js/api/releases/tag/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](https://github.com/paritytech/substrate/pull/12951) **Why is this change interesting for builders?** This PR introduces breaking changes in [pallet balances](https://paritytech.github.io/substrate/master/pallet_balances/index.html). 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 `reserve`s 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: 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::::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. ```rust 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`](https://github.com/paritytech/substrate/blob/d59d30074e8e2224b2372a631a36e7a53d615310/frame/balances/src/lib.rs#L655-L686) 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](https://github.com/paritytech/polkadot/pull/6780) Cumulus companion PR: [#2334](https://github.com/paritytech/cumulus/pull/2334) Related Issues: [#12918](https://github.com/paritytech/substrate/issues/12918), [#12701](https://github.com/paritytech/substrate/issues/12701) * * * # ⚠ Medium Impact ### Introduce OpenGov into Polkadot PR: [https://github.com/paritytech/polkadot/pull/6701](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](https://wiki.polkadot.network/docs/learn-opengov) **Does this change have a related companion PR?** Cumulus companion PR: [https://github.com/paritytech/cumulus/pull/2186](https://github.com/paritytech/cumulus/pull/2186) ## ### Remove deprecated batch verification PR: [Remove deprecated batch verification by bkchr · Pull Request #13799 · paritytech/substrate · GitHub](https://github.com/paritytech/substrate/pull/13799) **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](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](https://github.com/paritytech/substrate/pull/12951), 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](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](https://github.com/paritytech/substrate/tree/master/frame/nfts) ## ### [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](https://github.com/paritytech/substrate/pull/13760) **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](https://substrate.stackexchange.com/questions/7212/how-to-increase-the-limit-of-pallet-count-in-runtime) This PR increases the pallet limit in the runtime by 50% by modifying the following line in the runtime’s Cargo.toml file: ```rust 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](https://github.com/paritytech/substrate/pull/11813/files). **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](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](https://forum.polkadot.network/t/statemint-update-roadmap/1200). Of note to builders, a [`ForeignFungiblesTransactor`](https://github.com/paritytech/cumulus/pull/2133/files#diff-ac7a0bcd42042c13c01ed93f8296880d277055f6a79ec793296cca9da3488e58) was added and is worthwhile to review. ```rust /// 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](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 --- _[View the full topic](https://forum.polkadot.network/t/polkadot-release-analysis-v0-9-41-v0-9-42/2828)._