This documentation guide to address an incorrect exchange rate for a
non-withdrawable pool.

## Context

Implementing `HolderOf(collection_id)` we have observed a fancy glitch
where pallet deposits event with incorrect values

### Test case 

[Observe following
extrinsic](https://assethub-polkadot.subscan.io/extrinsic/0xdc72321b7674aa209c2f194ed49bd6bd12708af103f98b5b9196e0132dcba777)

To mint in collection `51` user needs to be `HolderOf(50)`.
Therefore current user is owner of item `394` `witness_data {
owned_item: 394 }`

All checking is done correctly, storage is updated correctly

 
![photo_2023-12-18 16 07
11](https://github.com/paritytech/polkadot-sdk/assets/22471030/ca991272-156d-4db1-97b2-1a2873fc5d3f)

However the event which is emitted does not make semantic sense as we
updated storage for `50-394` not for `51-114`

![photo_2023-12-18 16 07
17](https://github.com/paritytech/polkadot-sdk/assets/22471030/c998a92c-e306-4433-aad8-103078140e23

)

## The fix 

This PR fixes that depositing `PalletAttributeSet` emits correct values.

---------

Co-authored-by: Jegor Sidorenko <[email protected]>
Co-authored-by: Jegor Sidorenko <[email protected]>

This PR replaces the usage of
[secp256k](https://crates.io/crates/secp256k1) crate with
[k256](https://crates.io/crates/k256) in `core::crypto::ecdsa` for
`non-std` environments as outcome of discussion in #3448.

`secp256k1` is used in `std`, meaning that we should not affect host
performance with this PR.
`k256` is enabled in runtimes (`no-std`), and is required to proceed
with #2044.

If desirable, in future we can switch to `k256` also for `std`. That
would require some performance evaluation (e.g. for EVM chains as per
https://github.com/paritytech/polkadot-sdk/issues/3448#issuecomment-1976780391).

Closes https://github.com/paritytech/polkadot-sdk/issues/3448



---------

Co-authored-by: command-bot <>
Co-authored-by: Davide Galassi <[email protected]>

Signed-off-by: cuinix <[email protected]>
Co-authored-by: Bastian Köcher <[email protected]>

Co-authored-by: Alexander Theißen <[email protected]>
Co-authored-by: command-bot <>

Rustfmt will add a trailing comma for longer expression, this change
will make sure that the Range parameters can still be parsed.

---------

Co-authored-by: command-bot <>
Co-authored-by: Alexander Theißen <[email protected]>

Looking at rococo-asset-hub
https://github.com/paritytech/polkadot-sdk/issues/3519 there seems to be
a lot of instances where collator did not advertise their collations,
while there are multiple problems there, one of it is that we are
connecting and disconnecting to our assigned validators every block,
because on reconnect_timeout every 4s we call connect_to_validators and
that will produce 0 validators when all went well, so set_reseverd_peers
called from validator discovery will disconnect all our peers.
More details here:
https://github.com/paritytech/polkadot-sdk/issues/3519#issuecomment-1972667343

Now, this shouldn't be a problem, but it stacks with an existing bug in
our network stack where if disconnect from a peer the peer might not
notice it, so it won't detect the reconnect either and it won't send us
the necessary view updates, so we won't advertise the collation to it
more details here:

https://github.com/paritytech/polkadot-sdk/issues/3519#issuecomment-1972958276



To avoid hitting this condition that often, let's keep the peers in the
reserved set for the entire duration we are allocated to a backing
group. Backing group sizes(1 rococo, 3 kusama, 5 polkadot) are really
small, so this shouldn't lead to that many connections. Additionally,
the validators would disconnect us any way if we don't advertise
anything for 4 blocks.

## TODO
- [x] More testing.
- [x] Confirm on rococo that this is improving the situation. (It
doesn't but just because other things are going wrong there).

---------

Signed-off-by: Alexandru Gheorghe <[email protected]>

ApiVersion should have been bumped with
https://github.com/paritytech/polkadot-sdk/pull/3606
this does that and add a test so we don't forget to do that everytime

This is a refactoring, no changes to the logic are included (if you find
some, report :D).

## Change Overview
In https://github.com/paritytech/polkadot-sdk/issues/2455

, dependency on
actual runtimes was removed for the system parachains. This means that
the trait bounds we have on various `start_node_xy` do not check
anything anymore, since they all point to the same runtime. Exception is
asset-hub-polkadot which uses a different key type.

This PR unifies the different nodes as much as possible.
`start_node_impl` is doing the heavy lifting and has been made a bit
more flexible to support the rpc extension instantiation that was there
before.

The generics for `Runtime` and `AuraId` have been removed where
possible. The fake runtime is imported as `FakeRuntime` to make it very
clear to readers that it is not the generic parameter.

Multiple nodes where using the same import queue/start_consensus
closure, they have been unified.

---------

Co-authored-by: Kian Paimani <[email protected]>
Co-authored-by: Francisco Aguirre <[email protected]>
Co-authored-by: Adrian Catangiu <[email protected]>
Co-authored-by: Egor_P <[email protected]>
Co-authored-by: Dmitry Markin <[email protected]>
Co-authored-by: Xiliang Chen <[email protected]>
Co-authored-by: Andrei Eres <[email protected]>
Co-authored-by: Alexander Samusev <[email protected]>
Co-authored-by: Alin Dima <[email protected]>
Co-authored-by: gupnik <[email protected]>
Co-authored-by: Liam Aharon <[email protected]>
Co-authored-by: Dónal Murray <[email protected]>

Closes #376

---------

Co-authored-by: command-bot <>

Deprecate the `xcm::body::TREASURER_INDEX` constant and use the standard
Treasury variant from the `xcm::BodyId` type instead.

To align with the production runtimes:
https://github.com/polkadot-fellows/runtimes/pull/149

Oversight from PR https://github.com/paritytech/polkadot-sdk/pull/3384.
These 2 functions should have been tagged as stable

Unfortunately, the flakiness wasn't fixed by
https://github.com/paritytech/polkadot-sdk/pull/3595

. Let's disable the
test in the meanwhile since it is hanging on the CI a lot.

---------

Co-authored-by: Liam Aharon <[email protected]>

This is not maintained, and we should be able to get information
from the release changelog

substrate.io deprecation companion:
https://github.com/substrate-developer-hub/substrate-docs/pull/2139
pba-content companion:
https://github.com/Polkadot-Blockchain-Academy/pba-content/pull/978

partially inspired by:
https://github.com/paritytech/polkadot-sdk/issues/3535



---------

Co-authored-by: Ankan <[email protected]>

Moves [substrate-bip39](https://github.com/paritytech/substrate-bip39)
into substrate. All git history is preserved. Dependencies have been
updated to use the same version as the rest of the repo.

Fixes https://github.com/paritytech/polkadot-sdk/issues/1934

.

---------

Co-authored-by: Maciej Hirsz <[email protected]>
Co-authored-by: Maciej Hirsz <[email protected]>
Co-authored-by: Gav Wood <[email protected]>
Co-authored-by: Stanislav Tkach <[email protected]>
Co-authored-by: Robert Habermeier <[email protected]>
Co-authored-by: Pierre Krieger <[email protected]>
Co-authored-by: Demi M. Obenour <[email protected]>
Co-authored-by: Bastian Köcher <[email protected]>
Co-authored-by: NikVolf <[email protected]>
Co-authored-by: Bastian Köcher <[email protected]>
Co-authored-by: Benjamin Kampmann <[email protected]>
Co-authored-by: Maciej Hirsz <[email protected]>
Co-authored-by: cheme <[email protected]>
Co-authored-by: adoerr <[email protected]>
Co-authored-by: Jun Jiang <[email protected]>
Co-authored-by: Dan Shields <[email protected]>
Co-authored-by: Michal Kucharczyk <[email protected]>

Currently, pool member funds cannot be unbonded if the depositor's stake
is less than `MinNominatorBond`. This usually happens after
`T::MinNominatorBond` is increased.

To fix this, the above mentioned condition is added as a case for
permissionless dispatch of `chill`. After pool is chilled, pool members
can unbond their funds since pool won't be nominating anymore.

Consequently, same check is added to `nominate` call, i.e pool can not
start nominating if it's depositor does not have `MinNominatorBond`

cc @Ank4n @Kianenigma

 

closes #2350

Polkadot address: 16FqwPZ8GRC5U5D4Fu7W33nA55ZXzXGWHwmbnE1eT6pxuqcT

---------

Co-authored-by: Ankan <[email protected]>
Co-authored-by: Gonçalo Pestana <[email protected]>
Co-authored-by: command-bot <>

Changes the way we perform the random selection of backed candidates
when there isn't enough room for all of them. Instead of picking
individual backed candidates `apply_weight` now operates on chains of
candidates. This is fully backwards compatible and relies on the node
side (provisioner/prospective parachains) doing the heavy lifting and
providing the candidates in the order they form a chain.

The same approach can be implemented for bitfields random selection once
https://github.com/paritytech/polkadot-sdk/pull/3479

 is merged.

The approach taken in this PR aims for reduced additional complexity at
the cost of being less fair wrt how many backed candidates from each
chain are picked. It favors elastic scaling parachains vs parachains not
using elastic scaling, but from my perspective it should be fine as this
should happen under exceptional circumstances like dispute storms.

Note: to make things more fair we can consider specializing `random_sel`
such that it will try to pick candidates one by one in the order
provided by the provisioner such that non elastic scaling parachains
have the same chance of getting a candidate backed.

---------

Signed-off-by: Andrei Sandu <[email protected]>

In order to prepare for PolkaVM support I removed the wat support from
our test fixture crate.

- Removed redundant tests (invalid module checks are already inside the
prepare module where they belong
- Converted the gas_sync tests to Rust
- Moved the start function test to the `wasm` module

The current `penpal` runtime utilizes the `EthereumLocation` parameter,
which is employed for XCM emulated integration tests concerning the
Rococo <> ETH bridge. It includes a hard-coded chainId for the Ethereum
testnet utilized in Rococo. The `EthereumLocation` serves the purpose of
aligning with the `TrustedReserves`. However, due to this hard-coded
configuration, reusing `penpal` for testing various environments such as
Kusama/Polkadot versus Ethereum bridge becomes unfeasible.

This PR introduces the capability to easily customize the asset location
for `TrustedReserves` without needing to know anything about Ethereum.


## TODO
- [x] fix integration tests with
`System::set_storage(CustomizableAssetFromSystemAssetHub::key(),
<whatever-location-is-needed>)` @claravanstaden
- [ ] ~~maybe add some helper function/macro to support `set_storage`
for other runtimes (that we could reuse)~~
- [ ] Release patch for: `penpal-runtime` + emulated crate with
`set_storage` support (if needed)
  - [ ] backport to 1.7.0
  - [ ] backport to 1.8.0

---------

Co-authored-by: Clara van Staden <[email protected]>

Co-authored-by: Cyrill Leutwiler <[email protected]>
Co-authored-by: command-bot <>
Co-authored-by: Alexander Theißen <[email protected]>

This PR extends the Initialized event of the chainHead_follow
subscription.

Now, the event provides multiple finalized block hashes. This
information allows clients that are disconnected, and that want to
reconnect, to not lose information about the state of the chain.

At the moment, the spec encourages servers to provide at least 1 minute
of finalized blocks (~10 blocks). The users are responsible for
unpinning these blocks at a later time. This PR tries to report at least
1 finalized block and at most 16 blocks, if they are available.


Closes: https://github.com/paritytech/polkadot-sdk/issues/3432


cc @paritytech/subxt-team

---------

Signed-off-by: Alexandru Vasile <[email protected]>
Co-authored-by: Niklas Adolfsson <[email protected]>

Hopefully helps with test flakiness.

This PR makes `sc-network-sync` types public following
[this](https://github.com/paritytech/polkadot-sdk/issues/3556) issue.

Fixes #3556

Co-authored-by: Alexander Theißen <[email protected]>

Closes: #3196

---------

Co-authored-by: Alexander Theißen <[email protected]>
Co-authored-by: PG Herveou <[email protected]>

Changes:
- `QueueFootprint` gets a new field; `ready_pages` that contains the
non-overweight and not yet processed pages.
- `XCMP` queue pallet is change to use the `ready_pages` instead of
`pages` to calculate the channel suspension thresholds.

This should give the XCMP queue pallet a more correct view of when to
suspend channels.

---------

Signed-off-by: Oliver Tale-Yazdi <[email protected]>

# Description

Removed deprecated type `GenesisConfig` from the codebase.

Closes https://github.com/paritytech/polkadot-sdk/issues/175



# Checklist

- [x] My PR includes a detailed description as outlined in the
"Description" section above
- [x] My PR follows the [labeling requirements](CONTRIBUTING.md#Process)
of this project (at minimum one label for `T`
  required)
- [x] I have made corresponding changes to the documentation (if
applicable)

---------

Co-authored-by: Liam Aharon <[email protected]>
Co-authored-by: Michal Kucharczyk <[email protected]>

The first step towards
https://github.com/paritytech/polkadot-sdk/issues/3155

Brings all templates under the following structure

```
templates
|   parachain
|   |   polkadot-launch
|   |   runtime              --> parachain-template-runtime
|   |   pallets              --> pallet-parachain-template
|   |   node                 --> parachain-template-node
|   minimal
|   |   runtime              --> minimal-template-runtime
|   |   pallets              --> pallet-minimal-template
|   |   node                 --> minimal-template-node
|   solochain
|   |   runtime              --> solochain-template-runtime
|   |   pallets              --> pallet-template (the naming is not consistent here)
|   |   node                 --> solochain-template-node
```

The only note-worthy changes in this PR are: 

- More `Cargo.toml` fields are forwarded to use the one from the
workspace.
- parachain template now has weights and benchmarks
- adds a shell pallet to the minimal template
- remove a few unused deps 


A list of possible follow-ups: 

- [ ] Unify READMEs, create a parent README for all
- [ ] remove references to `docs.substrate.io` in templates
- [ ] make all templates use `#[derive_impl]`
- [ ] update and unify all licenses
- [ ] Remove polkadot launch, use
https://github.com/paritytech/polkadot-sdk/blob/35349df993ea2e7c4769914ef5d199e787b23d4c/cumulus/zombienet/examples/small_network.toml
instead.

Part of #3326 
This one is easier as all the storage items are public. 

@ggwpez @Kianenigma @shawntabrizi



---------

Signed-off-by: Matteo Muraca <[email protected]>
Co-authored-by: Liam Aharon <[email protected]>
Co-authored-by: command-bot <>
Co-authored-by: Kian Paimani <[email protected]>

Fixes failures like:
https://gitlab.parity.io/parity/mirrors/polkadot-sdk/-/jobs/5436619#L3319

# Description

*Deletes `testing.md` file in accordance with the discussion on issue
#2527.* Old references to Gurke or simnet have been removed.

Fixes #2527

---------

Co-authored-by: Bastian Köcher <[email protected]>

After some discussion with @kogeler

 after the we added the rate-limit
middleware it may slow down
the rpc call timings metrics significantly because it works as follows:

1. The rate limit guard is checked when the call comes and if a slot is
available -> process the call
2. If no free spot is available then the call will be sleeping
`jitter_delay + min_time_rate_guard` then woken up and checked at most
ten times
3. If no spot is available after 10 iterations -> the call is rejected
(this may take tens of seconds)

Thus, this PR adds a label "is_rate_limited" to filter those out on the
metrics "substrate_rpc_calls_time" and "substrate_rpc_calls_finished".

I had to merge two middleware layers Metrics and RateLimit to avoid
shared state in a hacky way.

---------

Co-authored-by: James Wilson <[email protected]>

Latest Rust nightly complains with `the item `Result` is imported
redundantly`

Co-authored-by: Sebastian Kunert <[email protected]>
Co-authored-by: Liam Aharon <[email protected]>

Bumps [mio](https://github.com/tokio-rs/mio) from 0.8.8 to 0.8.11.
<details>
<summary>Changelog</summary>
<p><em>Sourced from <a
href="https://github.com/tokio-rs/mio/blob/master/CHANGELOG.md">mio's
changelog</a>.</em></p>
<blockquote>
<h1>0.8.11</h1>
<ul>
<li>Fix receiving IOCP events after deregistering a Windows named pipe
(<a
href="https://redirect.github.com/tokio-rs/mio/pull/1760">tokio-rs/mio#1760</a>,
backport pr:
<a
href="https://redirect.github.com/tokio-rs/mio/pull/1761">tokio-rs/mio#1761</a>).</li>
</ul>
<h1>0.8.10</h1>
<h2>Added</h2>
<ul>
<li>Solaris support
(<a
href="https://redirect.github.com/tokio-rs/mio/pull/1724">tokio-rs/mio#1724</a>).</li>
</ul>
<h1>0.8.9</h1>
<h2>Added</h2>
<ul>
<li>ESP-IDF framework support
(<a
href="https://redirect.github.com/tokio-rs/mio/pull/1692">tokio-rs/mio#1692</a>).</li>
<li>AIX operating system support
(<a
href="https://redirect.github.com/tokio-rs/mio/pull/1704">tokio-rs/mio#1704</a>).</li>
<li>Vita support
(<a
href="https://redirect.github.com/tokio-rs/mio/pull/1721">tokio-rs/mio#1721</a>).</li>
<li><code>{UnixListener,UnixStream}:bind_addr</code>
(<a
href="https://redirect.github.com/tokio-rs/mio/pull/1630">tokio-rs/mio#1630</a>).</li>
<li><code>mio_unsupported_force_poll_poll</code> and
<code>mio_unsupported_force_waker_pipe</code>
<strong>unsupported</strong> configuration flags to force a specific
poll or waker
implementation
(<a
href="https://redirect.github.com/tokio-rs/mio/pull/1684">tokio-rs/mio#1684</a>,
<a
href="https://redirect.github.com/tokio-rs/mio/pull/1685">tokio-rs/mio#1685</a>,
<a
href="https://redirect.github.com/tokio-rs/mio/pull/1692">tokio-rs/mio#1692</a>).</li>
</ul>
<h2>Fixed</h2>
<ul>
<li>The <code>pipe(2)</code> based waker (swapped file descriptors)
(<a
href="https://redirect.github.com/tokio-rs/mio/pull/1722">tokio-rs/mio#1722</a>).</li>
<li>The duplicate waker check to work correctly with cloned
<code>Registry</code>s.
(<a
href="https://redirect.github.com/tokio-rs/mio/pull/1706">tokio-rs/mio#1706</a>).</li>
</ul>
</blockquote>
</details>
<details>
<summary>Commits</summary>
<ul>
<li><a
href="https://github.com/tokio-rs/mio/commit/0328bdef900b6396b8d00d33c825cd8af748553d"><code>0328bde</code></a>
Release v0.8.11</li>
<li><a
href="https://github.com/tokio-rs/mio/commit/708449851283b57eb6f514c8f289b66e982720b3"><code>7084498</code></a>
Fix warnings</li>
<li><a
href="https://github.com/tokio-rs/mio/commit/90d4fe00df870acd3d38f3dc4face9aacab8fbb9"><code>90d4fe0</code></a>
named-pipes: fix receiving IOCP events after deregister</li>
<li><a
href="https://github.com/tokio-rs/mio/commit/c710a307f8627c4d63ac1003252aa45175e08399"><code>c710a30</code></a>
Add v0.8.x to the CI</li>
<li><a
href="https://github.com/tokio-rs/mio/commit/c29e21c244b2b835e8b3e015b92c708c33c7d70a"><code>c29e21c</code></a>
Release v0.8.10</li>
<li><a
href="https://github.com/tokio-rs/mio/commit/f6a20da1c81c2d56a78bc6f6832b9904b9215914"><code>f6a20da</code></a>
Add Solaris operating system support (<a
href="https://redirect.github.com/tokio-rs/mio/issues/1724">#1724</a>)</li>
<li><a
href="https://github.com/tokio-rs/mio/commit/e80c3b21b59b92238f4c8c331fcfc4a71508d1c5"><code>e80c3b2</code></a>
Release v0.8.9</li>
<li><a
href="https://github.com/tokio-rs/mio/commit/862786bbbf719886be55631c0d150d4813a9a1b6"><code>862786b</code></a>
Fix importing of IoSourceState</li>
<li><a
href="https://github.com/tokio-rs/mio/commit/40348728e4f06f5e150783d8f1559ee974e5e834"><code>4034872</code></a>
Add support for vita target</li>
<li><a
href="https://github.com/tokio-rs/mio/commit/8eb4010a92bede550850e177d3dd7c4c76eb90ba"><code>8eb4010</code></a>
Fix receiver and sender fd in pipe based waker</li>
<li>Additional commits viewable in <a
href="https://github.com/tokio-rs/mio/compare/v0.8.8...v0.8.11">compare
view</a></li>
</ul>
</details>
<br />


[![Dependabot compatibility
score](https://dependabot-badges.githubapp.com/badges/compatibility_score?dependency-name=mio&package-manager=cargo&previous-version=0.8.8&new-version=0.8.11)](https://docs.github.com/en/github/managing-security-vulnerabilities/about-dependabot-security-updates#about-compatibility-scores)

Dependabot will resolve any conflicts with this PR as long as you don't
alter it yourself. You can also trigger a rebase manually by commenting
`@dependabot rebase`.

[//]: # (dependabot-automerge-start)
[//]: # (dependabot-automerge-end)

---

<details>
<summary>Dependabot commands and options</summary>
<br />

You can trigger Dependabot actions by commenting on this PR:
- `@dependabot rebase` will rebase this PR
- `@dependabot recreate` will recreate this PR, overwriting any edits
that have been made to it
- `@dependabot merge` will merge this PR after your CI passes on it
- `@dependabot squash and merge` will squash and merge this PR after
your CI passes on it
- `@dependabot cancel merge` will cancel a previously requested merge
and block automerging
- `@dependabot reopen` will reopen this PR if it is closed
- `@dependabot close` will close this PR and stop Dependabot recreating
it. You can achieve the same result by closing it manually
- `@dependabot show <dependency name> ignore conditions` will show all
of the ignore conditions of the specified dependency
- `@dependabot ignore this major version` will close this PR and stop
Dependabot creating any more for this major version (unless you reopen
the PR or upgrade to it yourself)
- `@dependabot ignore this minor version` will close this PR and stop
Dependabot creating any more for this minor version (unless you reopen
the PR or upgrade to it yourself)
- `@dependabot ignore this dependency` will close this PR and stop
Dependabot creating any more for this dependency (unless you reopen the
PR or upgrade to it yourself)
You can disable automated security fix PRs for this repo from the
[Security Alerts
page](https://github.com/paritytech/polkadot-sdk/network/alerts

).

</details>

Signed-off-by: dependabot[bot] <[email protected]>
Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>

Closes #2160

First part of [Extrinsic
Horizon](https://github.com/paritytech/polkadot-sdk/issues/2415

)

Introduces a new trait `TransactionExtension` to replace
`SignedExtension`. Introduce the idea of transactions which obey the
runtime's extensions and have according Extension data (né Extra data)
yet do not have hard-coded signatures.

Deprecate the terminology of "Unsigned" when used for
transactions/extrinsics owing to there now being "proper" unsigned
transactions which obey the extension framework and "old-style" unsigned
which do not. Instead we have __*General*__ for the former and
__*Bare*__ for the latter. (Ultimately, the latter will be phased out as
a type of transaction, and Bare will only be used for Inherents.)

Types of extrinsic are now therefore:
- Bare (no hardcoded signature, no Extra data; used to be known as
"Unsigned")
- Bare transactions (deprecated): Gossiped, validated with
`ValidateUnsigned` (deprecated) and the `_bare_compat` bits of
`TransactionExtension` (deprecated).
  - Inherents: Not gossiped, validated with `ProvideInherent`.
- Extended (Extra data): Gossiped, validated via `TransactionExtension`.
  - Signed transactions (with a hardcoded signature).
  - General transactions (without a hardcoded signature).

`TransactionExtension` differs from `SignedExtension` because:
- A signature on the underlying transaction may validly not be present.
- It may alter the origin during validation.
- `pre_dispatch` is renamed to `prepare` and need not contain the checks
present in `validate`.
- `validate` and `prepare` is passed an `Origin` rather than a
`AccountId`.
- `validate` may pass arbitrary information into `prepare` via a new
user-specifiable type `Val`.
- `AdditionalSigned`/`additional_signed` is renamed to
`Implicit`/`implicit`. It is encoded *for the entire transaction* and
passed in to each extension as a new argument to `validate`. This
facilitates the ability of extensions to acts as underlying crypto.

There is a new `DispatchTransaction` trait which contains only default
function impls and is impl'ed for any `TransactionExtension` impler. It
provides several utility functions which reduce some of the tedium from
using `TransactionExtension` (indeed, none of its regular functions
should now need to be called directly).

Three transaction version discriminator ("versions") are now
permissible:
- 0b000000100: Bare (used to be called "Unsigned"): contains Signature
or Extra (extension data). After bare transactions are no longer
supported, this will strictly identify an Inherents only.
- 0b100000100: Old-school "Signed" Transaction: contains Signature and
Extra (extension data).
- 0b010000100: New-school "General" Transaction: contains Extra
(extension data), but no Signature.

For the New-school General Transaction, it becomes trivial for authors
to publish extensions to the mechanism for authorizing an Origin, e.g.
through new kinds of key-signing schemes, ZK proofs, pallet state,
mutations over pre-authenticated origins or any combination of the
above.

## Code Migration

### NOW: Getting it to build

Wrap your `SignedExtension`s in `AsTransactionExtension`. This should be
accompanied by renaming your aggregate type in line with the new
terminology. E.g. Before:

```rust
/// The SignedExtension to the basic transaction logic.
pub type SignedExtra = (
	/* snip */
	MySpecialSignedExtension,
);
/// Unchecked extrinsic type as expected by this runtime.
pub type UncheckedExtrinsic =
	generic::UncheckedExtrinsic<Address, RuntimeCall, Signature, SignedExtra>;
```

After:

```rust
/// The extension to the basic transaction logic.
pub type TxExtension = (
	/* snip */
	AsTransactionExtension<MySpecialSignedExtension>,
);
/// Unchecked extrinsic type as expected by this runtime.
pub type UncheckedExtrinsic =
	generic::UncheckedExtrinsic<Address, RuntimeCall, Signature, TxExtension>;
```

You'll also need to alter any transaction building logic to add a
`.into()` to make the conversion happen. E.g. Before:

```rust
fn construct_extrinsic(
		/* snip */
) -> UncheckedExtrinsic {
	let extra: SignedExtra = (
		/* snip */
		MySpecialSignedExtension::new(/* snip */),
	);
	let payload = SignedPayload::new(call.clone(), extra.clone()).unwrap();
	let signature = payload.using_encoded(|e| sender.sign(e));
	UncheckedExtrinsic::new_signed(
		/* snip */
		Signature::Sr25519(signature),
		extra,
	)
}
```

After:

```rust
fn construct_extrinsic(
		/* snip */
) -> UncheckedExtrinsic {
	let tx_ext: TxExtension = (
		/* snip */
		MySpecialSignedExtension::new(/* snip */).into(),
	);
	let payload = SignedPayload::new(call.clone(), tx_ext.clone()).unwrap();
	let signature = payload.using_encoded(|e| sender.sign(e));
	UncheckedExtrinsic::new_signed(
		/* snip */
		Signature::Sr25519(signature),
		tx_ext,
	)
}
```

### SOON: Migrating to `TransactionExtension`

Most `SignedExtension`s can be trivially converted to become a
`TransactionExtension`. There are a few things to know.

- Instead of a single trait like `SignedExtension`, you should now
implement two traits individually: `TransactionExtensionBase` and
`TransactionExtension`.
- Weights are now a thing and must be provided via the new function `fn
weight`.

#### `TransactionExtensionBase`

This trait takes care of anything which is not dependent on types
specific to your runtime, most notably `Call`.

- `AdditionalSigned`/`additional_signed` is renamed to
`Implicit`/`implicit`.
- Weight must be returned by implementing the `weight` function. If your
extension is associated with a pallet, you'll probably want to do this
via the pallet's existing benchmarking infrastructure.

#### `TransactionExtension`

Generally:
- `pre_dispatch` is now `prepare` and you *should not reexecute the
`validate` functionality in there*!
- You don't get an account ID any more; you get an origin instead. If
you need to presume an account ID, then you can use the trait function
`AsSystemOriginSigner::as_system_origin_signer`.
- You get an additional ticket, similar to `Pre`, called `Val`. This
defines data which is passed from `validate` into `prepare`. This is
important since you should not be duplicating logic from `validate` to
`prepare`, you need a way of passing your working from the former into
the latter. This is it.
- This trait takes two type parameters: `Call` and `Context`. `Call` is
the runtime call type which used to be an associated type; you can just
move it to become a type parameter for your trait impl. `Context` is not
currently used and you can safely implement over it as an unbounded
type.
- There's no `AccountId` associated type any more. Just remove it.

Regarding `validate`:
- You get three new parameters in `validate`; all can be ignored when
migrating from `SignedExtension`.
- `validate` returns a tuple on success; the second item in the tuple is
the new ticket type `Self::Val` which gets passed in to `prepare`. If
you use any information extracted during `validate` (off-chain and
on-chain, non-mutating) in `prepare` (on-chain, mutating) then you can
pass it through with this. For the tuple's last item, just return the
`origin` argument.

Regarding `prepare`:
- This is renamed from `pre_dispatch`, but there is one change:
- FUNCTIONALITY TO VALIDATE THE TRANSACTION NEED NOT BE DUPLICATED FROM
`validate`!!
- (This is different to `SignedExtension` which was required to run the
same checks in `pre_dispatch` as in `validate`.)

Regarding `post_dispatch`:
- Since there are no unsigned transactions handled by
`TransactionExtension`, `Pre` is always defined, so the first parameter
is `Self::Pre` rather than `Option<Self::Pre>`.

If you make use of `SignedExtension::validate_unsigned` or
`SignedExtension::pre_dispatch_unsigned`, then:
- Just use the regular versions of these functions instead.
- Have your logic execute in the case that the `origin` is `None`.
- Ensure your transaction creation logic creates a General Transaction
rather than a Bare Transaction; this means having to include all
`TransactionExtension`s' data.
- `ValidateUnsigned` can still be used (for now) if you need to be able
to construct transactions which contain none of the extension data,
however these will be phased out in stage 2 of the Transactions Horizon,
so you should consider moving to an extension-centric design.

## TODO

- [x] Introduce `CheckSignature` impl of `TransactionExtension` to
ensure it's possible to have crypto be done wholly in a
`TransactionExtension`.
- [x] Deprecate `SignedExtension` and move all uses in codebase to
`TransactionExtension`.
  - [x] `ChargeTransactionPayment`
  - [x] `DummyExtension`
  - [x] `ChargeAssetTxPayment` (asset-tx-payment)
  - [x] `ChargeAssetTxPayment` (asset-conversion-tx-payment)
  - [x] `CheckWeight`
  - [x] `CheckTxVersion`
  - [x] `CheckSpecVersion`
  - [x] `CheckNonce`
  - [x] `CheckNonZeroSender`
  - [x] `CheckMortality`
  - [x] `CheckGenesis`
  - [x] `CheckOnlySudoAccount`
  - [x] `WatchDummy`
  - [x] `PrevalidateAttests`
  - [x] `GenericSignedExtension`
  - [x] `SignedExtension` (chain-polkadot-bulletin)
  - [x] `RefundSignedExtensionAdapter`
- [x] Implement `fn weight` across the board.
- [ ] Go through all pre-existing extensions which assume an account
signer and explicitly handle the possibility of another kind of origin.
- [x] `CheckNonce` should probably succeed in the case of a non-account
origin.
- [x] `CheckNonZeroSender` should succeed in the case of a non-account
origin.
- [x] `ChargeTransactionPayment` and family should fail in the case of a
non-account origin.
  - [ ] 
- [x] Fix any broken tests.

---------

Signed-off-by: georgepisaltu <[email protected]>
Signed-off-by: Alexandru Vasile <[email protected]>
Signed-off-by: dependabot[bot] <[email protected]>
Signed-off-by: Oliver Tale-Yazdi <[email protected]>
Signed-off-by: Alexandru Gheorghe <[email protected]>
Signed-off-by: Andrei Sandu <[email protected]>
Co-authored-by: Nikhil Gupta <[email protected]>
Co-authored-by: georgepisaltu <[email protected]>
Co-authored-by: Chevdor <[email protected]>
Co-authored-by: Bastian Köcher <[email protected]>
Co-authored-by: Maciej <[email protected]>
Co-authored-by: Javier Viola <[email protected]>
Co-authored-by: Marcin S. <[email protected]>
Co-authored-by: Tsvetomir Dimitrov <[email protected]>
Co-authored-by: Javier Bullrich <[email protected]>
Co-authored-by: Koute <[email protected]>
Co-authored-by: Adrian Catangiu <[email protected]>
Co-authored-by: Vladimir Istyufeev <[email protected]>
Co-authored-by: Ross Bulat <[email protected]>
Co-authored-by: Gonçalo Pestana <[email protected]>
Co-authored-by: Liam Aharon <[email protected]>
Co-authored-by: Svyatoslav Nikolsky <[email protected]>
Co-authored-by: André Silva <[email protected]>
Co-authored-by: Oliver Tale-Yazdi <[email protected]>
Co-authored-by: s0me0ne-unkn0wn <[email protected]>
Co-authored-by: ordian <[email protected]>
Co-authored-by: Sebastian Kunert <[email protected]>
Co-authored-by: Aaro Altonen <[email protected]>
Co-authored-by: Dmitry Markin <[email protected]>
Co-authored-by: Alexandru Vasile <[email protected]>
Co-authored-by: Alexander Samusev <[email protected]>
Co-authored-by: Julian Eager <[email protected]>
Co-authored-by: Michal Kucharczyk <[email protected]>
Co-authored-by: Davide Galassi <[email protected]>
Co-authored-by: Dónal Murray <[email protected]>
Co-authored-by: yjh <[email protected]>
Co-authored-by: Tom Mi <[email protected]>
Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>
Co-authored-by: Will | Paradox | ParaNodes.io <[email protected]>
Co-authored-by: Bastian Köcher <[email protected]>
Co-authored-by: Joshy Orndorff <[email protected]>
Co-authored-by: Joshy Orndorff <[email protected]>
Co-authored-by: PG Herveou <[email protected]>
Co-authored-by: Alexander Theißen <[email protected]>
Co-authored-by: Kian Paimani <[email protected]>
Co-authored-by: Juan Girini <[email protected]>
Co-authored-by: bader y <[email protected]>
Co-authored-by: James Wilson <[email protected]>
Co-authored-by: joe petrowski <[email protected]>
Co-authored-by: asynchronous rob <[email protected]>
Co-authored-by: Parth <[email protected]>
Co-authored-by: Andrew Jones <[email protected]>
Co-authored-by: Jonathan Udd <[email protected]>
Co-authored-by: Serban Iorga <[email protected]>
Co-authored-by: Egor_P <[email protected]>
Co-authored-by: Branislav Kontur <[email protected]>
Co-authored-by: Evgeny Snitko <[email protected]>
Co-authored-by: Just van Stam <[email protected]>
Co-authored-by: Francisco Aguirre <[email protected]>
Co-authored-by: gupnik <[email protected]>
Co-authored-by: dzmitry-lahoda <[email protected]>
Co-authored-by: zhiqiangxu <[email protected]>
Co-authored-by: Nazar Mokrynskyi <[email protected]>
Co-authored-by: Anwesh <[email protected]>
Co-authored-by: cheme <[email protected]>
Co-authored-by: Sam Johnson <[email protected]>
Co-authored-by: kianenigma <[email protected]>
Co-authored-by: Jegor Sidorenko <[email protected]>
Co-authored-by: Muharem <[email protected]>
Co-authored-by: joepetrowski <[email protected]>
Co-authored-by: Alexandru Gheorghe <[email protected]>
Co-authored-by: Gabriel Facco de Arruda <[email protected]>
Co-authored-by: Squirrel <[email protected]>
Co-authored-by: Andrei Sandu <[email protected]>
Co-authored-by: georgepisaltu <[email protected]>
Co-authored-by: command-bot <>

Closes https://github.com/paritytech/polkadot-sdk-docs/issues/35



- Moves pallet proc macro docs to `frame_support`
- Adds missing docs
- Revise revise existing docs, adding compiling doctests where
appropriate

---------

Co-authored-by: command-bot <>
Co-authored-by: Kian Paimani <[email protected]>

Step in https://github.com/paritytech/polkadot-sdk/issues/171

This PR removes the need to specify `as [disambiguation_path]` for cases
where the trait definition resides within the same scope as default impl
path.

For example, in the following macro invocation
```rust
#[derive_impl(frame_system::config_preludes::TestDefaultConfig as frame_system::DefaultConfig)]
impl frame_system::Config for Runtime {
   ...
}
```
the trait `DefaultConfig` lies within the `frame_system` scope and
`TestDefaultConfig` impls the `DefaultConfig` trait. Using this
information, we can compute the disambiguation path internally, thus
removing the need of an explicit specification.

In cases where the trait lies outside this scope, we would still need to
specify it explicitly, but this should take care of most (if not all)
uses of `derive_impl` within FRAME's context.