As follow-up of the discussion about the usage of the enum for the encoding, I have been thinking about it, and I see security wise benefits of constraining the type of encoding to an agreed range of enums. As for flexibility, we can still easily extend this enum upon request. Thus, I am ok keeping it like it is.

I tend to agree!

Would it make sense to make the timeout field into opaque bytes that may be interpreted differently depending on the chain? This would allow the chain to pack different information with different encoding into the field. Some examples:

• Optionality with Option type in Rust.
• Packing of either or both timeout height and timeout timestamp.
• Using the DA or L1 params to determine timeout.

Ultimately, the semantics of the timeout is tightly coupled with the IBC client. So it would be better to allow the IBC client to customize it.

It could make sense. We are trying to strike a balance between flexibility and just choosing a sane default.

Our thinking was that timestamps are way easier to understand and interpret for users. And most chains can implement either through BFT time directly in their protocol or through a time oracle application.

Does this mean multiple Payloads are allowed in one packet? This seems like a completely different behavior as compared to v1. Is this meant to improve performance, or is it to enable new features for IBC applications? I'm not sure if this is meant to allow partial failure, or is it to make it act like an atomic transaction that would fail if either of the payload fail.

It is different behaviour. The point is to enable new features for IBC applications. A key usecase is transfer + ICA

We want to eventually allow either partial failure or full atomic packets.

However, for launch we will only allow a single payload in this list and enable multiple in a future release

Hmm makes sense. Now I get a better understanding behind the design rationale.

Though I wonder what is supposed to be the API for enabling multi-payload packets? For the example case where we want to include both transfer and ICA payloads, would it be triggered by a multi-message transaction that sends multiple messages to transfer and ICA separately? Does this means that the IBC stack needs to somehow wrap around the transaction engine, and build only one IBC packet per src/dst pair for the entire transaction? Or do we need separate message-level APIs for constructing multi-payload packets?

I'm not sure it is good to attach the encoding information to individual packet metadata. The payload encoding should be configured during the initialization of an IBC application, and stay the same with the same port.

Yes but two applications sitting on different chains may be initialized with two different encoding. For example, with solidity some encodings may be more efficient and preferred. In this case, a cosmos chain can use that encoding to speak to the application.

In general, we've run into a lot of problems with prenegotiated parameters (like the channel version) as they become quite complicated to renegotiate and change after the fact. And to also coordinate that change across all users synchronously. Having these parameters in the packet allows for very simply asynchronous migration. And if the encoding desired in the packet is not supported by the app, it just errors

Ok, so I suppose with this design, the user gets to instruct the sender application to use a different encoding depending on the counterparty chain.

Would it make sense to set this as a string field and use MIME to define the encoding? We already have standard MIME types such as application/json, text/plain, etc.

It is not clear what should be the semantics if the given source / destination identifiers are invalid. Should the transaction fail? Or which layer should produce the error acknowledgement?

This is equivalent to passing in an invalid channel ID in IBC v1. It would be a core error that just rejects the tx. Not an error acknowledgement

I'm not sure what is the use for the version field, and can't it be included within the appData itself if needed?

Even if we keep it, it may make sense to keep it as raw bytes as well.

It could, however this would require a significant change to the IBC apps to support it which i think we would like to avoid.

How would this allow backward compatibility, if existing IBC apps assume that the version stays the same after the handshake? Actually, I'm a bit confused of how classic IBC apps can be initialized, if we remove channel handshake?

I think we should note that the use of CBOR encoding is specific to Cosmos SDK chains with ibc-go implementation. During verification, we should pass the packet as a structured data to the IBC client, so that it can choose the appropriate way to encode and verify the packet commitment on the counterparty chain.

No unfortunately the commitment has to be exactly the same across all chans so we must all agree at least on the commitment paths and the commitment values

If the implementation is using CBOR, why not also use that to encode the timeout field?

Would it make sense to rename this to nonce, and also allow bytes? It seems to me that the only purpose remaining for channels is to prevent replay attack.

Perhaps sequence would still make sense if we add back ordered channel later on. But I also can't see how ordered channel could work with a packet design that allows multiple ports and payloads.

Yes, we could do it this way.

What is the semantics of allowing different combinations of source and destination ports? Should it require a definite binding between the source port and destination port, or should each combination of source/destination port be identified uniquely?

Really all that matters is the portID on your side generally speaking. In case you want a strict mapping from your portID to counterparty portID that must be enforced in the application

I am still a bit confused on how the pairing would work, if there is no handshake and any application can send packet to any other application. It seems like we would need to take both the source and destination identifier pair as unique identification.

As an example, if we have two IBC transfer packets transfer-v1 -> transfer and transfer-v2 -> transfer, they should mint different denoms even when the destination port are the same.

I think it also probably make sense to call this an application identifier instead of calling it port. My understanding is that one application identifier is intended to be used for handling all packets of the same use case. So for example, there should be just one transfer or interchain-account identifier for all the respective packets, correct?

I think I also prefer referring to this as Application rather than port.

As far as I see, with this new packet structure, we’re no longer backward compatible with IBC v1. We can still reuse the same identifiers and sequence numbers from the v1 channel to create v2 packets and send them to the IBC v2 handlers. However, when IBC v2 interacts with applications, the callback functions still depend on the v1 packet structure. What’s the reasoning behind this? Is this implicitly requiring implementations now treat the packet field in callbacks as abstract and opaque, or has backward compatibility been dropped as a requirement for v2?

Backwards compatibility is not a strict requirement. We might break the application interfaces for the callback though their general expected behaviour can remain the same

