Changes:
- Use a sensible limit for the overweight-cutoff of a single messages
instead of the full configured `ServiceWeight`.
- Add/Update tests
---------
Signed-off-by: Oliver Tale-Yazdi <oliver.tale-yazdi@parity.io>
Combination of paritytech/polkadot#7005, its addon PR
paritytech/polkadot#7585 and its companion paritytech/cumulus#2433.
This PR introduces a new XcmFeesToAccount struct which implements the
`FeeManager` trait, and assigns this struct as the `FeeManager` in the
XCM config for all runtimes.
The struct simply deposits all fees handled by the XCM executor to a
specified account. In all runtimes, the specified account is configured
as the treasury account.
XCM __delivery__ fees are now being introduced (unless the root origin
is sending a message to a system parachain on behalf of the originating
chain).
# Note for reviewers
Most file changes are tests that had to be modified to account for the
new fees.
Main changes are in:
- cumulus/pallets/xcmp-queue/src/lib.rs <- To make it track the delivery
fees exponential factor
- polkadot/xcm/xcm-builder/src/fee_handling.rs <- Added. Has the
FeeManager implementation
- All runtime xcm_config files <- To add the FeeManager to the XCM
configuration
# Important note
After this change, instructions that create and send a new XCM (Query*,
Report*, ExportMessage, InitiateReserveWithdraw, InitiateTeleport,
DepositReserveAsset, TransferReserveAsset, LockAsset and RequestUnlock)
will require the corresponding origin account in the origin register to
pay for transport delivery fees, and the onward message will fail to be
sent if the origin account does not have the required amount. This
delivery fee is on top of what we already collect as tx fees in
pallet-xcm and XCM BuyExecution fees!
Wallet UIs that want to expose the new delivery fee can do so using the
formula:
```
delivery_fee_factor * (base_fee + encoded_msg_len * per_byte_fee)
```
where the delivery fee factor can be obtained from the corresponding
pallet based on which transport you are using (UMP, HRMP or bridges),
the base fee is a constant, the encoded message length from the message
itself and the per byte fee is the same as the configured per byte fee
for txs (i.e. `TransactionByteFee`).
---------
Co-authored-by: Branislav Kontur <bkontur@gmail.com>
Co-authored-by: joe petrowski <25483142+joepetrowski@users.noreply.github.com>
Co-authored-by: Giles Cope <gilescope@gmail.com>
Co-authored-by: command-bot <>
Co-authored-by: Francisco Aguirre <franciscoaguirreperez@gmail.com>
Co-authored-by: Liam Aharon <liam.aharon@hotmail.com>
Co-authored-by: Kian Paimani <5588131+kianenigma@users.noreply.github.com>
I have added some Traits that are missing and are useful for dealing
with non-fungible tokens on other pallets and their implementations for
NFTs pallet.
- In the Mutate trait, added methods for dealing with the metadata:
`set_metadata`, `set_collection_metadata`, `clear_metadata` and
`clear_collection_metadata`.
The motivation of adding this methods coming from a StackExchange
question asking for it: [Setting metadata of an item of the Nfts pallet
in a custom
pallet](https://substrate.stackexchange.com/questions/9974/setting-metadata-of-an-item-of-the-nfts-pallet-in-a-custom-pallet)
- A Trait for trading non-fungible items. The methods in that Trait are
`buy_item`, `set_price` and `item_price`
An example of where this Trait can be useful is a pallet that deals with
[NFT
Royalties](https://forum.polkadot.network/t/nfts-royalty-pallet/3766)
and needs to perform this actions.
---------
Co-authored-by: Jegor Sidorenko <5252494+jsidorenko@users.noreply.github.com>
Closes https://github.com/paritytech/polkadot-sdk/issues/1916
Changes:
- Trivially wrap the migration into a version migration to enforce
idempotency.
- Opinionated logging nits
@liamaharon maybe we can add a check to the `try-runtime-cli` that
migrations are idempotent? It should be possible to check that the
storage root is identical after executing a second time (and that it
does not panic like it did here 😆).
---------
Signed-off-by: Oliver Tale-Yazdi <oliver.tale-yazdi@parity.io>
Co-authored-by: Liam Aharon <liam.aharon@hotmail.com>
Co-authored-by: Francisco Aguirre <franciscoaguirreperez@gmail.com>
## Summary
This PR introduces several enhancements.
The current implementation of `NetworkExportTable` lacks remote location
filtering support beyond `NetworkId` lookup. To provide more control and
granularity, it's essential to allow configuration for bridging to
different consensus `NetworkId` while restricting access e.g. to
particular remote parachains.
Additionally, the `StartsWith` and `Equals` and
`StartsWithExplicitGlobalConsensus` helper functions, which are in
active use, are moved to the `xcm-builder` and `frame_support` modules
for better code organization.
Adds a new `LocationWithAssetFilters` filter to enable location-based
and asset-related filtering. This filter is useful for configuring the
`pallet_xcm` filter for
[XcmTeleportFilter](https://github.com/paritytech/polkadot-sdk/blob/master/polkadot/xcm/pallet-xcm/src/lib.rs#L212)
and
[XcmReserveTransferFilter](https://github.com/paritytech/polkadot-sdk/blob/master/polkadot/xcm/pallet-xcm/src/lib.rs#L216)
to restrict specific assets.
Furthermore, the `BridgeMessage` fields are not accessible outside of
`xcm-builder`, limiting the ability to create custom logic dependent on
it.
---------
Co-authored-by: Francisco Aguirre <franciscoaguirreperez@gmail.com>
Fix situation where BEEFY initial validator set could not be determined.
If state is unavailable at BEEFY genesis block to get initial validator
set, get the info from header digests. For this, we need to walk back
the chain starting from BEEFY genesis looking for the BEEFY digest
announcing the active validator set for that respective session.
This commit fixes a silly bug where walking back the chain was stopped
when reaching BEEFY genesis block, which is incorrect when BEEFY genesis
is not session boundary block. When BEEFY genesis is set to some random
block within a session, we need to walk back to the start of the session
to see the validator set announcement.
Added regression test for this fix.
Fixes https://github.com/paritytech/polkadot-sdk/issues/1885
Signed-off-by: Adrian Catangiu <adrian@parity.io>
# Description
Follow up for https://github.com/paritytech/polkadot-sdk/pull/1489.
Closes#611
Before we calculated the channel size during alert expression but in
#1489 a new metric was introduced that reports channel size.
## Changes:
1. updated alert rule to use new metric.
- Removal of Arkworks unit tests. These tests were just testing the
arkworks upstream implementation which should be assumed correct. This
is not the place to test well known dependencies.
- Removal of some over-engineering. We just store the calls to Arkworks
in one file. Per-curve sources are not required.
- Docs formatting
---
I also took the opportunity to bump the `bandersnatch-vrfs` crate
revision internally providing some new shiny stuff.
This PR refactors the staking ledger logic to encapsulate all reads and
mutations of `Ledger`, `Bonded`, `Payee` and stake locks within the
`StakingLedger` struct implementation.
With these changes, all the reads and mutations to the `Ledger`, `Payee`
and `Bonded` storage map should be done through the methods exposed by
StakingLedger to ensure the data and lock consistency of the operations.
The new introduced methods that mutate and read Ledger are:
- `ledger.update()`: inserts/updates a staking ledger in storage;
updates staking locks accordingly (and ledger.bond(), which is synthatic
sugar for ledger.update())
- `ledger.kill()`: removes all Bonded and StakingLedger related data for
a given ledger; updates staking locks accordingly;
`StakingLedger::get(account)`: queries both the `Bonded` and `Ledger`
storages and returns a `Option<StakingLedger>`. The pallet impl exposes
fn ledger(account) as synthatic sugar for `StakingLedger::get(account)`.
Retrieving a ledger with `StakingLedger::get()` can be done by providing
either a stash or controller account. The input must be wrapped in a
`StakingAccount` variant (Stash or Controller) which is treated
accordingly. This simplifies the caller API but will eventually be
deprecated once we completely get rid of the controller account in
staking. However, this refactor will help with the work necessary when
completely removing the controller.
Other goals:
- No logical changes have been introduced in this PR;
- No breaking changes or updates in wallets required;
- No new storage items or need to perform storage migrations;
- Centralise the changes to bonds and ledger updates to simplify the
OnStakingUpdate updates to the target list (related to
https://github.com/paritytech/polkadot-sdk/issues/443)
Note: it would be great to prevent or at least raise a warning if
`Ledger<T>`, `Payee<T>` and `Bonded<T>` storage types are accessed
outside the `StakingLedger` implementation. This PR should not get
blocked by that feature, but there's a tracking issue here
https://github.com/paritytech/polkadot-sdk/issues/149
Related and step towards
https://github.com/paritytech/polkadot-sdk/issues/443
BEEFY needs two cryptographic keys at the same time. Validators should
sign BEEFY payload using both ECDSA and BLS key. The network will gossip
a payload which contains a valid ECDSA key. The prover nodes aggregate
the BLS keys if aggregation fails to verifies the validator which
provided a valid ECDSA signature but an invalid BLS signature is subject
to slashing.
As such BEEFY session should be initiated with both key. Currently there
is no straight forward way of doing so, beside having a session with
RuntimeApp corresponding to a crypto scheme contains both keys.
This pull request implement a generic paired_crypto scheme as well as
implementing it for (ECDSA, BLS) pair.
---------
Co-authored-by: Davide Galassi <davxy@datawok.net>
Co-authored-by: Robert Hambrock <roberthambrock@gmail.com>
# Description
- What does this PR do?
- link added
- Why are these changes needed?
- improve docs
- How were these changes implemented and what do they affect?
- only concerns docs
closes#622
Pros:
* simpler interface, just functions:
`create_runtime_from_artifact_bytes()` and `execute_artifact()`
Cons:
* extra overhead of constructing executor semantics each time
I could make it a combination of
* `create_runtime_config(params)` (such that we could clone the
constructed semantics)
* `create_runtime(blob, config)`
* `execute_artifact(blob, config, params)`
Not sure if it's worth it though.
---------
Co-authored-by: Bastian Köcher <git@kchr.de>
- This PR refactors `alliance/src/benchmarkings.rs` to use benchmarking
v2. These changes are needed to improve the readability and
maintainability of the benchmarking code.
- No known issue to backlink.
## Local Testing
1. `cargo build --features runtime-benchmarks`
2. `cargo run --locked --release -p node-cli --bin substrate-node
--features runtime-benchmarks -- benchmark pallet --execution wasm
--wasm-execution compiled --chain dev --pallet "*" --extrinsic "*"
--steps 2 --repeat 1`
- Remove cached messages used for deduplication in `GossipValidator`
since they're already deduplicated in upper layer `NetworkGossip`.
- Add cache for "justified rounds" to quickly discard any further (even
if potentially different) justifications at the gossip level, once a
valid one (for a respective round) is submitted to the worker.
- Add short-circuit in worker `finalize()` method to not attempt to
finalize same block multiple times (for example when we get
justifications for same block from multiple components like
block-import, gossip or on-demand).
- Change a test which had A LOT of latency in syncing blocks for some
weird reason and would only run after ~150seconds. It now runs
instantly.
Fixes https://github.com/paritytech/polkadot-sdk/issues/1728
Fixes https://github.com/paritytech/polkadot-sdk/issues/1839
Currently, `composite_enum`s do not support pallet instances. This PR
allows the following:
```rust
#[pallet::composite_enum]
pub enum HoldReason<I: 'static = ()> {
SomeHoldReason
}
```
### Todo
- [x] UI Test
This PR refactors `identity/benchmarkings.rs` to use benchmarking v2.
These changes are needed to improve the readability and maintainability
of the benchmarking code. Changes were implemented using
[this](https://github.com/paritytech/polkadot-sdk/commit/9ec80090f5065ce0e3234886c43bc623e8e60d77)
commit as a guide. The logic of the benchmarks remains the same.
No known issue to backlink.
## Local Testing
To test the new benchmarks:
1. `cargo build --features runtime-benchmarks`
2. `./target/debug/polkadot benchmark pallet --steps=5 --repeat=2
--pallet=pallet_identity --extrinsic='*'`
---------
Co-authored-by: Richard Melkonian <movses@richards-mbp.home>
Co-authored-by: joe petrowski <25483142+joepetrowski@users.noreply.github.com>
Co-authored-by: command-bot <>
Co-authored-by: Francisco Aguirre <franciscoaguirreperez@gmail.com>
Co-authored-by: Oliver Tale-Yazdi <oliver.tale-yazdi@parity.io>
Needs https://github.com/sam0x17/macro_magic/pull/13
The associated PR allows the export of tokens from macro_magic at the
specified path. This fixes the path issue in derive-impl. Now, we can
import the default config using the standard rust syntax:
```rust
use frame_system::config_preludes::TestDefaultConfig;
[derive_impl(TestDefaultConfig as frame_system::DefaultConfig)]
impl frame_system::DefaultConfig for Test {
//....
}
```
# Description
Upgrades `macro_magic` to 0.4.3, which introduces the ability to have
`export_tokens` use the same name as the underlying item for its
auto-generated macro name. Ultimately this will allow for better dev ux
in our derive_impl feature.
Original PR https://github.com/paritytech/substrate/pull/14746
---
## Fixing stall
### Introduction
I experienced an apparent stall downloading state from
`https://rococo-try-runtime-node.parity-chains.parity.io:443` which was
having networking difficulties only responding to my JSONRPC requests
with 50-200KB/s of bandwidth.
This PR fixes the issue causing the stall, and generally improves
performance remote-ext when it downloads state by greatly reducing the
chances of a timeout occuring.
### Description
Introduces a new `REQUEST_DURATION_TARGET` constant and modifies
`get_storage_data_dynamic_batch_size` to
- Increase or decrease the batch size of the next request depending on
whether the elapsed time of the last request was gt or lt the target
- Reset the batch size to 1 if the request times out
This fixes an issue on slow connections that can otherwise cause
multiple timeouts and a stalled download when:
1. The batch size increases rapidly as remote-ext downloads keys with
small associated storage values
2. remote-ext tries to process a large series of subsequent keys all
with extremely large associated storage values (Rococo has a series of
keys 1-5MB large)
3. The huge storage values download for 5 minutes until the request
times out
4. The partially downloaded keys are thrown out and remote-ext tries
again with a smaller batch size, but the batch size is still far too
large and takes 5 minutes to be reduced again
5. The download will be essentially stalled for many hours while the
above step cycles
After this PR, the request size will
- Not grow as large to begin with, as it is regulated downwards as the
request duration exceeds the target
- Drop immediately to 1 if the request times out. A timeout indicates
the keys next in line to download have extremely large storage values
compared to previously downloaded keys, and we need to reset the batch
size to figure out what our new ideal batch size is. By not resetting
down to 1, we risk the next request timing out again.
## Reducing memory
As suggested by @bkchr, I adjusted `get_storage_data_dynamic_batch_size`
from being recursive to a loop which allows removing a bunch of clones
that were chewing through a lot of memory. I noticed actually it was
using up to 50GB swap previously when downloading Polkadot keys on a
slow connection, because it needed to recurse and clone a lot.
After this change it uses only ~1.5GB memory.
Adds a warning to FRAME pallets when a function argument that starts
with `_` is used in the weight formula.
This is in most cases an error since the weight witness needs to be
checked.
Example:
```rust
#[pallet::call_index(0)]
#[pallet::weight(T::SystemWeightInfo::remark(_remark.len() as u32))]
pub fn remark(_origin: OriginFor<T>, _remark: Vec<u8>) -> DispatchResultWithPostInfo {
Ok(().into())
}
```
Produces this warning:
```pre
warning: use of deprecated constant `pallet::warnings::UncheckedWeightWitness_0::_w`:
It is deprecated to not check weight witness data.
Please instead ensure that all witness data for weight calculation is checked before usage.
For more info see:
<https://github.com/paritytech/polkadot-sdk/pull/1818>
--> substrate/frame/system/src/lib.rs:424:40
|
424 | pub fn remark(_origin: OriginFor<T>, _remark: Vec<u8>) -> DispatchResultWithPostInfo {
| ^^^^^^^
|
= note: `#[warn(deprecated)]` on by default
```
Can be suppressed like this, since in this case it is legit:
```rust
#[pallet::call_index(0)]
#[pallet::weight(T::SystemWeightInfo::remark(remark.len() as u32))]
pub fn remark(_origin: OriginFor<T>, remark: Vec<u8>) -> DispatchResultWithPostInfo {
let _ = remark; // We dont need to check the weight witness.
Ok(().into())
}
```
Changes:
- Add warning on uncheded weight witness
- Respect `subkeys` limit in `System::kill_prefix`
- Fix HRMP pallet and other warnings
- Update`proc_macro_warning` dependency
- Delete random folder `substrate/src/src` 🙈
- Adding Prdoc
---------
Signed-off-by: Oliver Tale-Yazdi <oliver.tale-yazdi@parity.io>
Co-authored-by: joe petrowski <25483142+joepetrowski@users.noreply.github.com>
When retrieving the ready blocks, verify that the parent of the first
ready block is on chain. If the parent is not on chain, we are
downloading from a fork. In this case, keep downloading until we have a
parent on chain (common ancestor).
Resolves https://github.com/paritytech/polkadot-sdk/issues/493.
---------
Co-authored-by: Aaro Altonen <48052676+altonen@users.noreply.github.com>
See #1345, <https://github.com/paritytech/substrate/pull/14207>.
This adds all the necessary mixnet components, and puts them together in
the "kitchen-sink" node/runtime. The components added are:
- A pallet (`frame/mixnet`). This is responsible for determining the
current mixnet session and phase, and the mixnodes to use in each
session. It provides a function that validators can call to register a
mixnode for the next session. The logic of this pallet is very similar
to that of the `im-online` pallet.
- A service (`client/mixnet`). This implements the core mixnet logic,
building on the `mixnet` crate. The service communicates with other
nodes using notifications sent over the "mixnet" protocol.
- An RPC interface. This currently only supports sending transactions
over the mixnet.
---------
Co-authored-by: David Emett <dave@sp4m.net>
Co-authored-by: Javier Viola <javier@parity.io>
### Summary
This PR introduces new dispatchables to the treasury pallet, allowing
spends of various asset types. The enhanced features of the treasury
pallet, in conjunction with the asset-rate pallet, are set up and
enabled for Westend and Rococo.
### Westend and Rococo runtimes.
Polkadot/Kusams/Rococo Treasury can accept proposals for `spends` of
various asset kinds by specifying the asset's location and ID.
#### Treasury Instance New Dispatchables:
- `spend(AssetKind, AssetBalance, Beneficiary, Option<ValidFrom>)` -
propose and approve a spend;
- `payout(SpendIndex)` - payout an approved spend or retry a failed
payout
- `check_payment(SpendIndex)` - check the status of a payout;
- `void_spend(SpendIndex)` - void previously approved spend;
> existing spend dispatchable renamed to spend_local
in this context, the `AssetKind` parameter contains the asset's location
and it's corresponding `asset_id`, for example:
`USDT` on `AssetHub`,
``` rust
location = MultiLocation(0, X1(Parachain(1000)))
asset_id = MultiLocation(0, X2(PalletInstance(50), GeneralIndex(1984)))
```
the `Beneficiary` parameter is a `MultiLocation` in the context of the
asset's location, for example
``` rust
// the Fellowship salary pallet's location / account
FellowshipSalaryPallet = MultiLocation(1, X2(Parachain(1001), PalletInstance(64)))
// or custom `AccountId`
Alice = MultiLocation(0, AccountId32(network: None, id: [1,...]))
```
the `AssetBalance` represents the amount of the `AssetKind` to be
transferred to the `Beneficiary`. For permission checks, the asset
amount is converted to the native amount and compared against the
maximum spendable amount determined by the commanding spend origin.
the `spend` dispatchable allows for batching spends with different
`ValidFrom` arguments, enabling milestone-based spending. If the
expectations tied to an approved spend are not met, it is possible to
void the spend later using the `void_spend` dispatchable.
Asset Rate Pallet provides the conversion rate from the `AssetKind` to
the native balance.
#### Asset Rate Instance Dispatchables:
- `create(AssetKind, Rate)` - initialize a conversion rate to the native
balance for the given asset
- `update(AssetKind, Rate)` - update the conversion rate to the native
balance for the given asset
- `remove(AssetKind)` - remove an existing conversion rate to the native
balance for the given asset
the pallet's dispatchables can be executed by the Root or Treasurer
origins.
### Treasury Pallet
Treasury Pallet can accept proposals for `spends` of various asset kinds
and pay them out through the implementation of the `Pay` trait.
New Dispatchables:
- `spend(Config::AssetKind, AssetBalance, Config::Beneficiary,
Option<ValidFrom>)` - propose and approve a spend;
- `payout(SpendIndex)` - payout an approved spend or retry a failed
payout;
- `check_payment(SpendIndex)` - check the status of a payout;
- `void_spend(SpendIndex)` - void previously approved spend;
> existing spend dispatchable renamed to spend_local
The parameters' types of the `spend` dispatchable exposed via the
pallet's `Config` and allows to propose and accept a spend of a certain
amount.
An approved spend can be claimed via the `payout` within the
`Config::SpendPeriod`. Clients provide an implementation of the `Pay`
trait which can pay an asset of the `AssetKind` to the `Beneficiary` in
`AssetBalance` units.
The implementation of the Pay trait might not have an immediate final
payment status, for example if implemented over `XCM` and the actual
transfer happens on a remote chain.
The `check_status` dispatchable can be executed to update the spend's
payment state and retry the `payout` if the payment has failed.
---------
Co-authored-by: joe petrowski <25483142+joepetrowski@users.noreply.github.com>
Co-authored-by: command-bot <>
Bumps the known_good_semver group with 1 update:
[syn](https://github.com/dtolnay/syn).
<details>
<summary>Release notes</summary>
<p><em>Sourced from <a
href="https://github.com/dtolnay/syn/releases">syn's
releases</a>.</em></p>
<blockquote>
<h2>2.0.38</h2>
<ul>
<li>Fix <em>"method 'peek' has an incompatible type for
trait"</em> error when defining <code>bool</code> as a custom
keyword (<a
href="https://redirect.github.com/dtolnay/syn/issues/1518">#1518</a>,
thanks <a
href="https://github.com/Vanille-N"><code>@Vanille-N</code></a>)</li>
</ul>
</blockquote>
</details>
<details>
<summary>Commits</summary>
<ul>
<li><a
href="https://github.com/dtolnay/syn/commit/43632bfb6c78ee1f952645a268ab1ac4af162977"><code>43632bf</code></a>
Release 2.0.38</li>
<li><a
href="https://github.com/dtolnay/syn/commit/abd2c214b44da64a5e420d72919308300eebc23d"><code>abd2c21</code></a>
Merge pull request <a
href="https://redirect.github.com/dtolnay/syn/issues/1518">#1518</a>
from Vanille-N/master</li>
<li><a
href="https://github.com/dtolnay/syn/commit/6701e6077e15013ef34b15e3ffdae2657e499d83"><code>6701e60</code></a>
Absolute path to <code>bool</code> in
<code>custom_punctuation.rs</code></li>
<li><a
href="https://github.com/dtolnay/syn/commit/7313d242398111423f046386aa0a75548f63d236"><code>7313d24</code></a>
Resolve single_match_else pedantic clippy lint in code generator</li>
<li><a
href="https://github.com/dtolnay/syn/commit/67ab64f3c09e17b23493c7cda498e7edb8830f21"><code>67ab64f</code></a>
Include unexpected token in the test failure message</li>
<li><a
href="https://github.com/dtolnay/syn/commit/137ae33486de3f2652487f8f64436ad1429df496"><code>137ae33</code></a>
Check no remaining token after the first literal</li>
<li><a
href="https://github.com/dtolnay/syn/commit/258e9e8a11d188c1ee1ffb2b069819239999f9ac"><code>258e9e8</code></a>
Ignore single_match_else pedantic clippy lint in test</li>
<li><a
href="https://github.com/dtolnay/syn/commit/92fd50ee8cb52968d9c66fbe6d67638c1f838e26"><code>92fd50e</code></a>
Test docs.rs documentation build in CI</li>
<li>See full diff in <a
href="https://github.com/dtolnay/syn/compare/2.0.37...2.0.38">compare
view</a></li>
</ul>
</details>
<br />
[](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 <dependency name> major version` will close this
group update PR and stop Dependabot creating any more for the specific
dependency's major version (unless you unignore this specific
dependency's major version or upgrade to it yourself)
- `@dependabot ignore <dependency name> minor version` will close this
group update PR and stop Dependabot creating any more for the specific
dependency's minor version (unless you unignore this specific
dependency's minor version or upgrade to it yourself)
- `@dependabot ignore <dependency name>` will close this group update PR
and stop Dependabot creating any more for the specific dependency
(unless you unignore this specific dependency or upgrade to it yourself)
- `@dependabot unignore <dependency name>` will remove all of the ignore
conditions of the specified dependency
- `@dependabot unignore <dependency name> <ignore condition>` will
remove the ignore condition of the specified dependency and ignore
conditions
</details>
Signed-off-by: dependabot[bot] <support@github.com>
Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>
Bumps the known_good_semver group with 1 update:
[clap](https://github.com/clap-rs/clap).
<details>
<summary>Release notes</summary>
<p><em>Sourced from <a
href="https://github.com/clap-rs/clap/releases">clap's
releases</a>.</em></p>
<blockquote>
<h2>v4.4.6</h2>
<h2>[4.4.6] - 2023-09-28</h2>
<h3>Internal</h3>
<ul>
<li>Upgrade <code>anstream</code></li>
</ul>
<h2>v4.4.5</h2>
<h2>[4.4.5] - 2023-09-25</h2>
<h3>Fixes</h3>
<ul>
<li><em>(parser)</em> When inferring subcommand <code>name</code> or
<code>long_flag</code>, allow ambiguous-looking matches that
unambiguously map back to the same command</li>
<li><em>(parser)</em> When inferring subcommand <code>long_flag</code>,
don't panic</li>
<li><em>(assert)</em> Clarify what action is causing a positional that
doesn't set values which is especially useful for derive users</li>
</ul>
</blockquote>
</details>
<details>
<summary>Changelog</summary>
<p><em>Sourced from <a
href="https://github.com/clap-rs/clap/blob/master/CHANGELOG.md">clap's
changelog</a>.</em></p>
<blockquote>
<h2>[4.4.6] - 2023-09-28</h2>
<h3>Internal</h3>
<ul>
<li>Upgrade <code>anstream</code></li>
</ul>
<h2>[4.4.5] - 2023-09-25</h2>
<h3>Fixes</h3>
<ul>
<li><em>(parser)</em> When inferring subcommand <code>name</code> or
<code>long_flag</code>, allow ambiguous-looking matches that
unambiguously map back to the same command</li>
<li><em>(parser)</em> When inferring subcommand <code>long_flag</code>,
don't panic</li>
<li><em>(assert)</em> Clarify what action is causing a positional that
doesn't set values which is especially useful for derive users</li>
</ul>
</blockquote>
</details>
<details>
<summary>Commits</summary>
<ul>
<li><a
href="https://github.com/clap-rs/clap/commit/39f5e807af1c08acedbf7343ce9ec379a4308636"><code>39f5e80</code></a>
chore: Release</li>
<li><a
href="https://github.com/clap-rs/clap/commit/a5cb6bb988bbacb02e8cf98b6156c860d0801e08"><code>a5cb6bb</code></a>
docs: Update changelog</li>
<li><a
href="https://github.com/clap-rs/clap/commit/418c0017a654e9859adfa9b051815f20e4583e31"><code>418c001</code></a>
Merge pull request <a
href="https://redirect.github.com/clap-rs/clap/issues/5146">#5146</a>
from epage/update</li>
<li><a
href="https://github.com/clap-rs/clap/commit/485b957c4b90aa010276f813dbd429e1071f8fd9"><code>485b957</code></a>
chore: Upgrade anstream</li>
<li><a
href="https://github.com/clap-rs/clap/commit/a1af8d9ad8f81eb2d71203b50c370a78ce3ec9f3"><code>a1af8d9</code></a>
chore: Update from '_rust/main'</li>
<li><a
href="https://github.com/clap-rs/clap/commit/ac51f0925003597dec21529538597dbd7872d1ac"><code>ac51f09</code></a>
chore(ci): Normalize json5 syntax</li>
<li><a
href="https://github.com/clap-rs/clap/commit/86c29dea384c7392a2b682fa0150f52c0f4c7f00"><code>86c29de</code></a>
chore(ci): Updaet Renovate schema</li>
<li><a
href="https://github.com/clap-rs/clap/commit/204552890d316ec9ae0b21f85298ba1d5d0786f8"><code>2045528</code></a>
chore: Release</li>
<li><a
href="https://github.com/clap-rs/clap/commit/55d223001682bc668f5e4db91afd5e76c2a36597"><code>55d2230</code></a>
docs: Update changelog</li>
<li><a
href="https://github.com/clap-rs/clap/commit/492ee03b325ff98c7702295e024576b52b71358d"><code>492ee03</code></a>
Merge pull request <a
href="https://redirect.github.com/clap-rs/clap/issues/5140">#5140</a>
from epage/dyn</li>
<li>Additional commits viewable in <a
href="https://github.com/clap-rs/clap/compare/v4.4.4...v4.4.6">compare
view</a></li>
</ul>
</details>
<br />
[](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 <dependency name> major version` will close this
group update PR and stop Dependabot creating any more for the specific
dependency's major version (unless you unignore this specific
dependency's major version or upgrade to it yourself)
- `@dependabot ignore <dependency name> minor version` will close this
group update PR and stop Dependabot creating any more for the specific
dependency's minor version (unless you unignore this specific
dependency's minor version or upgrade to it yourself)
- `@dependabot ignore <dependency name>` will close this group update PR
and stop Dependabot creating any more for the specific dependency
(unless you unignore this specific dependency or upgrade to it yourself)
- `@dependabot unignore <dependency name>` will remove all of the ignore
conditions of the specified dependency
- `@dependabot unignore <dependency name> <ignore condition>` will
remove the ignore condition of the specified dependency and ignore
conditions
</details>
Signed-off-by: dependabot[bot] <support@github.com>
Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>
Closes#1767
Until now the `purge-chain` command would only remove the `full`
subfolder of the db folder. However there is also the `parachains` db
that currently remains and can cause problems on node restart.
Example wiht old code:
```
polkadot purge-chain --database paritydb --base-path /tmp/some-folder
Are you sure to remove "/tmp/some-folder/chains/polkadot/paritydb/full"? [y/N]: y
"/tmp/some-folder/chains/polkadot/paritydb/full" removed.
```
In this case `/tmp/some-folder/chains/polkadot/paritydb/parachains`
would remain and might cause problem on node restart because of version
conflicts as described in #1767. After this PR the whole
`/tmp/some-folder/chains/polkadot/paritydb` folder will be deleted.
Since the hash rules of this part of the `pallet_prefix/storage_prefix`
are always fixed, we can put the runtime calculation into compile time.
---
polkadot address: 15ouFh2SHpGbHtDPsJ6cXQfes9Cx1gEFnJJsJVqPGzBSTudr
---------
Co-authored-by: Juan <juangirini@gmail.com>
Co-authored-by: command-bot <>
Co-authored-by: Oliver Tale-Yazdi <oliver.tale-yazdi@parity.io>
Makes SPs first class citizens along with the relay chains in the
context of our CI runtime upgrade checks.
## Code changes
- Sets missing current storage version in `uniques` pallet
- Adds multisig V1 migration to run where it was missing
- Removes executed migration whos pre/post hooks were failing from
collectives runtime
- Initializes storage versions for SP pallets added after genesis
- Originally I was going to wait for
https://github.com/paritytech/polkadot-sdk/pull/1297 to be merged so
this wouldn't need to be done manually, but it doesn't seem like it'll
be merged any time soon so I've decided to set them manually to unblock
this
## CI changes
- Removed dependency of `westend` runtime upgrades being complete prior
to other ones running. I assume it is supposed to cache the
`try-runtime` build for a performance benefit, but it seems it wasn't
working. Maybe someone from the CI team can look into this or explain
why it needs to be there?
- Adds check-runtime-migration jobs for Parity asset-hubs, bridge-hubs
and contract chains
- Updated VARIABLES to accomodate the `kusama-runtime` package being
renamed to `staging-kusama-runtime` in
https://github.com/paritytech/polkadot-sdk/pull/1241
- Added `EXTRA_ARGS` variable to `check-runtime-migration`, and set
`--no-weight-warnings` to the relay chain runtime upgrade checks (relay
chains don't have weight restrictions).
Moving a few pallets to the latest and greatest `derive_impl` to give it
a try.
Part of #171
---------
Co-authored-by: Adrian Catangiu <adrian@parity.io>
Co-authored-by: Keith Yeung <kungfukeith11@gmail.com>
What does this PR do?
- Introduced the TotalValueLocked storage for nomination-pools.
- introduced a slashing api in mock.rs
- additional test for tracking a slashing event towards a pool without
sub-pools
- migration for the nomination-pools (V6 to V7) with
`VersionedMigration`
Why are these changes needed?
this is the continuation of the work by @kianenigma in this
[PR](https://github.com/paritytech/substrate/pull/13319)
How were these changes implemented and what do they affect?
- It's an extra StorageValue that's modified whenever funds flow in or
out of staking for any of the `bonded_account` of `BondedPools`
- The `PoolSlashed`event is now emitted even when no `SubPools` are
found
Closes https://github.com/paritytech/polkadot-sdk/issues/155
KSM: HHEEgVzcqL3kCXgsxSfJMbsTy8dxoTctuXtpY94n4s8F4pS
---------
Co-authored-by: Liam Aharon <liam.aharon@hotmail.com>
Co-authored-by: Kian Paimani <5588131+kianenigma@users.noreply.github.com>
Co-authored-by: Ankan <10196091+Ank4n@users.noreply.github.com>
Co-authored-by: Ankan <ankan.anurag@gmail.com>
Co-authored-by: command-bot <>
Derive `RuntimeDebug\Eq\PartialEq` but do not bound any generics.
This achieved by using their equivalent no bound versions:
`EqNoBound\PartialEqNoBound\RuntimeDebugNoBound`.
Deriving with `Debug`, `Eq`, and `PartialEq` for the `Debt` and `Credit`
type aliases of `Imbalance` is not feasible due to the `OnDrop` and
`OppositeOnDrop` generic types lacking implementations of the same
traits.
This absence posed challenges in testing and any scenarios that demanded
the traits implementations for the type.
closes https://github.com/paritytech/polkadot-sdk/issues/158.
partially addresses
https://github.com/paritytech/polkadot-sdk/issues/226.
Instead of fragile calculation of current balance by looking at `free
balance - ED`, Nomination Pool now freezes ED in the pool reward account
to restrict an account from going below minimum balance. This also has a
nice side effect that if ED changes, we know how much is the imbalance
in ED frozen in the pool and the current required ED. A pool operator
can diligently top up the pool with the deficit in ED or vice versa,
withdraw the excess they transferred to the pool.
## Notable changes
- New call `adjust_pool_deposit`: Allows to top up the deficit or
withdraw the excess deposited funds to the pool.
- Uses Fungible trait (instead of Currency trait). Since NP was not
doing any locking/reserving previously, no migration is needed for this.
- One time migration of freezing ED from each of the existing pools (not
very PoV friendly but fine for relay chain).
cheme