Polkadot Release Analysis v0.9.30

# Polkadot Release Analysis v0.9.30 :::warning :warning: ***The following 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](https://github.com/paritytech/polkadot/releases/tag/v0.9.30). 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 The main highlights for this release are related to the disputes slashing/reward mechanism for the parachains protocol and the implementation of the fast unstake pallet, which helps the users to have a better staking experience. These changes do not have a direct day-to-day impact on builders, but are significant changes in the protocol that are worth pointing out. Due to this, we believe these two fit within the Medium category. Additionally, there is likelihood that the underlying changes on the disputes protocol may incur increased support efforts. On the FRAME side, this release brings two breaking changes where some of the types from the `frame_system::Config` trait pallets are renamed. This requires all the definitions in pallets and runtimes to be renamed. Furthermore, there is progression in terms of the Weights v2 project that involves a reorganization around the dispatch methods that were previously defined in the weights crate. ## Runtimes built on this release - **Rococo v9230** - **Westend v9230** - **Kusama v9230** - **Polkadot v9230** # Release highlights ## :heavy_exclamation_mark: High Impact ### [BREAKING: Rename Origin](https://github.com/paritytech/substrate/pull/12258) ### [BREAKING: Rename Call & Event](https://github.com/paritytech/substrate/pull/11981) These PRs rename the following types in the system Config trait: `Call` → `RuntimeCall` `Event` → `RuntimeEvent` `Origin` → `RuntimeOrigin` Why is this important? Due to every pallet having dependency on the `frame_system::Config` trait, all pallets and runtime configurations should be updated for these three associated types to match the new names. If these changes are not made runtime compilation will fail because of types mismatch errors. What was the motivation of this change? The rationale behind this change is the need to distinguish between the calls/events/origins of the runtime (generated by `construct_runtime!` macro) and pallets (generated from `#[pallet::call]` FRAME system macro) in a discrete manner. There is an interesting discussion in this [Stack Exchange post](https://substrate.stackexchange.com/questions/3360/using-scheduler-pallet-to-schedule-contract-pallet-call) about the motivation for this change. - **How to guide / code snippets (expand)** **How to apply these changes to the runtime?** [https://github.com/paritytech/substrate/pull/11981/files#diff-67684005af418e25ff88c2ae5b520f0c040371f1d817e03a3652e76b9485224a](https://github.com/paritytech/substrate/pull/11981/files#diff-67684005af418e25ff88c2ae5b520f0c040371f1d817e03a3652e76b9485224a) **How to apply these changes to a pallet?** The `multisig` pallet is a good example since it contains a `RuntimeCall` type in its `Config`: [https://github.com/paritytech/substrate/pull/11981/files#diff-24d88dbb2cb8e8c19de1d235db557a306c189c2b0e90d40756776ba7261f2130](https://github.com/paritytech/substrate/pull/11981/files#diff-24d88dbb2cb8e8c19de1d235db557a306c189c2b0e90d40756776ba7261f2130) --- ### [Create sp-weights crate to store weight primitives](https://github.com/paritytech/substrate/pull/12219) Why is this important? In this PR, a new crate called `sp-weights` is created to store the `Weight` struct and its associated traits and types. Some existing types related to dispatch have also been relocated to `frame_support::dispatch` as they had never made sense to be grouped with weights. What was the motivation of this change? The primary rationale behind this change is to recognize that the notion of weights reaches far beyond FRAME. Therefore, weights should indeed be a separate crate from `frame_support` or `sp-runtime`. Additional considerations for Polkadot builders. In addition to the new crate `sp-weights`, as alluded to -- there is an important change to draw attention to i.e. the relocation of dispatch methods. Despite functionality being retained, anyone using these methods in their pallets will need to change the import statements. Example: ```rust // Before use frame_support::{ dispatch::{DispatchError, DispatchResultWithPostInfo, Dispatchable, PostDispatchInfo}, weights::{GetDispatchInfo, Pays, Weight}, }; // Now use frame_support::{ dispatch::{ DispatchError, DispatchResultWithPostInfo, Dispatchable, GetDispatchInfo, Pays, PostDispatchInfo, }, weights::Weight, }; ``` For the comprehensive list of all dispatch methods moved from the weights crate to the dispatch crate you can reference the `frame/support/src/dispatch.rs` file in the PR: [https://github.com/paritytech/substrate/pull/12219/files#diff-6faadaafc4a2f7556e8ba9cf9bd8544e5c039e97441e1d470a88c296d39819ed](https://github.com/paritytech/substrate/pull/12219/files#diff-6faadaafc4a2f7556e8ba9cf9bd8544e5c039e97441e1d470a88c296d39819ed) **(ask github to Load Diff)** ## :warning: Medium Impact ### [Fast Unstake Pallet](https://github.com/paritytech/substrate/pull/12129) What is important about this new feature? This change adds more flexibility and lower the barriers when users wants to contribute by staking their funds. From a builder perspective this change does not imply any action needs to be taken. The change is highlighted here as it is a fundamental improvement to one of the core components, and as such should be mentioned. This new pallet adds the following functionality: If a nominator has not actively backed any validators in the last `BondingDuration` (Number of eras that staked funds must remain bonded for days), then they can register themselves in this pallet. The benefit for users being registered to this queue is that they can unstake faster than having to wait an entire bonding duration, and potentially move into a nomination pool. Accounts being registered will be queued, this queue will be processed triggering `force_unstake` call for the nominator account: [https://github.com/paritytech/substrate/blob/e7f994d1e797420f252dd24714b029071ccbc46c/frame/staking/src/pallet/mod.rs#L1364](https://github.com/paritytech/substrate/blob/e7f994d1e797420f252dd24714b029071ccbc46c/frame/staking/src/pallet/mod.rs#L1364) This account will join a nomination pool if a `pool_id` was provided as a parameter in the extrinsic. This PR (included in this release) adds the pallet to all the runtimes: [https://github.com/paritytech/polkadot/pull/6050](https://github.com/paritytech/polkadot/pull/6050) --- ### [Rename anonymous to pure proxy](https://github.com/paritytech/substrate/pull/12283) This change only renames the `anonymous` term across the proxy pallet to the `pure` term. How can this change affect existing codebase/applications? While this change does not involve any functional changes, as it stated in the PR description the rename may break some tooling like PolkadotJS or any other API. **Extrinsics rename** `anonymous` → `create_pure` `kill_anonymous` → `pure_account` **Pallet impl fn rename:** `anonymous_account` → `pure_account` **Events rename** `AnonymousCreated` → `PureCreated` --- ### [Using array-bytes for Array/Bytes/Hex Operation](https://github.com/paritytech/substrate/pull/12190) Someone from the community put a new library called `array-bytes` that replaces the crates `hex-literal` & `hex crates`. This library is optimized for Substrate development since is based on all non-std and includes some helpers that makes conversions easier. Docs: [https://docs.rs/array-bytes/latest/array_bytes/](https://docs.rs/array-bytes/latest/array_bytes/) How does this change help? Even if it’s not mandatory to migrate to this new library, the fact that is 100% no-std and it adds some conversions helpers, makes an attractive library to give a try. Also as it is now being used across all the Substrate repository is close to become the standard. - **How to / Code Snippets (expand)** For example, the `sp_core::H256` has implemented the `From<[u8; 32]>`. With this crate, you could write something like: ```rust // better error handling let hash = array_bytes::hex_into::<H256, _>("0x840cff528f0a427cf1405cc474c76b369890fc01951c73c71ae1e2ad1e8baa7d").expect("valid hex; qed"); // also provides an infallible method let hash = array_bytes::hex_into_unchecked::<H256, _>("0x840cff528f0a427cf1405cc474c76b369890fc01951c73c71ae1e2ad1e8baa7d"); // For `AccountId32` let account = array_bytes::hex_into::<AccountId32, _>("0x840cff528f0a427cf1405cc474c76b369890fc01951c73c71ae1e2ad1e8baa7d").expect("valid hex; qed"); let account = array_bytes::slice_into::<AccountId32, _>(&[100, 118, 109, 58, 0, 0, 0, 0, 0, 0, 0, 213, 244, 148, 7, 4, 235, 76, 229, 228, 181, 24, 119, 212, 155, 88, 163, 233, 53, 49, 182, 96]).expect("valid data; qed"); ``` Please refer to this [comment](https://github.com/paritytech/substrate/issues/12111#issuecomment-1227255334) for more high level details about this change. --- ### [Const impls of base arithmetics for Weights with u64](https://github.com/paritytech/substrate/pull/12322) What is important about this change? This PR is adding a simple arithmetics methods to the Weights v2 struct that are mostly targeting constants definitions. As in Rust, the `unwrap()` is not available for const. Additionally, the checked versions are not particularly usable presently. **New methods available [HERE](https://github.com/paritytech/substrate/pull/12322/files#diff-ffca7028457970b52799e56e0c224d164dc90c39d991140a7e757e877e2130c1R163-R190)** What is interesting about this change? Defining constant values for weights is a common practice during runtime configuration. The implementation of these methods enable a significant improvement vis-à-vis runtime constant configuration. Example: [HERE](https://github.com/paritytech/substrate/blob/master/bin/node/runtime/src/lib.rs#L174) **Important consideration about why this is not catching errors explicitly:** [https://github.com/paritytech/substrate/pull/12322#issuecomment-1256661572](https://github.com/paritytech/substrate/pull/12322#issuecomment-1256661572) --- ### [Remove Ord impl for Weights V2 and add comparison fns](https://github.com/paritytech/substrate/pull/12183) With the new Weight struct normal ordering does not quite make sense, as it introduces ambiguity, e.g. > do we mean that *all* constituent weights need to be compared, or *any* one of them would suffice? > So, the functions available for comparisons/ordering now take care of the different vectors present in Weight. **New methods available [HERE](https://github.com/paritytech/substrate/pull/12183/files#diff-94afd287444d416e8c180cdce2d18388ffe71aa71690d41c09bef13f5da2184fR165-R219)** Why is this important to know? Managing weights over the runtime or in pallets is a very common practice, as Weighs v2 is one of the most important changes from this year, all the changes in how builders interacts with this new api are important. --- ### [rpc: Implement chainSpec RPC API](https://github.com/paritytech/substrate/pull/12261) This PR lays the ground for the implementation of the RPC spec and adds the `chainSpec` methods. The RPC methods are placed in the `rpc-spec` crate subject to change in the future. The `chainSpec` methods include: - `chainSpec_unstable_chainName` - Get the chain name, as present in the chain specification. - `chainSpec_unstable_genesisHash` - Get the chain's genesis hash. - `chainSpec_unstable_properties` - Get the properties of the chain, as present in the chain specification. How is this useful? The information gathered from these chain spec RPC api can be useful for tooling, but more importantly this PR is part of a bigger task which is a new JSON-RPC interface that will accomodate multiple kinds of audiences: - End-user-facing applications that want to read and interact with the blockchain. - Node operators that want to make sure that their node is operating correctly, and perform some administrative operations such as rotating keys. - Core/parachain developers that want to manually look at the storage and figure out what is happening on the blockchain. - Oracles or bridges that need to be able to read and interface with the blockchain. - Archivers that want to look at past data. More information: https://github.com/paritytech/substrate/issues/12071 - **How To (collapse)** ```rust $ curl -H "Content-Type: application/json" -d '{"id":1, "jsonrpc":"2.0", "method": "chainSpec_unstable_properties"}' http://localhost:9933/ {"jsonrpc":"2.0","result":{},"id":1} curl -H "Content-Type: application/json" -d '{"id":1, "jsonrpc":"2.0", "method": "chainSpec_unstable_chainName"}' http://localhost:9933/ {"jsonrpc":"2.0","result":"Development","id":1} curl -H "Content-Type: application/json" -d '{"id":1, "jsonrpc":"2.0", "method": "chainSpec_unstable_genesisHash"}' http://localhost:9933/ {"jsonrpc":"2.0","result":"0x7d341d884f3bea9b5668d29be58ac5e307d57122a7df21021a2099ffdd609928","id":1} ``` --- ### [runtime/disputes: slashing](https://github.com/paritytech/polkadot/pull/5535) As part of the disputes module description, the loosing side of the validators will suffer a slashing as a result of a misbehaviour. [Specs of the dispute module](https://paritytech.github.io/polkadot/book/runtime/disputes.html) Slashing logic: - Validator who voted that a valid (decided by a supermajority) candidate (parachain block) is invalid will be slashed **0.1%** of their stake (including nominators). This can happen to very slow validators that timeout during a PVF execution. - Validator who voted that a invalid (decided by a supermajority) candidate (parachain block) is valid will be slashed **100%** of their stake (including nominators) and kicked out of the validator set. This can happen to malicious validators or validators that are >6x faster than the supermajority (we have 2s timeout for backing and 12s for approval-voting). This PR specifically implements the runtime logic for disputes/slashing for Westend and Rococo runtimes but not for Kusama and Polkadot. Kusama and Polkadot runtimes just receives a type name change from `PunishValidators` to `SlashingHandler` but nothing else. There is an opened PR for activating slashing on Kusama: https://github.com/paritytech/polkadot/pull/5974 but is still on hold because of the discussions described in this forum entry: [https://forum.parity.io/t/slashing-known-issues-disputes-enablement/1219](https://forum.parity.io/t/slashing-known-issues-disputes-enablement/1219) **Note** This change does not change anything from the Polkadot ecosystem developer perspective, but is a key process in the whole protocol design. Being aware of this change might be useful for the support related activities. --- ### [Disputes rewards](https://github.com/paritytech/polkadot/pull/5862) This change is very related to the disputes/slashing mentioned above since it’s the other side of the disputes result: after a disputes resolution, the wining side gets rewarded. The wining side of the disputes receives 20 era points as per definition in the runtime. ```rust /// The amount of era points given by dispute voting on a candidate. pub const DISPUTE_STATEMENT_POINTS: u32 = 20; ``` Something to take into account is that slashing and rewarding mechanisms from disputes parachain module, are integrated with the staking pallet. Note: This is enabled for Westend and Kusama runtimes. --- ### [add inspect trait for asset roles](https://github.com/paritytech/substrate/pull/11738) This is a very useful change over the pallet_assets that permit query the asset account roles as `owner`, `issuer`, `admin` and `freezer`. ### Trait definition **frame/assets/src/impl_fungibles.rs** How can this change benefit the ecosystem? In XCM we can configure the behaviour of the asset when the message arrives/leaves the chain. With this new feature that provide these roles trough this new trait `Inspect` , in combination with the `Barrier` XCM config, we might add filters based on accounts for a certain asset. --- ### [Add special tag to exclude runtime storage items from benchmarking](https://github.com/paritytech/substrate/pull/12205) The Substrate runtime takes advantage of a storage cache where the first read of a storage item places an item in the cache, and subsequent reads of that item happen in memory. There are some storage items which we know will be accessed every block, and thus we ignore reads to these items already in our benchmarking: ```rust let whitelist: Vec<TrackedStorageKey> = vec![ // Block Number hex_literal::hex!("26aa394eea5630e07c48ae0c9558cef702a5c1b19ab7a04f536c519aca4983ac").to_vec().into(), // Total Issuance hex_literal::hex!("c2261276cc9d1f8598ea4b6a74b15c2f57c875e4cff74148e4628f264b974c80").to_vec().into(), ... ]; ``` This PR adds a `#[pallet::whitelist_storage]` attribute macro that can be applied to storage item declarations. Doing so will result in that storage item's storage key being automatically added to the whitelist shown above, meaning they will be excluded from benchmarking calculations. The PR also replaces the existing hard-coded whitelist with `[pallet::whitelist_storage]` calls that will instead generate the list organically. ## :information_source: Low Impact ### [pallet-identity: New registar check](https://github.com/paritytech/substrate/pull/12170) Prevents sticking a tx before the approve which changes the identity info. `provide_judgment` extrinsic now takes a new `identity` parameter. **Details:** ```rust pub fn provide_judgement( origin: OriginFor<T>, #[pallet::compact] reg_index: RegistrarIndex, target: AccountIdLookupOf<T>, judgement: Judgement<BalanceOf<T>>, identity: T::Hash, ) -> DispatchResultWithPostInfo { // --snip } ``` And adds a new error for the pallet: ```rust /// The provided judgement was for a different identity. JudgementForDifferentIdentity, ``` **Solution for the following problem:** A user can call `set_identity` and `request_judgement` with a valid identity and convince the registrar that this identity is correct. After that the registrar will submit a call to `provide_judgement` with a positive `Judgement`. However, this call is not bound to the confirmed identity. The significance of this call can be summarized as "I confirm that the identity set by `target` is correct." --- ### [Add `ConstFeeMultiplier` to the transaction payment pallet](https://github.com/paritytech/substrate/pull/12222) Implements a new `ConstFeeMultiplier<Get<Multiplier>>` struct that implements `MultiplierUpdate` and `Convert` traits in the `transaction-payment` pallet. This permits to set the constant accordingly as a type and to count with some helpers function. This change is solving mostly the issue on the node template where the default implementation was returning `0` instead of the expected value `1` , making transaction weights to be discarded. ```rust parameter_types! { pub FeeMultiplier: Multiplier = Multiplier::one(); } impl pallet_transaction_payment::Config for Runtime { ... type FeeMultiplierUpdate = ConstFeeMultiplier<FeeMultiplier>; } ``` --- ### [support upgrade hooks to directly pass data](https://github.com/paritytech/substrate/pull/12185) This PR lets to replace the previous method to share data between the `pre_upgrade` and the `post_upgrade` hook which was storing the value in the runtime storage (making the storage root to be changed during the execution of either hook). So now the pre_upgrade hook can retrieve a `Vec<u8>` as a Result and the post_upgrade hook can receive that `Vec<u8>` as input parameter. pre_upgrade and post_upgrade fn definitions: ```rust fn pre_upgrade() -> Result<Vec<u8>, &'static str> { Ok(Vec::new()) } fn post_upgrade(_state: Vec<u8>) -> Result<(), &'static str> { Ok(()) } ``` --- ### [Add base-weight to System::Extrinsic* events](https://github.com/paritytech/substrate/pull/12329) This PR fixes a problem with the weights used reported on PolkadotJS. The problem resided in that the `ExtrinsicSuccess` method did not included the `ExtrinsicBaseWeight`. Before the change a Remark call used to show 0 and now PolkadotJS shows the correct weight of a Remark: ```rust 87_298_000 = 86_298_000 (base) + 1_000_000 (remark) ``` This is identical to the result of `System::blockWeight(block_hash)` in that case.

Syntax	Example	Reference
# Header	Header	基本排版
- Unordered List	Unordered List
1. Ordered List	Ordered List
- [ ] Todo List	Todo List
> Blockquote	Blockquote
Bold font	Bold font
Italics font	Italics font
~~Strikethrough~~	~~Strikethrough~~
19^th^	19^th
H~2~O	H₂O
++Inserted text++	Inserted text
==Marked text==	Marked text
[link text](https:// "title")	Link
![image alt](https:// "title")	Image
`Code`	`Code`	在筆記中貼入程式碼
```javascript var i = 0; ```	`var i = 0;`
:smile:		Emoji list
{%youtube youtube_id %}	Externals
$L^aT_eX$	L^aT_eX
:::info This is a alert area. :::	This is a alert area.