Fixes https://github.com/paritytech/polkadot-sdk/issues/106
Port of cumulus PR https://github.com/paritytech/cumulus/pull/2960
This PR adds the ability to bid for collator slots even after the max
number of collators have already registered. This eliminates the first
come, first served mechanism that was in place before.
Key changes:
- added `update_bond` extrinsic to allow registered candidates to adjust
their bonds in order to dynamically control their bids
- added `take_candidate_slot` extrinsic to try to replace an already
existing candidate by bidding more than them
- candidates are now kept in a sorted list in the pallet storage, where
the top `DesiredCandidates` out of `MaxCandidates` candidates in the
list will be selected by the session pallet as collators
- if the candidacy bond is increased through a `set_candidacy_bond`
call, candidates which don't meet the new bond requirements are kicked
# Checklist
- [ ] My PR includes a detailed description as outlined in the
"Description" section above
- [ ] My PR follows the [labeling
requirements](https://github.com/paritytech/polkadot-sdk/blob/master/docs/CONTRIBUTING.md#process)
of this project (at minimum one label for `T` required)
- [ ] I have made corresponding changes to the documentation (if
applicable)
- [ ] I have added tests that prove my fix is effective or that my
feature works (if applicable)
- [ ] If this PR alters any external APIs or interfaces used by
Polkadot, the corresponding Polkadot PR is ready as well as the
corresponding Cumulus PR (optional)
---------
Signed-off-by: georgepisaltu <george.pisaltu@parity.io>
We are introducing a new set of `XcmController` traits (final name yet
to be determined).
These traits are implemented by `pallet-xcm` and allows other pallets,
such as `pallet_contracts`, to rely on these traits instead of tight
coupling them to `pallet-xcm`.
Using only the existing Xcm traits would mean duplicating the logic from
`pallet-xcm` in these other pallets, which we aim to avoid. Our
objective is to ensure that when these APIs are called from
`pallet-contracts`, they produce the exact same outcomes as if called
directly from `pallet-xcm`.
The other benefits is that we can also expose return values to
`pallet-contracts` instead of just calling `pallet-xcm` dispatchable and
getting a `DispatchResult` back.
See traits integration in this PR
https://github.com/paritytech/polkadot-sdk/pull/1248, where the traits
are used as follow to define and implement `pallet-contracts` Config.
```rs
// Contracts config:
pub trait Config: frame_system::Config {
// ...
/// A type that exposes XCM APIs, allowing contracts to interact with other parachains, and
/// execute XCM programs.
type Xcm: xcm_executor::traits::Controller<
OriginFor<Self>,
<Self as frame_system::Config>::RuntimeCall,
BlockNumberFor<Self>,
>;
}
// implementation
impl pallet_contracts::Config for Runtime {
// ...
type Xcm = pallet_xcm::Pallet<Self>;
}
```
---------
Co-authored-by: Alexander Theißen <alex.theissen@me.com>
Co-authored-by: command-bot <>
(imported from https://github.com/paritytech/cumulus/pull/2157)
## Changes
This MR refactores the XCMP, Parachains System and DMP pallets to use
the [MessageQueue](https://github.com/paritytech/substrate/pull/12485)
for delayed execution of incoming messages. The DMP pallet is entirely
replaced by the MQ and thereby removed. This allows for PoV-bounded
execution and resolves a number of issues that stem from the current
work-around.
All System Parachains adopt this change.
The most important changes are in `primitives/core/src/lib.rs`,
`parachains/common/src/process_xcm_message.rs`,
`pallets/parachain-system/src/lib.rs`, `pallets/xcmp-queue/src/lib.rs`
and the runtime configs.
### DMP Queue Pallet
The pallet got removed and its logic refactored into parachain-system.
Overweight message management can be done directly through the MQ
pallet.
Final undeployment migrations are provided by
`cumulus_pallet_dmp_queue::UndeployDmpQueue` and `DeleteDmpQueue` that
can be configured with an aux config trait like:
```rust
parameter_types! {
pub const DmpQueuePalletName: &'static str = \"DmpQueue\" < CHANGE ME;
pub const RelayOrigin: AggregateMessageOrigin = AggregateMessageOrigin::Parent;
}
impl cumulus_pallet_dmp_queue::MigrationConfig for Runtime {
type PalletName = DmpQueuePalletName;
type DmpHandler = frame_support::traits::EnqueueWithOrigin<MessageQueue, RelayOrigin>;
type DbWeight = <Runtime as frame_system::Config>::DbWeight;
}
// And adding them to your Migrations tuple:
pub type Migrations = (
...
cumulus_pallet_dmp_queue::UndeployDmpQueue<Runtime>,
cumulus_pallet_dmp_queue::DeleteDmpQueue<Runtime>,
);
```
### XCMP Queue pallet
Removed all dispatch queue functionality. Incoming XCMP messages are now
either: Immediately handled if they are Signals, enqueued into the MQ
pallet otherwise.
New config items for the XCMP queue pallet:
```rust
/// The actual queue implementation that retains the messages for later processing.
type XcmpQueue: EnqueueMessage<ParaId>;
/// How a XCM over HRMP from a sibling parachain should be processed.
type XcmpProcessor: ProcessMessage<Origin = ParaId>;
/// The maximal number of suspended XCMP channels at the same time.
#[pallet::constant]
type MaxInboundSuspended: Get<u32>;
```
How to configure those:
```rust
// Use the MessageQueue pallet to store messages for later processing. The `TransformOrigin` is needed since
// the MQ pallet itself operators on `AggregateMessageOrigin` but we want to enqueue `ParaId`s.
type XcmpQueue = TransformOrigin<MessageQueue, AggregateMessageOrigin, ParaId, ParaIdToSibling>;
// Process XCMP messages from siblings. This is type-safe to only accept `ParaId`s. They will be dispatched
// with origin `Junction::Sibling(…)`.
type XcmpProcessor = ProcessFromSibling<
ProcessXcmMessage<
AggregateMessageOrigin,
xcm_executor::XcmExecutor<xcm_config::XcmConfig>,
RuntimeCall,
>,
>;
// Not really important what to choose here. Just something larger than the maximal number of channels.
type MaxInboundSuspended = sp_core::ConstU32<1_000>;
```
The `InboundXcmpStatus` storage item was replaced by
`InboundXcmpSuspended` since it now only tracks inbound queue suspension
and no message indices anymore.
Now only sends the most recent channel `Signals`, as all prio ones are
out-dated anyway.
### Parachain System pallet
For `DMP` messages instead of forwarding them to the `DMP` pallet, it
now pushes them to the configured `DmpQueue`. The message processing
which was triggered in `set_validation_data` is now being done by the MQ
pallet `on_initialize`.
XCMP messages are still handed off to the `XcmpMessageHandler`
(XCMP-Queue pallet) - no change here.
New config items for the parachain system pallet:
```rust
/// Queues inbound downward messages for delayed processing.
///
/// Analogous to the `XcmpQueue` of the XCMP queue pallet.
type DmpQueue: EnqueueMessage<AggregateMessageOrigin>;
```
How to configure:
```rust
/// Use the MQ pallet to store DMP messages for delayed processing.
type DmpQueue = MessageQueue;
```
## Message Flow
The flow of messages on the parachain side. Messages come in from the
left via the `Validation Data` and finally end up at the `Xcm Executor`
on the right.
## Further changes
- Bumped the default suspension, drop and resume thresholds in
`QueueConfigData::default()`.
- `XcmpQueue::{suspend_xcm_execution, resume_xcm_execution}` errors when
they would be a noop.
- Properly validate the `QueueConfigData` before setting it.
- Marked weight files as auto-generated so they wont auto-expand in the
MR files view.
- Move the `hypothetical` asserts to `frame_support` under the name
`experimental_hypothetically`
Questions:
- [ ] What about the ugly `#[cfg(feature = \"runtime-benchmarks\")]` in
the runtimes? Not sure how to best fix. Just having them like this makes
tests fail that rely on the real message processor when the feature is
enabled.
- [ ] Need a good weight for `MessageQueueServiceWeight`. The scheduler
already takes 80% so I put it to 10% but that is quite low.
TODO:
- [x] Remove c&p code after
https://github.com/paritytech/polkadot/pull/6271
- [x] Use `HandleMessage` once it is public in Substrate
- [x] fix `runtime-benchmarks` feature
https://github.com/paritytech/polkadot/pull/6966
- [x] Benchmarks
- [x] Tests
- [ ] Migrate `InboundXcmpStatus` to `InboundXcmpSuspended`
- [x] Possibly cleanup Migrations (DMP+XCMP)
- [x] optional: create `TransformProcessMessageOrigin` in Substrate and
replace `ProcessFromSibling`
- [ ] Rerun weights on ref HW
---------
Signed-off-by: Oliver Tale-Yazdi <oliver.tale-yazdi@parity.io>
Co-authored-by: Liam Aharon <liam.aharon@hotmail.com>
Co-authored-by: joe petrowski <25483142+joepetrowski@users.noreply.github.com>
Co-authored-by: Kian Paimani <5588131+kianenigma@users.noreply.github.com>
Co-authored-by: command-bot <>
# Description
## Summary
Previously, the `pallet_xcm::do_reserve_transfer_assets` and
`pallet_xcm::do_teleport_assets` functions relied on weight estimation
for remote chain execution, which was based on guesswork derived from
the local chain. This approach led to complications for runtimes that
did not provide or support specific [XCM
configurations](https://github.com/paritytech/polkadot-sdk/blob/7cbe0c76ef8fd2aabf9f07de0156941ce3ed44b0/polkadot/xcm/xcm-executor/src/config.rs#L43-L47)
for `IsReserve` or `IsTeleporter`. Consequently, such runtimes had to
resort to implementing hard-coded weights for XCM instructions like
`reserve_asset_deposited` or `receive_teleported_asset` to support
extrinsics such as `pallet_xcm::reserve_transfer_assets` and
`pallet_xcm::teleport_assets`, which depended on remote weight
estimation.
The issue of remote weight estimation was addressed and resolved by
[Pull Request
#1645](https://github.com/paritytech/polkadot-sdk/pull/1645), which
removed the need for remote weight estimation.
## Solution
As a continuation of this improvement, the current PR proposes further
cleanup by removing unnecessary hard-coded values and rectifying
benchmark results with `Weight::MAX` that previously used
`T::BlockWeights::get().max_block` as an override for unsupported XCM
instructions like `ReserveAssetDeposited` and `ReceiveTeleportedAsset`.
## Questions
- [x] Can we remove now also `Hardcoded till the XCM pallet is fixed`
for `deposit_asset`? E.g. for AssetHubKusama
[here](https://github.com/paritytech/polkadot-sdk/blob/7cbe0c76ef8fd2aabf9f07de0156941ce3ed44b0/cumulus/parachains/runtimes/assets/asset-hub-kusama/src/weights/xcm/mod.rs#L129-L134)
- [x] Are comments like
[this](https://github.com/paritytech/polkadot-sdk/blob/7cbe0c76ef8fd2aabf9f07de0156941ce3ed44b0/polkadot/runtime/kusama/src/weights/xcm/mod.rs#L94)
`// Kusama doesn't support ReserveAssetDeposited, so this benchmark has
a default weight` still relevant? Shouldnt be removed/changed?
## TODO
- [x] `bench bot` regenerate xcm weights for all runtimes
- [x] remove hard-coded stuff from system parachain weight files
- [ ] when merged, open `polkadot-fellow/runtimes` PR
## References
Fixes#1132Closes#1132
Old polkadot repo [PR](https://github.com/paritytech/polkadot/pull/7546)
---------
Co-authored-by: command-bot <>
* paritytech/ci-cd#697: Update weights with VM runners
- Update weights using VM instances
- Change runner tag for weights ci job to weights-vm
* ".git/.scripts/commands/bench/bench.sh" all
* ".git/.scripts/commands/bench-all/bench-all.sh" --target_dir=cumulus
---------
Co-authored-by: parity-processbot <>
Co-authored-by: Branislav Kontur <bkontur@gmail.com>
* remove candidate when to invulnerable
* fix
* candidates to collators
* make parameters consistent and more reasonable
* add call to kick invulnerable candidates
* factor removal into weight
* fix: use accrue instead of add
* make set_invulnerables non-atomic
* benchmark add_invulnerable to account for candidate removal
* don't remove from candidates with set_invulnerables
* fix bounds on benchmarking
* protect against zero min invulnerables underflow
* extra event and tests
* make candidates/invulnerables self-cleaning on session change
* add integrity test
* unused imports
* make rococo-contracts have 1 collator
* Fix APIs
* Reflect API changes
* Everything builds
* Fixes
* Fixes
* Update Cargo.toml
* Fixes
* Fixes
* No networks use freezes/holds
* update lockfile for {"polkadot", "substrate"}
* Fix test
ED cannot be zero anymore.
Signed-off-by: Oliver Tale-Yazdi <oliver.tale-yazdi@parity.io>
* Fix test
---------
Signed-off-by: Oliver Tale-Yazdi <oliver.tale-yazdi@parity.io>
Co-authored-by: parity-processbot <>
Co-authored-by: Oliver Tale-Yazdi <oliver.tale-yazdi@parity.io>
* Wwstmint test for ReceiveTeleportedAsset
* Missing fix for `weigh_multi_assets`
* Added tests for statemine/statemint
* [Enhancement] Use XCM V3 for initiate_teleport weight calc (#2102)
* [Enhancement] Use XCM V3 for initiate_teleport weight calc
* deref
* replicate in all the runtimes
* fmt
* better handling for AllOf
* fmt
* small type fix
* replicate the fix for all runtimes
---------
Co-authored-by: parity-processbot <>
* removed `frame_support::sp_tracing::try_init_simple();`
* Review fixes
* Removed `as u64`
---------
Co-authored-by: Branislav Kontur <bkontur@gmail.com>
Co-authored-by: Roman Useinov <roman.useinov@gmail.com>
* [Enhancement] Use XCM V3 for initiate_teleport weight calc
* deref
* replicate in all the runtimes
* fmt
* better handling for AllOf
* fmt
* small type fix
* replicate the fix for all runtimes
---------
Co-authored-by: parity-processbot <>
georgepisaltu