​
变更记录

  • 07-09-2022：初始草案

​
状态

已接受，并已在 ibc-go v6 中实现

​
背景

ICS 27（Interchain Accounts）引入了一个构建在 IBC 之上的跨链账户管理协议。 它使链能够以编程方式代表对端链创建账户，并可为该跨链账户启用多种认证方式。 ICS 27 的初始版本重点支持那些可能不需要使用私钥签名的认证方案，例如通过治理等链上机制进行认证。 在 ICS 27 初始版本发布后，很明显出现了以下需求：
  • 提供默认认证模块将促进 ICS 27 的使用
  • 通用认证模块应能够对跨链账户注册进行认证
  • 封装 ICS 27 数据包发送的应用逻辑不需要与认证逻辑关联

​
决策

控制器模块应被简化，以移除跨链账户认证逻辑与跨链账户应用逻辑之间的关联。 为尽量减少对基于 ICS 27 控制器模块原始设计进行开发的开发者造成的影响，所有变更都将以向后兼容的方式进行。

​
Msg server

为实现这一点，正如 @damiannolan 所述，提议：
向 27-interchain-accounts 添加一个新的 MsgServer，暴露两个彼此独立的 RPC 端点：
  • RegisterInterchainAccount
  • SendTx
这将使任何 SDK（认证）模块都能够注册跨链账户，并代表这些账户发送交易。 可从这一变更中受益的现有 SDK 模块示例包括：
  • x/auth
  • x/gov
  • x/group
现有的 Go 函数 RegisterInterchainAccount() 和 SendTx() 将保留，并继续按照此前发布版本中的方式运行。 这将适用于 SDK v0.46.x 及以上版本。

​
允许底层应用为 nil

认证模块应通过消息服务器与控制器模块交互，而不应与应用逻辑关联。 目前，将允许把底层应用设置为 nil。 未来版本可能会完全移除底层应用。 参见 issue #2040

​
通道 capability 认领

控制器模块现在将在 OnChanOpenInit 中认领通道 capability。 底层应用在 OnChanOpenInit 中将收到一个 nil capability。 通道 capability 迁移将分两步加入：
  • 升级处理器迁移：将通道 capability 的所有者从底层应用改为控制器模块
  • ICS 27 模块自动迁移：断言升级处理器的通道 capability 迁移已成功执行
参见 issue #2033

​
启用中间件的通道

为保持向后兼容，并避免要求底层应用开发者处理那些并非由其注册的跨链账户，现已增加一个布尔映射，用于跟踪账户的创建方式所对应的行为。 如果账户是通过旧版 API 创建的，则会执行底层应用回调。 如果账户是通过新 API（消息服务器）创建的，则不会执行底层应用回调。 参见 issue #2145

​
未来考量

ADR 008 提议创建一种中间件，使 IBC 数据包发送的调用方能够与 IBC 应用配合执行应用逻辑。 一旦此类中间件可用，就可以移除底层应用，因为那将成为在 ICS 27 数据包发送时执行应用逻辑的首选方式。

​
杂项

为避免导入循环，genesis 类型已被移动到单独的目录中。 同时为 genesis 类型创建了一个新的 protobuf 包。 参见 PR #2133 已向 ActiveChannel 类型新增一个字段，用于在 genesis 导入/导出时存储 IsMiddlewareEnabled 字段。 参见 issue #2165

​
后果

​
正面

  • 提供了默认认证模块（x/auth、x/group、x/gov）
  • 现在任何 SDK 认证模块都可与 ICS 27 一起使用
  • 实现了与 ICS 27 相关的认证逻辑与应用逻辑分离
  • 尽量减少了对现有 ICS 27 控制器模块开发工作的干扰
  • 底层应用不再需要处理 capability
  • 在 ADR 008 创建后，可以以最小干扰的方式移除底层应用
  • 只有注册了该跨链账户的底层应用才会为该账户执行应用逻辑（底层应用无需感知那些并非由其注册的账户）

​
负面

  • 安全模型已降低为 SDK 的安全模型。SDK 模块可以为任意跨链账户发送数据包。
  • 需要额外维护新增的消息以及中间件启用标志
  • 将成为 ADR 008 模块的底层应用不需要感知那些并非由其注册的账户
  • 调用旧版 API 与新 API 会导致具有底层应用的 ICS 27 应用栈表现出不同的行为

