Skip to content

Make pallets XCM compatible + less configuration overhead #2457

Open
@svyatonik

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 and LaneId. 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 have ChainIds and every bridge will be assigned a single lane (e.g. Statimine <> Statemint will be using lane 0x00000000). We may remove ChainId and LaneId types and instead use pair of MultiLocations (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 single type 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
No labels

Type

No type

Projects

No projects

Relationships

None yet

Development

No branches or pull requests

Issue actions