You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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
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.
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,
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.
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
The text was updated successfully, but these errors were encountered: