fix: max-rate bellow the era min-rate #4552
Conversation
|
can you test it on localnet with external validator created with a max rat of 5% ? |
yup! will do |
| @@ -267,3 +267,27 @@ func UpdateMinimumCommissionFee( | |||
| } | |||
| return false, nil | |||
| } | |||
|
|
|||
| // UpdateMaxCommissionFee makes sure the max-rate is at least higher than the rate + max-rate-change. | |||
| func UpdateMaxCommissionFee(state *state.DB, addr common.Address, minRate numeric.Dec) (bool, error) { | |||
There was a problem hiding this comment.
bool value returns from function, but never used. Maybe use it in tests?
There was a problem hiding this comment.
yeah good catch! i wanted to keep the same function signature as the UpdateMinCommissionFee but as you said if not used then we can remove it
And it works! tested it two validators as you can see in the PR test script, one had the max-rate bellow the min and the other had the max-rate above, the latter got updated as soon as hip30 hit, while the former didn't (as expected) however when the MaxRate epoch hit the former got the update as well. |
|
|
* fix: max-rate bellow the era min-rate * fix comments * add localnet epoch config * update config * update config * update config * update config
* Removed outdated check. * Fallback for old sync for BeaconBlockChannel. * Additional logs. * fix: max-rate bellow the era min-rate (#4552) * fix: max-rate bellow the era min-rate * fix comments * add localnet epoch config * update config * update config * update config * update config * Revert "fix: max-rate bellow the era min-rate (#4552)" (#4578) This reverts commit f993468. --------- Co-authored-by: Diego Nava <8563843+diego1q2w@users.noreply.github.com>
Issue
Following the discovery in issue #4549 on the Harmony repository, there is an operational inconsistency that occurs before a block is finalized. During the process where the validator data stored in memory, are written to disk as defined in statedb.go lines 896-898, a sanity check is performed. This check executes a series of rules to ensure the integrity of the data before it's committed to disk. One particular rule, which can be found in validator.go lines 315-320, verifies that the rate is not exceeding the maximum allowed rate. If the rate is greater than the maximum, the write operation fails.
This issue became prominent after the HIP30 hard fork, which increased the minimum rate to 7%. Subsequently, validators with a 5% maximum rate were unable to adjust their fees accordingly due to the aforementioned validation rule.
In this PR, we address the issue by adjusting the max-rate to be at least equal to the sum of the minRate and the max-increase-rate. This change requires a hard fork, as it necessitates consensus across the majority of the nodes to ensure that all participants agree on the same value.