# Polkadot Release Analysis v0.9.31 & v0.9.32

: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.31](https://github.com/paritytech/polkadot/releases/tag/v0.9.31) & [release notes v0.9.32](https://github.com/paritytech/polkadot/releases/tag/v0.9.32). 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.***

# Summary

## v0.9.31
This release represents an important step for a diverse set of initiatives arriving on the Polkadot ecosystem. The most exciting (author's opinion) is that Governance v2 (Gov2) is activated on the Kusama runtime! :tada:

Additionally, this release establishes the proper migration for the new field of Weights v2 (as well as introducing the new field `proof_size` in the `Weight` struct) , PoV error preventions around preimages and the introduction of the manual parachain unlocking mechanism among other changes.

## v0.9.32
This release can be considered a patch release of the version `v0.9.31` and it is mostly focused on solving an issue around the RPC call `payment_queryFeeInfo` that breaks many integrations with wallets, dapps, etc. It also includes some PRs that are not mentioned in this report.

<br/>

## Runtimes built on release v0.9.31

- **Rococo v9310**
- **Westend v9310**
- **Kusama v9310**
- **Polkadot v9310**

❗️Please note runtimes Polkadot v9310 & Kusama v9310 are deprecated and will NOT be proposed for upgrade because of the RPC error mentioned on the [#PR 12633](https://github.com/paritytech/substrate/pull/12633)❗️

## Runtimes built on release v0.9.32

- **Rococo v9320**
- **Westend v9320**
- **Kusama v9320**
- **Polkadot v9320**

This runtimes includes the changes from v9310 + [the patch for the RPC](https://github.com/paritytech/substrate/pull/12633).

<br/>

# ❗️High Impact

### [Governance v2 (Kusama only)](https://github.com/paritytech/polkadot/pull/5205)

This PR activates Gov2 on the Kusama runtime! Adding more context to this topic here is replicative as Gavin already explained it. In case you missed the update, here is the blog entry:

[https://polkadot.network/blog/gov2-polkadots-next-generation-of-decentralised-governance/](https://polkadot.network/blog/gov2-polkadots-next-generation-of-decentralised-governance/)

However, we can suppliment with some code related updates pertaining to Gov2:

New pallets added:

- pallet-conviction-voting
- pallet-ranked-collective
- pallet-referenda
- pallet-whitelist

In the `runtime/kusama/src/governance` some new files were added:

**`fellowship.rs`**

This is a temporary file that contains governance code concerning the Polkadot Fellowship. As stated in the comments at the top of the file:

*This is only a temporary arrangement since the Polkadot Fellowship belongs under the Polkadot Relay. However, that is not yet in place, so until then it will need to live here. Once it is in place and there exists a bridge between Polkadot/Kusama then this code can be removed.*

**`origins.rs`**

This file defines the different Origins involved in Gov2.

In the `Origin` enum we can get all the different origins defined: [https://github.com/paritytech/polkadot/pull/5205/files#diff-e2ff2aad6f036e6418cff48b86e36ce4f37ede962af95486fc046f0021a79f0fR34-R89](https://github.com/paritytech/polkadot/pull/5205/files#diff-e2ff2aad6f036e6418cff48b86e36ce4f37ede962af95486fc046f0021a79f0fR34-R89)

**`tracks.rs`**

Defines different constants for configuring tracks and exposes the `TracksInfo` implementation that contains the `tracks()` and `track_for(id: &Self::RuntimeOrigin)` functions.

Each track defines all the information per each “Dan” in the fellowship: [https://github.com/paritytech/polkadot/pull/5205/files#diff-a24c8d8587aeea476b7282a5fbda68fcfc3d134b8f19ba54084aed4647aa5fc0R42-R65](https://github.com/paritytech/polkadot/pull/5205/files#diff-a24c8d8587aeea476b7282a5fbda68fcfc3d134b8f19ba54084aed4647aa5fc0R42-R65)

---

### [**Bound uses of `Call`**](https://github.com/paritytech/substrate/pull/11649)

*Polkadot companion PR: [PR #5729](https://github.com/paritytech/polkadot/pull/5729)*

This PR introduces a new utility type `Bounded<T>` and two new traits `QueryPreimage` and `StorePreimage`. This change prevents PoV-bloat-attack through the unbounded preimage lookups like `PreimageProvider` and `PreimageRecipient` (soon to be deprecated).

A new Scheduler API `scheduler::v3` with updated `Anon`/`Named` traits is also introduced which uses the `Bounded<Call>` (rather than the previous `ValueOrHash<Call>`).

Luckily, this PR is very well documented which includes a brief description as well as specific changes introducing new Runtime primitives, Frame Support, Frame System, Scheduler, Referenda, Preimage and Democracy pallets.

**How this impacts the Polkadot builders?**

Please pay considerable attention on the ****Migration notes****, which describe in detail how to migrate the storage for pallets Democracy, Preimage and Scheduler.

Additionally, something particularly noteworthy, is that as part of this change the Multisig pallet does not store the Calls in the pallet storage anymore. Check details here: [PR #12072](https://github.com/paritytech/substrate/pull/12072)

---

### [Add storage size component to weights](https://github.com/paritytech/substrate/pull/12277)

*⚠️ This change was reverted from release v0.9.30 because some migrations were needed (now included in the [PR #6091](https://github.com/paritytech/polkadot/pull/6091))*

As a continuation of [Weights v1.5 Opaque Struct](https://www.notion.so/BREAKING-Weight-v1-5-Opaque-Struct-2f988363acb84a59818a963df472fa3b) project that was previously discussed in the release v0.9.29, this PR is effectively introducing the `proof_size` field that justifies the whole Weights v2 project. This new field tracks the storage bandwidth used.

pub struct Weight {
	#[codec(compact)]
	/// The weight of computational time used based on some reference hardware.
	ref_time: u64,
	#[codec(compact)]
	/// The weight of storage space used by proof of validity.
	proof_size: u64,
}

While this is another bounding step closer to Weights v2 completion, there is still some work to do that will activate this `proof_size` measure. Please check the remaining items here: [Issue #12176](https://github.com/paritytech/substrate/issues/12176)

---

### [Properly migrate weights to v2](https://github.com/paritytech/polkadot/pull/6091)

The `MigrateToV3<Runtime>` migration for Weights v2 was set up in the [mod v3](https://github.com/paritytech/polkadot/pull/6091/files#diff-5b78372b193e42fcea8ab3e10b232f02354e1b30e5a1960f7859cd633ad7b4d4) (ask GitHub to load diff).

This PR is adding the migration described above to the relay chain runtimes as well as some pallet adjustments over the XCM configuration.

Following is a code sample of the migration configuration on the Kusama runtime:

[https://github.com/paritytech/polkadot/pull/6091/files#diff-0d5d1f76b24989edd69c12c2f482abdf143d8926f1b3191665378b848515d45cR1456](https://github.com/paritytech/polkadot/pull/6091/files#diff-db5840c3c03c740de25aed56b9257559c224a04619c079c94cddbb23f9a855a4R1481)

**Why is this change interesting for Polkadot builders?**

This is one step closer to Weights v2 and it is being natually implemented on Kusama first. Additionally, the migration definition may serve as a baseline code example for additional migrations required as a result of Weights v2.

---

### [Manual Parachain Lock (#5451)](https://github.com/paritytech/polkadot/pull/5451)

Typically, a parachain gets locked after securing a slot on Polkadot via crowdloan. In this manner, participants of said crowdloan can be certain that the registered genesis code or state won’t be changed by the controlled account of the parachain, this avoids certain scenarios where users could be exploited.

While a parachain doesn’t have a manager lock; a subset of actions of the parachain remain under the control of a certain account.

Previously, this lock could then only be removed by root which presented some inconveniences under time sensitive circumstances.

This PR implements functionality that enables the parachain to remove the lock itself, and is no loger solely dependend on root/sudo.

This is not the only change included, the following extrinsics have also been exposed:

- [fn add_lock](https://github.com/paritytech/polkadot/pull/5451/files#diff-ab7d6d99fdfc340b013bbbe8ed039bf09e43f46bbc15c1ebd1cd7db0791d41a9R365)
- [schedule_code_upgrade](https://github.com/paritytech/polkadot/pull/5451/files#diff-ab7d6d99fdfc340b013bbbe8ed039bf09e43f46bbc15c1ebd1cd7db0791d41a9R375)
- [set_current_head](https://github.com/paritytech/polkadot/pull/5451/files#diff-ab7d6d99fdfc340b013bbbe8ed039bf09e43f46bbc15c1ebd1cd7db0791d41a9R389)

---

### [`payment_queryInfo`: Make it work with `WeightV2`](https://github.com/paritytech/substrate/pull/12633) **(v0.9.32)**

[#PR 12277](https://github.com/paritytech/substrate/pull/12277) introduced a Weight format change that makes the RPC Call `payment_queryFeeInfo` to fail. The `query_info` runtime api returns `RuntimeDispatchInfo` which contains the weight and as a result it breaks the decoding for old runtimes. [#PR 12633](https://github.com/paritytech/substrate/pull/12633) fixes the issue by forcing the RPC to always return `WeightV1`.

**How can this change affects the Polkadot builders?**

The runtime API `payment_queryFeeInfo` is widely used by wallets and all kind of applications that needs to calculate the fees for a transaction. Without this change several tools would be affected. Even if a workaround was applied in this case the tooling builders should migrate to the `state_call(TransactionPaymentCallApi_query_call_info)` as soon as possible.

One can find more details about this issue [here](https://substrate.stackexchange.com/questions/5634/rpc-payment-queryfeeinfo-fails-on-westend-9310).

# ⚠️ Medium Impact

### [Enable collation via RPC relay chain node](https://github.com/paritytech/cumulus/pull/1585)

**How this impacts builders?**

Following the effort of decoupling collators and full relay nodes, this PR adds the possibility of pointing the collator to an “external” (non in-process) relay node. This is still considered experimental, and the relay node is suggested to run on the same machine than the collator for the moment.

To specify the relay full node rpc:
`polkadot-parachain --alice --collator --relay-chain-rpc-url <rpc-websocket-url>`

---

### **[rpc: Implement `transaction` RPC API](https://github.com/paritytech/substrate/pull/12328)**

This PR is part of the **RPC API spec** described and being tracked in this issue [#12328](https://github.com/paritytech/substrate/pull/12328).

This change specifically adds two new methods [transaction_unstable_submitAndWatch](https://paritytech.github.io/json-rpc-interface-spec/api/transaction_unstable_submitAndWatch.html#transaction_unstable_submitandwatch) (Submit and watch an extrinsic via RPC pubsub) and [transaction_unstable_unwatch](https://paritytech.github.io/json-rpc-interface-spec/api/transaction_unstable_unwatch.html#transaction_unstable_unwatch) (Unsubscribe) under this new api spec.

The documentation for this can be found specifically in the following link: [`transaction` methods.](https://paritytech.github.io/json-rpc-interface-spec/api/transaction.html) As well as for the whole rpc spec, please see https://github.com/paritytech/json-rpc-interface-spec/

**Why is this change interesting for the Polkadot builders?**

This specification aims at establishing a *lingua franca* between UIs, tools, etc. that would like to access a Substrate-based blockchain, and node client implementations that actually connect to the blockchain (as stated in the documentation introduction). The transaction RPC calls will be highly used for the day to day calls processing.

---

### [frame/utils: introduce `substrate-rpc-client` crate for RPC utils](https://github.com/paritytech/substrate/pull/12212)

This change adds a **`substrate-rpc-client`**  crate that defines the `HeaderProvider`, `HeaderSubscription`, `FinalizedHeaders` structs and its methods in this crate making them reutilizable across all the code base. Implementation details can be checked in the new file: [utils/frame/rpc/client/src/lib.rs](https://github.com/paritytech/substrate/pull/12212/files#diff-4874470be0bbce3da1dbada3de0687fcc25843bc6979cc2475ded4048a2f8d20)

(Also this new crate is replacing **utils/frame/remote-externalities/src/rpc_api.rs.)**

Polkadot companion PR: [PR #6162](https://github.com/paritytech/polkadot/pull/6162)

---

### [Add `force_open_hrmp_channel` Call](https://github.com/paritytech/polkadot/pull/6155)

This PR avoids the extra XCM round trip as well as the ability to avoid a deposit when a channel with a common good parachain is opened.

Essentially, the change focuses on the implementation of the `force_open_hrmp_channel` call that `init_open_channel` & `accept_open_channel` in the same call as root.

More details [here](https://github.com/paritytech/polkadot/pull/6155/files#diff-eb22a633f28e45a4f4b303b7d24ca298e96882492cb3267015e39b7368fc0c24R587-R612).

<br/>

# ℹ️ Low Impact

### [Support running the pallet benchmarks analysis without running the benchmarks](https://github.com/paritytech/substrate/pull/12361)

This PR adds a new argument to the benchmarking CLI: `--json-input <path.json>`

Now it is possible to rerun the analysis part of the benchmark as many times as wanted without the need of running the actual benchmarks every time.

As stated on the PR description the expected use is the following:

- Running the benchmarks once, generating the results with `--json-file`
- Then, execute the analysis with the new argument and the generated result.

This introduces certain separation between the values set on the benchmarks and the different configurations used for the analysis of the results.

---

### **[Vesting pallet - make WithdrawReasons configurable](https://github.com/paritytech/substrate/pull/12109)**

*Polkadot companion PR: [PR #5929](https://github.com/paritytech/polkadot/pull/5929)*

Updates the vesting pallet to support custom `WithdrawReasons` for the vesting lock.

    parameter_types! {
    	pub const MinVestedTransfer: Balance = 100 * DOLLARS;
    	pub UnvestedFundsAllowedWithdrawReasons: WithdrawReasons =
    		WithdrawReasons::except(WithdrawReasons::TRANSFER | WithdrawReasons::RESERVE);
    }
    
    impl pallet_vesting::Config for Runtime {
    	...
    	type WeightInfo = pallet_vesting::weights::SubstrateWeight<Runtime>;
    	type UnvestedFundsAllowedWithdrawReasons = UnvestedFundsAllowedWithdrawReasons;
      ...
    }

---

### **[macro stubs for all pallet:: macros to improve documentation visibility](https://github.com/paritytech/substrate/pull/12334)**

Not critically significant, but quite useful to understand what a macro does behind the scenes. This shows the macro documentation when it’s hovered:


---

### [**Enable the `wasmtime`-based WASM executor by default**](https://github.com/paritytech/substrate/pull/12486)

**Why is this change interesting for the Polakdot builders?**

Before this change only the interpreted WASM executor was included in per default compilations. Making the compiled executor opt-in, now, compiled WASM executor is set by default and an opt-out instead.

**How this impacts the Polkadot builders?**

Users could see a big performance difference between using these two, as more recent versions of the interpreter see a regression in performance.

An example where this has caused problems for builders: [Issue #12320](https://github.com/paritytech/substrate/issues/12320)

---

### [**Punish peers for duplicate GRANDPA neighbor messages**](https://github.com/paritytech/substrate/pull/12462)

**Why is this change interesting for the Polkadot builders?**

The code already contains logic that doesn't allow sending GRANDPA neighbour messages with the same or decreasing set ID / round within a set / finalized number. This PR only enforces this upon reception and reports misbehaving peers.

**How this impacts the Polkadot builders?**

Before this change if a node spammed `Neighbor Messages` its reputation would go up. A modified version of a node would be needed to be able to do this spam on purpose.

---

### **[Rename `from_components` to `from_parts`](https://github.com/paritytech/substrate/pull/12473)**

Rename `from_components` from **Weight** implementation to `from_parts`. Logic remains the same.

- /// Construct [`Weight`] with weight components, namely reference time and storage size weights.
+ /// Construct [`Weight`] from weight parts, namely reference time and proof size weights.
- pub const fn from_components(ref_time: u64, proof_size: u64) -> Self {
+	pub const fn from_parts(ref_time: u64, proof_size: u64) -> Self {
-		Self { ref_time, proof_size }
+		Self { ref_time, proof_size }
	}