​
中性

  • 需要一次主版本发布

​
Changelog

  • 07-09-2022: Initial draft

​
Status

Accepted, implemented in v6 of ibc-go

​
Context

ICS 27 (Interchain Accounts) brought a cross-chain account management protocol built upon IBC. It enabled chains to programmatically create accounts on behalf of counterparty chains which may enable a variety of authentication methods for this interchain account. The initial release of ICS 27 focused on enabling authentication schemes that may not require signing with a private key, such as via on-chain mechanisms like governance. Following the initial release of ICS 27 it became evident that:
  • a default authentication module would enable more usage of ICS 27
  • generic authentication modules should be capable of authenticating an interchain account registration
  • application logic which wraps ICS 27 packet sends does not need to be associated with the authentication logic

​
Decision

The controller module should be simplified to remove the correlation between the authentication logic for an interchain account and the application logic for an interchain account. To minimize disruption to developers working on the original design of the ICS 27 controller module, all changes will be made in a backwards compatible fashion.

​
Msg server

To achieve this, as stated by @damiannolan, it was proposed to:
Add a new MsgServer to 27-interchain-accounts which exposes two distinct rpc endpoints:
  • RegisterInterchainAccount
  • SendTx
This will enable any SDK (authentication) module to register interchain accounts and send transactions on their behalf. Examples of existing SDK modules which would benefit from this change include:
  • x/auth
  • x/gov
  • x/group
The existing go functions: RegisterInterchainAccount() and SendTx() will remain to operate as they did in previous release versions. This will be possible for SDK v0.46.x and above.

​
Allow nil underlying applications

Authentication modules should interact with the controller module via the message server and should not be associated with application logic. For now, it will be allowed to set a nil underlying application. A future version may remove the underlying application entirely. See issue #2040

​
Channel capability claiming

The controller module will now claim the channel capability in OnChanOpenInit. Underlying applications will be passed a nil capability in OnChanOpenInit. Channel capability migrations will be added in two steps:
  • Upgrade handler migration which modifies the channel capability owner from the underlying app to the controller module
  • ICS 27 module automatic migration which asserts the upgrade handler channel capability migration has been performed successfully
See issue #2033

​
Middleware enabled channels

In order to maintain backwards compatibility and avoid requiring underlying application developers to account for interchain accounts they did not register, a boolean mapping has been added to track the behaviour of how an account was created. If the account was created via the legacy API, then the underlying application callbacks will be executed. If the account was created with the new API (message server), then the underlying application callbacks will not be executed. See issue #2145

​
Future considerations

ADR 008 proposes the creation of a middleware which enables callers of an IBC packet send to perform application logic in conjunction with the IBC application. The underlying application can be removed at the availability of such a middleware as that will be the preferred method for executing application logic upon a ICS 27 packet send.

​
Miscellaneous

In order to avoid import cycles, the genesis types have been moved to their own directory. A new protobuf package has been created for the genesis types. See PR #2133 An additional field has been added to the ActiveChannel type to store the IsMiddlewareEnabled field upon genesis import/export. See issue #2165

​
Consequences

​
Positive

  • default authentication modules are provided (x/auth, x/group, x/gov)
  • any SDK authentication module may now be used with ICS 27
  • separation of authentication from application logic in relation to ICS 27
  • minimized disruption to existing development around ICS 27 controller module
  • underlying applications no longer have to handle capabilities
  • removal of the underlying application upon the creation of ADR 008 may be done in a minimally disruptive fashion
  • only underlying applications which registered the interchain account will perform application logic for that account (underlying applications do not need to be aware of accounts they did not register)

​
Negative

  • the security model has been reduced to that of the SDK. SDK modules may send packets for any interchain account.
  • additional maintenance of the messages added and the middleware enabled flag
  • underlying applications which will become ADR 008 modules are not required to be aware of accounts they did not register
  • calling legacy API vs the new API results in different behaviour for ICS 27 application stacks which have an underlying application

​
Neutral

  • A major release is required