# Polkadot Release Analysis v0.9.39

:warning: ***The following report is not an exhaustive list of changes included in the release, but a set of changes that we felt deserved to be highlighted due to their impact on the Polkadot ecosystem builders.***

***Please do not stop reading the [release notes v0.9.39](https://github.com/paritytech/polkadot/releases/tag/v0.9.39). 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.***

# Summary

This release includes some interesting feautures such as adding metadata to a referendum proposal, the chance to parametrize the executor environment as well as features added to the new NFT pallet. Also there is a new pallet called Glutton that makes it possible to test the boundaries of a chain.

<br/>

## Runtimes built on release v0.9.39

- **Rococo v9390**
- **Westend v9390**
- **Kusama v9390**
- **Polkadot v9390**

<br/>

# :hammer_and_wrench: Tooling Section
---

TxWrapper Core - [v5.0.0](https://github.com/paritytech/txwrapper-core/releases/tag/v5.0.0)
Substrate Sidecar API - [v14.4.0](https://github.com/paritytech/substrate-api-sidecar/releases/tag/v14.4.0)
Polkadot JS API - [v9.14.2](https://github.com/polkadot-js/api/releases/tag/v9.14.2)

---

# ⚠️ Medium Impact

### Referendum proposal's metadata
PR: https://github.com/paritytech/substrate/pull/12568

**Why is this important?**

This PR permits to attach metadata for a proposal/referendum on the referenda and democracy pallets. Both pallets just store the hash of the preimage through a preimage provider, which in the case of Polkadot/Kusama is the `pallet_preimage`.

Implementation rules (as stated in the PR description):

*In the democracy pallet the metadata can be set only for a proposal (public or external). If the proposal evolves to the referendum the metadata. The metadata of a referendum can be cleared only by root origin (due the absence of the submitter information, and it fits to the overall idea).*

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

The democracy pallet is a pallet widely used within most parachains and having proposal/referendum metadata is a feature that has been sought after by the community.

---

### [NFTs] Offchain mint
PR: https://github.com/paritytech/substrate/pull/13158

**Why is this important?**

With this PR, a collection owner can **sign mint data** offchain and pass the signed mint data to the enduser who in turn can submit it onchain via the new `mint_pre_signed` extrinsic. The **pre-signed mint data** consists of the following:

pub struct PreSignedMint<CollectionId, ItemId, AccountId, Deadline> {
	/// 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,
}

> Note that you can have `None` as a value for `only_account`. This would allow anyone to claim the NFT.

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

Offchain minting of NFTs is a powerful feature which is now available in the [NFT pallet](https://paritytech.github.io/substrate/master/pallet_nfts/index.html). If you are not familiar with the [NFT pallet](https://paritytech.github.io/substrate/master/pallet_nfts/index.html), you can start [here](https://github.com/paritytech/substrate/tree/master/frame/nfts).

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

Offchain NFT minting can offer several benefits in terms of cost, speed, flexibility, scalability, privacy, and user experience.

---

### Glutton pallet
PR: https://github.com/paritytech/substrate/pull/12833

**Why is this important?**

This pallet adds the functionality to use all the weight, both time and space, remaining in each produced block.

With this pallet, we can perform practical tests and check the theoretical limits of how many parachains can run in parallel without destabilizing the Relay chain.

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

You can read the conversations prior to its development in the following forum post and github issue:
- [polkadot forum post](https://forum.polkadot.network/t/push-kusama-limits-with-pov-weight-limit-system-parachains/1068)
- [github issue](https://github.com/paritytech/substrate/issues/12772)

The idea is to create several runtimes with this pallet and bootstrap a number of "Glutton Parachains", and connect them to Kusama so we can have a clearer picture of the real number of parachains a Relay chain can handle.

The pallet exposes three extrinsics that `Root` origin will be able to successfully call, these are:

pub fn initialize_pallet(
    origin: OriginFor<T>,
	new_count: u32,
	witness_count: Option<u32>,
) -> DispatchResult { // -- snip -- }
    
pub fn set_compute(
    origin: OriginFor<T>,
    compute: Perbill
) -> DispatchResult { // -- snip -- }
    
pub fn set_storage(
    origin: OriginFor<T>,
    storage: Perbill
) -> DispatchResult { // -- snip -- }

With these extrinsics, we can initialize the pallet, set the PoV `ref_time` and size usage for every block.

---

# ℹ️ Low Impact

### add warp to target block for parachains
PR: https://github.com/paritytech/substrate/pull/12761

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

Substrate provides a few sync mechanisms like full sync, fork sync, gap sync, warp sync, state sync, etc. `warp sync` is much faster than the others. It initially downloads the best finalized block and the whole state at that block, and finality proofs (currently from GRANDPA) for all validator set transitions from genesis up until the best finalized block. After the initial warp sync is done, the node is ready to import the latest blocks and it will start downloading all previous blocks in the background.

Prior to this PR, warp sync was not supported in parachains. This PR provides warp sync implementation for parachains as well.

Please visit this [section](https://github.com/paritytech/cumulus/pull/1909/files#diff-5b3ed1e5750fd3c75ed8cd988f461ab32cda64cbe5901bcf42bd70ce6ae18919) to see the changes, which you have to make in your `service.rs` to enable warp sync support. You can find more details in companion PRs and related issue.

**Does this change have a related companion PR?**
Polkadot companion PR [#6334](https://github.com/paritytech/polkadot/pull/6334)
Cumulus companion PR [#1909](https://github.com/paritytech/cumulus/pull/1909)

Related Issues: https://github.com/paritytech/cumulus/issues/1619

---

### sc-client-db: Fix PruningMode::ArchiveCanonical
PR: https://github.com/paritytech/substrate/pull/13361

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

In a Substrate node, we can set state pruning to `archive-canonical`, which would only archive the finalized chain and keep only the state of finalized blocks. In [Polkadot-v0.9.30](https://github.com/paritytech/substrate/pull/11983), `archive-canonical` parameter was added to the `--block-prunning` and `--state-prunning` parameters, which permits to keep the blocks that are only finalized as well as only the state related to finalized blocks.

At the moment, `archive-canonical` flag is broken and is not working properly. This PR fixes the issues related to `archive-canonical`.

Related Issues:
https://github.com/paritytech/substrate/issues/12824
https://github.com/paritytech/substrate/issues/13269

---

### [Feature] Introduce storage_alias for CountedStorageMap
PR: https://github.com/paritytech/substrate/pull/13366

**Why is this important?**

This PR introduces a storage alias for `CountedStorageMap`. If you are not familiar with `CountedStorageMap`, you can read about it [here](https://paritytech.github.io/substrate/master/frame_support/pallet_prelude/struct.CountedStorageMap.html#).

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

You can now interact with the `CountedStorageMap` via the storage alias:

type ExampleCountedMap = CountedStorageMap<Prefix, Twox64Concat, u16, u32>;
assert_eq!(ExampleCountedMap::count(), 0);
ExampleCountedMap::insert(3, 10);

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

Better developer ergonomics.

---

### try-runtime::fast-forward
PR: https://github.com/paritytech/substrate/pull/12896

**Why is this important?**

The try-runtime feature `fast-forward` in conjunction with `RemoteExternalities` scrapes live chain state, inserts it into a `TestExternality` and produces N empty blocks or indefinitely creates empty blocks.

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

This is one additional feature to utilize in the arsenal of try-runtime. If you're not familiar with try-runtime, there is an excellent resource [here](https://paritytech.github.io/substrate/master/try_runtime_cli/index.html).

Example Usage:

./target/release/node-template try-runtime --runtime existing fast-forward --n-blocks 2 live --uri ws://127.0.0.1:9944

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

Try-runtime allows the developer to run tests off of live chain state.

---

### Staking and nomination pools runtime API improvements
PR: https://github.com/paritytech/substrate/pull/13119
Polkadot companion PR: https://github.com/paritytech/polkadot/pull/6683

**Why is this important?**

This PR adds new runtime API calls for staking and nomination pools that can be called through `state_call` rpc to fetch:

Nominations quota (`StakingApi_nominations_quota`)
- Returns the current nominations quota for nominators. For now, this api runtime call will always return value of `T::MaxNominations` and thus it is redundant. However, with the upcoming changes in: [Implements dynamic number of nominators #12970](https://github.com/paritytech/substrate/pull/12970) the nominations quota will change depending on the nominators balance. We're introducing this runtime API now to prepare the community to use it before rolling it out in [PR#12970](https://github.com/paritytech/substrate/pull/12970).

Points to balance conversion for pools (`NominationPoolsApi_points_to_balance`)
- Returns the points to balance conversion for a specified pool.

Balance to point conversion for pools (`NominationPoolsApi_balance_to_points`)
- Returns the equivalent `new_funds` balance to point conversion for a specified pool.

---

### Executor Environment parameterization
PR: https://github.com/paritytech/polkadot/pull/6161

**Why is this important?**

This PR helps with the following issue:

Currently there is no explicit versioning on the PVF execution environment (EE), so once a client release includes a different EE there will be a window of time where the previous and last version of EE will be available at the same time. This implies that there might exist a candidate which would be valid on the newer version and invalid on the previous one, leading to disputes.

The changes included in this PR make the [execution environment parametrized](https://github.com/paritytech/polkadot/blob/e4680ea965aa262a583e20ae508812d9e0fa2258/runtime/parachains/src/session_info.rs#L116), hence bounding these parameters to the session, so when a candidate produced in an older session needs to be a candidate in a newer session the EE will use the parameters that existed in that older session.

To be noted, as per this change executor environment parameters may only be changed with runtime upgrades, this could be changed in favor of being able to change the parameters on the fly.

Additionally, this PR only takes care of parametrizing the EE, this is not versioning, however it is one step in that direction.

**Does this change have a related companion PR?**
Cumulus companion PR: https://github.com/paritytech/cumulus/pull/2151