-
Notifications
You must be signed in to change notification settings - Fork 208
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
removed zero error case in slash query #1025
Conversation
LGTM So this also means that for validators with 0 delegation, even if they really were slashed, we can't detect it with our current methods because we are computing the weight from the delegation changes not able to ICQ the weight directly. If we have the wrong weight on a validator, when we actually add delegation what are the implications? Do we really only have to care about the multiplicative change over time as it relates to our delegations and not the absolute value of the weight for that validator? (aside: in the precision error case why do we only check one sided? Could precision errors also cause a LT to happen but in a very small amount? Right now even a minuscule difference to the downside is interpreted as a slash) |
Discussed this in standup, but just to reiterate - any downward change is registered as a slash and automatically updated (regardless of the magnitude). The precision error check is only for the GT case because if the query response is much greater than our internal accounting - that indicates an actual error
That's right, but we would expect the query response also has 0 or represents a precision error case and is caught upstream. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for doing this!
@riley-stride are you signed off on this? I thought from axolo that it looked like you reviewed |
Context
There's currently an error case that's preventing validator's with 0 delegations from having their slash queries reset. This check was only meant to protect against a division by zero error, but it's repeated downstream here in a more suitable place.
Really, there are 3 scenarios we could run into:
All that said, we don't need to throw the original error at the top of the function.
Brief Changelog