You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Right now, ibc-rs doesn't support IBC Client params. With Client params, the host chain can disable or enable supported client types via governance.
Proposal
Let me differentiate between supported clients and allowed clients.
Supported Clients: This is implementation specific. This indicates the client state decoders available in the host chain implementation.
Allowed Clients: This is blockchain specific. The blockchain community decides which client state decoders should be allowed on the chain via governance.
The allowed clients must also be supported. Otherwise, the implementation can't decode a valid allowed client.
IMO, the distinction is required to give flexibility to the community without any developer intervention. This is useful in the case of any faulty implementation of a client type. A chain can immediately pass a governance to disable a client type without a chain upgrade.
Implementation
I propose to use ClientState macro to create a method called supported_clients to return a set of the supported client types corresponding to the enum variants.
At Genesis
In the genesis, the client params can have a subset of the supported client types as allowed clients. And the subset condition is checked at ibc module initialization.
At Client Create or Client Upgrade
Successfully create or upgrade client state if the client state can be decoded to one of the allowed_clients types - whose decoders are available. Otherwise, the transaction fails.
At Client Params Update
Successfully update the client params on the blockchain if the provided allowed_clients is a subset of supported_clients. Otherwise, the transaction fails.
The text was updated successfully, but these errors were encountered:
Feature Summary
Right now, ibc-rs doesn't support IBC Client params. With Client params, the host chain can disable or enable supported client types via governance.
Proposal
Let me differentiate between supported clients and allowed clients.
The allowed clients must also be supported. Otherwise, the implementation can't decode a valid allowed client.
IMO, the distinction is required to give flexibility to the community without any developer intervention. This is useful in the case of any faulty implementation of a client type. A chain can immediately pass a governance to disable a client type without a chain upgrade.
Implementation
I propose to use
ClientState
macro to create a method calledsupported_clients
to return a set of the supported client types corresponding to the enum variants.At Genesis
In the genesis, the client params can have a subset of the supported client types as allowed clients. And the subset condition is checked at ibc module initialization.
At Client Create or Client Upgrade
Successfully create or upgrade client state if the client state can be decoded to one of the
allowed_clients
types - whose decoders are available. Otherwise, the transaction fails.At Client Params Update
Successfully update the client params on the blockchain if the provided
allowed_clients
is a subset ofsupported_clients
. Otherwise, the transaction fails.The text was updated successfully, but these errors were encountered: