ICS24: Standardize Packet, Acknowledgement, and Receipt commitments

[AdityaSripal]

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]

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.