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: Standardize Packet, Acknowledgement, and Receipt commitments #1145

Open
AdityaSripal opened this issue Sep 2, 2024 · 1 comment
Open
Assignees
Labels
feat/eureka v2 TAO specification

Comments

@AdityaSripal
Copy link
Member

Originally the details of how to commit the packet, acknowledgement and receipt were in ICS4. However, we want to place all of the cross-implementation requirements of IBC into a single specification ICS24.

The only requirements IBC makes is a provable key/value store; and the ability to submit executable messages that will conditionally write to that key/value store after performing some logic.

IBC then uses these two key pieces to communicate with its counterparty through packets, acknowledgements, and receipts. These are stored in the provable key value store, and proven by counterparties in order to send and authenticate cross-chain messages.

Since the key/values for packets, acknowledgements, and receipts are the only parts of IBC that are expected to be exact across IBC chains and implementations they must be standardized and kept together in the same specification for quick reference.

The keys are already housed in ICS24 thus we will also store the expected values in this specification.

Packet Commitment: This commitment will require the most discussion as it contains many fields that need to be processed by core IBC. We need to come to agreement on which fields are going to be committed to in the packet, how they will be represented and marshalled, and how all the fields together will be hashed to form a binding, unique, canonical commitment.

Packet Acknowledgement: The acknowledgement at the moment is not acted upon by core IBC handlers at all. It is simply passed to the application. Thus, it is currently simply a hash of the bytes being passed to and interpreted by the application. This may change along with changes to the packet structure and packet commitment.

Packet Receipt: This is the simplest. It just needs to be non-empty. In the case where the implementation cannot support non-inclusion proofs; then it may be more complicated

@AdityaSripal AdityaSripal self-assigned this Sep 2, 2024
@AdityaSripal
Copy link
Member Author

This is a core change to IBC and must get feedback from both experts in commitment structures as well as potential users to ensure the commitments are secure, sound, and easily implementable across multiple platforms.

@AdityaSripal AdityaSripal added the feat/eureka v2 TAO specification label Sep 2, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
feat/eureka v2 TAO specification
Projects
Status: No status
Development

No branches or pull requests

1 participant