-
Notifications
You must be signed in to change notification settings - Fork 610
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Prune Expired Tendermint Consensus States #52
Comments
This makes sense, and I think your proposed solution
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 cosmos/ibc#447 instead of a |
#125 addresses basic pruning of tendermint consensus state. Each update can potentially prune the oldest consensus state Future improvements should support:
|
is there an update to this issue, state growth on networks using IBC seems to grow faster than others |
We already prune a single consensus state for each new one. But batch pruning has not been implemented and is not on the immediate roadmap |
oh okay, if we prune as the new one comes in, then why would batch be needed? |
because when the new one comes in, there may be multiple expired consensus states in store. we only prune the oldest as of now. We could prune all, but it introduces variable gas costs into |
Migrating from stargate to ibc-go will prune all expired consensus states |
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. ResetEarliestHeight
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
The text was updated successfully, but these errors were encountered: