ICS24: Restructure provable packet keys #1155
Merged
+15
−13
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
damiannolan
approved these changes
Oct 28, 2024
4 tasks
gjermundgaraba
approved these changes
Oct 28, 2024
sangier
approved these changes
Oct 28, 2024
soareschen
reviewed
Oct 28, 2024
| | -------------- | ------------------------------------------------- | ---------- | ------------------------------------ | | ||
| | 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) | |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
Indeed, the one concern I had was that it could be easy to mess up in the future
AdityaSripal
added a commit
that referenced
this pull request
Mar 26, 2025
* add v2 folder * create structure and paste v1 specs for now * TAO V2 support in 07 client (#1137) * deprecate delay period params * add params into clientState * fix comment * include PR link in history * fixes * fix comment * fix modified field * Copied README.md to v2/ while preserving history * Reverted README.md to commit 825d47d * fix deadlinks * rm v1 deprecation references * del v2 folder and readme * cp v1 spec into TAO_V1_README * apply v2 changes * fix dead links * fix deadlinks 2 * fix image links * fixes * fixes * fix link to v2 version --------- Co-authored-by: Stefano Angieri <stefano@interchain.io> * 02-client-TAOv2 (#1147) * rm delayPeriods * add msg and hanlder * fixes * del things * fix order * typos * review comments --------- Co-authored-by: Stefano Angieri <stefano@interchain.io> * 24-host: Reduce provable surface area to only packet flow keys (#1144) * start 24-host by removing unnecessary requirements and moving some provable keys to private keys * fix layout rendering * fix links * address Stefano's comments * high level path space and commitment specification --------- Co-authored-by: Carlos Rodriguez <carlos@interchain.io> * 04-Packet-Flow-v2 (#1148) * start removing channel refs * add counterparty refs * introducing multi-packet data structure * add multi-data packet * introduce packet handlers * send packet handl * change packet commitment paths * fix paths * mod sendPacket * mod receive * allign with new packet structure * mod ack and paths * change counterparty def * discussions-related-fixes * add sketch packet flow * rework + ack logic * fixes + timeout logic * start addressing review * addressing review comments * fixes * client-creation-registration * ante-error-post conditions sendPacket * fixes * handlers pre-error-post conditions * fixes * add mermaid diagrams, fixes * router fixes * improvements and fixes * minor fix * improvements * adding considerations * add condition table * change condition table format * multi-payload,paths,router,acks fixes * improve createClient conditions * table fix * registerChannel table * fixes * improvements * fixes * setup fixes * diagram fixes * fix diagram * test fix * two and three step setup * send-receive conditions * router fixes * createChannl conditions * register table fixes * conditions tables * table fixes * self review * self review * add soundness and correctness * self review * self review * fixes * minor fixes * rename folder * polish * change registerChannel to registerCounterparty * Apply suggestions from code review Co-authored-by: Aditya <14364734+AdityaSripal@users.noreply.github.com> * address review comments * rm counterparty channel id check in send packet * mod writeAck function * delete packet once async ack has been written * fix callbacks * fixes * fix mermaid * rm relayer from SendPack * Apply suggestions from code review --------- Co-authored-by: Aditya <14364734+AdityaSripal@users.noreply.github.com> * ics20-tao-v2-support (#1157) * start v2 changes * mod onRecv callback * mod revert,refund * wip refactor * wip-packet-reasoning * callbacks interface update * fixes * v2Tao support in v1 * Apply suggestions from code review Co-authored-by: Aditya <14364734+AdityaSripal@users.noreply.github.com> * fix sequence type * unrmarshal utility function * fix write ack * fix revertInFlightsChanges * fixes * rm relayer from onSend * Apply suggestions from code review --------- Co-authored-by: Aditya <14364734+AdityaSripal@users.noreply.github.com> * ICS24: Restructure provable packet keys (#1155) * imp: note that commitments must be lexographically ordered to maintain soundness (#1153) * restructure ibc keys * add value instead of redundant provable store column * chore: remove myself as codeowner (#1156) * Fix variable name (#1162) * fix link and put new provable keys into 04-channel spec --------- Co-authored-by: colin axnér <25233464+colin-axner@users.noreply.github.com> Co-authored-by: Christoph Otter <chipshort@tutanota.com> * add timeoutTimestamp in forwarding (#1163) * Packet Spec: Hash App data rather than standardizing encoding (#1152) * add packet and acknowledgement structs and commitment details * add CBOR as suggested encoding and SENTINEL_ACKNOWLEDGEMENT value * explain each field in the code * change id to channel * switch cbor encoding to hashing in packet commitment * switch cbor encoding to hashing in acknowledgement * Apply suggestions from code review Co-authored-by: sangier <45793271+sangier@users.noreply.github.com> * add recursive hashing suggestion from amulet * prepend protocol byte --------- Co-authored-by: sangier <45793271+sangier@users.noreply.github.com> * Move PACKET.md (#1166) * move PACKET.md to the right folder * linter * linter * ICS4: Create 32 byte commitment (#1168) * move protocol version inside final hash * Update spec/core/v2/ics-004-packet-semantics/PACKET.md Co-authored-by: DimitrisJim <d.f.hilliard@gmail.com> --------- Co-authored-by: DimitrisJim <d.f.hilliard@gmail.com> * ICS4: Event Emission Specification (NO PSEUDOCODE) (#1172) * event specification * specify events for channel creation * add client id to register counterparty events * rename emitLogEntry to emitEvents * address reviews * fix typo * remove explicit event implementation and include event writeup on what should be included * continue changes * add packet handler to v2 spec * move to v2 folder in top-level spec * simplify the spec * rename folder for more visibility * specify client handler specification * cleanup ICS-2 and start with ICS24 * ics5 port specification * halfway through ICS26 * specify packet callbacks * move folders to core * fix table * write overview doc * add link to payload docs * header corrections * address marius reviews and lint lists * revert non-core changes * revert client changes * satisfy linter * fix links * fix more linting issues * lint --------- Co-authored-by: sangier <45793271+sangier@users.noreply.github.com> Co-authored-by: Stefano Angieri <stefano@interchain.io> Co-authored-by: Carlos Rodriguez <carlos@interchain.io> Co-authored-by: colin axnér <25233464+colin-axner@users.noreply.github.com> Co-authored-by: Christoph Otter <chipshort@tutanota.com> Co-authored-by: DimitrisJim <d.f.hilliard@gmail.com>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
These keys are now less verbose and also keys being proved on the same channel will be closer together in the tree since we key first on channelID. This will improve efficiency when we implement batching