Also fixes: https://github.com/paritytech/polkadot-sdk/issues/1417
- [x] CoreIndex -> AssignmentProvider mapping will be able to change any
time.
- [x] Implement
- [x] Provide Migrations
- [x] Add and fix tests
- [x] Implement bulk assigner logic
- [x] bulk assigner tests
- [x] Port over current assigner to use bulk designer (+ share on-demand
with bulk): top-level assigner has core ranges: legacy, bulk
- [x] Adjust migrations to reflect new assigner structure
- [x] Move migration code to Assignment code directly and make it
recursive (make it possible to skip releases) -> follow up ticket.
- [x] Test migrations
- [x] Add migration PR to runtimes repo -> follow up ticket.
- [x] Wire up with actual UMP messages
- [x] Write PR docs
---------
Co-authored-by: eskimor <eskimor@no-such-url.com>
Co-authored-by: Bradley Olson <34992650+BradleyOlson64@users.noreply.github.com>
Co-authored-by: BradleyOlson64 <lotrftw9@gmail.com>
Co-authored-by: Anton Vilhelm Ásgeirsson <antonva@users.noreply.github.com>
Co-authored-by: antonva <anton.asgeirsson@parity.io>
Co-authored-by: Bastian Köcher <git@kchr.de>
Co-authored-by: Marcin S. <marcin@realemail.net>
Co-authored-by: Bastian Köcher <info@kchr.de>
Co-authored-by: command-bot <>
This PR adds [Rococo
People](https://github.com/paritytech/polkadot-sdk/pull/2281) <> [Rococo
Bulletin](https://github.com/zdave-parity/polkadot-bulletin-chain) to
the Rococo Bridge Hub code. There's a couple of things left to do here:
- [x] add remaining tests - it'd need some refactoring in the
`bridge-hub-test-utils` - will do in a separate PR;
- [x] actually run benchmarks for new messaging pallet (do we have bot
nowadays?).
The reason why I'm opening it before this ^^^ is ready, is that I'd like
to hear others opinion on how to deal with hacks with that bridge.
Initially I was assuming that Rococo Bulletin will be the 1:1 copy of
the Polkadot Bulletin (to avoid maintaining multiple
runtimes/releases/...), so you can see many `PolkadotBulletin` mentions
in this PR, even though we are going to bridge with the parallel chain
(`RococoBulletin`). That's because e.g. pallet names from
`construct_runtime` are affecting runtime storage keys and bridges are
using runtime storage proofs => it is important to use names that the
Bulletin chain expects.
But in the end, this hack won't work - we can't use Polkadot Bulletin
runtime to bridge with Rococo Bridge Hub, because Polkadot Bulletin
expects Polkadot Bridge hub to use `1002` parachain id and Rococo Bridge
Hub seats on the `1013`. This also affects storage keys using in
bridging, so I had to add the [`rococo`
feature](https://github.com/svyatonik/polkadot-bulletin-chain/blob/add-bridge-pallets/runtime/Cargo.toml#L198)
to the Bulletin chain. So now we can actually alter its runtime and
adapt it for Rococo.
So the question here is - what's better for us here
- to leave everything as is (seems hacky and non-trivial);
- change Bulletin chain runtime when `rococo` feature is used - e.g. use
proper names there (`WithPolkadotGrandpa` -> `WithRococoGrandpa`, ...)
- add another set of pallets to the Bulletin chain runtime to bridge
with Rococo and never use them in production. Similar to hack that we
had in Rococo/Wococo
cc @acatangiu @bkontur @serban300
also cc @joepetrowski as the main "client" of this bridge
---
A couple words on how this bridge is different from the Rococo <>
Westend bridge:
- it is a bridge with a chain that uses GRANDPA finality, not the
parachain finality (hence the tests needs to be changed);
- it is a fee-free bridge. So
`AllowExplicitUnpaidExecutionFrom<Equals<SiblingPeople>>` + we are not
paying any rewards to relayers (apart from compensating transaction
costs).
---------
Signed-off-by: dependabot[bot] <support@github.com>
Signed-off-by: Andrei Sandu <andrei-mihail@parity.io>
Co-authored-by: Adrian Catangiu <adrian@parity.io>
Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>
Co-authored-by: Andrei Sandu <54316454+sandreim@users.noreply.github.com>
Co-authored-by: Egor_P <egor@parity.io>
Co-authored-by: command-bot <>
We currently use a bit of a hack in `.cargo/config` to make sure that
clippy isn't too annoying by specifying the list of lints.
There is now a stable way to define lints for a workspace. The only down
side is that every crate seems to have to opt into this so there's a
*few* files modified in this PR.
Dependencies:
- [x] PR that upgrades CI to use rust 1.74 is merged.
---------
Co-authored-by: joe petrowski <25483142+joepetrowski@users.noreply.github.com>
Co-authored-by: Branislav Kontur <bkontur@gmail.com>
Co-authored-by: Liam Aharon <liam.aharon@hotmail.com>
As suggested in this thread:
https://github.com/polkadot-fellows/runtimes/pull/87#discussion_r1400237122
We already have the `IsChildSystemParachain`, which may be used at relay
chain, but it can't be used at a parachain level. So let's use
`AllSiblingSystemParachains` for that. I was thinking about
`AllSystemParachains`, but it may cause wrong impression that it can be
used at a relay chain level.
---------
Co-authored-by: joe petrowski <25483142+joepetrowski@users.noreply.github.com>
Using taplo, fixes all our broken and inconsistent toml formatting and
adds CI to keep them tidy.
If people want we can customise the format rules as described here
https://taplo.tamasfe.dev/configuration/formatter-options.html
@ggwpez, I suggest zepter is used only for checking features are
propagated, and leave formatting for taplo to avoid duplicate work and
conflicts.
TODO
- [x] Use `exclude = [...]` syntax in taplo file to ignore zombienet
tests instead of deleting the dir
---------
Signed-off-by: Oliver Tale-Yazdi <oliver.tale-yazdi@parity.io>
Co-authored-by: Oliver Tale-Yazdi <oliver.tale-yazdi@parity.io>
Co-authored-by: Bastian Köcher <git@kchr.de>
One for local networks with `fast-runtime` feature activated (1 minute
sessions) and one without the feature activated that will be the default
that runs with 1 hour long sessions.
## Problem
This PR addresses the issue with testnet AssetHub builds, which was
discovered during the execution of `bot bench`.
https://gitlab.parity.io/parity/mirrors/polkadot-sdk/-/jobs/4038738
```
Compiling asset-hub-rococo-runtime-wasm v1.0.0 (/builds/parity/mirrors/polkadot-sdk/target/production/wbuild/asset-hub-rococo-runtime)
warning: Linking globals named 'Core_version': symbol multiply defined!
error: failed to load bitcode of module "rococo_runtime-8799ee884447805a.rococo_runtime.0bc572b8-cgu.0.rcgu.o":
warning: `asset-hub-rococo-runtime-wasm` (lib) generated 1 warning
error: could not compile `asset-hub-rococo-runtime-wasm` (lib) due to previous error; 1 warning emitted
```
https://gitlab.parity.io/parity/mirrors/polkadot-sdk/-/jobs/4038739
```
Compiling asset-hub-westend-runtime-wasm v1.0.0 (/builds/parity/mirrors/polkadot-sdk/target/production/wbuild/asset-hub-westend-runtime)
warning: Linking globals named 'Core_version': symbol multiply defined!
error: failed to load bitcode of module "westend_runtime-86d7844430f97d5c.westend_runtime.b7678d03-cgu.0.rcgu.o":
warning: `asset-hub-westend-runtime-wasm` (lib) generated 1 warning
error: could not compile `asset-hub-westend-runtime-wasm` (lib) due to previous error; 1 warning emitted
```
## Solution
- Removed dependencies on `rococo-runtime` and `westend-runtime`
introduced by [this
PR](https://github.com/paritytech/polkadot-sdk/pull/1234/files#diff-a86375df98e04ca3cce1ea35c40257a222e2d5087f5f528ff33307678b78dc2dR534-R550).
- Replaced `<rococo_runtime::Treasury as PalletInfoAccess>::index()`
with `rococo_runtime_constants::TREASURY_PALLET_ID`.
- Added `check_treasury_pallet_id` to the relay runtimes to ensure that
the constant is aligned with the pallet id.
- Added "Rococo Treasury" to the waived locations (that will not be
charged fees in the executor) for `BridgeHubRococo` (to be aligned with
AssetHubs).
## References
[Full element discussion
here](https://matrix.to/#/!JUeaZUiYbdrvzvtwSL:parity.io/$2PnjYMsWRjR7M3oOfGuRI0XkjdoqJLtRcAPVcDLuLVg?via=parity.io&via=web3.foundation).
---------
Co-authored-by: command-bot <>
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>
[`RococoGenesisExt`](https://github.com/paritytech/polkadot-sdk/blob/a414ea7515c9cdc81f1d12410e646afc148250e8/polkadot/node/service/src/chain_spec.rs#L152-L171)
is removed. It was the hack to allow overwriting
`EpochDurationInBlocks`. Removal of `RococGenesisExt` prevents from
manipulating the state to change the runtime constants.
Changes:
- Environment variable which controls the `time::EpochDurationInBlocks`
value was added: `ROCOCO_EPOCH_DURATION` (epoch duration will be set to
the value of env),
- `10,100,600` versions of rococo-runtime are built in CI and put into `polkadot-debug` docker image.
`rococo-runtime` building examples:
- to build runtime for `versi_staging_testnet` which had
EpochDurationInBlocks set to 100:
```
ROCOCO_EPOCH_DURATION=100 cargo build --features=fast-runtime -p
rococo-runtime
```
- to build runtime for `wococo_development`
```
ROCOCO_EPOCH_DURATION=10 cargo build --features=fast-runtime -p
rococo-runtime
```
- to build `versi-staging` chain spec:
```
ROCOCO_EPOCH_DURATION=100 cargo run -p polkadot --features=fast-runtime
-- build-spec --chain versi-staging --raw
```
- to build `wococo-dev` chain spec:
```
ROCOCO_EPOCH_DURATION=10 cargo run -p polkadot --features=fast-runtime
-- build-spec --chain wococo-dev --raw
```
It is also possible to change the epoch duration by replacing the `code` field in the chain spec with the hex dump of pre-built runtime wasm blob (because the epoch duration is hard-coded into wasm blob).
---------
Co-authored-by: Bastian Köcher <git@kchr.de>
* Happy New Year!
* Remove year entierly
Co-authored-by: Oliver Tale-Yazdi <oliver.tale-yazdi@parity.io>
* Remove years from copyright notice in the entire repo
---------
Co-authored-by: Oliver Tale-Yazdi <oliver.tale-yazdi@parity.io>
* rust 1.64 enables workspace properties
* add edition, repository and authors.
* of course, update the version in one place.
Co-authored-by: Andronik <write@reusable.software>
* westend: update transaction version
* polkadot: update transaction version
* kusama: update transaction version
* Bump spec_version to 9330
* bump versions to 0.9.33
* Bump crate versions
* Bump spec_version to 9280 for kusama
* Bump spec_version to 9280 for polkadot
* Bump spec_version to 9280 for rococo
* Bump spec_version to 9280 for westend
* update Cargo.lock
Co-authored-by: parity-processbot <>
Liam Aharon