Pre-Incentivized testnet IBC things

[evan-forbes]

We still have some IBC related things that we would like to complete by the incentivized testnet feature freeze. The main three are already in progress and should be fairly straight forward, which involve enabling IBC in the first place

• chore: update to tm v0.34.23  celestia-core#906
• chore: update sdk from v0.46.0 to v0.46.6 cosmos-sdk#288
• Re-enable IBC #412
• Investigate limiting IBC connections #235
• The IBC portion of Investigate and finalize resource pricing  #658 comment

I don't think we have social consensus yet on anything, but one simple idea that could be a good starting point would also be looking into only allowing transfers of Celestia tokens #696 (comment) .

[cmwaters]

I've been following the various conversations happening around here just to gather as much context as possible and wanted to provide my view on a couple of these decisions:

1. Shall Celestia be deployed with IBC?
For me this is a resounding yes. Celestia depends on a marketplace whereby rollups can buy celestia tokens and validators and delegators can sell those tokens. This doesn't necessarily have to be through IBC (It most likely will be supported via centralized exchanges), but it's important to have that option there for users who prefer decentralised exchanges.

2. Should the Celestia network support anything else than the transferring of Celestia tokens?
I'm in agreement with what Ismail said about being as minimal as possible and like Zaki's suggestion. I think only the transfer module should be supported and only channels with the Celestia denomination should be allowed. There is no supported use case for any other denomination than the Celestia native token on Celestia. With that in mind, it shouldn't allow anything else by design.

3. Should we limit which chains connect with Celestia?
In alignment with the "permissionless" ethos, I think we should allow users to send Celestia tokens to and from whatever chain they want so long as it's sufficiently compensated. If we feel the resources for supporting IBC is incorrectly calculated we can modify this. We may want to put more emphasis on high throughput chains over lower throughput chains by increasing the gas to open connections and lowering the gas per transfer across the channel.

Are there any other questions on this topic we feel need to be resolved before mainnet launch? Does anyone have stronger opinions against the stances I've put forward i.e. should we set up a meeting in the near future to discuss these points? @evan-forbes @adlerjohn @liamsi @musalbas

[musalbas]

In general I am in favor of enabling IBC for Celestia's native token, but I'd quite like to know the resource pricing for IBC for sanity checking

[cmwaters]

but I'd quite like to know the resource pricing for IBC for sanity checking

Okay I'll start to do some research on that

[cmwaters]

So looking into the IBC repository, it seems that there are no adjustments to gas consumption outside of how the SDK normally calculates it i.e. writes and reads to the kvstore (and signature verification) as follows:

// KVGasConfig returns a default gas config for KVStores.
func KVGasConfig() GasConfig {
	return GasConfig{
		HasCost:          1000,
		DeleteCost:       1000,
		ReadCostFlat:     1000,
		ReadCostPerByte:  3,
		WriteCostFlat:    2000,
		WriteCostPerByte: 30,
		IterNextCostFlat: 30,
	}
}

The main messages we'd expect and the average gas consumed (on Cosmos Hub) are:

Msg	Gas
MsgUpdateClient	~350,000
MsgTransfer	~90,000
MsgRecvPacket	~80,000
MsgAcknowledgement	~30,000

From looking into the code, IBC keeps as minimal amount of state as possible so the overhead per connection with a chain is actually quite low.

[musalbas]

Is it the case that for example, IBC packets that contain more signatures (because the chain's validator set is bigger) or have higher proof size, would have higher gas?

[cmwaters]

Yes although larger validator sets won't make a difference to the amount written to state as only hashes are stored, but the increase in the transaction size themselves will mean more gas is required (by default 10 gas per byte of txs written to the blockstore.db).

In the SDK, all signatures have an additional "computational" cost (i.e. 590 gas for each ed25519 signature) but although IBC also verifies signatures, I don't believe it consumes gas. I have created an issue in their repo about it: cosmos/ibc-go#2951

[musalbas]

In the SDK, all signatures have an additional "computational" cost (i.e. 590 gas for each ed25519 signature) but although IBC also verifies signatures, I don't believe it consumes gas. I have created an issue in their repo about it: cosmos/ibc-go#2951

Why is it the case that normal signatures cost gas, but IBC ones don't?

[cmwaters]

I'm not sure if there was any intention behind it. From what I gather, the SDK decided that signature verification is costly enough to consider charging gas for verifying the signer of each sdk.Tx. The validator signatures in IBC are inside the messages of the Tx itself (specifically MsgUpdateClient), so the SDK is unaware of it and either IBC decided it didn't make sense, it was too difficult to implement (it's hard to know how many signatures needed to be verified), or that they simply missed it.

[evan-forbes]

In general I am in favor of enabling IBC for Celestia's native token

To move forward with this, I think we can progress to #235, where we aim to find out what is needed to limit IBC to only Celestia's native token.

I, or @cmwaters, can talk with the IBC to see what the particular reason was for not charging gas, and then weight our options from there. In the future, I imagine that we should be able to add gas costs to those signatures if it becomes an issue.

[evan-forbes]

closing, as we've merged our initial restrictions on IBC and enabled it. We will still document the gas usage, specifically how we are not currently charging gas for signatures and the values above, in #658

[evan-forbes]

we also have a follow up for more thorough, yet slightly complex e2e tests for IBC connections to chains such as osmosis and cosmos hub in #1249, and then we will include the implemented token filter #1219 in the specs in #734