perf(x/staking/keeper): make Slash return early iff zero tokens to burn #18049
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
julienrbrt
added
the
backport/v0.50.x
julienrbrt
approved these changes
Oct 11, 2023
There was a problem hiding this comment.
lgtm! Can we add a test case here https://github.com/cosmos/cosmos-sdk/blob/2808e030cf5e167a727caa06792c1542bb95cb71/tests/integration/staking/keeper/slash_test.go ?
atheeshp
approved these changes
Oct 12, 2023
This change makes Keeper.Slash return early if there are no tokens
to burn! This change also skips invoking the
.Hooks().BeforeValidatorSlashed hook because literally there is no
slashing that can happen if there are no tokens to burn.
Given that the result of burning zero tokens SHOULD be a no-operation
(noop) but we go through the whole routine, assuming no zero tokens
would be burnt, one could argue on a protocol implementation/conformation
that with zero tokens to burn, invoking Keeper.RemoveValidatorTokens which
invokes:
Keeper.DeleteValidatorByPowerIndex
-> (Keeper.DeleteValidatorByPowerIndex)
-> validator.RemoveTokens
-> Keeper.SetValidator
-> Keeper.SetValidatorByPowerIndex
was causing a potential self inflicted Byzantine risk because that operation
is non-atomic (it ran through a series of operations that could fail on
their own yet could not be rolled back and not idempotent), will rely
on network operations yet the actual result will have the operations back
to the original: more investigation is needed to examine the risk/impact
of previously letting zero tokens be burnt and run through that process.
Also while here, employed a Go pattern to reuse condition variables just
as a code hygiene improvement and also given that as a Go reviewer, the
unnecessary allocation of variables however small must be avoided.
Fixes #18034
odeke-em
force-pushed
the
x-staking-keeper-return-early-on-with-zero-tokens-to-burn
branch
from
ecca2b9
to
bb54a89
Compare
julienrbrt
deleted the
x-staking-keeper-return-early-on-with-zero-tokens-to-burn
branch
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This change makes Keeper.Slash return early if there are no tokens to burn! This change also skips invoking the
.Hooks().BeforeValidatorSlashed hook because literally there is no slashing that can happen if there are no tokens to burn.
Given that the result of burning zero tokens SHOULD be a no-operation (noop) but we go through the whole routine, assuming no zero tokens would be burnt, one could argue on a protocol implementation/conformation that with zero tokens to burn, invoking Keeper.RemoveValidatorTokens which invokes:
Keeper.DeleteValidatorByPowerIndex
-> (Keeper.DeleteValidatorByPowerIndex)
-> validator.RemoveTokens
-> Keeper.SetValidator
-> Keeper.SetValidatorByPowerIndex
was causing a potential self inflicted Byzantine risk because that operation is non-atomic (it ran through a series of operations that could fail on their own yet could not be rolled back and not idempotent), will rely on network operations yet the actual result will have the operations back to the original: more investigation is needed to examine the risk/impact of previously letting zero tokens be burnt and run through that process.
Fixes #18034