Polkadot Release Analysis v0.9.36 :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 v0.9.36. 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. Help us improve the release analysis by completing this 6 question survey. Summary This release was given high priority due to the inclusion of a fix for the disputes overload faced by Kusama validators in recent weeks, as well as some enhancements to the node’s shutdown process. From the perspective of Parachain builders, there are some new interesting features added to FRAME and the RPC server. Additionally, there are changes to some sensitive weight constants that are worth reviewing. Important Notes about this release/report :information_source: Due to the detected changes in behavior starting a node can run into the error: State Database error: Incompatible pruning modes. To avoid it start your node with the: --state-pruning . (As PROUNING_MODE should be used one mentioned in the error message) :information_source: On account of the previous release (0.9.35) being labeled as optional by the Release Analysis Report team, we have decided to include some of the important changes from that release in this report. The PRs from 0.9.35 will be marked with the following tag: From release 0.9.35 Runtimes built on release v0.9.36 Rococo v9360 Westend v9360 Kusama v9360 Polkadot v9360 :red_exclamation_mark:High Impact Fix wrong rate limit + add a few logs. PR: https://github.com/paritytech/polkadot/pull/6440 Related issue: Disputes Causing Unresponsivenss · Issue #6412 · paritytech/polkadot · GitHub This PR resolves the latest issues identified on Kusama regarding multiple unknown disputes that caused nodes to crash. As described in the PR, there was an incorrect rate limit on unknown disputes. This led to an increasing number of unknown disputes. As the start_send_for_dispute method already applied the limit, the rate_limit.limit(..) call has now been removed. Why is this change interesting for builders? This change is particularly important for teams or individuals who maintain validator infrastructure. :warning: Medium Impact Automatic withdraw_unbonded upon unbond PR: https://github.com/paritytech/substrate/pull/12582 Why is this change interesting for builders? A nomination pool member can unbond the token at any time from the pool. However, presently there are some limitations with unbond function. Specifically, if the MaxUnlockingChunks limit is hit, then the staking pallet will fail to unbond more funds, and it will return an error NoMoreChunks. As a part of this PR, unbond will check whether there is any available chunk slot or not. If no chunk slots are available, withdraw_unbonded will be called implicitly to remove unlocking chunks from the queue. However, in the case that the MaxUnlockingChunks limit gets hit, one may still encounter NoMoreChunks. Use explicit call indices PR: https://github.com/paritytech/substrate/pull/12891 How can this change affects builders? This PR introduces explicit call indices to some pallets. We encourage all builders to follow this practice, moreso if a chain implements a governance system similar to that of Kusama or Polkadot. The reason for this is that governance votes on a (pallet, call) index pair. Meaning that if a pair mutates, then the call to be executed would be distinctly different in comparison to what would be expected. Why is this change interesting for builders? This is good practice in terms of pallet design. Furthermore, this PR has a follow-up #12894, which would emit a warning in case this index has not been explicitly set for a call. rpc server with HTTP/WS on the same socket (From release 0.9.35) PR: https://github.com/paritytech/substrate/pull/12663 How can this change affects builders? In support of the overarching objective of removing the HTTP RPC server completely, this PR adds a new RPC server with support for both, HTTP and WS, on the same socket. If this change is especially interesting for you, our suggestion would be check the details as this PR also includes some new functionality to this socket as tower middleware. Why is this change interesting for builders? The long-term goal is to remove the HTTP RPC server completely and rely on the “mixed WS/HTTP” server, however, the HTTP server has been temporarily retained for backward compatibility, thus enabling time for builders to migrate to the mixed WS/HTTP server. Does this change have a related companion PR? Polkadot companion PR: #6339 Cumulus companion PR: #1905 Ensure that we inform all tasks to stop before starting the 60 seconds shutdown (From release 0.9.35) PR: Ensure that we inform all tasks to stop before starting the 60 seconds shutdown by bkchr · Pull Request #12897 · paritytech/substrate · GitHub How can this change affects builders? Solution for issue #12892. Historically, after killing a node (Ctrl+C) a user would have to wait 60 seconds until the process actually terminated. The reason for this was that tasks were not properly instructed to shut down. With this change the task manager is dropped which will inform all tasks to shut down; this will avoid long waits going forward. Introduce sensible weight constants (From release 0.9.35) PR: https://github.com/paritytech/substrate/pull/12868 How can this change affects builders? This PR removes WEIGHT_PER_{SECOND, MILLIS, MICROS, NANOS} constants and replace them with the following: // primitives/weights/src/lib.rs pub const WEIGHT_REF_TIME_PER_SECOND: u64 = 1_000_000_000_000; pub const WEIGHT_REF_TIME_PER_MILLIS: u64 = 1_000_000_000; pub const WEIGHT_REF_TIME_PER_MICROS: u64 = 1_000_000; pub const WEIGHT_REF_TIME_PER_NANOS: u64 = 1_000; Adding these new ones: pub const WEIGHT_PROOF_SIZE_PER_MB: u64 = 1024 * 1024; pub const WEIGHT_PROOF_SIZE_PER_KB: u64 = 1024; Note that types of this constant have changed from Weight to u64. Does this change have a related companion PR? Polkadot companion PR: #6406 Cumulus companion PR: #1970 Let the PVF host kill the worker on timeout (From release 0.9.35) PR: https://github.com/paritytech/polkadot/pull/6381 Why is this change interesting for builders? An issue of killing PVF worker process was found here. Presently, if a PVF child worker process is timed out then the process would be terminated. This PR makes a small change in the flow so that the host will kill the worker once it gets the TimeOut error. If you are not familiar with what the Parachain Validation Function (PVF) is, there was a nice post about it recently. You can find it here. General Message Queue Pallet (From release 0.9.35) PR: https://github.com/paritytech/substrate/pull/12485 Why is this change interesting for builders? As a part of this PR, A new pallet General Message Queue Pallet has been introduced. The PR and associated issue are very well documented which includes a brief description. The overall purpose of this pallet is to enqueue, store, and process messages. It provides a easily configurable queuing mechanism, which will have a single XCM queue instead of several different XCM message queues. The origin of every message will define into which queue it will be stored. This pallet will be used in multiple scenarios like Message enqueuing, Message processing and Overweight execution. Is there any related issue? #6129 :information_source: Low Impact (From release 0.9.35) [pallet-assets] add asset_exists(id: AssetId) function PR: [pallet-assets] add asset_exists(id: AssetId) function by dharjeezy · Pull Request #12782 · paritytech/substrate · GitHub Why is this change interesting for builders? This PR implements in Assets pallet, a basic functionality to check whether an asset exits. For now this is added only in fungibles::Inspect trait. How this impacts our polkadot builders? Now you do not need to write extra code to verify asset. You can simply call asset_exists. - !T::Assets::minimum_balance(asset_id).is_zero() + T::Assets::asset_exists(asset_id) Is there any related issue? #12444. frame-support: Introduce EnsureOriginOrHigherPrivilege (From release 0.9.35) PR: frame-support: Introduce `EnsureOriginOrHigherPrivilege` by bkchr · Pull Request #12844 · paritytech/substrate · GitHub How can this change affects builders? EnsureOrigin implementation that checks that an origin has equal or higher privilege compared to the expected Origin. It will take the shortcut of comparing the incoming origin with the expected Origin and if both are the same the origin is accepted. The expected Origin can be configured within the runtime like so: parameter_types! { pub const ExpectedOrigin: Origin = Origin::SomethingBelowRoot; } // -- snip -- type EnsureOrigin = EnsureOriginEqualOrHigherPrivilege ; This EnsureOrigin expects something implementing PrivilegeCmp; OriginPrivilegeCmp being the struct with this implementation in the above example. See how OriginPrivilegeCmp is implemented for Kusama runtime here. Remove mem_info and references to parity-util-mem (From release 0.9.35) PR: https://github.com/paritytech/substrate/pull/12795 Why is this change interesting for builders? parity_util_mem is used for parity memory management related utilities. Presently, one of its traits, MallocSizeOf is being used in multiple places. This PR removes the references to parity-util-mem from all locations. You may need to upgrade some dependencies(memory-db, kvdb, kvdb-rocksdb, kvdb-memorydb, trie-bench) to fully remove it from Cargo.lock. Does this change have a related companion PR? Polkadot companion PR: #6374 Is there any related issue? #12658 Your friendly neighbourhood Polkadot Release Analysis team, @hectorb @alejandro @bruno @ayush.mishra

In case you missed the report from the previous release (v0.9.35): [image] Polkadot Release Analysis v0.9.35 Ecosystem Polkadot Release Analysis v0.9.35 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 v0.9.35. This report is complementary to the changelogs, not a replacement. Help us improve the release analysis by filling out this 6 question survey. Summary Please note that this release is for the Kusa…

Hi @ayush.mishra! Those reports are super helpful; thanks for providing them. Out of curiosity: are you compiling these manually or do you have (semi)-automated way?

Hi @dom , I am glad you liked it. Yes, we compile it manually. As mentioned in the beginning of the report, this report considers only those PRs which could impact Polkadot ecosystem builders.

Hello @dom! As Ayush correctly mentioned, we are currently monitoring every pull request (PR) that is merged to the master branch after the previous release. The process is quite manual and the criteria for selecting and categorizing PRs is based on how we consider they might impact parachain builders, tooling developers and infrastructure node related topics. In the near future, we plan to use new GitHub labels where the PR authors can specify the impact on builders. We believe that human curation is still necessary for producing high quality reports. Additionally, we see value in using these posts as a common place for all the ecosystem to share useful information about changes included in the release. Thank you for your feedback!

Polkadot Release Analysis v0.9.36

Ecosystem

alejandro January 2, 2023, 2:43pm 2

In case you missed the report from the previous release (v0.9.35):

Topic		Replies	Views
Polkadot Release Analysis Ecosystem release-analysis	4	2109	December 14, 2022
Polkadot Release Analysis v0.9.33 Ecosystem release-analysis	2	1106	December 15, 2022
Polkadot Release Analysis v0.9.34 Ecosystem release-analysis	7	1489	January 11, 2023
Polkadot Release Analysis v1.3.0 Miscellaneous release-analysis	2	1210	January 11, 2024
Polkadot Release Analysis v0.9.38 Ecosystem release-analysis	1	1248	February 22, 2023

Polkadot Release Analysis v0.9.36

Related topics