Investigate limiting IBC connections

[liamsi]

Summary

While we do want IBC connections to a few selected chains (#734), we do not want that anyone can establish a connection to arbitrary zones. Reason is that we want to keep the state machine as minimal as possible as well as the base layer as focused as possible.

Problem Definition

Need to limit the chains that can connect to Celestia to a predefined allow-list. That allow-list might grow over time. Either it can be modified via governance (#168), or, modifications to the list must require a hard-fork.

Proposal

TODO write proposal in more details:

• create ibc clients for target chains on genesis
• reject CreateClient txs
• allow governance to whitelist and create new clients?
• ...

[musalbas]

Reason is that we want to keep the state machine as minimal as possible as well as the base layer as focused as possible.

Can we expand on this a bit? What extra complexity on computation is introduced if arbitrary IBC connections are allowed? Is it that relayers can cause Celestia validators to validate arbitrary block headers and signatures from other chain? I think, if the transaction fee for that is priced correctly it might not be necessarily bad, but not entirely sure yet.

[liamsi]

Is it that relayers can cause Celestia validators to validate arbitrary block headers and signatures from other chain?

Yes, though as the validator sets (or at least the +2/3 of stake) are relatively stable usually, this is not too bad as IBC defaults to skipping verification and does not require a MsgUpdateClient too often to keep the connection alive (and relayers pay themselves for these Tx).

I think, if the transaction fee for that is priced correctly it might not be necessarily bad, but not entirely sure yet.

I am not sure if the Txs are priced in a particularly special way. The more sigs, the larger the Tx, the more gas it would consume (and the higher the fee). But not sure if that matches "priced correctly".

[liamsi]

An alternative we could consider here is to instead "white-list" the token denoms that go in and out. Basically any Tx that is not related to the celestia native token should be dropped. I think @zmanian suggested that as an alternative worth exploring instead.

[musalbas]

Are we sure we need a white-list anyways? Is adding new IBC connections execution/state heavy?