ICS 11: IBC state optimizations / pruning

[cwgoes]

Primarily a port of the optimizations section of the original IBC spec.

Will cover:

• Conditions under which packets can be pruned
• Conditions under which channel data can be pruned
• Conditions under which connection data can be pruned
• Other possible state optimizations (storage rent, Merkle root tracking)

[cwgoes]

Ref #48 - the more I think about this the more I think we should just separate availability from commitment instead of implementing pruning strategies.

[ebuchman]

we should just separate availability from commitment instead of implementing pruning strategies.

Can you clarify this further ? Specifically the impact on the spec

[cwgoes]

In the original IBC specifications (that I have read, and the latest version in #36), packets were stored in full in the state of the outgoing chain, then later deleted once a receipt had been sent back from the destination chain.

I do not think this is necessary, and it might be an overly complex / costly (more transactions required) way to minimize state usage (especially when receipts are not required for the application layer) as compared to storing a much smaller commitment or updated accumulator root in the source chain. The destination chain, when it checks the inclusion proof, wants to verify:

1. That the source chain finalized a particular packet
2. That any state transitions (e.g. escrowing tokens) associated with sending that packet were executed

(2) already requires prior knowledge about how the source chain's state machine works, so I think we can instead have the source chain execute the packet but only store a commitment (e.g. sha256 hash) in state and prove storage of that commitment to the destination chain. The packet data will already be public (in the transaction history of the source chain), so relayers can read it and submit the packet on the destination chain, and the destination chain can calculate the hash of the packet data and verify inclusion of the hash in the most recent header from the source chain. If we do this, sending an extra receipt back to the source chain for packet cleanup is much less necessary, since the only stored value is a short commitment (and maybe not even that with better accumulator constructions).

Thoughts?

If this seems reasonable, I will write it up in more detail in #36. Source chains could still opt to store the packet data if desired, I just think it doesn't really need to be part of the protocol.

[ebuchman]

Oh interesting - so just store the hash in the egress queue rather than the whole packet. I guess the only concern may be re data availability, eg if the source needs to do a dump/restart and loses its tx history

[cwgoes]

Oh interesting - so just store the hash in the egress queue rather than the whole packet.

Yes, precisely.

I guess the only concern may be re data availability, eg if the source needs to do a dump/restart and loses its tx history

That's true but seems like an exceptional case - a chain would have to be export-imported, restarted, and all nodes (or all nodes willing to provide the data) would need to have deleted their transaction history.

Even in that case, if the packet had a timeout, a new one could just be resent after the new chain started.

If there is at least a minor incentive to relay packets (including just an incentive for the original sender, if they are acting as their own relayer) nodes seem likely to keep the transaction data.

[mossid]

I agree that commitment values are much efficient on space occupiation & there are almost no drawbacks. I'm just not sure is it better to enforce that in the core protocol, we can easily implement a wrapper to make the IBC applications store the hashes (which is treated as a plain text by the IBC logic) instead of the actual values.

Also, we need a way to query original data from only the transaction and the state machine, without storing it in the state, which will be tricky. It is more like an implementation issue. Especially there can be cases where the transactions do not include the packet data: the packet can be generated from the state and the state machine, without relying on the transaction(e.g. a heartbeat ibc packet generated on endblocker...?) which needs the full state for the relayers to acknowledge about the packet data

[cwgoes]

Not yet sure if this will need to be separate from ICS 4 or not.

[cwgoes]

I think this can be part of ICS 4.

[cwgoes]

Superseded by ICS 4, which covers everything we should need for the moment.