Skip to content
This repository has been archived by the owner on Nov 15, 2023. It is now read-only.

Opening channels in both direction in one go #3545

Open
pepyakin opened this issue Aug 1, 2021 · 0 comments
Open

Opening channels in both direction in one go #3545

pepyakin opened this issue Aug 1, 2021 · 0 comments
Labels
J0-enhancement An additional feature request.

Comments

@pepyakin
Copy link
Contributor

pepyakin commented Aug 1, 2021

HRMP as well as XCMP supports channels only in one direction. Right now, there is logic only for opening a channel in one direction: from one party to another. In case communication is required in both directions the parties should go through opening the channels, i.e. creating a request and accepting it, twice.

Bidirectional communication seems to be a common enough case that it deserves it's own simplified way. Specifically, one confirmation from either side should be enough to create channels in both directions.

This probably will look like as follows. We have another list of open channel request specifically dedicated for this case. The request will be identified by a tuple which contains both sender and recipient.

Unlike the unidirectional channels, there will be no initiating party. Therefore, the tuple should be the same whether a para A initiates the request or B. A simple way to achieve that is to make the first tuple item a para with the lower numerical para ID and the send with the greater.

When the counterparty sends the corresponding message (perhaps even of the same kind) then the channel can be opened at the next session change.

The initiator will leave two deposits: one for where the initiator is the sender and one for where it's the receiver. At the time when counterparty leaves the deposits in the same manner.

Canceling of the request is only possible before the request is accepted. Either of the parties should be able to cancel the request.

Participating in the request should be counted as 2 channels towards the channel limit.

When either of the parties para offboards, the request should be removed. That implies there is a mapping between parachains and the bidirectional channels open requests. In case there is an accepted request it is ignored. The deposit is not returned to the offboarded party, but should be refunded to the para that is still live (see also #3544)

@pepyakin pepyakin added the J0-enhancement An additional feature request. label Aug 1, 2021
@pepyakin pepyakin added this to To Do in Cross Chain Message Transport via automation Aug 1, 2021
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
J0-enhancement An additional feature request.
Development

No branches or pull requests

1 participant