[AHM] Disable indirect XCMs from RC to AH and vice versa during migration #774
Conversation
| Coretime(..) => (ON, ON), | ||
| StateTrieMigration(..) => (OFF, OFF), // Deprecated | ||
| XcmPallet(..) => (OFF, ON), /* TODO allow para origins and root to call this during the migration, see https://github.com/polkadot-fellows/runtimes/pull/559#discussion_r1928789463 */ | ||
| XcmPallet(..) => (OFF, ON), |
There was a problem hiding this comment.
muharem
changed the title
| type Currency = Balances; | ||
| type CheckingAccount = xcm_config::CheckAccount; | ||
| type SendXcm = xcm_config::XcmRouter; | ||
| type SendXcm = xcm_config::XcmRouterWithoutException; |
There was a problem hiding this comment.
Why do we need a special one here on the relay? I thought we want to use the one that disables during migration.
There was a problem hiding this comment.
bc its the only one that can send to AH and we need it for the migrator pallet to send data. the rest cannot.
| type LocalXcmRouter = pallet_ah_migrator::RouteInnerWithException< | ||
| LocalXcmRouterWithoutException, | ||
| Equals<ParentLocation>, | ||
| crate::AhMigrator, |
There was a problem hiding this comment.
Not sure i understand it here: I thought we want to block messages from all origins that are not ParentLocation.
But looking at the code of RouteInnerWithException it seems like it will block Equals<ParentLocation> when the migration is ongoing.
There was a problem hiding this comment.
we do not lock anyone from sending to RC or AH and they will use that 2 blocks from our pattern (lets say (18, 2)). but we do not let their xcm programs to send messages from RC or AH to AH or RC and use that 18 blocks from our pattern.
There was a problem hiding this comment.
@muharem can you please add some docs for:
// TODO: some docs
FromContains<Equals<ParentLocation>, pallet_ah_migrator::ExceptResponseFor<Equals<Here>>>,
Could you please add a test covering this? Is Equals<Here> the correct value? Does Here applies from the ParentLocation point of view?
Where do we even send QueryResponse? Is it because the xcm-executor can send it internally? Can I see somewhere the flow which triggers QueryResponse?
I'm trying to read the to_querier function, the QueryResponse instruction, and the surrounding code, but it's not exactly easy bedtime reading :)
There was a problem hiding this comment.
Could you please add a test covering this? Is Equals the correct value?
migration_works_time test covers this, without this our flow-control system wont simply work
Does Here applies from the ParentLocation point of view?
yes
Where do we even send QueryResponse? Is it because the xcm-executor can send it internally? Can I see somewhere the flow which triggers QueryResponse?
our flow control system for migration
I will add more docs.
There was a problem hiding this comment.
I have added more docs
There was a problem hiding this comment.
Before doing detailed review, I have a high-level question:
What are the scenarios where this is needed? Do you have practical examples?
I understand we don't want other chains to be able to get RC or AH to send XCM messages to each other (route through one to get to the other), but I believe we are already covered and do not need this extra mechanism (more complexity, more failure points).
Afaict, the only ways to have chain A initiate a (new) XCM message to chain B are:
- Through extrinsics that end up doing
xcm::send()- these can all be covered using call filters. - Through XCM asset transfers from chain C to B where A acts as the reserve
- A -> RC -> AH: RC is only reserve for DOT, and DOT teleports are already disabled (will fail) during migration,
- A -> AH -> RC: AH is reserve for many assets, and could act as router to RC (even if the assets are effectively lost/trapped on RC because it doesn't accept them) - we can also cover this case by using existing reserve transfers filters to disallow reserve transfers to RC.
but we did not, even not all the cases you have listed. you can also reroute via the solution form this PR looks simple to me. but I do not insist on it. if you see a better solution, I am happy to hand over this issue to you. |
|
@acatangiu and I definitely will need your careful review for this PR if we decide to move forward with it 🙏 |
|
ok, I will review in depth |
today I learned that QueryResponseInfo takes a |
pallets/rc-migrator/src/types.rs
Outdated
| /// A wrapper around `Inner` that routes messages through `Inner` unless `Exception` is true and | ||
| /// `MigrationState` is ongoing. | ||
| pub struct RouteInnerWithException<Inner, Exception, MigrationState>( | ||
| PhantomData<(Inner, Exception, MigrationState)>, | ||
| ); |
There was a problem hiding this comment.
some improvement can be made to Exception naming to explain that it is a condition applied to the destination, but just nice to have, the type defined here will be short-lived anyway (removed after AHM)
There was a problem hiding this comment.
some improvement can be made to
Exceptionnaming to explain that it is a condition applied to thedestination
Agree, I would vote for renaming Exception to BlockFor - BlockFor::contains(destination
There was a problem hiding this comment.
@bkontur RouteInnerWithException<.., BlockFor, ..> ?
There was a problem hiding this comment.
ok, no problem, we can keep as it is.
Or other suggestions :D
/// A wrapper around `Inner` that routes messages through `Inner` unless `Exception` is true and
/// `MigrationState` is ongoing.
pub struct RouteInnerUnlessException<Inner, Exception, MigrationState>(
or shorther
pub struct RouteInnerUnless<Inner, Exception, MigrationState>(
or even shorter
pub struct RouteUnless<Inner, Exception, MigrationState>(
There was a problem hiding this comment.
I asked a large language model
There was a problem hiding this comment.
haha, suggestions above were also based on AI :D :D :D,
let's keep it as it is :)
…muharem-ahm-lock-xcm-forward
| if MigrationState::is_ongoing() && | ||
| Exception::contains(destination.as_ref().ok_or(SendError::MissingArgument)?) | ||
| { | ||
| Err(SendError::Unroutable) | ||
| } else { | ||
| Inner::validate(destination, message) | ||
| } |
There was a problem hiding this comment.
I would switch the conditions - MigrationState::is_ongoing() is touching the storage, right?
so in most cases we don't need to hit the storage, right?
| if MigrationState::is_ongoing() && | |
| Exception::contains(destination.as_ref().ok_or(SendError::MissingArgument)?) | |
| { | |
| Err(SendError::Unroutable) | |
| } else { | |
| Inner::validate(destination, message) | |
| } | |
| if Exception::contains(destination.as_ref().ok_or(SendError::MissingArgument)?) && MigrationState::is_ongoing() | |
| { | |
| Err(SendError::Transport("Migration ongoing - routing is temporary blocked!")) | |
| } else { | |
| Inner::validate(destination, message) | |
| } |
There was a problem hiding this comment.
migration stage gonna be read at every block anyway when we deploy this runtime version
There was a problem hiding this comment.
also, my thinking when writing this was: if the migration isn’t ongoing, I don’t even want to bother checking those conditions. That means outside of the migration, we’re not relying on the correctness of those checks - less risk overall.
Co-authored-by: Branislav Kontur <[email protected]>
| impl<Querier: Contains<Location>> Contains<Xcm<()>> for ExceptResponseFor<Querier> { | ||
| fn contains(l: &Xcm<()>) -> bool { | ||
| match l.first() { | ||
| Some(QueryResponse { querier: Some(querier), .. }) => !Querier::contains(querier), |
There was a problem hiding this comment.
we have to whitelist query responses for our flow control system
There was a problem hiding this comment.
querier here from the perspective of the destination
|
Review required! Latest push from author must always be reviewed |
| type RcToAhPalletsOrigin = ah_migration::RcToAhPalletsOrigin; | ||
| type Preimage = Preimage; | ||
| type SendXcm = xcm_config::XcmRouter; | ||
| type SendXcm = xcm_config::LocalXcmRouterWithoutException; |
There was a problem hiding this comment.
I am just thinking loud, does this AH migrator send messages just to the RC? Or possibly to other parachains?
Can we just use ParentAsUmp directly here? (I am ok, also with LocalXcmRouterWithoutException tuple - not that big deal)
| type SendXcm = xcm_config::LocalXcmRouterWithoutException; | |
| type SendXcm = WithUniqueTopic< | |
| cumulus_primitives_utility::ParentAsUmp<ParachainSystem, PolkadotXcm, PriceForParentDelivery>, | |
| >; |
But the other thing - the XcmRouter was previously wrapped with WithUniqueTopic, but whatever we are adding here isn't. That means the SetTopic feature for tracking XCM messages won't apply probably.
Maybe we don’t need to track XCM messages at all. I need to go through the entire flow starting from the initial migration message (first-tracking-id). Most likely, the up-and-down migration messages won’t be tracked under the same first-tracking-id due to the query/response behavior (also need to check).
Anyway, just wanted to raise the point: without WithUniqueTopic, we most probably lose the ability to track messages using the SetTopic feature from the AssetHub migrator to the RC (maybe not that big issue also).
cc: @raymondkfcheung maybe, it could be worth to double-check all the XCM routing set it up for this migration, when everyhting will be ready (all similar PRs are merged to this dev-ahm branch).
There was a problem hiding this comment.
I usually try to introduce as little entropy as possible. The LocalXcmRouterWithoutException type is exactly the same as the one currently used (prior to this PR); only the name has been changed. This means I do not introduce any behaviour change to the migrator pallets with this PR.
There was a problem hiding this comment.
This means I do not introduce any behaviour change to the migrator pallets with this PR.
Well, using LocalXcmRouterWithoutException instead of XcmRouter avoids using SetTopic with WithUniqueTopic - which may not be relevant behaviour change for migration. As I said before, just raising the point, we can go with or without WithUniqueTopic probably.
There was a problem hiding this comment.
I see now. I was trying to avoid touching the ToKusamaXcmRouter and SovereignPaidRemoteExporter<...> routers, this sounds good to you? I am adding now the SetTopic for the migrator router.
|
@acatangiu @bkontur thank you for review! |
…harem-ahm-lock-xcm-forward
Signed-off-by: Oliver Tale-Yazdi <[email protected]>
Signed-off-by: Oliver Tale-Yazdi <[email protected]>
Signed-off-by: Oliver Tale-Yazdi <[email protected]>
ggwpez
merged commit 2b278c4
into
polkadot-fellows:dev-asset-hub-migration
A high-level look of the migration is this: <img width="1204" height="745" alt="Screenshot 2025-09-17 at 18 23 57" src="https://github.com/user-attachments/assets/1fb39ef8-5efa-4db2-81db-6dd775af3a39" /> You can see the main components being the `pallet_rc_migrator` and `pallet_ah_migrator`. The RC migrator pallet takes data out of the RC storage and enqueues it for AH through XCM::Transact calls to the AH migrator pallet. Each pallet on the RC side has a migrator module that handles the removal of the old data and creation of the messages for AH. AH then processes these messages through the MQ pallet and acknowledges back to RC that they were processed (not shown in the graphic). There is rate-limiting code in place to prevent it from overloading the DMP queue or Asset Hub. ## For Reviewers The review comments are being addressed in #915. We need eyes on the Core part that is described below. ## Core STM The main stage transitions look like this. The only manual part is the scheduling call by the fellowship that kicks off the procedure: * `Pending` wait for Fellowship to call `schedule_migration(when)` -> Scheduled * `Scheduled` waiting for scheduled block -> `WaitingForAH` * `WaitingForAH` AH replies that it is ready -> `WarmUp` * `WarmUp` waiting for warm-up end -> `Starting` * `Starting` doing some startup initialization -> `DataMigration` * `DataMigration` MAIN PART **all pallet migrations finish** -> `CoolOff` * `CoolOff` waiting for cool-off to end -> `SignalMigrationFinish` * `SignalMigrationFinish` send signal to AH that we are done -> `MigrationDone` * `MigrationDone` finished, unlock all Pallets. ### State Machine The core State Machine lives in the `RcMigrator` pallet in its `on_initialize`: https://github.com/polkadot-fellows/runtimes/blob/8ef1cc739d756b109dc93eaf3b9da00e3dcf1383/pallets/rc-migrator/src/lib.rs#L1338-L1342 On each block the Rc Migrator checks the current state and possibly progresses to the next one. It will only do a single state transition per block to reduce complexity of the code. Generally, there are three states per pallet (called [*stages*](https://github.com/polkadot-fellows/runtimes/blob/8ef1cc739d756b109dc93eaf3b9da00e3dcf1383/pallets/rc-migrator/src/lib.rs#L190-L389) in the code). Some pallets have more then three, but it is generally still a multiple of three and always follows the pattern of `PalletInit`, `PalletOngoing { cursor }`, `PalletDone`: https://github.com/polkadot-fellows/runtimes/blob/8ef1cc739d756b109dc93eaf3b9da00e3dcf1383/pallets/rc-migrator/src/lib.rs#L239-L244 Each pallet then has one migrator struct (eg. `MultisigMigrator<T>`) that migrates the storage items from the Relay side. It lives in the module of its name `rc-migrator/src/multisig.rs` respectively. Taking Multisigs as an example; you can find two functions in the migrator struct: `migrate_many` and `migrate_single`. The former one is from the [`PalletMigration` trait](https://github.com/polkadot-fellows/runtimes/blob/715dbb4455a127066d0118ce7a096c72200e1126/pallets/rc-migrator/src/types.rs#L209-L221). The `migrate_single` function is done by convention to keep the code readable. The `migrate_many` does the following: - Weight accounting for the RC side: Normal weight tracking to not have overtime RC blocks - Weight accounting for the AH side: Ensuring to not send messages that would take up too much weight on AH processing - Ensure that DMP messages are sensibly sized by using the `XcmBatchAndMeter` - Taking the data out from the Relay chain (deleting it) - Including the data into a DMP message and sending it towards AH ### AH Side The main logic on Asset Hub lives in the `AhMigrator` pallet. It contains at least one extrinsic per pallet to receive the incoming data from the RC. We are using extrinsics since RC is wrapping the data into XCM::Transacts: https://github.com/polkadot-fellows/runtimes/blob/9a20b12e22b019c1c0b15b9af897567a559e424c/pallets/ah-migrator/src/lib.rs#L650-L653 This calls into the [`multisig` module](https://github.com/polkadot-fellows/runtimes/blob/6b603ca47e5c49b3a898be3f8f6b078c424f42a0/pallets/ah-migrator/src/multisig.rs#L37) to integrate the data into the storage. Per convention we are emitting events for each item and the whole batch. The main task of the AH side is to integrate the data. In the example of the multisig it is special since we do not migrate the multisig, but only the reserved account which will be unreserved on AH. ## Messaging Logic The messaging is ACK based. The Relay sends message to Asset Hub up to a specified limit (50). The limit can be adjusted on the fly through a dedicated dispatchable call, restricted to Admin and Manager roles. The limit may be overstepped by the configured batch-size (10), so in total there should never be more than 60 DMPs queued. Each DMP is set to at most [50KB](https://github.com/polkadot-fellows/runtimes/blob/8ef1cc739d756b109dc93eaf3b9da00e3dcf1383/pallets/rc-migrator/src/lib.rs#L131). The Relay Chain migrator creates a query for each XCM data message using the XCM query–response primitives and attaches a response status request from Asset Hub to the message. The XCM executor on Asset Hub then sends back the response status for every message with such a request. The Relay migrator stores each data message sent to Asset Hub until it receives confirmation of successful processing. It also provides a dispatchable call, available only to Admin and Manager roles, to resend any unconfirmed messages. A bug that prevented certain messages from being accounted for during a particulat pallet migration caused the Westend AHM stall. The system was queuing too many DMPs, which forced WAH to author an overweight block while attempting to process them all at once. ## Call Filtering Pallet calls are filtered during the migration for three reasons: - prevent malicious users from spamming the chain with cheap TX and slowing down the migration - prevent users from sending many UMPs out of AH to clog up the UMP queue - prevent interference with pallets that are being migrated to avoid messing up their storage invariants Both RC and AH provide call filters for `Before`, `During` and `After` the migration. As you can see, most things are disabled during the migration on both chains. After the migration, Relay chain keeps pretty much everything disabled since it was now enabled on AH: - Before: RC everything enabled, AH all new pallets disabled (staking, gov etc) - During: RC mostly everything disabled, AH mostly everything disabled - After: RC mostly everything disabled (staking, gov etc), AH everything enabled (staking, gov etc) This is implemented by returning three bools, one for each phase: https://github.com/polkadot-fellows/runtimes/blob/88f4aaf62236fbee9cfb9183e44333bac45b1371/system-parachains/asset-hubs/asset-hub-polkadot/src/ah_migration/call_filter.rs#L81-L83 ## Testing and Dry-Runs https://github.com/paritytech/ahm-dryrun is the repository for testing infrastructure for AHM. As of now, the following is being tested there (as a part of "[AHM Flow (all steps)](https://github.com/paritytech/ahm-dryrun/actions/workflows/zombie-bite.yml)" nightly action): * Dry-running a migration on a fork of Kusama * Re-running the rust unit tests introduced in this branch * Re-running a subset of the same tests, re-written in TS * Re-running PET tests. Each action produces a table with the summary of the test results: <img width="682" height="357" alt="Screenshot 2025-09-19 at 09 03 20" src="https://github.com/user-attachments/assets/69c1e37d-6f8f-4b57-b97f-75781a1e1a3a" /> And 4 snapshot files (2 real databases, 2 try-runtime snapshots) which can be used to re-run any of the tests, or run the pre/post migration chain, locally. <img width="1347" height="476" alt="Screenshot 2025-09-19 at 09 03 40" src="https://github.com/user-attachments/assets/127cbf76-b2fb-467f-8fef-3e93a9a709f6" /> <details><summary>Full Changelog</summary> <p> - **[AHM] OpenGov for Kusama AH (#877)** - **Relay Chain Accounts to Asset Hub Migration (#515)** - **Test Relay<->AH migration through DMP messages (#528)** - **[AHM] Improve account migration (#532)** - **[AHM] Add multisig migration (#534)** - **[AHM] Proxy migration (#542)** - **[AHM] Cleanup and add Preimage doc (#543)** - **[AHM] Improve accounts migration (#550)** - **[AHM] Preimage migration (#545)** - **[AHM] Add Polkadot call filtering (#559)** - **[AHM] Nomination pools (#562)** - **[AHM] referenda pallet (#558)** - **[AHM] Cleanup (#565)** - **[AHM] Scheduler Pallet (#569)** - **[AHM] Fast unstake and Bags list (#563)** - **[AHM] Pallet claims (#570)** - **[AHM] Conviction Voting Pallet (#578)** - **[AHM] Pallet Indices (#577)** - **[AHM] pause scheduler during migration (#580)** - **[AHM] Asset rate pallet migration (#581)** - **[AHM] Bounties data migration (#585)** - **[AHM] Vesting (#575)** - **[AHM] fix the rc-migrator call filter (#598)** - **[AHM] Sovereign Account Translation (#594)** - **[AHM] Crowdloans (#592)** - **[AHM] Set up AH migration testing framework for single pallets (#597)** - **[AHM] Stage management (#584)** - **[AHM] Do not pause inherents 🙈 (#609)** - **[AHM] Relay Chain accounts' reserves (#602)** - **[AHM] Benchmarks (#589)** - **[AHM] Pallet testing framework (#612)** - **[AHM] fix xcm weight at most (#617)** - **[AHM] Improve weight accounting for accounts migration (#618)** - **[AHM] AH acks messages from RC (#620)** - **[AHM] Pure Proxy Investigation (#621)** - **[AHM] Remove migrated items for pallet preimage and improve testing (#619)** - **[AHM] Referenda metadata (#633)** - **[AHM] Fix accounts migration failures (#628)** - **[AHM] refactor events and enable scheduled migration start (#634)** - **[AHM] Migrating DOT total issuance tracking from RC to AH (#607)** - **[AHM] Comment faulty checks out (#640)** - **Account migrator refactor (#639)** - **[AHM] Rebase (#641)** - **[AHM] Run AHM test in CI (#642)** - **[AHM] Vesting test (#615)** - **[AHM] bags_list and conviction_voting tests (#632)** - **[AHM] Treasury pallet migration (#624)** - **[AHM] Fix tests for pallet preimage (#643)** - **[AHM] Test Coverage Report (#650)** - **[AHM] deactivate/reactivate total issuance & weights (#648)** - **[AHM] add sudo behind feature flag (#657)** - **[AHM] fast_unstake tests (#658)** - **[AHM] asset_rate test (#660)** - **[AHM] Pallet treasury tests (#664)** - **[AHM] Improve account balances integration tests (#655)** - **[AHM] Integrate AH migrator weights to RC (#665)** - **Testing for bounties migration (#669)** - **[AHM] Westend port adapters (#652)** - **[AHM] fix checking account and total issuance migration (#636)** - **[AHM] Bump polkadot relay and AH versions (#667)** - **[AHM] Fix tests for pallet treasury (#671)** - **[AHM] Claims and Crowdloan tests (#622)** - **[AHM] Benchmarks (#663)** - **[AHM] Add Asset Hub CallFilter (#670)** - **[AHM] Westend staking migration (#689)** - **[AHM] Referenda migration storage checks (#672)** - **[AHM] AH benchmarks cleanup (#690)** - **[AHM] Westend Async Staking Migration (#691)** - **[AHM] Relay Chain migrator benchmarks (#692)** - **[AHM] Asset Hub ops pallet benchmarks (#693)** - **[AHM] Xcm send weights and Batch helper types (#694)** - **Finish staking Westend (#695)** - **[AHM] Account provider/consumer references (#702)** - **[AHM] Fix westend builds (#704)** - **[AHM] Generate weights (#706)** - **[AHM] Proxy fixes and more tests (#707)** - **[AHM] Docs and simpler events (#699)** - **[AHM] Test call decoding (#710)** - **[AHM] Emulated test for migration with async backing (#717)** - **[AHM] Increase test coverage (#720)** - **[AHM] Add referenda checks to Westend migration (#713)** - **[AHM] Nom_pools test (#677)** - **[AHM] Scheduler storage item checks (#680)** - **[AHM] Update Polkadot Snapshot (#725)** - **[AHM] Pallet multisig tests (#666)** - **[AHM] Adapt XCM configuration to account for changes before and after migration (#722)** - **[AHM] document checking account migration (#716)** - **[AHM] Dependency fixes for integration tests and the Polkadot runtime (#751)** - **[AHM] Remove empty conviction voting filter (#750)** - **[AHM] Missing TODOs and `AccountState` type update (#742)** - **[AHM] DMP prioritization on AH (#772)** - **[AHM] Disable #[pallet::hooks] for migrating pallets during migration (#784)** - **[AHM] AH messages prioritization on RC (#787)** - **[AHM] Cache test snapshots and include more tests into CI job (#788)** - **[AHM] Cleanup Westend feature (#789)** - **[AHM] Introducing the Cool-Off stage (#786)** - **[AHM] Flow Control System (#780)** - **[AHM] Migrate pallet delegated-staking to AH (#791)** - **[AHM] Merge master into dev branch (#793)** - **[AHM] Disable indirect XCMs from RC to AH and vice versa during migration (#774)** - **Rebase** - **bring back RelayTreasuryLocation to make old tests compiole** - **[AHM] Missing `RootLocation` for WaivedLocation for AHP (#798)** - **[AHM] Missing `SecretaryEntities` for AHP (#797)** - **[AHM] Migration idempotency (#808)** - **[AHM] Block number providers for migrating pallets (#809)** - **[AHM] Copy latest ah-ops pallet from the SDK (#810)** - **[AHM / ah-migrator]: Implement RC->AH account translation `mocked` migration across all involved pallets (#807)** - **[AHM] Complete account balances tests (#674)** - **[AHM] Address TODOs (#815)** - **[AHM] Async staking config (#812)** - **[AHM] Optional migration manager account id (#818)** - **[AHM] Type safe Hold and Freeze-Reason translation (#819)** - **[AHM] Create new response query on resend and tests (#816)** - **PolkadotAssetHub: Enable Async Backing (#763)** - **Ensure no era planned when migration starts (#728)** - **[AHM] with async backing (#822)** - **[AHM] Staking migration (#821)** - **identify with only validator account** - **[AHM] Tests work for Paseo (#827)** - **[AHM] Child bounties (#613)** - **[AHM] Cleanup and linter fixes (#828)** - **[AHM] Fix snowbridge test - wrong import of `RelayTreasuryPalletAccount` (instead of AH, it should be BH) (#831)** - **[AHM] Account Translation mapping (#829)** - **Fast unstake: remove alias** - **fmt** - **[AHM] Max migrated items per block (#834)** - **[AHM] Record migration timings (#835)** - **[AHM] Remove storage aliases and cleanup (#832)** - **[AHM] fix Kusama bags list pallet benchmarks (#836)** - **[AHM] Unprocessed msg buffer size 50 (#839)** - **[AHM] Post migration cool off stage (#841)** - **[AHM] Multisig test and storage_alias cleanup (#842)** - **[AHM] Remove fast-unstake and test fixes (#846)** - **Run try-state check for all pallets post AHM rust tests (#833)** - **[AHM] Preserve on RC manager' account (#843)** - **[AHM] Filter staking calls before migration starts (#847)** - **[AHM] State Decode Tests (#848)** - **[AHM] Send xcm extrinsic within migrator pallets (#851)** - **Merge and cleanup merge commit** - #845 - #852 - #862 - #875 - #872 - #877 - #626 - #879 - #885 - #886 - #882 - #883 - #854 - #888 - #895 - #892 - #896 - #889 </p> </details> // only to let all CIs to execute for now - [ ] Does not require a CHANGELOG entry --------- Signed-off-by: Oliver Tale-Yazdi <[email protected]> Signed-off-by: Adrian Catangiu <[email protected]> Signed-off-by: Andrei Sandu <[email protected]> Signed-off-by: Alexandru Vasile <[email protected]> Co-authored-by: Muharem <[email protected]> Co-authored-by: Dónal Murray <[email protected]> Co-authored-by: Adrian Catangiu <[email protected]> Co-authored-by: Giuseppe Re <[email protected]> Co-authored-by: Andrii <[email protected]> Co-authored-by: Bastian Köcher <[email protected]> Co-authored-by: Yuri Volkov <[email protected]> Co-authored-by: s0me0ne-unkn0wn <[email protected]> Co-authored-by: Kian Paimani <[email protected]> Co-authored-by: Branislav Kontur <[email protected]> Co-authored-by: GitHub Action <[email protected]> Co-authored-by: Francisco Aguirre <[email protected]> Co-authored-by: fellowship-merge-bot[bot] <151052383+fellowship-merge-bot[bot]@users.noreply.github.com> Co-authored-by: Pablo Andrés Dorado Suárez <[email protected]> Co-authored-by: ordian <[email protected]> Co-authored-by: Alistair Singh <[email protected]> Co-authored-by: Sergej Sakac <[email protected]> Co-authored-by: Bastian Köcher <[email protected]> Co-authored-by: Serban Iorga <[email protected]> Co-authored-by: Xiliang Chen <[email protected]> Co-authored-by: Nikolai Kozlov <[email protected]> Co-authored-by: nkprt <[email protected]> Co-authored-by: Eugenio Paluello <[email protected]> Co-authored-by: Javier Viola <[email protected]> Co-authored-by: polka.dom <[email protected]> Co-authored-by: Dónal Murray <[email protected]> Co-authored-by: Karol Kokoszka <[email protected]> Co-authored-by: joe petrowski <[email protected]> Co-authored-by: Clara van Staden <[email protected]> Co-authored-by: Ankan <[email protected]> Co-authored-by: clangenb <[email protected]> Co-authored-by: Andrei Sandu <[email protected]> Co-authored-by: Andrei Sandu <[email protected]> Co-authored-by: Alexandre Baldé <[email protected]> Co-authored-by: Maksym H <[email protected]> Co-authored-by: Alin Dima <[email protected]> Co-authored-by: Alexander Theißen <[email protected]> Co-authored-by: Christian Langenbacher <[email protected]> Co-authored-by: Ankan <[email protected]> Co-authored-by: Karol Kokoszka <[email protected]> Co-authored-by: brenzi <[email protected]> Co-authored-by: Doordashcon <[email protected]> Co-authored-by: eskimor <[email protected]> Co-authored-by: Robert <[email protected]> Co-authored-by: Raymond Cheung <[email protected]> Co-authored-by: Maciej <[email protected]> Co-authored-by: Paolo La Camera <[email protected]> Co-authored-by: kianenigma <[email protected]> Co-authored-by: Alexandru Vasile <[email protected]> Co-authored-by: Alexander Cyon <[email protected]>
4 participants
Disable indirect XCMs from RC to AH and vice versa during migration
While we want to prioritize migration-related XCM messages between the Relay Chain (RC) and the Asset Hub (AH), we must ensure that no one can abuse the routing logic to indirectly send messages between them via XCM forwarding.
Specifically, this PR prevents scenarios where an external parachain (e.g., chain X) crafts an XCM message to the AH that, when executed, results in a forwarded message to the RC — or vice versa. During migration, this kind of message forwarding must be blocked to ensure predictable and secure behavior.
This PR: