Implementer's Guide: HRMP: Reliable way to notify PVF about incoming channels

[pepyakin]

The PVF needs a way to authenticate that the following events:

1. there is a new inbound open request
2. an outbound open request was confirmed by the recipient
3. an outbound open request timed out. This one could theoretically be tracked by the PVF, but only assuming that the configuration doesn't change which can happen even if rarely.

(I believe other cases can be tracked by the PVF itself. E.g. it should know that it shouldn't send two open requests to the same recipient, confirm the same inbound open request twice, etc)

A collator should not be able to conceal any of these events.

I see the following solutions:

1. put raw requests into PersistedValidationData. That inflates the persistent data, but not that bad: the number of open and close requests are bounded (the former is by the sum of max ingress and egress channels, the latter by the number of already opened channels).
   • Then we can further compress data by leveraging the fact that either sender or recipient is this para.
   • Then, we can remove confirmed: bool for all inbound open requests.
   • This data will be duplicated for successive block in the same session though.
2. put a hash into PersistedValidationData.
   • Essentially, allows us to move this data into the PVF's state and not duplicate it.
3. send a DM for each of these events.
   • The same as previous but less complex since it relies on an existing mechanism
   • A caveat: the para can be a bit slow to process DMQ and potentially miss a notification or receive it when it's too late.
4. punt off on the relay chain storage root proofs.

Originally posted by @pepyakin in #1588 (comment)

[AlistairStewart]

Outbound requests are limited, but inboound ones might not be. Therefore I would favour solution 3 for problem 1. If the timeout is generous then messages being slow is not a problem. Solution 1 might not be so bad for problems 2 or 3 since they are about outbound requests.

For solution 2, there is the issue with were we get the preimage of this hash. In general, we have to work out where this XCMP channel metadata lives. I suppose a hash is ok if we are looking up the information for the pre-image in the relay chain state anyway.

Of course if we want something fast to implement for HRMP, just going with 3 or even 1, for everything and hoping and then fixing it later might be ok.

[pepyakin]

Thanks for the input!

I suppose a hash is ok if we are looking up the information for the pre-image in the relay chain state anyway.

Yeah, the state about channels are still stored on the relay-chain so the preimages are available.

Of course if we want something fast to implement for HRMP, just going with 3 or even 1, for everything and hoping and then fixing it later might be ok.

Yeah, agreed about HRMP, especially in the light of #1642 (TL;DR: imposing the harsh limits that prevents the abuse).

Outbound requests are limited, but inbound ones might not be.

Good point. There are two sides of this:

• HRMP. Guide: Tighten HRMP #1642 implies there the number of inbound channels is limited.
• XCMP, my earlier idea of leaving the CST entry at the sender and let's the recipient to read the messages also implies that, but we haven't yet agreed if we are going to go this way to implement the channels yet.