Genesis bridge: better UX for chains without genesis transfers

[danwt]

We can trivially support them with a MsgCreateRollapp flag (transfersEnabled) but it leaves room for user error

Ideally we'd have something on the RA side, but there is no obvious way to transmit that info the Hub without piggybacking the memo, but there is no transfer being made to memo off of

[danwt]

related https://github.com/dymensionxyz/research/issues/278

[danwt]

@mtsitrin made the suggestion that we just use the first transfer RA->Hub that does not include the 'genesis transfer special memo' to signal that the bridge should be opened.

It's an elegant solution because it removes the need for rollapps that don't want to use genesis transfers to have to set 'transfersEnabled' on the MsgCreateRollapp

Also, it allows a possible additional simplification: we may not require a genesis transfer counter on the hub. The hub could simply use the first normal transfer as the signal.

The only problem with this additional simplification is that the rollapps would break their genesis phase if a regular transfer accidentally got relayed before all the genesis transfers. To mitigate that, we could either

• a) place the responsibility on the operator
• b) we could keep the transfer counter on the hub. In this way, after the first genesis transfer arrives then all are expected. This does't completely avoid the problem in theory though, since a regular transfer can still race ahead of all the genesis ones
• c) disable transfers on the rollapp until successful acks have been received for every genesis transfer packet (currently we do not do this, we just allow them to be sent, but they will get refunded)

Personally, I like the idea, and option (a)

cc @omritoptix

[omritoptix]

@danwt how do you imagine this being enforced by (a)? i.e does he need to make sure there are special conditions in place and protect from specific attack vectors? if so I think we should avoid this. imo should be smooth experience with minimal "learning" overhead.

given what I wrote, and the fact that I'm still not sure exactly about what (a) requires from the operator, I think (c) makes sense.

[danwt]

how do you imagine this being enforced by (a)

Yeah I was just thinking, because we already agreed that it is up to the operator not expose his RPC endpoint before he finishes creating the channel with the Hub, then it might also be reasonable to assume that he shall not expose the endpoint until all the genesis transfers have finished being relayed

He could know when it's finished by waiting until all packet commits are cleared

But anyways, sure, I will investigate (c), should be easy