-
Notifications
You must be signed in to change notification settings - Fork 399
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Figure out prefixing in coordination with SDK implementation #387
Comments
I looked at more paths, here is what I think we currently have (ICS vs SDK). I checked some of these with the debugger on some of the packet and handshake tests. ICS24: ICS24: ICS24: ICS24: ICS24: ICS24: ICS24: ICS24: ICS24: |
also, from the private store: ICS24: ICS24: BTW, the |
@fedekunze or @AdityaSripal - do you recall why we did this in the SDK? Was it for some ease-of-query reason? Ideally we would avoid unnecessary prefixes, I think. |
The only KeyFormat that remains different from spec is clientState, which is stored under:
Didn't find a good way to conform to spec here since EDIT: Figured it out, the prefixes were added to allow for iteration over all channels, all packet commitments, all acknowledgements, etc. efficiently I took out the prefixes, and don't have an efficient way to iterate over these objects anymore without also iterating over many other objects that we're not trying to fetch. For example: With the prefix, iterating over channels is as simple as creating a However without the prefixes, there isn't a good way to do this apart from iterating over all objects that has a prefix channelPath, i.e. all channels, all channel capabilities, all sequences, ports, packet commitments, and acknowledgements This makes me lean towards keeping the prefixes, at least the ones on Channels, Ports, and Packets. |
Alright - thanks for the clarification; prefixes are fine as long as they are consistent - do you want to update the spec, or can you point me to where all of these are defined in the code & I can? |
They're defined here: https://github.com/cosmos/cosmos-sdk/blob/ibc-alpha/x/ibc/types/keys.go I can update them but currently busy with routing/dynamic capabilities. Think prefixes for the all the stuff in ICS4 makes a lot of sense. I don't think they should be numbers created by |
@AdityaSripal @ancazamfir I have updated ICS 24 in d107eb2, does that look accurate to you? However, I wonder if we should make these paths client-type-specific - there is no particular reason every Tendermint chain would need to use the same paths. |
Not sure I understand, would this be for all paths? And something different than store prefix? could you give an example? |
Perhaps it is simpler to standardise, but in principle the particular paths used for acknowledgements, packet commitments, etc. are unrelated to the light client validity predicate, so different Tendermint chains could use different paths (in addition to the store prefix being different), yes. |
Seems like the SDK implementation adds an extra prefix to paths after the store key but before the ICS24-specified path. Thanks @ancazamfir.
The text was updated successfully, but these errors were encountered: