cli
cli copied to clipboard
INIT: Make IBC module scaffolding compatible with interchain accounts
In module_ibc.go inside OnChanOpenInit:
boundPort := im.keeper.GetPort(ctx)
if boundPort != portID {
return "", sdkerrors.Wrapf(porttypes.ErrInvalidPort, "invalid port: %s, expected %s", portID, boundPort)
}
When building an ICA authentication module, on the controller chain separate ports are opened for separate accounts. So, instead of having a single port for a module, you'd get a bunch of ports like icacontroller-cosmos***. If we have an error checking like above, it will always throw an invalid port error.
if version != types.Version {
return "", sdkerrors.Wrapf(types.ErrInvalidVersion, "got %s, expected %s", version, types.Version)
}
failed to execute message; message index: 0: channel open init callback
failed: got {"version":"ics27-1","controller_connection_id":"connection-0",
"host_connection_id":"connection-0","address":"","encoding":"proto3","tx_type":"sdk_multi_msg"},
expected blog-1: invalid version'
Basically, if we remove these two checks (or somehow modify them), a newly scaffolded IBC module would be possible to use as an ICA authentication module.
The current ibc-module.go scaffolding is a generic scaffold for checks that you generally have for most modules.
Like the version check, versioning is a feature offered by IBC so we generate the code that is necessary to check the version.
Then you add additional logic based on your module, like verified client check for monitoring module of spn
So I don't think we should remove the version checking, but in the context of the ICA auth module you should have the check with version==ics27-1
To me, it seems like we should have two versions of IBC module scaffolding. The ICA compatible one and the one for classic IBC module specific for certain purposes, for example we would not use ICA for the monitoring module