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
State machine testing in #1612 has revealed an issue with the slashing of redelegated tokens.
In Quint (informalsystems/partnership-heliax#64), the function endOfEpoch contains a variable mapValidatorSlash that the contains the amounts to slash in a given epoch for a given validator. The misbehaving validator as well as any destination validators holding redelegated tokens originally used to commit the infraction are slashed.
The map is constructed such that tokens may be deducted from each validator starting in the following epoch and up through the pipeline epoch relative to the current one. In Namada, we execute this procedure at the beginning of the following epoch rather than at the end of the current one as in Quint, and so to be consistent, we may update the validator deltas starting at the current Namada epoch up through the epoch preceding the pipeline epoch.
This poses an issue in Namada. Now with redelegation, we may need to slash a validator that is not jailed and may be in either the consensus or below-capacity sets. In this case, we can no longer update the validator's stake in the current epoch (which we are in the very beginning of when processing slashes). We can shift the epochs in which we slash the stake to one more in the future, though even this will have considerations for a future DKG, since this would still be the first time in the protocol that we may update a consensus validator's stake before the pipeline offset. However, this can possibly be considered out of scope for Namada, which can function properly by delaying the slashing of such a validator's stake by one full epoch.
The text was updated successfully, but these errors were encountered:
My opinion is that at minimum, we shift the slashing of validator stake to one more epoch in the future. Then, we try to evaluate whether this is an issue for Anoma and the DKG at a later time. If we desire, we can keep the same procedure for jailed validators and only make the change for non-jailed validators, but I don't think this helps us in any way or makes any difference.
My opinion is that at minimum, we shift the slashing of validator stake to one more epoch in the future. Then, we try to evaluate whether this is an issue for Anoma and the DKG at a later time. If we desire, we can keep the same procedure for jailed validators and only make the change for non-jailed validators, but I don't think this helps us in any way or makes any difference.
This is fine, we don't need to worry about the DKG for now, and I think even if we did in the future this wouldn't be too hard to work around. Let's go ahead with this plan.
State machine testing in #1612 has revealed an issue with the slashing of redelegated tokens.
In Quint (informalsystems/partnership-heliax#64), the function
endOfEpoch
contains a variablemapValidatorSlash
that the contains the amounts to slash in a given epoch for a given validator. The misbehaving validator as well as any destination validators holding redelegated tokens originally used to commit the infraction are slashed.The map is constructed such that tokens may be deducted from each validator starting in the following epoch and up through the pipeline epoch relative to the current one. In Namada, we execute this procedure at the beginning of the following epoch rather than at the end of the current one as in Quint, and so to be consistent, we may update the validator deltas starting at the current Namada epoch up through the epoch preceding the pipeline epoch.
This poses an issue in Namada. Now with redelegation, we may need to slash a validator that is not jailed and may be in either the consensus or below-capacity sets. In this case, we can no longer update the validator's stake in the current epoch (which we are in the very beginning of when processing slashes). We can shift the epochs in which we slash the stake to one more in the future, though even this will have considerations for a future DKG, since this would still be the first time in the protocol that we may update a consensus validator's stake before the pipeline offset. However, this can possibly be considered out of scope for Namada, which can function properly by delaying the slashing of such a validator's stake by one full epoch.
The text was updated successfully, but these errors were encountered: