Interchain Accounts
About IBC integration in ENIZ Token from Ignite CLI Tokenfactory.
Last updated
About IBC integration in ENIZ Token from Ignite CLI Tokenfactory.
Last updated
The Interchain Accounts module in the Cosmos SDK, which is an implementation of the ICS-27 protocol, is utilized by RetisubioLab in the context of the ENIZ token functioning across Stellar and Cosmos SDK blockchains. Through the integration of the IBC protocol and this specific module, RetisubioLab leverages Stellar's public deposit addresses to automatically create corresponding personal accounts for staking in the Cosmos blockchain and the associated beta blockchain, enizchain.
This integration showcases a sophisticated use of the Interchain Accounts module, allowing seamless interaction between different blockchain ecosystems. By leveraging Stellar's public addresses, RetisubioLab ensures that users can smoothly transition and manage their assets in the Cosmos network, particularly for staking purposes. This approach emphasizes the utility of the IBC protocol and the Interchain Accounts module in creating a more interconnected and efficient blockchain environment, where assets and operations can be fluidly moved and managed across different blockchain platforms.
Key Concepts:
Host Chain: This is the blockchain where the interchain account is established. It receives and executes instructions (like Cosmos SDK messages) contained in IBC packets from a controller chain.
Controller Chain: It manages and registers an account on the host chain, sending instructions via IBC packets.
Interchain Account: Created using the ICS-27 protocol on the host chain, this account type has the same functionalities as a regular account. However, it executes transactions based on IBC packets sent by a controller chain, instead of using a private key for transaction signing.
Authentication Module: This is a specialized application module on the controller chain. It employs the Interchain Accounts module to devise unique mechanisms for creating and managing interchain accounts. While the legacy API or the Cosmos SDK application module can be used for this, the latter is the recommended method in ibc-go v6, especially if packet callbacks are not required. It's important to note that the legacy API will be phased out in future releases.
Security Model of SDK:
In the SDK's security framework, modules on a chain are deemed trustworthy. For instance, there's no mechanism to stop a dubious module from interacting with the bank keeper. The ICS-27 implementation in ibc-go is built on this trust assumption and expects that other IBC application modules won't use ports within the ICS-27 namespace.
Channel Closure:
While the current interchain account host and controller don't support ChanCloseInit, they do accept ChanCloseConfirm. This means these modules wonât initiate channel closures but will confirm closures started by other ICS-27 implementations.
In scenarios where a channel closes (like a packet timeout in an ordered channel), the associated interchain account can be reactivated by creating a new channel with a JSON-formatted version string mirroring the original channel's Metadata. This reopening can be done through MsgRegisterInterchainAccount or MsgChannelOpenInit. When using MsgRegisterInterchainAccount, the version field in the message can be left blank as it's filled by the controller submodule. However, for MsgChannelOpenInit, the correct JSON-encoded Metadata string must be provided. The ordering of channels reopened with the default controller submodule cannot be altered without undergoing a channel upgrade handshake or by using a custom controller implementation. For more details, refer to the section on Understanding Active Channels.
