-
Notifications
You must be signed in to change notification settings - Fork 675
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
ACP-77: Implement SetSubnetValidatorWeightTx
#3421
ACP-77: Implement SetSubnetValidatorWeightTx
#3421
Conversation
…77-sov-validators-state
…cp-77-deactivation
…nt-acp-77-register-subnet-validator-tx
…lement-acp-77--set-subnet-validator-weight-tx
…77-sov-validators-state
…cp-77-deactivation
…nt-acp-77-register-subnet-validator-tx
…lement-acp-77--set-subnet-validator-weight-tx
…lement-acp-77--set-subnet-validator-weight-tx
currentTimestamp = e.state.GetTimestamp() | ||
upgrades = e.backend.Config.UpgradeConfig | ||
) | ||
if !upgrades.IsEtnaActivated(currentTimestamp) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm not super familiar with the code, but could the:
IsEtnaActivated()
SyntacticVerify()
VerifyMemoFieldLength()
CalculateFee()
VerifySpend()
flow be moved to a helper? Seems to be repeated (or at least close to repeated) for multiple tx types here.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I do think this can be cleaned up... But I'd prefer it to be done holistically... Since this doesn't really impact correctness, I'm going to merge this PR and treat this as a followup.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM, just two questions. One if a few of the standard calls for tx verification could be combined in a helper, the other the same as @ceyonur: will SetSubnetValidatorWeightTx
s be considered to have the same complexity whether the weight is 0 or not? I guess it would always be charged for the worst case if so?
…bnet-validator-weight-tx
…7--set-subnet-validator-weight-tx
…7--set-subnet-validator-weight-tx
Why this should be merged
This PR introduces the
SetSubnetValidatorWeightTx
defined by ACP-77.This PR includes:
SetSubnetValidatorWeightTx
serialization definitionSetSubnetValidatorWeightTx
building and wallet supportSetSubnetValidatorWeightTx
SetSubnetValidatorWeightTx
SetSubnetValidatorWeightTx
This PR does not include:
SetSubnetValidatorWeightTx
How this works
This PR adds the new
SetSubnetValidatorWeightTx
type and implements all the required visitors.How this was tested