ibc-go
ibc-go copied to clipboard
Change packet key to support efficient iteration in v2
Summary
Change packet keys to use big endian encodings on the sequence to support efficient iteration
Problem Definition
Packet keys which have sequences which are lexographically ordered are not efficient to iterate and cause issues later on which are hard to workaround. See https://github.com/cosmos/ibc-go/issues/5413 for example. This will also be problematic if we tried to create a pruning solution as we cannot easily iterate. We would need to do individual deletions or queries to the store.
Proposal
The "Eureka" version of IBC introduces a V2 to the packet commitment structure. Given that we are changing how we are committing to packets, we might as well change how we are storing these packet commitments, so that we can future proof the protocol and make future features, like pruning, much easier to implement
I propose changing the packet key structure to be:
clients/<client-ID/sequences/<big-endian-encoded-sequence>
Currently we use:
ports/<port-ID>/channels/<channel-id>/sequences/<sequence>
I think the port ID should be moved to the commitment value (this would be in-line with multi-packetdata) and I think we should be more explicit in the future approach that we are using clientIDs not channelIDs, but I haven't given these additional points much thought, so I am happy to exclude them. The big endian encoding of the sequence should definitely be done
For Admin Use
- [ ] Not duplicate issue
- [ ] Appropriate labels applied
- [ ] Appropriate contributors tagged/assigned
Note: if we decide to use the proposed new path key we should also document this in the specs.
https://github.com/cosmos/ibc-go/issues/5752 umbrella issue on some level
This has been changed in the spec: https://github.com/cosmos/ibc/pull/1144
sequence in keys formatted using Big Endian in #7378
This issue was mistakenly reopened during some integration work, so closing again now.