Synopsis
Authentication modules play the role of theBase Application
as described in ICS30 IBC Middleware, and enable application developers to perform custom logic when working with the Interchain Accounts controller API.
The controller submodule is used for account registration and packet sending.
It executes only logic required of all controllers of interchain accounts.
The type of authentication used to manage the interchain accounts remains unspecified.
There may exist many different types of authentication which are desirable for different use cases.
Thus the purpose of the authentication module is to wrap the controller module with custom authentication logic.
In ibc-go, authentication modules are connected to the controller chain via a middleware stack.
The controller module is implemented as middleware and the authentication module is connected to the controller module as the base application of the middleware stack.
To implement an authentication module, the IBCModule
interface must be fulfilled.
By implementing the controller module as middleware, any amount of authentication modules can be created and connected to the controller module without writing redundant code.
The authentication module must:
- Authenticate interchain account owners
- Track the associated interchain account address for an owner
- Claim the channel capability in
OnChanOpenInit
- Send packets on behalf of an owner (after authentication)
IBCModule implementation
The followingIBCModule
callbacks must be implemented with appropriate custom logic:
OnChanOpenInit
otherwise the authentication module will not be able to send packets on the channel created for the associated interchain account.
The following functions must be defined to fulfill the IBCModule
interface, but they will never be called by the controller module so they may error or panic.
RegisterInterchainAccount
The authentication module can begin registering interchain accounts by calling RegisterInterchainAccount
:
version
argument is used to support ICS29 fee middleware for relayer incentivization of ICS27 packets. Consumers of the RegisterInterchainAccount
are expected to build the appropriate JSON encoded version string themselves and pass it accordingly. If an empty string is passed in the version
argument, then the version will be initialized to a default value in the OnChanOpenInit
callback of the controller’s handler, so that channel handshake can proceed.
The following code snippet illustrates how to construct an appropriate interchain accounts Metadata
and encode it as a JSON bytestring:
Metadata
type:
SendTx
The authentication module can attempt to send a packet by calling SendTx
:
InterchainAccountPacketData
must be serialized using a format supported by the host chain.
If the host chain is using the ibc-go host chain submodule, SerializeCosmosTx
should be used. If the InterchainAccountPacketData.Data
is serialized using a format not support by the host chain, the packet will not be successfully received.
OnAcknowledgementPacket
Controller chains will be able to access the acknowledgement written into the host chain state once a relayer relays the acknowledgement.
The acknowledgement bytes will be passed to the auth module via the OnAcknowledgementPacket
callback.
Auth modules are expected to know how to decode the acknowledgement.
If the controller chain is connected to a host chain using the host module on ibc-go, it may interpret the acknowledgement bytes as follows:
Begin by unmarshaling the acknowledgement into sdk.TxMsgData:
<=
v0.45.
The auth module should interpret the txMsgData.Data as follows:
handler
and handleAny
.