Revive an expired IBC client

Hello! I’m attempting to revive an expired IBC client that I have setup with the Cosmos Go Relayer.

I attempted to update the client with the following command.

rly tx update-clients my-path

but unfortunately it seems to throw an error with the following message for the expired client.

Error building or broadcasting transaction {“provider_type”: “cosmos”, “chain_id”: “pio-testnet-1”, “attempt”: 4, “max_attempts”: 5, “error”: “rpc error: code = Unknown desc = rpc error: code = Unknown desc = failed to execute message; message index: 0: cannot update client (07-tendermint-80) with status Expired: client state is not active [cosmos/ibc-go/[email protected]/modules/core/02-client/keeper/client.go:67] with gas used: ‘77585’: unknown request”}

Any suggestions on how I could go about renewing/reviving the IBC client would be greatly appreciated.

hey, in short, to revive an expired ibc client you’d need to:

1. create a new identical ibc client
2. create a governance proposal that substitutes expired client with the new client
3. once governance proposal passes → client will be revived

relevant docs can be found here: Governance Proposals | IBC-Go

you can create a new client with hermes or rly (use correct params for your case):

hermes create client --host-chain pio-testnet-1 --reference-chain <other-chain-id> --trusting-period 10000000ms --unbonding-period 1814400000ms ...

rly transact client <path-name>  --client-tp "10000000m" --client-unbonding-period "1814400000m" ...

update-clients command is used to keep the clients alive and prevent expiration, but it can’t revive a client once it is expired already

Why are IBC clients required to be gov props? These go down all the time and the gov process is slow and annoying. Why not allow permissionless IBC client creation and then frontends select which ones to include? I’m sure there’s a reason, but it’s confusing to me.

reasonant:

Why not allow permissionless IBC client creation and then frontends select which ones to include?

Actually creating IBC clients or channels is permissionless. Problem is, if you relay your tokens via two different IBC channels, it’s gonna be 2 different tokens, and to relay them back, you need to relay it via the same channel you’ve relayed it with previously.

Ok so basically the govprop ensures everyone is using the same ibc client and therefore the same token, and therefore instantiating a new one creates new tokens which is why we want to revive existing ones?

Yep, exactly!

And generally speaking, so long as IBC transactions are flowing through a channel, it doesn’t expire

Specifically the gov prop manually sets the counterparty client state.

This can be used for fraud (bigly) so that’s why governance handles it.