- Chains
- IBC Apps
- Relayers
- IBC Light Clients
Chains
ICS20
Thetransferkeeper.NewKeeper(...) now takes in an ICS4Wrapper.
The ICS4Wrapper should be the IBC Channel Keeper unless ICS 20 is being connected to a middleware application.
ICS27
ICS27 Interchain Accounts has been added as a supported IBC application of ibc-go. Please see the ICS27 documentation for more information.Upgrade Proposal
If the chain will adopt ICS27, it must set the appropriate params during the execution of the upgrade handler inapp.go:
InitModule.
Add StoreUpgrades for ICS27 module
For ICS27 it is also necessary to manually add store upgrades for the new ICS27 module and then configure the store loader to apply those upgrades in app.go:
Added field.
Genesis migrations
If the chain will adopt ICS27 and chooses to upgrade via a genesis export, then the ICS27 parameters must be set during genesis migration. The migration code required may look like:Ante decorator
The field of typechannelkeeper.Keeper in the AnteDecorator structure has been replaced with a field of type *keeper.Keeper:
IBC Apps
OnChanOpenTry must return negotiated application version
The OnChanOpenTry application callback has been modified.
The return signature now includes the application version.
IBC applications must perform application version negotiation in OnChanOpenTry using the counterparty version.
The negotiated application version then must be returned in OnChanOpenTry to core IBC.
Core IBC will set this version in the TRYOPEN channel.
OnChanOpenAck will take additional counterpartyChannelID argument
The OnChanOpenAck application callback has been modified.
The arguments now include the counterparty channel id.
NegotiateAppVersion removed from IBCModule interface
Previously this logic was handled by the NegotiateAppVersion function.
Relayers would query this function before calling ChanOpenTry.
Applications would then need to verify that the passed in version was correct.
Now applications will perform this version negotiation during the channel handshake, thus removing the need for NegotiateAppVersion.
Channel state will not be set before application callback
The channel handshake logic has been reorganized within core IBC. Channel state will not be set in state after the application callback is performed. Applications must rely only on the passed in channel parameters instead of querying the channel keeper for channel state.IBC application callbacks moved from AppModule to IBCModule
Previously, IBC module callbacks were apart of the AppModule type.
The recommended approach is to create an IBCModule type and move the IBC module callbacks from AppModule to IBCModule in a separate file ibc_module.go.
The mock module go API has been broken in this release by applying the above format.
The IBC module callbacks have been moved from the mock modules AppModule into a new type IBCModule.
As apart of this release, the mock module now supports middleware testing. Please see the README for more information.
Please review the mock and transfer modules as examples. Additionally, simapp provides an example of how IBCModule types should now be added to the IBC router in favour of AppModule.
IBC testing package
TestChains are now created with chainID’s beginning from an index of 1. Any calls to GetChainID(0) will now fail. Please increment all calls to GetChainID by 1.
Relayers
AppVersion gRPC has been removed.
The version string in MsgChanOpenTry has been deprecated and will be ignored by core IBC.
Relayers no longer need to determine the version to use on the ChanOpenTry step.
IBC applications will determine the correct version using the counterparty version.
IBC Light Clients
TheGetProofSpecs function has been removed from the ClientState interface. This function was previously unused by core IBC. Light clients which don’t use this function may remove it.