Skip to content
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

Crisis Invariant check per block height #3967

Closed
rigelrozanski opened this issue Mar 23, 2019 · 6 comments
Closed

Crisis Invariant check per block height #3967

rigelrozanski opened this issue Mar 23, 2019 · 6 comments

Comments

@rigelrozanski
Copy link
Contributor

Offshoot of #3656

Currently, the invariant check messages run at the latest height of the blockchain. This could be a problem if the invariant was temporarily broken (and thus should have halted the blockchain) but was then somehow corrected at a later height. Thus we ought to implement the ability to run an invariant check at a specific height of the blockchain.

@cwgoes
Copy link
Contributor

cwgoes commented Mar 24, 2019

That would be nice, but wouldn't it require that all nodes store all past state versions?

I think the most concerning invariant violations are likely to break an invariant that will remain broken - admittedly, it's hard to formalize that intuition, there could be exceptional cases.

@rigelrozanski
Copy link
Contributor Author

Does cosmos store a certain amount of previous state?

but this seems like way less of a priority given #3969
which would make it less likely that an invariant would go unnoticed for any substantial amount of time

@cwgoes
Copy link
Contributor

cwgoes commented Mar 26, 2019

There is a default pruning strategy, which IIRC is fairly aggressive (prunes all but the most recent states).

I don't think we can reasonably expect node operators to store all past states (which we would require if it were part of the state machine like this).

Agreed that #3969 will reduce the need for this.

@rigelrozanski
Copy link
Contributor Author

@cwgoes as long as there are a few blocks worth of state stored then we can at least be reassured that the correct circuit breaker occurs.. like it could be a part of this transaction that if you want to include a block height it can only occur within the past say 5 blocks from the current height (or else reject the transaction) - this would be sufficient to ensure that auto-sent transactions (per #3969) would definitely circuit break correctly. Of course I don't think it's reasonable for any more than a few blocks to be stored by the node operators.

but yeah this is low low priority AFAICT haha - for the long game

@github-actions
Copy link
Contributor

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

@github-actions github-actions bot added the stale label Jul 17, 2020
@tac0turtle tac0turtle removed the stale label Apr 3, 2023
@tac0turtle
Copy link
Member

closing for now since we will end up rewriting how crisis works

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants