Polkadot Release Analysis v0.9.36
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
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 <PRUNING_MODE>. (As PROUNING_MODE should be used one mentioned in the error message)
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
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.
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: Use explicit call indices by ggwpez · Pull Request #12891 · paritytech/substrate · GitHub
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: Introduce sensible weight constants by KiChjang · Pull Request #12868 · paritytech/substrate · GitHub
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
Low Impact
(From release 0.9.35)
[pallet-assets] add asset_exists(id: AssetId) function
PR: https://github.com/paritytech/substrate/pull/12782
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<ExpectedOrigin, OriginPrivilegeCmp>;
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