-
Notifications
You must be signed in to change notification settings - Fork 1.6k
Conversation
runtime/parachains/src/hrmp.rs
Outdated
use xcm::v0::{Result as XcmResult}; | ||
impl<T: Config> ExecuteHrmp for Module<T> { | ||
fn hrmp_init_open_channel(sender: u32, recipient: u32, max_message_size: u32, max_capacity: u32) -> XcmResult { | ||
Self::init_open_channel(sender.into(), recipient.into(), max_capacity, max_message_size).map_err(|_| ().into()) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Right now, this is returning the XcmError::Undefined if a runtime error is returned. What error should it be?
This PR is ready for review. The CI is red because there are no labels (and I cannot set this). Let me know of suggestions @pepyakin @shawntabrizi |
I received feedback that the I assumed the messages included in this PR were uncontroversial because they correspond directly to the actions for interacting with the |
HrmpCloseChannel { | ||
#[codec(compact)] sender: u32, | ||
#[codec(compact)] recipient: u32, | ||
}, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Recalling an open channel request is upcoming in #3543
I think it's worth to reconsider these messages in the light of that PR.
xcm/xcm-executor/src/config.rs
Outdated
@@ -29,6 +29,9 @@ pub trait Config { | |||
/// How to withdraw and deposit an asset. | |||
type AssetTransactor: TransactAsset; | |||
|
|||
/// How to execute HRMP-related actions | |||
type HrmpExecutor: ExecuteHrmp; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think this could be improved by specifying what exactly actions are (i.e. the channel management). It is also better to take into account how the developers will approach it. I think this is mostly relevant for relay-chains which is a way less common case. Thus it would be good to guide a typical implementer of this to use the ()
dummy
Co-authored-by: Sergei Shulepov <[email protected]>
xcm/src/v0/traits.rs
Outdated
pub trait ExecuteHrmp { | ||
fn hrmp_init_open_channel(sender: u32, recipient: u32, max_message_size: u32, max_capacity: u32) -> Result; | ||
fn hrmp_accept_open_channel(recipient: u32, sender: u32) -> Result; | ||
fn hrmp_close_channel(initiator: u32, sender: u32, recipient: u32) -> Result; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
DQ: why are all parameters u32 all across the place?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I presumed it's the same reason why we use u32 within XCM definitions. The alternative you are thinking of is ParaId
. That comes from the primitives crate. Unlike one may think, it can be pretty heavy, bringing all kinds of cruft. At the same time, we want this crate to be used pervasively thus we want to minimize the number of dependencies.
The new trait which exposes HRMP channel management functionality is: pub trait HrmpChannelManagementHooks {
type HrmpCall: Dispatchable + GetDispatchInfo;
fn hrmp_init_open_channel(
recipient: u32,
max_message_size: u32,
max_capacity: u32,
) -> result::Result<Self::HrmpCall, Error>;
fn hrmp_accept_open_channel(sender: u32) -> result::Result<Self::HrmpCall, Error>;
fn hrmp_close_channel(sender: u32, recipient: u32) -> result::Result<Self::HrmpCall, Error>;
} Each method returns a call so we can do the weight checks done for |
Current error, PRing substrate with impl
|
branch is stale, I don't have time now to update/maintain it |
As of now, to open, accept, and close channels on the relay chain, parachains must send the message
Xcm::Transact
with the formatted call data forhrmp
dispatchables. Forming this call is hard from the parachain runtime; this Acala demo uses polkadot-js to form the call from the relay chain context and remove the prefix.There is a
xcm-format
PR which includes three newXcm
variants to open, accept, and close channels. This PR adds those variants and the execution logic. This will make it unnecessary to useXcm::Transact
for those actions.