Each IBC tendermint client must be kept up to date by submitting tendermint headers to the chain. These headers then get stored as ConsensusStates. As IBC clients are long-lived, they will store many consensus states. Each consensus state stores the validator set (which may contain ~100 validators), thus they take up a nontrivial amount of space.
However, the only consensus states that need to be kept by the IBC client are the ones that are within the current unbonding period. Every other consensus state that has been stored since client state initialization can be pruned.
Since well-connected chains like hubs maybe connected to many clients, each of which may be submitting many headers, I think it is worth pruning the consensus states so that the space required by IBC module does not explode with time.
Not sure if this is absolutely necessary for IBC 1.0, but definitely seems like a good feature to have, and relatively simple to implement.
Open to other proposals but a simple fix is to prune all expired consensus states upon receiving a new one. This would just require that clients also have a field that includes the earliest consensus height that is still in state EarliestHeight uint64.
The UpdateClient function would then, upon receiving a valid update, check the earliest height to see if it is expired given unbonding period. If it is, then delete it from store and keep checking and deleting the next earliest heights until we find one that isn't expired. Reset EarliestHeight in client and return.
This should keep the space taken by each client bounded by the average number of blocks produced within an unbonding period.
cc: @cwgoes @fedekunze @colin-axner
This makes sense, and I think your proposed solution
Open to other proposals but a simple fix is to prune all expired consensus states upon receiving a new one. This would just require that clients also have a field that includes the earliest consensus height that is still in state EarliestHeight uint64.
should work fine. One minor note is that the timestamp & height may both need to be checked to see whether a consensus state is within the unbonding period.
I like this proposal a lot. One thing to consider is to be careful when pruning consensus states from a previous version, i.e after upgrading. I propose to use the abstract height from https://github.com/cosmos/ics/pull/447 instead of a uint 馃憤
Most helpful comment
I like this proposal a lot. One thing to consider is to be careful when pruning consensus states from a previous version, i.e after upgrading. I propose to use the abstract height from https://github.com/cosmos/ics/pull/447 instead of a
uint馃憤