# Polkadot Release Analysis v1.0.0

: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 v1.0.0](https://github.com/paritytech/polkadot/releases/tag/v1.0.0). 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.***

***Also there is a section related to all note worthy changes related to tooling integration.***

[Help us improve the release analysis by filling out this 6 question survey.](https://forms.gle/mdneyTfvYDtXftaX9)

# Summary

This analysis is for **Polkadot 1.0.0** release :tada:.

Note that from this release onwards the [runtime code will be living in the fellowship](https://github.com/polkadot-fellows)!

This Polkadot Release Analysis (PRA) features notable changes like a complete shift in gas metering for `pallet-contracts`, a starting point for a multi-block migration framework, `pallet-aura` allowing multiple blocks per slot, and many more!

Breaking changes are also covered 🚧

## Runtimes built on release v1.0.0

- **Kusama v10000**
- **Polkadot v10000**

<br/>

# :hammer_and_wrench: Tooling Section

- Sidecar - [v17.1.1](https://github.com/paritytech/substrate-api-sidecar/releases/tag/v17.1.1)
- Txwrapper - [v7.0.1](https://github.com/paritytech/txwrapper-core/releases/tag/v7.0.1)

---

# ❗️ High Impact

### contracts: switch to wasmi gas metering
PR: https://github.com/paritytech/substrate/pull/14084

**Why is this important?**

As it is explained in the [original issue](https://github.com/paritytech/substrate/issues/13639) fuel consumption was measured via `gas` host function invocation. For this the executed Wasm blob needed to be instrumented first, i.e. the aforementioned host function calls needed to be injected into each metering block of the code. Now we use built-in wasmi fuel metering instead, which allows us get rid of the instrumentation, saving both storage (as we don't need to store the instrumented code alongside original code) and performance (as calling host function in every block is costly operation).

This change also translates into cost savings for both, contract authors and users. Also, fuel metering on the engine side [is faster](https://github.com/paritytech/wasm-instrument/pull/56).

Another positive side effect of this change we is that other Wasm features beyond MVP can be enabled, like the sign_extension has been alreedy enabled at [PR#14565](https://github.com/paritytech/substrate/pull/14565)

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

Having the metering alogrithm being part of the runtime instead of declared in the client also means that changes made to this piece of logic won't introduce consensus problems between versions.

As from this change two separate fuel meters exists, each having its own units of measurement:

* **Gas Meter built into the pallet**, measures 2-dimension Weight burn during runtime host function execution.
* **Fuel Meter built into the wasmi**, measures 1-dimension Fuel burn in engine for Wasm instruction execution.

Units of fuel consumption in wasmi are normalized, so that basic operations like `i64.const` cost 1 Fuel. For [conversion between the two UoM](https://github.com/paritytech/substrate/blob/40e3395765b756ce7eb3949be4c22fe9a42825d6/frame/contracts/src/gas.rs#L198), the `ref_time` component of `i64.const` instruction Weight is used.

**How does this impact the Polkadot builders?**

To accomodate for these changes users of `pallet-contract` need to run a migration, provided in this PR, which does the following:

* Removes `CodeStorage` with all instrumented contract codes.
The only one needed is `PristineCode` with the original uploaded (and validated) codes.
* Renames `OwnerInfo` into `CodeInfo`, which incurs moving it to another `StorageMap`.
Code related "meta" data is stored in a separate storage item, which now contains not only owner-related fields. Hence the rename.
* As the migration frees up a decent amount of storage, deposits attached to it are refunded.
The amount due to refund is [calculated](https://github.com/paritytech/substrate/blob/5f6c1ac3ab4ff4a5877cbf0ada34be4ff5b586cb/frame/contracts/src/migration/v12.rs#L133) pro rata to the currently held deposit.

---

### Society v2
PR: https://github.com/paritytech/substrate/pull/11324

**Why is this important?**

Significant changes have been made to `pallet-society` such as modifying how the society itself works in regards to membership and the voting of members. Refer to the PR description for a clear understanding of how the society will behave from now on.

**How does this impact the Polkadot builders?**

The changes revamp the definition of different storage items and types accross the pallet, for instance:
> The number of members are no longer limited technically (Members is no longer a `Vec` item).

- pub type Members<T: Config<I>, I: 'static = ()> =
-    StorageValue<_, Vec<T::AccountId>, ValueQuery>; 
    
+ pub type Members<T: Config<I>, I: 'static = ()> =
+    StorageMap<_, Twox64Concat, T::AccountId, MemberRecord, OptionQuery>;

Inclusion of member ranks or use of `BoundedVec` are other examples from the list of changes that require migrating the data to comply with the new definitions. **This migration is provided within this PR**, take care of running it in case you are a user of this pallet.

Other notable mentions is the inclusion of new extriniscs:
- `waive_repay` call_index: `7`
- `punish_skeptic` call_index: `12`
- `claim_membership` call_index: `13`
- `bestow_membership` call_index: `14`
- `kick_candidate` call_index: `15`
- `resign_candidacy` call_index: `16`
- `drop_candidate` call_index: `17`

Watch out for **modifications on call indices** from the previous version of the pallet.

---

# ⚠️ Medium Impact

### Take into account proof size for transaction payment and priority

PR: https://github.com/paritytech/substrate/pull/13958

**Why is this important?**

This PR makes changes to the [transaction payment pallet](https://github.com/paritytech/substrate/blob/93b31904c9dd421e28c9efb0aa7d1c14c86410d6/frame/transaction-payment/src/lib.rs) specifically so that PoV size is now taken into account when calculating the `TargetedFeeAdjustment` and transaction priority.

**How does this impact the Polkadot builders?**

PoV size or `proof_size` is not something that needs to be taken into account for transactions on the Relay, however for parachains the PoV is limited to 5 MB. An attacker could take advantage of this by filling a block with storage size and not paying a transaction fee that takes into account the `proof_size`.

There is also a note on the PR regarding considerations when selecting a max PoV size for your chain. If you select a really high value, it would result in your blocks never being full and if you select too low of a value, it would mean that your blocks would be constantly full and transaction fees would keep increasing. The key is to find an optimal PoV size. More info on this is in the [PR description](https://github.com/paritytech/substrate/pull/13958).

A new term is introduced with this PR: `limiting dimension` which refers to the dimension (`ref_time` and `proof_size`) that has the scarcer resource. The following [doc comment](https://github.com/paritytech/substrate/blob/93b31904c9dd421e28c9efb0aa7d1c14c86410d6/frame/transaction-payment/src/lib.rs#L113C1-L118C10) encompasses the full definition:

/// Since block weight is multi-dimension, we use the scarcer resource, referred as limiting
/// dimension, for calculation of fees. We determine the limiting dimension by comparing the
/// dimensions using the ratio of `dimension_value / max_dimension_value` and selecting the largest
/// ratio. For instance, if a block is 30% full based on `ref_time` and 25% full based on
/// `proof_size`, we identify `ref_time` as the limiting dimension, indicating that the block is 30%
/// full. 

Related Issue: [#13898](https://github.com/paritytech/substrate/issues/13898)

---

### contracts: Multi block migrations
PR: https://github.com/paritytech/substrate/pull/14045

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

If we are upgrading to a new version and using [pallet-contracts](https://marketplace.substrate.io/pallets/pallet-contracts/), we need to perform large storage migrations and all migrations need to happen in a single block.

As a part of this PR, this problem is solved by introducing multi-block migrations in the contracts pallet.

**How does this impact the Polkadot builders?**

This PR adds a multi-block migration framework for pallet-contracts. Please refer to the PR description for testing multi block migration. At the moment, this feature is available only for the contracts pallet and will be generalized to the rest of FRAME in the future.

With this PR, when the migration starts, access to `pallet-contracts` is blocked while the migration is in progress.

Related Issue: [#13638](https://github.com/paritytech/substrate/issues/13638)

---

### Move type Migrations to Config
PR: https://github.com/paritytech/substrate/pull/14309

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

As described above, a [multi-block migration](https://github.com/paritytech/substrate/pull/14045) framework has been introduced for [pallet-contracts](https://marketplace.substrate.io/pallets/pallet-contracts/) in `release-v1.0.0`.

This PR is related to that change and adds a new config in `pallet-contracts`:

type Migrations: MigrateSequence

**How does this impact the Polkadot builders?**

If we are using `pallet-contracts`, we need to include this in our runtime configuration with our pending migrations (or `()` if none). otherwise this will result in compilation failure.

**How to use?**

To avoid compilation failure:

impl pallet_contracts::Config for Runtime {
  // .. snip
  type Migrations = ();
}

For more details, please check the PR description.

Cumulus Companion PR: [#2701](https://github.com/paritytech/cumulus/pull/2701)
Related Substrate PR: [#14045](https://github.com/paritytech/substrate/pull/14045)

---

### pallet-aura: Allow multiple blocks per slot
PR: https://github.com/paritytech/substrate/pull/14024

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

As we know, [pallet-aura](https://docs.rs/pallet-aura/latest/pallet_aura/#) has a key role in the block authoring process. Aura works by having a list of authorities, who are allowed to produce blocks. The authorities must be chosen before block production begins and all authorities must know the entire authority set. Time is divided up into `slots` of a fixed length. During each slot one block is produced, and the authorities take turns producing blocks in order forever.

At the moment, only one block is produced in each slot.

This PR optionally allows sequential blocks to be authored within the same slot.

**How does this impact the Polkadot builders?**

A new config `type AllowMultipleBlocksPerSlot: Get<bool>` has been added in [pallet-aura](https://docs.rs/pallet-aura/latest/pallet_aura/#). If you are using Aura consensus for block authorization, this would be a breaking change and fail the compilation.

We can set its value as `false` to maintain current behavior. If you are looking for enabling asynchronous backing, you can set its value as `true` but this may require other changes alongside.

**How to use?**

To avoid compilation failure:

impl pallet_aura::Config for Runtime {
  // .. snip
  type AllowMultipleBlocksPerSlot = ConstBool<false>;
}

For more details, please check the PR description and related issue.

Cumulus Companion PR: [#2707](https://github.com/paritytech/cumulus/pull/2707)
Related Issue: [#2476](https://github.com/paritytech/cumulus/issues/2476)

---

### [NFTs] Add minting price to the pre-signed mint object
PR: https://github.com/paritytech/substrate/pull/14242

**Why is this important?**

This PR allows for the `PreSignedMint` data to include an optional mint price.

**How does this impact the Polkadot builders?**

This is a breaking change for the [NFTs pallet](https://docs.rs/pallet-nfts/15.0.0/pallet_nfts) as we are adding a new field `mint_price` to the `PreSignedMint` struct:

pub struct PreSignedMint<CollectionId, ItemId, AccountId, Deadline, Balance> {
	/// A collection of the item to be minted.
	pub(super) collection: CollectionId,
	/// Item's ID.
	pub(super) item: ItemId,
	/// Additional item's key-value attributes.
	pub(super) attributes: Vec<(Vec<u8>, Vec<u8>)>,
	/// Additional item's metadata.
	pub(super) metadata: Vec<u8>,
	/// Restrict the claim to a particular account.
	pub(super) only_account: Option<AccountId>,
	/// A deadline for the signature.
	pub(super) deadline: Deadline,
+       /// An optional price the claimer would need to pay for the mint.
+       pub(super) mint_price: Option<Balance>,
}

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

[Offchain minting](https://forum.polkadot.network/t/offchain-minting-on-substrate) allows others to know the what they will be claiming because the metadata and attributes are part of the presigned mint data and therefore known. Adding an optional price to this mint data allows for more use cases, elevating the offchain minting experience.

**How to use?**

PreSignedMint {
    collection: 0,
    item: 0,
    attributes: vec![(vec![0], vec![1]), (vec![2], vec![3])],
    metadata: vec![0, 1],
    only_account: None,
    deadline: 10000000,
    mint_price: Some(10),
};

You can refer to the full test [here](https://github.com/paritytech/substrate/blob/77cad1120db1e1993b79a804cc422a17a4d4502c/frame/nfts/src/tests.rs#L3173-L3342).

---

### Frame: Give Referendum SubmitOrigin argument
PR: https://github.com/paritytech/substrate/pull/14326

**Why is this important?**

This PR allows for a more granular control over a submission origin depending on the track it is submitting for. The type `SubmitOrigin` in `pallet-referenda` is now defined as:

type SubmitOrigin: EnsureOriginWithArg<
	Self::RuntimeOrigin,
	PalletsOriginOf<Self>,
	Success = Self::AccountId,
>;

**How does this impact the Polkadot builders?**

Users of `pallet-referenda` might encounter build errors related with their custom origins and as per the author's instructions these can be solved by wrapping the type with `frame_support::AsEnsureOriginWithArg`, e.g:

impl pallet_referenda::Config for Runtime {
    type SubmitOrigin = MyEnsureOriginImpl;
    // snip
}

The above, would become:

impl pallet_referenda::Config for Runtime {
    type SubmitOrigin = frame_support::AsEnsureOriginWithArg<MyEnsureOriginImpl>;
    // snip
}

---

<details>
<summary>⚠️ Expand for additional MEDIUM impact PRs</summary>

### HoldReason: Improve usage
PR: https://github.com/paritytech/substrate/pull/13869

**Why is this important?**

`HoldReason` was switched recently to use the [`composite_enum`](https://paritytech.github.io/substrate/master/frame_support/pallet_macros/attr.composite_enum.html) 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](https://github.com/paritytech/polkadot/pull/7119)

Cumulus Companion PR: [#2631](https://github.com/paritytech/cumulus/pull/2631)

---

### migrations: VersionedRuntimeUpgrade
PR: https://github.com/paritytech/substrate/pull/14311

**Why is this important?**

This PR introduces [`VersionedRuntimeUpgrade`](https://paritytech.github.io/substrate/master/frame_support/migrations/struct.VersionedRuntimeUpgrade.html) 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_upgrade` method is called, the on-chain version of the pallet is compared to `From`. If they match, `Inner::on_runtime_upgrade` is called and the pallets on-chain version is set to `To`. 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
PR: https://github.com/paritytech/substrate/pull/14511

**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.

Polkadot Companion PR: [#7459](https://github.com/paritytech/polkadot/pull/7459)
Cumulus Companion PR: [#2821](https://github.com/paritytech/cumulus/pull/2821)

</details>

---

# ℹ️ Low Impact

### Asset Conversion pallet
PR: https://github.com/paritytech/substrate/pull/12984

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

As a part of this PR, A new [Asset Conversion pallet](https://github.com/paritytech/substrate/pull/12984/files#diff-d0216ff13e1e61b4503ca4614994420219152fa0ec43465602367a509668aee0) has been introduced, which is a simple audited AMM (automated market maker) pallet. This pallet is based on [Uniswap V2](https://github.com/Uniswap/v2-core) logic.

This pallet allows you to:

- create a liquidity pool for 2 assets
- provide the liquidity and receive back an LP token
- exchange the LP token back to assets
- swap a specific amount of assets for another if there is a pool created, or
- swap some assets for a specific amount of another
- query for an exchange price via a runtime call endpoint
- query the size of a liquidity pool via a runtime api endpoint.

Related Issue: [#33](https://github.com/paritytech/roadmap/issues/33)

---

### Bump sp-crates from latest crates.io version and release
PR: https://github.com/paritytech/substrate/pull/14265

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

As a part of this PR, `sp-crates` have been bumped to the latest version. This might be a breaking change if you don't update `Cargo.toml` or `Cargo.lock`.

If you are using `sp-crates` without mentioning version in `Cargo.toml`, then you can simply run `cargo update` and update your `Cargo.lock`.

In case, if you are using version, you have to update `Cargo.toml`. For example:

- sp-core = { version = "7.0.0" }
+ sp-core = { version = "21.0.0" }

Related PR: [#14237](https://github.com/paritytech/substrate/pull/14237)
Polkadot Companion PR: [#7307](https://github.com/paritytech/polkadot/pull/7307)
Cumulus Companion PR: [#2655](https://github.com/paritytech/cumulus/pull/2655)

---

### Add Ability to Add/Remove Invulnerable Collators
PR: https://github.com/paritytech/cumulus/pull/2596

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

As a part of this PR, two new extrinsics `add_invulnerable` and `remove_invulnerable` have been introduced, which will allow to add or remove individual collators to/from the Invulnerables set. Now there won't be any need for any kind of nomination or delegation scheme.

Related Discussion:
- https://forum.polkadot.network/t/economic-model-for-system-para-collators/1010

---

### Rename Statemint to Asset Hub
PR: https://github.com/paritytech/cumulus/pull/2633

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

`Statemint` is a system parachain on Polkadot, also referred as `common-good` parachain, allows the deployment and transfer of assets (both fungible and non-fungible tokens) and serves as the fundamental infrastructure that enables the Polkadot ecosystem to communicate with the rest of the on-chain and off-chain environment.

The name `Statemint` has introduced a lot of confusion across the ecosystem (especially with its counterpart, Statemine).

As a part of this PR, `Statemint` has been renamed to `Asset Hub`. You can find more details [here](https://support.polkadot.network/support/solutions/articles/65000181800-what-is-statemint-and-statemine-and-how-do-i-use-them-).

**How does this impacts the Polkadot builders?**

There are no changes on the chainspec or the endpoints even though the name has officially changed.

Related Issue: [#2591](https://github.com/paritytech/cumulus/issues/2591)
Related Discussion: https://forum.polkadot.network/t/the-naming-of-things-viz-statemint/2328

---

### Soft deprecate GenesisConfig
PR: https://github.com/paritytech/substrate/pull/14210

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

As a part of this PR, `GenesisConfig` has been renamed to `RuntimeGenesisConfig`. Most of the composite enums are already renamed earlier with the same pattern i.e. `RuntimeXXX`.

This PR softy deprecates `GenesisConfig` and does not generate a deprecation warning. However, a related PR [#14224](https://github.com/paritytech/substrate/pull/14224) has also been merged in the same release to generate a warning when using the runtime level `GenesisConfig`.

Related PR: [#14224](https://github.com/paritytech/substrate/pull/14224)
Related Issue: [#14065](https://github.com/paritytech/substrate/issues/14065)

---

### [FRAME Core] Default Pallet Config Trait / derive_impl
PR: https://github.com/paritytech/substrate/pull/13454

**Why is this important?**

This PR add the ability for a pallet to have a default config. This has been idea that has [been discussed](https://github.com/paritytech/substrate/issues/10687) and is now coming to fruition.

This PR brings in the basic working functionality for a default config for testing purposes. There are a [few more action items](https://github.com/paritytech/substrate/issues/14234) pending for this to be fully production ready.

**How does this impact the Polkadot builders?**

Having this feature would simplify runtime development as developers will often opt in for default values.

There is a full example pallet using the default config feature in Substrate:
- [frame/example/default-config](https://github.com/paritytech/substrate/blob/638c1fa3d97bb2af697f50e9d12278f388bee735/frame/examples/default-config/src/lib.rs)

This gist is that you annotate you pallet config like so:

#[pallet::config(with_default)]
pub trait Config: frame_system::Config {
    ...

You can optionally mark a type with no default:

#[pallet::no_default]
type CannotHaveDefault: Get<Self::AccountId>;

---

### Adds ability to prepare/initialize before running set_code benchmark
PR: https://github.com/paritytech/substrate/pull/14435

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

After the [inclusion of benchmarks for system::set_code](https://github.com/paritytech/substrate/pull/13373) cumulus codebases might run into issues if configured with:

type OnSetCode = cumulus_pallet_parachain_system::ParachainSetCode<Self>;

This PR adds a way to provide the required pre existing data in order to benchmark successfully the above mentioned extinsic.

Cumulus companion PR [#2766](https://github.com/paritytech/cumulus/pull/2766)

---

### [NFTs] Add mint price to the witness object on mint and confirm it
PR: https://github.com/paritytech/substrate/pull/14257

**Why is this important?**

This PR adds `mint_price` to the witness data object.

**How does this impact the Polkadot builders?**

When minting an NFT using the [NFTs pallet](https://docs.rs/pallet-nfts/15.0.0/pallet_nfts), there are three types of mints that are possible:

pub enum MintType<CollectionId> {
    /// Only an `Issuer` could mint items.
    Issuer,
    /// Anyone could mint items.
    Public,
    /// Only holders of items in specified collection could mint new items.
    HolderOf(CollectionId),
}

When `HolderOf(CollectionId)` is used, a witness data object that proves that they are a holder of an NFT item in that collection is required. This is done via the `MintWitness`:

pub struct MintWitness<ItemId, Balance> {
    /// Provide the id of the item in a required collection.
    pub owned_item: ItemId,
+	/// The price specified in mint settings.
+	pub mint_price: Option<Balance>,
}

`mint_price` is now part of that witness data.

If you're curious how the mint witness works, you can see in action in the [NFTs pallet's `mint` call](https://github.com/paritytech/substrate/blob/fe2d51377fe1a8fbbb0599523f4fdc1422c82f81/frame/nfts/src/lib.rs#L776-L787), specifically [here](https://github.com/paritytech/substrate/blob/fe2d51377fe1a8fbbb0599523f4fdc1422c82f81/frame/nfts/src/lib.rs#L823-L832).

---

<details>
<summary>ℹ️ Expand for additional LOW impact PRs</summary>

### Restructure macro-related exports into private mods for frame
PR: https://github.com/paritytech/substrate/pull/14375

**Why is this important?**

This PR is part of a larger issue [#14213](https://github.com/paritytech/substrate/issues/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::BlockT` is removed and should be imported from `sp_runtime::traits::Block`
- `frame::support::inherent::Extrinsic` is removed and should be imported from `sp-runtime::traits::Extrinsic`
- some other minor type re-export are removed and should be imported from their respective origins. Refer to [PR](https://github.com/paritytech/substrate/pull/14375) for changes

Related Issue: [#14213](https://github.com/paritytech/substrate/issues/14213)
Cumulus Companion PR: [#2733](https://github.com/paritytech/cumulus/pull/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](https://marketplace.substrate.io/pallets/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](https://marketplace.substrate.io/pallets/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](https://github.com/paritytech/polkadot/issues/7181)
Polkadot Companion PR: [#7309](https://github.com/paritytech/polkadot/pull/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](https://github.com/paritytech/polkadot/issues/6749).

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](https://github.com/paritytech/polkadot/issues/6749) to see all the steps that are involved.

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

This PR has a [well-documented migration](https://github.com/paritytech/substrate/blob/1aeb2911696b3334041efa87ba20878afad04528/frame/tips/src/migrations/unreserve_deposits.rs) that unreserves deposits and can be a useful reference.

---

### frame-support Add translate_next
PR: https://github.com/paritytech/substrate/pull/14043

**Why is this important?**

This PR adds a [`translate_next`](https://paritytech.github.io/substrate/master/frame_support/storage/trait.IterableStorageMap.html#tymethod.translate_next) function that works similar to [`translate`](https://paritytech.github.io/substrate/master/frame_support/storage/trait.IterableStorageMap.html#tymethod.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](https://github.com/paritytech/substrate/blob/8f3ace05f1db952cbbab4294511179f35ffb555b/frame/contracts/src/migration/v9.rs#L71-L97).

---

### Bump version of pallet-contracts-primitives for release
PR: https://github.com/paritytech/substrate/pull/14288

**Why is this important?**

In accordance with [#14265](https://github.com/paritytech/substrate/pull/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)](https://crates.io/crates/pallet-contracts-primitives/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](https://github.com/paritytech/cumulus/pull/2679)

---

### pallet-uniques: remove #[transactional] macro for buy_item
PR: https://github.com/paritytech/substrate/pull/14277

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

Substrate has a [Uniques pallet](https://crates.parity.io/pallet_uniques/index.html) 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]](https://crates.parity.io/frame_support/attr.transactional.html) 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
PR: https://github.com/paritytech/substrate/pull/14270

**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
PR: https://github.com/paritytech/substrate/pull/14238

**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: https://github.com/paritytech/substrate/pull/14258

**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](https://paritytech.github.io/substrate/master/frame_support/traits/tokens/pay/trait.Pay.html). There are also some interesting use cases mentioned in [this closed PR's description](https://github.com/paritytech/substrate/pull/13607#issue-1625580885https://github.com/paritytech/substrate/pull/13607#issue-1625580).

The PR also mentions that this `Error` item is used in [XCM: PayOverXcm config](https://github.com/paritytech/polkadot/pull/6900)

---

### sp-wasm-interface: remove useless wasmi impl
PR: https://github.com/paritytech/substrate/pull/14208

**Why is this important?**

`wasmi` backend was removed from `sc-executor` in [#13800](https://github.com/paritytech/substrate/pull/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](https://github.com/paritytech/substrate/issues/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](https://github.com/paritytech/polkadot/pull/7295)

---

### RPC-Spec-V2: Rename `runtimeUpdates` flag to `withRuntime`
PR: https://github.com/paritytech/substrate/pull/14244

**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](https://github.com/paritytech/json-rpc-interface-spec/issues/30) 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](https://github.com/paritytech/json-rpc-interface-spec/issues/30#issuecomment-1428099652), the idea is that:

- `withRuntime` set to `false` means 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.

- `withRuntime` set to `true` means you need all of these things, and as such you get access to more features.

You can read more about the `withRuntime` parameter [here](https://github.com/tomaka/json-rpc-interface-spec/blob/5052e4f3184709128ab7dd6cc43e6ce41646aa58/src/api/chainHead_unstable_follow.md#the-withruntime-parameter).

---

### 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](https://marketplace.substrate.io/pallets/pallet-proxy/) to remove all the proxies so that other pallets can call this.

Related Issue: [#7557](https://github.com/paritytech/substrate/issues/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](https://github.com/paritytech/substrate/issues/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:
- https://forum.polkadot.network/t/genesisconfig-in-wasm-runtime-a-step-towards-a-non-native-future

Polkadot Companion PR: [#7271](https://github.com/paritytech/polkadot/pull/7271)
Cumulus Companion PR: [#2624](https://github.com/paritytech/cumulus/pull/2624)

---

### remove OnStakerSlash replace with OnStakingEvents
PR: https://github.com/paritytech/substrate/pull/14527

**Why is this important?**

In a step towards [Approval Stake tracking #12719](https://github.com/paritytech/substrate/issues/12719), this PR removes `OnStakerSlash` and replaces it with `OnStakingEvents`.

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

---

### frame-benchmarking-cli: Remove native dispatch requirement
PR: https://github.com/paritytech/substrate/pull/14474

**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](https://github.com/paritytech/polkadot/pull/7434)
Cumulus Companion PR: [#2792](https://github.com/paritytech/cumulus/pull/2792)

---

### pallet-merkle-mountain-range: Remove extra Hash type
PR: https://github.com/paritytech/substrate/pull/14214

**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](https://github.com/paritytech/polkadot/pull/7283)

---

### arkworks integration
PR: https://github.com/paritytech/substrate/pull/13031

**Why is this important?**

This PR integrates [arkworks](https://github.com/arkworks-rs) into Substrate. [arkworks](https://github.com/arkworks-rs) 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
PR: https://github.com/paritytech/substrate/pull/14338

**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.

</details>