Make pallets XCM compatible + less configuration overhead #2457
Open
Description
We've removed a lot of code (#1638) because the architecture has been changed significantly. And now we have some options to make pallets configuration easier. That's a task for the future (after initial deployment), but I'm gonna leave some ideas here:
- now we have 3 types with almost the same meaning: XCM
MultiLocation
,ChainId
andLaneId
. The idea is that we'll have two bridge hubs, which will be used to build bridges between different parachains. Every bridge now (not at the code, but in plans) uses types in following matter: every parachain (bridge hubs, Statemin?, ...) all have XCM "addresses" (MultiLocations
), bridge hubs also haveChainId
s and every bridge will be assigned a single lane (e.g. Statimine <> Statemint will be using lane0x00000000
). We may removeChainId
andLaneId
types and instead use pair ofMultiLocation
s (or whatever is used to identify chains in global consensus); - we may remove configurable proof types from the messaging pallet and move storage proof verification code to the messaging pallet;
- we may move most of
bridge-runtime-common
code to the messaging pallet and then we'll be able to replace most of configuration options and glue code by adding singletype BridgedChain = SomeBridgedChain;
. This would also allow us to implement things like Signed extension to refund relayer at the target chain #1657 easier;
Things to do after refactoring:
- review and remove/add conditions to integrity tests;
- (optionally?) maybe remove
VerificationError
and move all variants to the pallet errors?
Metadata
Assignees
Labels
No labels