Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
serban300 opened this issue Jun 14, 2024 · 3 comments
Open
Assignees
Labels
T15-bridges This PR/Issue is related to bridges.

Comments

@serban300
Copy link
Contributor

serban300 commented Jun 14, 2024

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: AcalaNetwork/chopsticks#741

@serban300 serban300 added the T15-bridges This PR/Issue is related to bridges. label Jun 14, 2024
@xlc
Copy link
Contributor

xlc commented Jun 14, 2024

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
Copy link
Contributor

bkontur commented Jun 14, 2024

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
Copy link
Contributor

bkontur commented Jun 14, 2024

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

@acatangiu acatangiu moved this to High Priority in Bridges + XCM Aug 6, 2024
@bkontur bkontur self-assigned this Sep 9, 2024
@serban300 serban300 assigned serban300 and unassigned bkontur Sep 12, 2024
@acatangiu acatangiu moved this to Todo in Bridges + XCM Oct 14, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
T15-bridges This PR/Issue is related to bridges.
Projects
Status: Todo
Development

No branches or pull requests

3 participants