Support a packet commitment structure which contains multiple packet data's

[colin-axner]

Create a spec requirement for sending packets with multiple packet data's as outlined cosmos/ibc-go#7008

The spec should also indicate how a packet be self introspected to determine if it contains a multi-packetdata data. This may be through:

• the port ID
• a protocol version (relayer provided)

[colin-axner]

This issue relates to #1140, specifically:

Specify and explain new packet structure (including multidata)
Specify and explain new acknowledgment structure (including metadata)

Usage

We have a few goals here:

• supporting multi app data structures
• not imposing timeout height legacy usage
• no dependency on protobuf
• ensuring future flexibility in adjusting the packet commitment structure (adding additional features/options)

One future feature which we can already see desirability for is conditional packets. That is, the ability to indicate the packet data's should be executed in strict ordering and maintain interdependency (that is, if a packet data in a chain of packet data fails, revert the entire execution flow).

problem/solution discussion

Lets define the packet v2 structure as something like:

message Packet {
    uint64              sequence       = 1;
    string              source_id      = 2;
    string              destination_id = 3;
    string              timeout        = 4;
    repeated PacketData data           = 5;
}

where the PacketData type encapsulates the source port, the destination port, the version, and encoding of the data.

Packets need a source identifier and a destination identifer for sending and delivery. They need timeout information and they need a unique identifier to represent them (the id + sequence tuple depending on the reference point). Finally they need a payload, or data to be delivered at the application layer.

The key path for the packet commitment should include: source_id and the sequence. That means our packet commitment must contain: destination_id, timeout, data.

With regards to the timeout. We currently support timeout_timestamp and timeout_height, but it is up to ibc implementations to define their own timeout concept, as it tends to be very chain specific. We can achieve this by allowing the timeout to be a string value which is interpreted by the ibc implementation on the receiving side, and the light client on the source side (see cosmos/ibc-go#7055 for difficulty in core ibc interpreting timeout values on behalf of clients on source side). In addition, for v2 packets, we should enforce usage of a single timeout value (in ibc-go, only allow a timestamp or height, but not both)

I would like to provide a starting point for discussion:

Here we would hash the final buffer before setting the packet commitment

Pros:

• supporting multi app data structures
• not imposing timeout height legacy usage
• length restrictions for each slot
• no dependency on protobuf

Cons:

• a lot of hashing, linear with packet data's

If we wanted to extend this packet commitment structure, I imagine we could insert an "options" section which can also be length prefixed. This might indicate additional processing for the packet like if it should be conditionally processed, or perhaps if the results of the packet processing should be passed to another actor (contract).

I'd like to also note, if we wanted to protect the commitment structure even further, we could prefix the final commitment hash with the protocol version it used to generate the commitment. In this case, we could set the final commitment as byte(2) + packet_commitment

---

Acknolwedgement commitment

We have similar goals for generating the acknowledgement commitment. Currently we just hash the acknowledgement data. It's not very clear how to structure the acknowledgement commitment. Another goal with acknowledgements we should support are one-sided application, the ability for a single side to add a ibc application which the counterparty can send data to.

A good example would be if the receiving chain adds a new ibc module. The sender side may not have added it, but may want to interact with it by sending it data from the source chain. In this case, the packet data is specified only for the destination port (source port is left empty). There is no reason for the destination chain to write an acknowledgement for the source side to interact with (as no processing should occur, source port was left empty).

1. When a packet data is one sided, should we include no-op acks, or skip over these entries?
2. Based on the question above, should we length prefix the acknowledgements?

Otherwise, I think it'd be natural to say the acknowledgement should be stored under a key that contains the destination_id and sequence and which has a value which is a loop over a hash of each ack which should be relayed back to the source chain