​
概述

本标准规定了端口分配系统，模块可通过该系统绑定到由 IBC 处理器分配的唯一命名端口。 数据包中的端口标识符定义了应将数据包回调路由到哪个应用。源 portID 是发送数据包的应用标识符，因此它也会接收 AcknowledgePacket 和 TimeoutPacket 回调。目标 portID 是接收数据包的应用标识符，并将接收 ReceivePacket 回调。 模块可以在一个状态机上注册多个端口，并可从其任意已注册端口向远程状态机上的任意端口发送数据。状态机上的每个端口都必须映射到由 ICS-26 定义的特定 IBC 模块。因此，IBC 应用到 portID 的映射关系是一对多。 注意：IBC v1 包含通道以及通道握手，用于在对手链的两个 portID 之间显式关联一个唯一通道。因此，两侧的 portID 是紧密耦合的，除了由这些 portID 绑定的应用之外，其他应用都不允许在该专用通道上发送数据包。IBC v2 移除了通道的概念，所有数据包流动都发生在链与链之间，而不再是隔离的模块到模块通信。因此，发送链上的一个应用可以通过在数据包中使用 portID 标识应用，向目标链上的任意其他应用发送数据包。因此，应用现在需要自行负责限制哪些应用被允许向其发送数据包，方法是在回调中检查 portID，并拒绝任何来自未授权应用的数据包。

​
动机

跨链通信协议旨在促进模块到模块的通信，其中模块是在主权账本上执行的、相互独立、可能彼此不信任、且自包含的代码单元。

​
技术规范

​
注册端口

IBC 处理器必须提供一种方式，使应用能够在某个 portID 上注册其回调。 
function registerPort(portId: Identifier, cbs: ICS26App) => void
RegisterPort 前置条件：
  • 对于给定的 portId，端口路由器上不存在其他已注册的应用。
RegisterPort 后置条件：
  • ICS26 应用已注册到提供的 portId 上。
  • 任何发往该 portId 的入站数据包流消息都会被路由到该 ICS26 应用。任何使用该 portId 作为地址的出站数据包流消息都必须来自该 ICS26 应用。

​
对数据包流消息进行认证与路由

一旦某个应用注册了端口，端口路由器就有责任根据负载中的 portId，将数据包流消息正确路由到相应的应用。同样，当应用向端口路由器发送数据包流消息时，路由器必须通过检查负载中的 portID 是否注册给该应用，来确保该应用已被认证并有权发送该数据包流消息。 对于数据包发送链上的数据包流消息（例如 SendPacket、AcknowledgePacket、TimeoutPacket），端口路由器必须使用数据包负载中的 sourcePortId 来完成此认证与路由。 对于数据包接收链上的数据包流消息（例如 RecvPacket 以及可选的异步 WriteAcknowledgement），端口路由器必须使用数据包负载中的 destPortId 来完成此认证与路由。 ICS-4 定义了数据包流消息以及各自处理器的预期行为。当数据包流消息从核心 ICS-4 处理器到达应用时（例如 RecvPacket、AcknowledgePacket、TimeoutPacket），portRouter 作为路由器，将消息从核心处理器路由到 ICS26 应用。当数据包流消息从应用到达核心 ICS-4 处理器时（例如 SendPacket，或可选的 WriteAcknowledgement），portRouter 则作为认证器，在将消息发送给 ICS-4 处理器之前，检查调用应用是否已注册为其希望使用的端口的所有者。 注意：实现可以调整执行流程的顺序，只要仍然遵守 ICS-4 中定义的所有预期语义和行为。在这种情况下，端口路由器作为路由器或认证器的角色也会相应变化。

​
Synopsis

This standard specifies the port allocation system by which modules can bind to uniquely named ports allocated by the IBC handler. The port identifiers in the packet defines which application to route the packet callback to. The source portID is an identifier of the application sending the packet, thus it will also receive the AcknowledgePacket and TimeoutPacket callback. The destination portID is the identifier of the application receiving the packet and will receive the ReceivePacket callback. Modules may register multiple ports on a state machine and send from any of their registered ports to any arbitrary port on a remote state machine. Each port on a state machine must be mapped to a specific IBC module as defined by ICS-26. Thus the IBC application to portID mapping is one-to-many. NOTE: IBC v1 included a channel along with a channel handshake that explicitly associated a unique channel between two portIDs on counterparty chains. Thus, the portIDs on both sides were tightly coupled such that no other application other than the ones bound by the portIDs were allowed to send packets on the dedicated channel. IBC v2 removed the concept of a channel and all packet flow is between chains rather than being isolated module-module communication. Thus, an application on a sending chain is allowed to send a packet to ANY other application on a destination chain by identifying the application with the portIDs in the packet. Thus, it is now the responsibility of applications to restrict which applications are allowed to send packets to them by checking the portID in the callback and rejecting any packet that comes from an unauthorized application.

​
Motivation

The interblockchain communication protocol is designed to facilitate module-to-module communication, where modules are independent, possibly mutually distrusted, self-contained elements of code executing on sovereign ledgers.

​
Technical Specification

​
Registering a port

The IBC handler MUST provide a way for applications to register their callbacks on a portID. 
function registerPort(portId: Identifier, cbs: ICS26App) => void
RegisterPort Preconditions:
  • There is no other application that is registered on the port router for the given portId.
RegisterPort Postconditions:
  • The ICS26 application is registered on the provided portId.
  • Any incoming packet flow message addressed to the portId is routed to the ICS26 application. Any outgoing packet flow message addressed by the portId MUST come from the ICS26 application

​
Authenticating and Routing Packet Flow Messages

Once an application is registered with a port, it is the port router’s responsibility to properly route packet flow messages to the appropriate application identified by the portId in the payload. Similarly when the application sends packet flow messages to the port router, the router MUST ensure that the application is authenticated to send the packet flow message by checking if the payload portIDs are registered to the application. For packet flow messages on the packet sending chain (e.g. SendPacket, AcknowledgePacket, TimeoutPacket); the port router MUST do this authentication and routing using the packet payload’s sourcePortId. For packet flow messages on the packet receiving chain (e.g. RecvPacket and optionally the asynchronous WriteAcknowledgement); the port router MUST do this authentication and routing using the packet payload’s destPortId. ICS-4 defines the packet flow messages and the expected behavior of their respected handlers. When the packet flow message arrives from the core ICS-4 handler to the application (e.g. RecvPacket, AcknowledgePacket, TimeoutPacket); then the portRouter acts as a router routing the message from the core handler to the ICS26 application. When the packet flow message arrives from the application to the core ICS-4 handler (e.g. SendPacket, or the optional WriteAcknowledgement); then the portRouter acts as an authenticator by checking that the calling application is registered as the owner of port they wish to send the message on before sending the message to the ICS-4 handler. NOTE: It is possible for implementations to change the order of execution flow so long as they still respect all the expected semantics and behavior defined in ICS-4. In this case, the port router’s role as router or authenticator will change accordingly.