-
Notifications
You must be signed in to change notification settings - Fork 198
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
Make churner produce params for all specified quorums #288
Make churner produce params for all specified quorums #288
Conversation
d5229f9
to
4e8ca7d
Compare
@@ -89,14 +93,54 @@ func teardown() { | |||
func TestChurner(t *testing.T) { |
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.
This test was not testing anything because no operators have been registered.
Churner simply exited without any OperatorsToChurn
4e8ca7d
to
b1678f4
Compare
239fe3d
to
3d587e3
Compare
3d587e3
to
441c768
Compare
if uint32(len(operatorStakes[quorumID])) < operatorSetParams.MaxOperatorCount { | ||
// quorum is not full, so we can continue | ||
continue | ||
if len(operatorStakes[quorumID]) == 0 { |
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.
-
So this would cause registration to fail if there was one empty quorum and another quorum which was full. Can't we handle this case by just passing in an empty operators to churn object?
-
Shouldn't we also pass in an empty object whenever the quorum isn't full? It doesn't look like the contracts require the object to be populated in that case, but maybe there's an issue I'm not seeing.
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 like that idea.
@0x0aa0 can you chime in here?
Can we have zero address for operator address in operatorKickParams in case the quorum isn't full?
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.
Done
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.
(edited) Yes this does appear to work
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.
@0x0aa0 , but in these situations, the call to deregisterOperator
couldn't be occurring...
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.
Looks good, just one question
Why are these changes needed?
Currently, operator software will call either
RegisterOperatorWithChurn
orRegisterOperator
to opt into quorums. But when there are multiple quorums where only a subset of the quorums are full, this call won't work because churner won't produce a kick params for the quorum which aren't full. The contract code to register with churn handles the case where only a subset quorums are full, but it enforces that kick params are specified for all quorums.This PR makes churner produce kick params even for quorums that aren't full.
Checks