Polkadot Release Analysis v0.9.30

# Polkadot Release Analysis v0.9.30 ***Longer Version*** :::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 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.*** ::: ## Changes 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 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 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 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` --- ### [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. **List of methods:** ```rust /// Constant version of Add with u64. /// /// Is only overflow safe when evaluated at compile-time. pub const fn add(self, scalar: u64) -> Self { Self { ref_time: self.ref_time + scalar } } /// Constant version of Sub with u64. /// /// Is only overflow safe when evaluated at compile-time. pub const fn sub(self, scalar: u64) -> Self { Self { ref_time: self.ref_time - scalar } } /// Constant version of Div with u64. /// /// Is only overflow safe when evaluated at compile-time. pub const fn div(self, scalar: u64) -> Self { Self { ref_time: self.ref_time / scalar } } /// Constant version of Mul with u64. /// /// Is only overflow safe when evaluated at compile-time. pub const fn mul(self, scalar: u64) -> Self { Self { ref_time: self.ref_time * scalar } } ``` 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: ```rust const MAXIMUM_BLOCK_WEIGHT: Weight = WEIGHT_PER_SECOND.mul(2); parameter_types! { pub const BlockHashCount: BlockNumber = 2400; pub const Version: RuntimeVersion = VERSION; pub RuntimeBlockLength: BlockLength = BlockLength::max_with_normal_ratio(5 * 1024 * 1024, NORMAL_DISPATCH_RATIO); pub RuntimeBlockWeights: BlockWeights = BlockWeights::builder() .base_block(BlockExecutionWeight::get()) .for_class(DispatchClass::all(), |weights| { weights.base_extrinsic = ExtrinsicBaseWeight::get(); }) .for_class(DispatchClass::Normal, |weights| { weights.max_total = Some(NORMAL_DISPATCH_RATIO * MAXIMUM_BLOCK_WEIGHT); }) .for_class(DispatchClass::Operational, |weights| { weights.max_total = Some(MAXIMUM_BLOCK_WEIGHT); // Operational transactions have some extra reserved space, so that they // are included even if block reached `MAXIMUM_BLOCK_WEIGHT`. weights.reserved = Some( MAXIMUM_BLOCK_WEIGHT - NORMAL_DISPATCH_RATIO * MAXIMUM_BLOCK_WEIGHT ); }) .avg_block_initialization(AVERAGE_ON_INITIALIZE_RATIO) .build_or_panic(); } ``` 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: ```rust /// Returns true if any of `self`'s constituent weights is strictly greater than that of the /// `other`'s, otherwise returns false. pub const fn any_gt(self, other: Self) -> bool { self.ref_time > other.ref_time } /// Returns true if all of `self`'s constituent weights is strictly greater than that of the /// `other`'s, otherwise returns false. pub const fn all_gt(self, other: Self) -> bool { self.ref_time > other.ref_time } /// Returns true if any of `self`'s constituent weights is strictly less than that of the /// `other`'s, otherwise returns false. pub const fn any_lt(self, other: Self) -> bool { self.ref_time < other.ref_time } /// Returns true if all of `self`'s constituent weights is strictly less than that of the /// `other`'s, otherwise returns false. pub const fn all_lt(self, other: Self) -> bool { self.ref_time < other.ref_time } /// Returns true if any of `self`'s constituent weights is greater than or equal to that of the /// `other`'s, otherwise returns false. pub const fn any_gte(self, other: Self) -> bool { self.ref_time >= other.ref_time } /// Returns true if all of `self`'s constituent weights is greater than or equal to that of the /// `other`'s, otherwise returns false. pub const fn all_gte(self, other: Self) -> bool { self.ref_time >= other.ref_time } /// Returns true if any of `self`'s constituent weights is less than or equal to that of the /// `other`'s, otherwise returns false. pub const fn any_lte(self, other: Self) -> bool { self.ref_time <= other.ref_time } /// Returns true if all of `self`'s constituent weights is less than or equal to that of the /// `other`'s, otherwise returns false. pub const fn all_lte(self, other: Self) -> bool { self.ref_time <= other.ref_time } /// Returns true if any of `self`'s constituent weights is equal to that of the `other`'s, /// otherwise returns false. pub const fn any_eq(self, other: Self) -> bool { self.ref_time == other.ref_time } // NOTE: `all_eq` does not exist, as it's simply the `eq` method from the `PartialEq` trait. ``` 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. - **How to guide / Code Snippets** Find here some code snippets from our code base ```rust // frame/multisig/src/lib.rs // --snip ensure!(call.get_dispatch_info().weight.all_lte(max_weight), Error::<T>::MaxWeightTooLow ); // --snip ``` ```rust // frame/scheduler/src/lib.rs // --snip if !hard_deadline && order > 0 && test_weight.any_gt(limit) { // --snip ``` ```rust // frame/staking/src/tests.rs // --snip assert!(zero_nom_payouts_weight.any_gt(Weight::zero())); assert!(half_max_nom_rewarded_weight.any_gt(zero_nom_payouts_weight)); assert!(max_nom_rewarded_weight.any_gt(half_max_nom_rewarded_weight)); // --snip ``` 🧠 Keep in mind that solo chains might choose to not care about one of the components conforming the new Weight struct (right now only time is in place, but size will eventually be included). And it will be up to these teams to set the correct configuration for the limits of each component. So, if size complexity is not of interest for one solo chain implementation, then options are either setting an infinite limit on their source code, or taking care of describing every Weight with `size=0`. --- ### [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 helps? 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 repo 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"); ``` Migration examples: ```rust //Before assert!(hex::decode(buf).is_ok()); //Now assert!(array_bytes::hex2bytes(&buf).is_ok()); ------- //Before assert!(sr25519::Pair::from_seed_slice(&hex::decode(&seed[2..]).unwrap()) //Now assert!(sr25519::Pair::from_seed_slice(&array_bytes::hex2bytes_unchecked(&seed)) -------- // Before #[error("Invalid hexadecimal string data")] HexDataConversion(#[from] hex::FromHexError), // Now #[error("Invalid hexadecimal string data, {0:?}")] HexDataConversion(array_bytes::Error), ``` Please refer to this [comment](https://github.com/paritytech/substrate/issues/12111#issuecomment-1227255334) for more high level details about this change. --- ### [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 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 builder perspective, but is a key process in the whole protocol design. Being aware of this change might be useful for the support team that might be face questions on the sdk node side. --- ### [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. --- ### [Remove discarded blocks and states from database by default](https://github.com/paritytech/substrate/pull/11983) Block header and bodies currently account for 90% of the database size on disk. By default the node keeps all headers and bodies in the database, even ones that are not in the finalized chain. So this change adds the `archive-canonical` parameter to the `--block-prunning` and `--state-prunning` parameters. This permits to keep the blocks that are only finalized as well as only the state related to finalized blocks. Why is this change important? This is a major optimization to the DB size being used for block and state tracking. By setting these flags when we run the node, the DB size needed is less and as a result in the long term this might benefit the performance of DB IO. --- ### [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 accounts from the asset account roles. ### Trait definition **frame/assets/src/impl_fungibles.rs** ```rust impl<T: Config, I: 'static> fungibles::roles::Inspect<<T as SystemConfig>::AccountId> for Pallet<T, I> { fn owner(asset: T::AssetId) -> Option<<T as SystemConfig>::AccountId> { Asset::<T, I>::get(asset).map(|x| x.owner) } fn issuer(asset: T::AssetId) -> Option<<T as SystemConfig>::AccountId> { Asset::<T, I>::get(asset).map(|x| x.issuer) } fn admin(asset: T::AssetId) -> Option<<T as SystemConfig>::AccountId> { Asset::<T, I>::get(asset).map(|x| x.admin) } fn freezer(asset: T::AssetId) -> Option<<T as SystemConfig>::AccountId> { Asset::<T, I>::get(asset).map(|x| x.freezer) } } ``` 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. - **How to (expand)** The following test suite shows how we can use these new trait. ```rust #[test] fn querying_roles_should_work() { new_test_ext().execute_with(|| { use frame_support::traits::tokens::fungibles::roles::Inspect; assert_ok!(Assets::force_create(Origin::root(), 0, 1, true, 1)); assert_ok!(Assets::set_team( Origin::signed(1), 0, // Issuer 2, // Admin 3, // Freezer 4, )); assert_eq!(Assets::owner(0), Some(1)); assert_eq!(Assets::issuer(0), Some(2)); assert_eq!(Assets::admin(0), Some(3)); assert_eq!(Assets::freezer(0), Some(4)); }); } ``` --- ### [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. - **How To (expand)** How to whitelist specific storage item? ```rust // frame/balances/src/lib.rs #[pallet::storage] #[pallet::getter(fn total_issuance)] #[pallet::whitelist_storage] pub type TotalIssuance<T: Config, I: 'static = ()> = StorageValue<_, T::Balance, ValueQuery>; ``` How do we retrieve this list generated from the macro? ```rust let whitelist: Vec<TrackedStorageKey> = AllPalletsWithSystem::whitelisted_storage_keys(); ``` ## :information_source: Low Impact ### [Use parameter_types instead of thread_local for test-setup](https://github.com/paritytech/substrate/pull/12036) Interesting change for setting pallet type parameters on a mocked runtime. Instead of spawning a new `thread!` which contains the type values, we can use the `parameter_types!` macro following the same process as the runtime configuration: ```rust // Before thread_local! { pub static MEMBERS: RefCell<Vec<u64>> = RefCell::new(vec![]); } // Now parameter_types! { pub static MembersTestValue: Vec<u64> = vec![]; } ``` --- ### [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 /// Provide a judgement for an account's identity. /// /// The dispatch origin for this call must be _Signed_ and the sender must be the account /// of the registrar whose index is `reg_index`. /// /// - `reg_index`: the index of the registrar whose judgement is being made. /// - `target`: the account whose identity the judgement is upon. This must be an account /// with a registered identity. /// - `judgement`: the judgement of the registrar of index `reg_index` about `target`. /// - `identity`: The hash of the [`IdentityInfo`] for that the judgement is provided. /// /// Emits `JudgementGiven` if successful. /// /// # <weight> /// - `O(R + X)`. /// - One balance-transfer operation. /// - Up to one account-lookup operation. /// - Storage: 1 read `O(R)`, 1 mutate `O(R + X)`. /// - One event. /// # </weight> #[pallet::weight(T::WeightInfo::provide_judgement( T::MaxRegistrars::get(), // R T::MaxAdditionalFields::get(), // X ))] 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. - **How To (expand)** ```rust parameter_types! { pub FeeMultiplier: Multiplier = Multiplier::one(); } impl pallet_transaction_payment::Config for Runtime { type Event = Event; type OnChargeTransaction = CurrencyAdapter<Balances, ()>; type OperationalFeeMultiplier = ConstU8<5>; type WeightToFee = IdentityFee<Balance>; type LengthToFee = IdentityFee<Balance>; type FeeMultiplierUpdate = ConstFeeMultiplier<FeeMultiplier>; } ``` --- ### [Expose some of the staking miner types over metadata](https://github.com/paritytech/substrate/pull/12245) Adds the following types to constants metadata for `election-provider-multi-phase` pallet. - `max_lenght` - `max_weight` - `max_votes_per_voter` These types were moved previously from this pallet’s `trait Config` to `trait MinerConfig` The following shows how these types are retrieving values from `MinerConfig` trait, though they are defined within election-provider-multi-phase trait MinerConfig ```rust // frame/election-provider-multi-phase/src/lib.rs // --snip // Expose miner configs over the metadata such that they can be re-implemented. #[pallet::extra_constants] impl<T: Config> Pallet<T> { #[pallet::constant_name(MinerMaxLength)] fn max_length() -> u32 { <T::MinerConfig as MinerConfig>::MaxLength::get() } #[pallet::constant_name(MinerMaxWeight)] fn max_weight() -> Weight { <T::MinerConfig as MinerConfig>::MaxWeight::get() } #[pallet::constant_name(MinerMaxVotesPerVoter)] fn max_votes_per_voter() -> u32 { <T::MinerConfig as MinerConfig>::MaxVotesPerVoter::get() } } // --snip ``` --- ### [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(()) } ``` - **How To (expand)** frame/bags-list/src/migrations.rs ```rust fn pre_upgrade() -> Result<Vec<u8>, &'static str> { // The old explicit storage item. #[frame_support::storage_alias] type CounterForListNodes<T: crate::Config, I: 'static> = @@ -51,7 +53,7 @@ impl<T: crate::Config, I: 'static> OnRuntimeUpgrade for CheckCounterPrefix<T, crate::ListNodes::<T, I>::count() ); Ok(Vec::new()) } fn post_upgrade(node_count_before: Vec<u8>) -> Result<(), &'static str> { let node_count_before: u32 = Decode::decode(&mut node_count_before.as_slice()) .expect("the state parameter should be something that was generated by pre_upgrade"); // Now the list node data is not corrupt anymore. let iter_node_count_after: u32 = crate::ListNodes::<T, I>::iter().count() as u32; let tracked_node_count_after: u32 = crate::ListNodes::<T, I>::count(); crate::log!( info, "number of nodes after: {:?} {:?}", iter_node_count_after, tracked_node_count_after, ); ensure!(iter_node_count_after == node_count_before, "Not all nodes were migrated."); ensure!(tracked_node_count_after == iter_node_count_after, "Node count is wrong."); Ok(()) } ``` --- ### [Allow specifying immediate finalize for manual-seal](https://github.com/paritytech/substrate/pull/12106) Adds a new function `run_instant_seal_and_finalize` similar to `run_instant_seal` which produces a block per transaction imported into the tx pool, but also finalizes this block instantly. Contrary to `manual-seal` engine which seals blocks automatically for each issued transaction, but doesn't finalize them until an RPC `finalize_block` call is explicitly issued. This inclusion comes handy for some E2E testing when running under the assumption of finalized blocks. As a more concrete example, this PR points to https://github.com/paritytech/ink/issues/1234 as a user of this change. --- ### [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: ``` 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. --- ### [Make automatic storage deposits resistant against changing deposit prices](https://github.com/paritytech/substrate/pull/12083) This PR focuses on bringing the following changes to the contracts pallet: - **Delay deposit calculation until the end of the contracts execution.** Before this deposits were calculated at every storage change. - **Make refunds pro rata of consumed storage** Before this change `bytes_removed * current_price` was refunded. Which doesn’t really handle when the runtime changes the price per byte or per storage item. With this change, If I remove 1% of storage I get back 1% of the deposit. This makes sure that the contract never runs dry and never has too much deposit. > One can easily see that for rising prices that can lead to the contract running dry of deposits (removing the incentive to cleanup) or on falling prices accumulating too much deposit that can only be removed by terminating the contract. > This PR also includes a migration exposed by a type named `Migration` that already implements `OnRuntimeUpgrade` which already performs all necessary migrations based on `StorageVersion`