You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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
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
Is there an existing issue for this?
What happened?
Noticed while auditing and testing that this code
cosmos-sdk/x/staking/keeper/slash.go
Lines 146 to 168 in 599b58d
if the value of tokensToBurn is zero, the code down below takes an unnecessary path
but in there:
cosmos-sdk/x/staking/keeper/slash.go
Lines 152 to 159 in 599b58d
cosmos-sdk/x/staking/keeper/validator.go
Lines 165 to 167 in 4001e2b
Suggestion
/cc @elias-orijtech
Cosmos SDK Version
main
How to reproduce?
No response
The text was updated successfully, but these errors were encountered: