Skip to content
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

ICS24: Restructure provable packet keys #1155

Merged
merged 8 commits into from
Nov 6, 2024
Prev Previous commit
Next Next commit
restructure ibc keys
  • Loading branch information
AdityaSripal committed Oct 25, 2024
commit 6e51b71f83b3e60c119bd760f61bc232c5fc478a
10 changes: 5 additions & 5 deletions spec/core/v2/ics-024-host-requirements/README.md
Original file line number Diff line number Diff line change
Expand Up @@ -110,11 +110,11 @@ IBC/TAO implementations MUST implement the following paths for the `provableStor
Future paths may be used in future versions of the protocol, so the entire key-space in the provable store MUST be reserved for the IBC handler.


| Store | Path format | Value type | Defined in |
| -------------- | -------------------------------------------------------------------------- | ----------------- | ---------------------- |
| provableStore | "commitments/channels/{identifier}/sequences/{bigEndianUint64Sequence}" | bytes | [ICS 4](../ics-004-packet-semantics) |
| provableStore | "receipts/channels/{identifier}/sequences/{bigEndianUint64Sequence}" | bytes | [ICS 4](../ics-004-packet-semantics) |
| provableStore | "acks/channels/{identifier}/sequences/{bigEndianUint64Sequence}" | bytes | [ICS 4](../ics-004-packet-semantics) |
| Store | Path format | Value type | Defined in |
| -------------- | ------------------------------------------------- | ---------- | ------------------------------------ |
| provableStore | {channelIdentifier}|0x1|{bigEndianUint64Sequence} | bytes | [ICS 4](../ics-004-packet-semantics) |
| provableStore | {channelIdentifier}|0x2|{bigEndianUint64Sequence} | bytes | [ICS 4](../ics-004-packet-semantics) |
| provableStore | {channelIdentifier}|0x3|{bigEndianUint64Sequence} | bytes | [ICS 4](../ics-004-packet-semantics) |

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think you need a length prefix, or it would be vulnerable to ambiguous encoding.

Also, can't we extend the IBC client API with 3 methods with explicit parameters, so that it can verify the commitment in different ways? The IBC client API don't really need a general method to verify all possible blockchain commitments. Also, not all blockchains need to store commitments in a flattened Merkle store. They may be stored in more efficient or more secure ways, e.g. nested Merkle trees or ZK storage proofs.

For backward compatibility, we can just wrap the legacy IBC clients, and use the encoding scheme verified here to verify the IBC commitments.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hmm this is a good point though I don't think there actually is an ambiguous encoding. Since we are creating the key out of 3 components. The channelId, the byte identifying which value type we're storing, and the big endian sequence.

The last two components have a standardized length. So it is only the channel ID that has a variable length.

Thus, i don't think it is possible to construct two channelID, value type, sequence tuples that would yield the same key. Please correct me if I'm mistaken

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Oh right, it is not ambiguous because u64 is fixed size. Though I think it is tricky to reason about ambiguity depending on whether the subsequent fields are fixed size. It would also become ambiguous in case if we generalize sequence in the future to allow variable-length nonce bytes.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Indeed, the one concern I had was that it could be easy to mess up in the future


### Provable Commitments

Expand Down