ACP-77: Deactivate SoVs without sufficient fees #3412
Conversation
| @@ -565,5 +569,70 @@ func (v *verifier) processStandardTxs(txs []*txs.Tx, feeCalculator fee.Calculato | |||
| } | |||
| } | |||
|
|
|||
| // After processing all the transactions, deactivate any SoVs that might not | |||
There was a problem hiding this comment.
What does "might not" mean in this context? Is it nondeterministic?
There was a problem hiding this comment.
This is deterministic. However, this check is not accurate.
Specifically, it's possible for another block to be issued at the same timestamp. This means that a later block technically could be issued with the same timestamp as this block and the balance of this SoV could be increased (for example).
Ideally this SoV would not have been marked as inactive in this case, because it was always able to pay fees for the time it was in the validator set. But we can't know for certain at this point that this will or will not happen, so we take the conservative approach here and disable the SoV.
| // If the validator has exactly the right amount of fee for the next | ||
| // second we should not remove them here. | ||
| if sov.EndAccumulatedFee >= potentialAccruedFees { | ||
| break |
There was a problem hiding this comment.
Should this be continue?
There was a problem hiding this comment.
No, I think break is correct.
This is iterating over sovs (which means that sov.EndAccumulatedFee is monotonically increasing). Once we find the first SoV that has sov.EndAccumulatedFee >= potentialAccruedFees, we know that all following SoVs will have sov.EndAccumulatedFee >= potentialAccruedFees.
Technically a continue would still work here - but it would mean that we are iterating over SoVs that do not need to be iterated over.
There was a problem hiding this comment.
Ah, I was missing that the sov's are ordered in that way. I think a comment explaining that any following sov's will also pass this check would be helpful.
Why this should be merged
ACP-77 introduces a new type of validator: the
SubnetOnlyValidator.This PR introduces logic to disable this new validator type when a validator no longer has sufficient balance to pay additional fees.
How this works
How this was tested
Added unit tests.
Need to be documented in RELEASES.md?
There are no user facing changes.