Synopsis
Learn how to integrate IBC to your application This document outlines the required steps to integrate and configure the IBC module to your Cosmos SDK application and enable sending fungible token transfers to other chains. An example app using ibc-go v10 is linked.Integrating the IBC module
Integrating the IBC module to your SDK-based application is straightforward. The general changes can be summarized in the following steps:- Define additional
Keeperfields for the new modules on theApptype. - Add the module’s
StoreKeys and initialize theirKeepers. - Create Application Stacks with Middleware
- Set up IBC router and add route for the
transfermodule. - Grant permissions to
transfer’sModuleAccount. - Add the modules to the module
Manager. - Update the module
SimulationManagerto enable simulations. - Integrate light client modules (e.g.
07-tendermint). - Add modules to
Begin/EndBlockersandInitGenesis.
Add application fields to App
We need to register the core ibc and transfer Keepers. To support the use of IBC v2, transferv2 and callbacksv2 must also be registered as follows:
app.go
Configure the Keepers
Initialize the IBC Keepers (for core ibc and transfer modules), and any additional modules you want to include.
Notice The capability module has been removed in ibc-go v10, therefore the
ScopedKeeper has also been removedCreate Application Stacks with Middleware
Middleware stacks in IBC allow you to wrap anIBCModule with additional logic for packets and acknowledgements. This is a chain of handlers that execute in order. The transfer stack below shows how to wire up transfer to use packet forward middleware, and the callbacks middleware. Note that the order is important.
IBC v2 Application Stack
For IBC v2, an example transfer stack is shown below. In this case the transfer stack is using the callbacks middleware.Register module routes in the IBC Router
IBC needs to know which module is bound to which port so that it can route packets to the
appropriate module and call the appropriate callbacks. The port to module name mapping is handled by
IBC’s port Keeper. However, the mapping from module name to the relevant callbacks is accomplished
by the port
Router on the
ibc module.
Adding the module routes allows the IBC handler to call the appropriate callback when processing a channel handshake or a packet.
Currently, a Router is static so it must be initialized and set correctly on app initialization.
Once the Router has been set, no new routes can be added.
app.go
IBC v2 Router
With IBC v2, there is a new router that needs to register the routes for a portID to a given IBCModule.Module Manager and SimulationManager
In order to use IBC, we need to add the new modules to the module Manager and to the SimulationManager, in case your application supports simulations.
app.go
Module account permissions
After that, we need to grantMinter and Burner permissions to
the transfer ModuleAccount to mint and burn relayed tokens.
app.go
Integrating light clients
Note that from v10 onwards, all light clients are expected to implement theAll light clients must be registered withLightClientInterfaceinterface defined by core IBC, and have to be explicitly registered in a chain’s app.go. This is in contrast to earlier versions of ibc-go when07-tendermintand06-solomachinewere added out of the box. Follow the steps below to integrate the07-tendermintlight client.
module.Manager in a chain’s app.go file. The following code example shows how to instantiate 07-tendermint light client module and register its ibctm.AppModule.
app.go
Allowed Clients Params
The allowed clients parameter defines an allow list of client types supported by the chain. The default value is a single-element list containing theAllowedClients wildcard ("*"). Alternatively, the parameter
may be set with a list of client types (e.g. "06-solomachine","07-tendermint","09-localhost").
A client type that is not registered on this list will fail upon creation or on genesis validation.
Note that, since the client type is an arbitrary string, chains must not register two light clients
which return the same value for the ClientType() function, otherwise the allow list check can be
bypassed.
Application ABCI ordering
One addition from IBC is the concept ofHistoricalInfo which is stored in the Cosmos SDK x/staking module. The number of records stored by x/staking is controlled by the HistoricalEntries parameter which stores HistoricalInfo on a per-height basis.
Each entry contains the historical information for the Header and ValidatorSet of this chain which is stored
at each height during the BeginBlock call. The HistoricalInfo is required to introspect a blockchain’s prior state at a given height in order to verify the light client ConsensusState during the
connection handshake.
app.go
transfer module, and are now able to send fungible tokens across
different chains. If you want to have a broader view of the changes take a look into the SDK’s
SimApp.