-
Notifications
You must be signed in to change notification settings - Fork 6
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
jailed validators (from downtime) attempt to jail every block #163
Comments
@Reecepbcups what makes it attempt to re-jail every block? Do we need to simply need to mark the validator as jailed? Or perhaps, there is an |
@alexanderbez here is where it's sort of stemming from: #160 (comment) Issue: x/staking panics if pulling a jailed validator from the validator set on ApplyValUpdates (staking endblock). So we have to override the validator from being jailed so that the last ApplyValUpdates can be set as they begin unbonding. We can't just delete the validator outright (DeleteLastValidatorPower) from the CometBFT updates since that would be 2x abci.ValUpdate updates (x/staking) from a single val, resulting in a consensus panic I think a solution here is yet another cache where:
pretty much a delay of jail by h+1 rather than at h. This way x/staking and x/slashing can handle all their logic as normal, and so teams do not have to fork the SDK / staking |
Update, removing this from the upstream SDK would solve the issue. Unsure why we panic vs continuing since we iter all validators anyways.
|
Yup, makes sense. Good catch and patch. |
resolved in #165 |
Built into #160, when a validator is jailed the logic continues to try and set jailed state.
There does not seem to be a technical issue with it, but jailing a validator every block for an entire unbonding period is no bueno
Solutions
The text was updated successfully, but these errors were encountered: