IBC Classic 与 IBC v2 在链间发送和接收代币的核心业务逻辑大体保持不变。下面详细说明了一些需要特别注意的关键差异。

​
不再有通道握手、新的数据包格式与编码支持

  • IBC v2 不会通过通道握手在应用之间建立连接。通道标识符表示 Client ID，并包含在 Payload 中
    • 源端口和目标端口都必须是 "transfer"
    • 通道 ID 必须是有效的 client ID，格式为 {clientID}-{sequence}，例如 08-wasm-007
  • Payload 包含用于代币转账的 FungibleTokenPacketData。
下面的代码片段展示了 Payload 结构体。 
/ Payload contains the source and destination ports and payload for the application (version, encoding, raw bytes)

type Payload struct {
	/ specifies the source port of the packet, e.g. transfer
	SourcePort string `protobuf:"bytes,1,opt,name=source_port,json=sourcePort,proto3" json:"source_port,omitempty"`
	/ specifies the destination port of the packet, e.g. trasnfer
	DestinationPort string `protobuf:"bytes,2,opt,name=destination_port,json=destinationPort,proto3" json:"destination_port,omitempty"`
	/ version of the specified application
	Version string `protobuf:"bytes,3,opt,name=version,proto3" json:"version,omitempty"`
	/ the encoding used for the provided value, for transfer this could be JSON, protobuf or ABI
	Encoding string `protobuf:"bytes,4,opt,name=encoding,proto3" json:"encoding,omitempty"`
	/ the raw bytes for the payload.
	Value []byte `protobuf:"bytes,5,opt,name=value,proto3" json:"value,omitempty"`
}
下面的代码片段展示了代币转账时 Payload 字节内容的结构。 
/ FungibleTokenPacketData defines a struct for the packet payload
/ See FungibleTokenPacketData spec:
/ https://github.com/cosmos/ibc/tree/master/spec/app/ics-020-fungible-token-transfer#data-structures
type FungibleTokenPacketData struct {
	/ the token denomination to be transferred
	Denom string `protobuf:"bytes,1,opt,name=denom,proto3" json:"denom,omitempty"`
	/ the token amount to be transferred
	Amount string `protobuf:"bytes,2,opt,name=amount,proto3" json:"amount,omitempty"`
	/ the sender address
	Sender string `protobuf:"bytes,3,opt,name=sender,proto3" json:"sender,omitempty"`
	/ the recipient address on the destination chain
	Receiver string `protobuf:"bytes,4,opt,name=receiver,proto3" json:"receiver,omitempty"`
	/ optional memo
	Memo string `protobuf:"bytes,5,opt,name=memo,proto3" json:"memo,omitempty"`
}

​
基础 denom 不能包含斜杠

在新的 Denom 结构体中，基础 denom（例如 uatom）与 trace 分离；trace 表示该代币经过的路径。trace 以 Hop 数组的形式表示。 由于 IBC v2 不再使用通道，因此无法再依赖标识符的固定格式，所以不允许使用包含 / 的基础 denom。

​
应用模块接口的变化

IBC v2 不再通过 port.IBCModule 实现代币转账，而是使用新的应用接口 api.IBCModule。关于接口差异的更多信息，可参见应用章节。

​
MsgTransfer 入口点

为了继续支持大多数现有前端已集成的通用入口点，MsgTransfer 入口被保留了下来。 如果在 MsgTransfer 中将 clientID 用作 msg.SourceChannel，处理器会自动使用 IBC v2 协议。它会在内部调用 MsgSendPacket 端点，从而使所有 IBC v2 数据包在状态机中的执行流程保持一致，同时对用户仍然暴露相同的入口点。 当然，我们仍然希望保留在现有通道上发送 v2 数据包的能力。在 IBC v1 中，代币一旦离开原始链，其 denomination 会带上 port 和 channel ID 前缀。此外，用于托管原始代币的 transfer 托管账户也是根据 channel ID 生成的。因此，如果我们希望使用 IBC v2 与这些远端代币交互，仍然必须使用它们最初发送时所使用的 v1 通道标识符。 因此，MsgTransfer 新增了一个 UseAliasing 布尔字段，用于表示我们希望在继续使用旧 v1 通道标识符的同时启用 IBC v2 协议。这样一来，用户就可以在 IBC v2 协议下，继续使用与之前相同的 denomination 来与相同的代币、DEX 池以及跨链 DeFi 协议交互。要在启用 aliasing 的情况下使用 MsgTransfer，可以像下面这样提交消息： 
MsgTransfer{
    SourcePort:       "transfer",
    SourceChannel:    "channel-4", /note: we are using an existing v1 channel identiifer
	Token:            "uatom",
    Sender:           {
    senderAddr
},
    Receiver:         {
    receiverAddr
},
    TimeoutHeight:    ZeroHeight, / note: IBC v2 does not use timeout height
	TimeoutTimestamp: 100_000_000,
    Memo:             "",
    UseAliasing:      true, / set aliasing to true so the handler uses IBC v2 instead of IBC v1
}
Much of the core business logic of sending and recieving tokens between chains is unchanged between IBC Classic and IBC v2. Some of the key differences to pay attention to are detailed below.

​
No Channel Handshakes, New Packet Format and Encoding Support

  • IBC v2 does not establish connection between applications with a channel handshake. Channel identifiers represent Client IDs and are included in the Payload
    • The source and destination port must be "transfer"
    • The channel IDs must be valid client IDs of the format {clientID}-{sequence}, e.g. 08-wasm-007
  • The Payload contains the FungibleTokenPacketData for a token transfer.
The code snippet shows the Payload struct. 
/ Payload contains the source and destination ports and payload for the application (version, encoding, raw bytes)

type Payload struct {
	/ specifies the source port of the packet, e.g. transfer
	SourcePort string `protobuf:"bytes,1,opt,name=source_port,json=sourcePort,proto3" json:"source_port,omitempty"`
	/ specifies the destination port of the packet, e.g. trasnfer
	DestinationPort string `protobuf:"bytes,2,opt,name=destination_port,json=destinationPort,proto3" json:"destination_port,omitempty"`
	/ version of the specified application
	Version string `protobuf:"bytes,3,opt,name=version,proto3" json:"version,omitempty"`
	/ the encoding used for the provided value, for transfer this could be JSON, protobuf or ABI
	Encoding string `protobuf:"bytes,4,opt,name=encoding,proto3" json:"encoding,omitempty"`
	/ the raw bytes for the payload.
	Value []byte `protobuf:"bytes,5,opt,name=value,proto3" json:"value,omitempty"`
}
The code snippet shows the structure of the Payload bytes for token transfer 
/ FungibleTokenPacketData defines a struct for the packet payload
/ See FungibleTokenPacketData spec:
/ https://github.com/cosmos/ibc/tree/master/spec/app/ics-020-fungible-token-transfer#data-structures
type FungibleTokenPacketData struct {
	/ the token denomination to be transferred
	Denom string `protobuf:"bytes,1,opt,name=denom,proto3" json:"denom,omitempty"`
	/ the token amount to be transferred
	Amount string `protobuf:"bytes,2,opt,name=amount,proto3" json:"amount,omitempty"`
	/ the sender address
	Sender string `protobuf:"bytes,3,opt,name=sender,proto3" json:"sender,omitempty"`
	/ the recipient address on the destination chain
	Receiver string `protobuf:"bytes,4,opt,name=receiver,proto3" json:"receiver,omitempty"`
	/ optional memo
	Memo string `protobuf:"bytes,5,opt,name=memo,proto3" json:"memo,omitempty"`
}

​
Base Denoms cannot contain slashes

With the new Denom struct, the base denom, i.e. uatom, is seperated from the trace - the path the token has travelled. The trace is presented as an array of Hops. Because IBC v2 no longer uses channels, it is no longer possible to rely on a fixed format for an identifier so using a base denom that contains a ”/” is dissallowed.

​
Changes to the application module interface

Instead of implementing token transfer for port.IBCModule, IBC v2 uses the new application interface api.IBCModule. More information on the interface differences can be found in the application section.

​
MsgTransfer Entrypoint

The MsgTransfer entrypoint has been retained in order to retain support for the common entrypoint integrated in most existing frontends. If MsgTransfer is used with a clientID as the msg.SourceChannel then the handler will automatically use the IBC v2 protocol. It will internally call the MsgSendPacket endpoint so that the execution flow is the same in the state machine for all IBC v2 packets while still presenting the same endpoint for users. Of course, we want to still retain support for sending v2 packets on existing channels. The denominations of tokens once they leave the origin chain are prefixed by the port and channel ID in IBC v1. Moreover, the transfer escrow accounts holding the original tokens are generated from the channel IDs. Thus, if we wish to interact these remote tokens using IBC v2, we must still use the v1 channel identifiers that they were originally sent with. Thus, MsgTransfer has an additional UseAliasing boolean field to indicate that we wish to use IBC v2 protocol while still using the old v1 channel identifiers. This enables users to interact with the same tokens, DEX pools, and cross-chain DEFI protocols using the same denominations that they had previously with the IBC v2 protocol. To use the MsgTransfer with aliasing we can submit the message like so: 
MsgTransfer{
    SourcePort:       "transfer",
    SourceChannel:    "channel-4", /note: we are using an existing v1 channel identiifer
	Token:            "uatom",
    Sender:           {
    senderAddr
},
    Receiver:         {
    receiverAddr
},
    TimeoutHeight:    ZeroHeight, / note: IBC v2 does not use timeout height
	TimeoutTimestamp: 100_000_000,
    Memo:             "",
    UseAliasing:      true, / set aliasing to true so the handler uses IBC v2 instead of IBC v1
}