[xcm-v3] Bridging xcm:v3:Transact and handling AccountId32 on target chain (with different globalConsensus)

[bkontur]

Story:

• bridging xcm:v3:Transact calls from Rococo:Statemine(1000) -> Rococo:BridgeHub(1013) -> substrate-relayer -> Wococo:BridgeHub(1014) -> Wococo:Westmint(1000)
• some on Rococo:Statemine account can submit extrinsic xcm:Transact(System::remark_with_event) like this:
• message comes and is dispatched on Wococo:Westmint as:
• account in received Event::Remark is sovereign account of Wococo:BridgeHub(1014)

Problem and proof-of-concept

• System::remark_with_event does validation let who = ensure_signed(origin)?;
• to pass ensure_signed xcm config needs to have some implementation for OriginConverter that returns RuntimeOrigin::signed(...)
• here is very very naive xcm ConvertOrigin implementation BridgedSignedAccountId32AsNative, which just converts MultiLocation{ parents: 2, interior: X3(GlobalConsensus(Rococo), Parachain(1000), AccountId32 { network: Rococo, id: ... })} to the configured local bridge-hub sovereign account LocationConverter::convert(MultiLocation { parents: 1, interior: X1(Parachain(1014)) }) (I know this impl is no-go for any production, it is just PoC to trigger successful dispatch + test )

Question:

• what should be the "proper/correct/recommended" way to handle this AccountId conversion from different globalConsensus ?

[bkontur]

@gavofyork @KiChjang @joepetrowski could you, please, check this and maybe give me some hints/leads (maybe I am totally missing something)?

also I just found something about "Origin aliasing" paritytech/polkadot-sdk#925, which looks similar, but I dont know

[KiChjang]

Unless I'm misunderstanding something, I think you can simply convert the ID in the AccountId32 junction directly to a local SS58 address. You'll most likely create a new struct under xcm-builder to allow this.

[bkontur]

something similiar #6612