Add HRMP notification handlers to the xcm-executor #3696
Conversation
|
User @JuaniRios, please sign the CLA here. |
|
cc @bkontur |
JuaniRios
changed the title
|
Original disussion: polkadot-fellows/RFCs#82 |
|
bot fmt |
|
@bkontur https://gitlab.parity.io/parity/mirrors/polkadot-sdk/-/jobs/5539729 was started for your command Comment |
|
@bkontur Command |
|
@JuaniRios also please fix all compilation issues e.g.https://gitlab.parity.io/parity/mirrors/polkadot-sdk/-/jobs/5539475 and we should be good to go |
Done |
8b3bf39
Currently the xcm-executor returns an `Unimplemented` error if it receives any HRMP-related instruction. What I propose here, which is what we are currently doing in our forked executor at polimec, is to introduce a trait implemented by the executor which will handle those instructions. This way, if parachains want to keep the default behavior, they just use `()` and it will return unimplemented, but they can also implement their own logic to establish HRMP channels with other chains in an automated fashion, without requiring to go through governance. Our implementation is mentioned in the [polkadot HRMP docs](https://arc.net/l/quote/hduiivbu), and it was suggested to us to submit a PR to add these changes to polkadot-sdk. --------- Co-authored-by: Branislav Kontur <bkontur@gmail.com> Co-authored-by: command-bot <>
|
This is a breaking change until we have default configs |
yes, but the "soft" breaking type - only breaking at runtime config level and with |
|
@JuaniRios Could you update the description with your "polkadot address: XYZ"? |
Added at the bottom of the PR description :) |
|
/tip small |
|
@bkchr A referendum for a small (20 DOT) tip was successfully submitted for @JuaniRios (15fj1UhQp8Xes7y7LSmDYTy349mXvUwrbNmLaP5tQKBxsQY1 on polkadot). Referendum number: 589. |
|
The referendum has appeared on Polkassembly. |
Currently the xcm-executor returns an `Unimplemented` error if it receives any HRMP-related instruction. What I propose here, which is what we are currently doing in our forked executor at polimec, is to introduce a trait implemented by the executor which will handle those instructions. This way, if parachains want to keep the default behavior, they just use `()` and it will return unimplemented, but they can also implement their own logic to establish HRMP channels with other chains in an automated fashion, without requiring to go through governance. Our implementation is mentioned in the [polkadot HRMP docs](https://arc.net/l/quote/hduiivbu), and it was suggested to us to submit a PR to add these changes to polkadot-sdk. --------- Co-authored-by: Branislav Kontur <bkontur@gmail.com> Co-authored-by: command-bot <>
|
This pull request has been mentioned on Polkadot Forum. There might be relevant details there: https://forum.polkadot.network/t/parity-tech-update-for-march/7226/1 |
… from the relaychain (#4156) This PR: - introduces `AllowHrmpNotificationsFromRelayChain` barrier for allowing HRMP notifications just from the relay chain (to fulfill safety assumptions - [see](https://github.com/paritytech/polkadot-sdk/blob/master/polkadot/xcm/src/v4/mod.rs#L532)) - sets it up for all testnet SP parachains Continuation of: #3696
Currently the xcm-executor returns an
Unimplementederror if it receives any HRMP-related instruction.What I propose here, which is what we are currently doing in our forked executor at polimec, is to introduce a trait implemented by the executor which will handle those instructions.
This way, if parachains want to keep the default behavior, they just use
()and it will return unimplemented, but they can also implement their own logic to establish HRMP channels with other chains in an automated fashion, without requiring to go through governance.Our implementation is mentioned in the polkadot HRMP docs, and it was suggested to us to submit a PR to add these changes to polkadot-sdk.
Polkadot address: 15fj1UhQp8Xes7y7LSmDYTy349mXvUwrbNmLaP5tQKBxsQY1