It seems the collection of PRs we wanted to feature for this feature is bigger(in characters) than what this forum post’s body accepts as maximum, so I am adding here some other relevant PRs:
⚠️ Expand for additional MEDIUM impact PRs
HoldReason: Improve usage
PR: HoldReason: Improve usage by bkchr · Pull Request #13869 · paritytech/substrate · GitHub
Why is this important?
HoldReason was switched recently to use the composite_enum attribute which allows you to define an enum that gets composed as an aggregate enum by construct_runtime. Similar to #[pallet::event].
This PR properly implements HoldReason by adding a RuntimeHoldReason as a type to the Config trait and requiring that Currency is using the same reason.
One notable change in this PR is to the pallet balances config, where HoldIdentifier is changed to RuntimeHoldReason and pass the RuntimeHoldReason that is being generated by construct_runtime!.
How does this impact the Polkadot builders?
If you’re using pallet balances, you will need the following change:
- type HoldIdentifier: Parameter + Member + MaxEncodedLen + Ord + Copy;
+ type RuntimeHoldReason: Parameter + Member + MaxEncodedLen + Ord + Copy;
Refer to PR for full details.
Polkadot Companion PR: #7119
Cumulus Companion PR: #2631
migrations: VersionedRuntimeUpgrade
PR: https://github.com/paritytech/substrate/pull/14311
Why is this important?
This PR introduces VersionedRuntimeUpgrade for migrations under the experimental flag - meaning that the API can change. Previously if one were to write a migration they would need to write logic to check the previous storage version to make sure the migration that they are applying makes sense as well as writing separate logic to set the storage version once the migration is applied, with VersionedRuntimeUpgrade this is built in to the API:
pub struct VersionedRuntimeUpgrade<const FROM: u16, const TO: u16, Inner, Pallet, Weight> { /* private fields */ }
How does it work?
As the PR so nicely states:
When a VersionedRuntimeUpgrade’s
on_runtime_upgrademethod is called, the on-chain version of the pallet is compared toFrom. If they match,Inner::on_runtime_upgradeis called and the pallets on-chain version is set toTo. Otherwise, a warning is logged notifying the developer that the upgrade was a noop and should probably be removed.
How does this impact the Polkadot builders?
This will make it easier to write versioned runtime upgrades and avoid mishaps since the From and To are defined in the actual API of the migration.
How to use?
// In file defining migrations
pub struct VersionUncheckedMigrateV5ToV6<T>(sp_std::marker::PhantomData<T>);
impl<T: Config> OnRuntimeUpgrade for VersionUncheckedMigrateV5ToV6<T> {
// OnRuntimeUpgrade implementation...
}
pub type VersionCheckedMigrateV5ToV6<T, I> =
VersionedRuntimeUpgrade<
5,
6,
VersionUncheckedMigrateV5ToV6<T, I>,
crate::pallet::Pallet<T, I>,
<T as frame_system::Config>::DbWeight
>;
// Migrations tuple to pass to the Executive pallet:
pub type Migrations = (
// other migrations...
VersionCheckedMigrateV5ToV6<T, ()>,
// other migrations...
);
Refer to the PR for full details
sc-cli: Remove SubstrateCli::native_runtime_version function
Why is this important?
As part of a native runtime free world, the SubstrateCli::native_runtime_version function is being removed.
How does this impact the Polkadot builders?
Builders should remove the native_runtime_version from their implementation of the SubstrateCli trait.
Refer to the companion PRs for examples.
ℹ️ Expand for additional LOW impact PRs
Restructure macro-related exports into private mods for frame
Why is this important?
This PR is part of a larger issue #14213 to restructure macro-related exports into private mods so that they will be exempt from semantic versioning.
How does this impact the Polkadot builders?
This PR does have breaking changes. Notably:
frame::support::inherent::BlockTis removed and should be imported fromsp_runtime::traits::Blockframe::support::inherent::Extrinsicis removed and should be imported fromsp-runtime::traits::Extrinsic- some other minor type re-export are removed and should be imported from their respective origins. Refer to PR for changes
Related Issue: #14213
Cumulus Companion PR: #2733
[frame/im-online] remove network state from heartbeats
PR: https://github.com/paritytech/substrate/pull/14251
Why is this change interesting for builders?
This PR introduces the changes in pallet-im-online and removes the requirement of adding external_addresses, which was being used for unstable work of authority discovery. Since this is stable now, so it can be saftly removed.
How does this impact the Polkadot builders?
Since we don’t need network state from heartbeat now, a config MaxPeerDataEncodingSize has been removed, which was being used for the maximum size of the encoding of PeerId and MultiAddr.
If you are using pallet-im-online, you need to remove MaxPeerDataEncodingSize in your runtime configuration otherwise this will result in compilation failure.
How to use?
To avoid compilation failure, remove MaxPeerDataEncodingSize:
impl pallet_im_online::Config for Runtime {
// .. snip
- type MaxPeerDataEncodingSize = MaxPeerDataEncodingSize;
}
For more details, please check the PR description.
Related Issue: #7181
Polkadot Companion PR: #7309
migration(tips): unreserve deposits
PR: https://github.com/paritytech/substrate/pull/14241
Why is this important?
This PR is part of a larger issue of removing Gov V1 from Polkadot/Kusama and unlocking/unreserving funds.
This PR contains a migration to unreserve all deposits made by the tips pallet.
How does this impact the Polkadot builders?
If your parachain has Gov v1 and you’re looking to upgrade to Gov v2, then keep your eyes pealed on this issue to see all the steps that are involved.
Why is this change interesting for builders?
This PR has a well-documented migration that unreserves deposits and can be a useful reference.
frame-support Add translate_next
PR: frame-support Add translate_next by pgherveou · Pull Request #14043 · paritytech/substrate · GitHub
Why is this important?
This PR adds a translate_next function that works similar to translate but only translates a single entry of the map.
Why is this change interesting for builders?
As the PR so nicely states, translate_next can be useful for multi-block migrations where better granularity is needed to translate large storage maps.
How to use?
As a review here is the function signature of translate:
fn translate<O: Decode, F: FnMut(K, O) -> Option<V>>(f: F)
This function translates the values of all elements by a function f, in the map in lexicographical order of the encoded key. By returning None from f for an element, you’ll remove it from the map.
Where as for translate_next:
fn translate_next<O: Decode, F: FnMut(K, O) -> Option<V>>(
previous_key: Option<Vec<u8>>,
f: F
) -> Option<Vec<u8>>
This translates the next entry following previous_key by a function f. By returning None from f for an element, you’ll remove it from the map.
Returns the next key to iterate from in lexicographical order of the encoded key
A concrete example of how to use translate_next in a multi-block migration can be found here.
Bump version of pallet-contracts-primitives for release
Why is this important?
In accordance with #14265, this PR bumps the pallet contracts version to be in line with crates.io by bumping one version higher that what is currently in crates.io (23.0.0):
- pallet-contracts-primitives = { version = "7.0.0", default-features = false, path = "../../../frame/contracts/primitives/" }
+ pallet-contracts-primitives = { version = "24.0.0", default-features = false, path = "../../../frame/contracts/primitives/" }
How does this impact the Polkadot builders?
If you’re using pallet contracts, you will need to make sure to bump to version 24.0.0.
Cumulus Companion PR: #2679
pallet-uniques: remove #[transactional] macro for buy_item
Why is this change interesting for builders?
Substrate has a Uniques pallet for dealing with non-fungible assets. This pallet has an extrinsic buy_item, which allows to buy an item if it is ready for sale.
At the moment, this extrinsic is associated with #[transactional] macro. This macro ensures that any modifications to storage are not persisted in case of an error during execution. It wraps the logic inside of a particular function in its own transactional layer and rolls back whenever an error is returned by the function.
As a part of this PR, this macro has been removed from this extrinsic.
FRAME: Introduce ConvertToValue adapter
Why is this important?
This PR adds an adapter which turns a Get implementation into a Convert implementation which always returns the same value no matter the input.
pub struct ConvertToValue<T>(sp_std::marker::PhantomData<T>);
impl<X, Y, T: Get<Y>> Convert<X, Y> for ConvertToValue<T> {
fn convert(_: X) -> Y {
T::get()
}
}
Expose build_system_rpc_future and TransactionPoolAdapator in sc-service
Why is this important?
This PR exposes the build_system_rpc_future function and allows to contruct a new instance of TransactionPoolAdapter to allow for replicating build_network().
Pay trait gets Error item
PR: `Pay` trait gets `Error` item by gavofyork · Pull Request #14258 · paritytech/substrate · GitHub
Why is this important?
With this PR, the Pay trait gets an Error item.
If you’re not familiar with the more generic Pay trait, you can read more about here. There are also some interesting use cases mentioned in this closed PR’s description.
The PR also mentions that this Error item is used in XCM: PayOverXcm config
sp-wasm-interface: remove useless wasmi impl
Why is this important?
wasmi backend was removed from sc-executor in #13800 which meant that the runtime can no longer be run with an interpreter rather execution will be exclusive to wasmtime. This PR removes a remnant: the wasmi_impl.
wasm-builder: Enforce runtime_version wasm section
PR: https://github.com/paritytech/substrate/pull/14228
Why is this important?
This PR makes runtime_version a requirement and therefore avoids issues where the runtime_version is unintentionally omitted (i.e. #14223) from the runtime.
It is possible to disable this requirement:
WasmBuilder::new()
...
...
...
.disable_runtime_version_section_check()
.build()
This can be useful in tests.
Polkadot Companion PR: #7295
RPC-Spec-V2: Rename runtimeUpdates flag to withRuntime
Why is this important?
In this PR, there is a rename of chainHead_follow RPC method’s runtimeUpdates flag to withRuntime.
The decision to rename came out of an interesting discussion around its purpose.
Why is this change interesting for builders?
If withRuntime is set to true then blocks will be reported to JSON-RPC clients once the JSON-RPC server has finished obtaining the runtime specification of the blocks that it reports.
As noted here, the idea is that:
-
withRuntimeset tofalsemeans you only care about blocks. You don’t care about the runtime, you’re not going to need the metadata, you’re not going to do calls, etc. -
withRuntimeset totruemeans you need all of these things, and as such you get access to more features.
You can read more about the withRuntime parameter here.
Add remove_proxies API for pallet-proxies
PR: https://github.com/paritytech/substrate/pull/12714
Why is this change interesting for builders?
As a part of this pallet, a public API remove_all_proxy_delegates has been added in Proxy pallet to remove all the proxies so that other pallets can call this.
Related Issue: #7557
frame: GenesisBuild::build allowed in no_std
PR: https://github.com/paritytech/substrate/pull/14107
Why is this important?
In a step towards a “native free runtime world”, this PR makes it so that the GenesisBuild::build function is allowed in no_std .
Why is this change interesting for builders?
As detailed in #13334, the GenesisConfig is currently one of the only things that still requires the native runtime. The idea is to make the GenesisConfig build in Wasm.
A full discussion of moving towards a non-native future can be found here:
Polkadot Companion PR: #7271
Cumulus Companion PR: #2624
remove OnStakerSlash replace with OnStakingEvents
Why is this important?
In a step towards Approval Stake tracking #12719, this PR removes OnStakerSlash and replaces it with OnStakingEvents.
Polkadot Companion PR: #7475
frame-benchmarking-cli: Remove native dispatch requirement
Why is this important?
This is a re-factor which removes the requirement to pass the ExecDispatch generic parameter and instead to pass the host functions directly.
How does this impact the Polkadot builders?
Refer to the Cumulus Companion PR for what needs to be updated.
Polkadot Companion PR: #7434
Cumulus Companion PR: #2792
pallet-merkle-mountain-range: Remove extra Hash type
Why is this important?
This PR removes the type Hash from pallet markle-mountain-range.
Refer to PR and companion PR for how to remove.
Polkadot Companion PR: #7283
arkworks integration
PR: https://github.com/paritytech/substrate/pull/13031
Why is this important?
This PR integrates arkworks into Substrate. arkworks provides Rust interfaces for zkSNARK programming. Full details can be found in the PR. This is still considered unstable/experimental.
pallet-glutton: over-unity consumption
Why is this important?
In order to get the testing pallet pallet-glutton to achieve its purpose over-unity values are needed for the proof and computation weight.
This is done by changing Perbill to FixedU64 with a range of [0, 10] that will be interpreted as [0, 1000]%.
How does this impact the Polkadot builders?
To achieve so the following breaking changes were included:
- pub(crate) type Compute<T: Config> = StorageValue<_, Perbill, ValueQuery>;
+ pub(crate) type Compute<T: Config> = StorageValue<_, FixedU64, ValueQuery>;
- pub(crate) type Storage<T: Config> = StorageValue<_, Perbill, ValueQuery>;
+ pub(crate) type Storage<T: Config> = StorageValue<_, FixedU64, ValueQuery>;
pub struct GenesisConfig {
- pub compute: Perbill,
- pub storage: Perbill,
pub trash_data_count: u32,
}
pub struct GenesisConfig {
+ pub compute: FixedU64,
+ pub storage: FixedU64,
pub trash_data_count: u32,
}
As well as the function signatures of set_storage and set_compute to accomodate said changes.
Notice that no migration is provided as this pallet is not meant to be used in value-bearing chains.