Interchain Accounts 仅兼容 IBC Classic，不兼容 IBC v2
什么是 Interchain Accounts 模块？
Interchain Accounts 是 ICS-27 协议在 Cosmos SDK 中的实现，使基于 IBC 的跨链账户管理成为可能。
普通账户使用私钥对交易进行签名。而 Interchain Accounts 则由对手链通过 IBC 数据包以编程方式进行控制。
Host Chain：注册跨链账户的链。主机链会监听来自控制链的 IBC 数据包，其中应包含该跨链账户将要执行的指令（例如 Cosmos SDK 消息）。
Controller Chain：在主机链上注册并控制账户的链。控制链通过向主机链发送 IBC 数据包来控制该账户。
Interchain Account：使用 ICS-27 协议在主机链上创建的账户。跨链账户具备普通账户的全部能力。但它不是通过私钥签名交易，而是由控制链向主机链发送 IBC 数据包，以指示该跨链账户应执行哪些交易。
Authentication Module：控制链上的一个自定义应用模块，使用 Interchain Accounts 模块来构建跨链账户创建与管理的自定义逻辑。它既可以是一个使用旧版 API的 IBC 应用模块，也可以是一个常规的 Cosmos SDK 应用模块，通过向控制器子模块的 MsgServer 发送消息来工作（如果不需要访问数据包回调，这是从 ibc-go v6 开始推荐的方式）。请注意，旧版 API 最终将被移除，后续版本中的 IBC 应用将无法再使用它们。
SDK 安全模型
链上的 SDK 模块默认被视为可信。例如，没有任何检查来阻止不可信模块访问 bank keeper。
ibc-go 中对 ICS-27 的实现，在安全性考量中使用了这一假设。
该实现还假设其他 IBC 应用模块不会绑定到 ICS-27 命名空间中的端口。
通道关闭
提供的跨链账户 host 和 controller 实现不支持 ChanCloseInit，但支持 ChanCloseConfirm。
这意味着 host 和 controller 模块无法主动关闭通道，但会确认由其他 ICS-27 实现发起的通道关闭。
在通道关闭的情况下（例如，有序通道中的数据包超时），如果随后创建了一个新通道，并且其版本字符串采用 JSON 格式编码了与前一个通道完全相同的 Metadata 信息，那么与该通道关联的跨链账户可以再次变为可访问状态。该通道可以通过 MsgRegisterInterchainAccount 或 MsgChannelOpenInit 重新打开。如果使用 MsgRegisterInterchainAccount，则可以将消息中的 version 字段留空，因为控制器子模块会自动填充它。如果使用 MsgChannelOpenInit，则必须在 version 字段中提供正确的 JSON 编码 Metadata 字符串。更多信息请参见 Understanding Active Channels 一节。
使用默认 controller 子模块重新打开通道时，无法更改该通道的排序方式。
Interchain Accounts is only compatible with IBC Classic, not IBC v2
Synopsis
Learn about what the Interchain Accounts module is
What is the Interchain Accounts module?
Interchain Accounts is the Cosmos SDK implementation of the ICS-27 protocol, which enables cross-chain account management built upon IBC.
- How does an interchain account differ from a regular account?
Regular accounts use a private key to sign transactions. Interchain Accounts are instead controlled programmatically by counterparty chains via IBC packets.
Concepts
Host Chain: The chain where the interchain account is registered. The host chain listens for IBC packets from a controller chain which should contain instructions (e.g. Cosmos SDK messages) for which the interchain account will execute.
Controller Chain: The chain registering and controlling an account on a host chain. The controller chain sends IBC packets to the host chain to control the account.
Interchain Account: An account on a host chain created using the ICS-27 protocol. An interchain account has all the capabilities of a normal account. However, rather than signing transactions with a private key, a controller chain will send IBC packets to the host chain which signals what transactions the interchain account should execute.
Authentication Module: A custom application module on the controller chain that uses the Interchain Accounts module to build custom logic for the creation & management of interchain accounts. It can be either an IBC application module using the legacy API, or a regular Cosmos SDK application module sending messages to the controller submodule’s MsgServer (this is the recommended approach from ibc-go v6 if access to packet callbacks is not needed). Please note that the legacy API will eventually be removed and IBC applications will not be able to use them in later releases.
SDK security model
SDK modules on a chain are assumed to be trustworthy. For example, there are no checks to prevent an untrustworthy module from accessing the bank keeper.
The implementation of ICS-27 in ibc-go uses this assumption in its security considerations.
The implementation assumes other IBC application modules will not bind to ports within the ICS-27 namespace.
Channel Closure
The provided interchain account host and controller implementations do not support ChanCloseInit. However, they do support ChanCloseConfirm.
This means that the host and controller modules cannot close channels, but they will confirm channel closures initiated by other implementations of ICS-27.
In the event of a channel closing (due to a packet timeout in an ordered channel, for example), the interchain account associated with that channel can become accessible again if a new channel is created with a (JSON-formatted) version string that encodes the exact same Metadata information of the previous channel. The channel can be reopened using either MsgRegisterInterchainAccount or MsgChannelOpenInit. If MsgRegisterInterchainAccount is used, then it is possible to leave the version field of the message empty, since it will be filled in by the controller submodule. If MsgChannelOpenInit is used, then the version field must be provided with the correct JSON-encoded Metadata string. See section Understanding Active Channels for more information.
When reopening a channel with the default controller submodule, the ordering of the channel cannot be changed.
