paritytech / polkadot-sdk

The Parity Polkadot Blockchain SDK
https://polkadot.com/
1.93k stars 709 forks source link

Bridges: enable chopsticks to emulate passing XCM messages over bridge #4793

Open serban300 opened 5 months ago

serban300 commented 5 months ago

In order to send messages over the bridge we need to also pass a finality proof and a storage proof. Chopsticks doesn't support this at the moment and it would be quite complex to implement.

One idea would be to expose a runtime API for dispatching bridged messages and then chopsticks will be able to call this runtime API, get storage diffs, and actually build a block with those storage diffs enacted

We can explore other options as well

Related chopsticks issue: https://github.com/AcalaNetwork/chopsticks/issues/741

xlc commented 5 months ago

Another alternative will be having a root origin call to apply an arbitrary message without proof. This could also be used by governance for whatever reason. And then we should be able to fake a DMP from relaychain to dispatch call from root origin to dispatch messages.

bkontur commented 5 months ago

just thinking out loud, yeah that dry_run messages runtime API is not a bad idea, here I wrote how should be possible to read message (BridgeMessage(dest, xcm) as Vec<u8>) on source BH,

and then we could expose MessageDispatch as this runtime API on target BH, because the real message dispatch should hit this code: https://github.com/paritytech/polkadot-sdk/blob/master/polkadot/xcm/xcm-builder/src/universal_exports.rs#L428-L434, which decodes BridgeMessage(dest, xcm) as Vec<u8> and sends it with XcmRouter, which is using XcmpQueue, so the XcmpQueue makes storage diff which we need.

bkontur commented 5 months ago

Another alternative will be having a root origin call to apply an arbitrary message without proof. This could also be used by governance for whatever reason. And then we should be able to fake a DMP from relaychain to dispatch call from root origin to dispatch messages.

@xlc I think if we allow pallet_xcm::Config::SendXcmOrigin for a governance on target BH, it should be "almost" enough. We can decode BridgeMessage(dest, xcm) as Vec<u8> from source BH, but we need to prepend it with https://github.com/paritytech/polkadot-sdk/blob/master/polkadot/xcm/xcm-builder/src/universal_exports.rs#L428-L434 to be valid on the target AssetHub