Once two chains connected, by providing the destIdentifier, the IBC core should be able to retrieve the sourceIdentifier from storage and determine its value. Isn’t requiring this info unnecessary? After all, the sourceIdentifier linked to a destIdentifier will have to be stored anyway so that can perform a sanity check.

On the source chain there is a map from sourceId -> destId and vice versa.

But the source chain does not have a map destId -> sourceId because a counterparty's id for us is not unique from our perspective. So we do need the sourceId in the packet if we are going to use it on acknowledgement/timeout to retrieve the correct information

Are the source and destination identifiers supposed to be used like client ID or channel ID? If there are two separate IBC clients A1 and A2 created on Chain A for Chain B, can they both be used to send packets to the same IBC client B on chain B?

My feeling is that this should be possible, as otherwise we would need to perform redundant client updates. But to allow this, either we have to introduce something like channel ID as an indirection, or the chain should use both source and destination identifiers to form a unique pairing, and use it for nonce verification and sandboxing.

Doesn't this open the door to a DoS attack through payload flooding? Shouldn't hosts consider a cap for that, depending on their characteristics?

I think we should think about DoS prevention at the full packet level, rather than the individual fields. An IBC packet should be encoded into a reasonable size when submitted as a ReceivePacket message to a chain. A chain may reject an IBC packet that is too large, or more sensibly the message handling would simply runs out of gas. Within that size limit, any field within the packet would also not exceed that size, so it can be reasonably handled, even if it is unusually larger than it usually should.

An application should not assume that an IBC packet can always be successfully relayed to a counterparty chain. Aside from the packet size, there are many ways the packet may fail, such as when there are malformed packet data, or when errors occurred when an application is processing the packet. Aside from that, a relayer should set their own limit of how large an IBC packet they are willing to relay, or how many retries they should make, so that it would not indefinitely try to relay a malformed packet. In general, a chain may contain arbitrary state machine logic that allows it to craft bad IBC packets. So neither the relayer nor the counterparty chain should trust that the packet is always wellformed.

We are only allowing single payload for now in ibc-go

Implementations should probably have a total packet size cap. And indeed relayers should also do this

On a more general note, I suggest we be very cautious about imposing string types at the protocol level. This can become costly in resource-limited environments like smart contracts. One field might not have a huge impact, though not being careful and leaving strings scattered throughout different data structures can increase memory allocations and overall costs due to operations like parsing.

Is it ok if there's just an equality check on the whole string? Even if we aren't parsing the internal details of the string

It helps a lot, but there is a cost to those as well.

To quickly illustrate with a dummy contract I wrote and tested in Remix:

// SPDX-License-Identifier: MIT
pragma solidity ^0.8.20;

enum MimeType {
    JSON,
    PROTOBUF
}

contract GasTest {

    function stringEqualityCheck(string calldata encodingType) public pure returns (bool) {
        return keccak256(abi.encodePacked(encodingType)) == keccak256(abi.encodePacked("application/json"));
    }

    function enumEqualityCheck(MimeType encodingType) public pure returns (bool) {
        return encodingType == MimeType.JSON;
    }
}

The cost was 1327 and 593 for the string and enum check respectively.

Isn't it restrictive to define the timeout as only a UNIX timestamp? Was there a specific reason we're no longer allowing timeout height?

Unnecessary and unintuitive

With this definition, each port ID corresponds to a single application. I wonder how this applies to cases like ICS-27, where one app manages multiple ports. It would be helpful to clarify this relationship somewhere.

There is a mapping from portID to app. So multiple portIDs can map to the same application

Should this be an enum for efficiency or something more like string for flexibility?

Interpet this as seconds on receiver block time.

Reject timeouts that are too far in future in implementations (ibc-go) to ensure nanoseconds don't accidentally get interpreted as seconds

I think we should make the format of failure acknowledgement explicit. Regardless of which part of the IBC stack failed, the error should be formatted in a way that is standard for relayers and middlewares to understand. This would help in diagnostics for failures.

What is the semantics if the acknowledgement list has a different size than the original payloads count? If there are less, do the application receive a default sentinel ack? If there are more, do the extra acks get ignored?

Is the handling of acks meant to be also atomic, similar to receiving packets? If one of the ack processing failed, how would it affect other ack handlers? Similarly, how do we handle timeouts if one of the application handler failed?

Do we need to lower the protocol assumption, so that applications are designed to handle the case when neither ack nor timeout is called for a packet?

I think that an acknowledgement should be rejected if if it has a different size than the original payload count. I believe it would fail during packet acknowledgement verification if this was the case anyway.

Regarding atomicity, my understanding of how this should work is that they are not atomic, (we could have some failures and some successes, they would not all share the same result).

However I think if a single application was async, the sending chain should be able to acknowledge the acknowledgement until all async acks have been written. (The receiving chain would not write the acknowledgement until the final application has written the async ack)

I think that an acknowledgement should be rejected if if it has a different size than the original payload count. I believe it would fail during packet acknowledgement verification if this was the case anyway.

Regarding atomicity, my understanding of how this should work is that they are not atomic, (we could have some failures and some successes, they would not all share the same result).

However I think if a single application was async, the sending chain should be able to acknowledge the acknowledgement until all async acks have been written. (The receiving chain would not write the acknowledgement until the final application has written the async ack)

regarding the [bytes] type, for the appAcknowledgement, is it necessary to be pure bytes? Would there be a benefit to some sort of enum e.g. Failure,Success,Async,Sentinel/NOOP ?

EDIT: I noticed soareschen mentioned a point about an explicit format, I guess this is the same point.

I think I also prefer referring to this as Application rather than port.

I tend to agree!