If, in a committee, there is, for some reason, a disparity between known validators, we can hit some edge condition that will prevent the creation of a Beacon object. Take a look at this example:
Operator
Validators
1
A, B
2
A, B
3
A, C
4
C
In the case where an operator fails whenever it sees a message with an unknown validator, no Beacon Object for validator A will ever be created. There could be more realistic scenarios where we lose some fault tolerance where not all operators create the beacon object.
Fix
This PR changes the CommitteeRunner to allow signatures of unknown validators. For that, we made the following changes:
validatePartialSigMsgForSlot now doesn't check if the validator index exists in the share map.
new validateValidatorIndexInPartialSigMsg function called to validate ValidatorIndex for validator runners.
In CommitteeRunner.ProcessPostConsensus, instead of returning an error in case of an unknown (validator, root) pair, we call "continue" to process remaining (root, validator) pairs. This is due to the edge case in which an operator may not be up to date and not have a (validator, root) pair, even though it received a quorum of signatures for such root.
Issue
If, in a committee, there is, for some reason, a disparity between known validators, we can hit some edge condition that will prevent the creation of a Beacon object. Take a look at this example:
In the case where an operator fails whenever it sees a message with an unknown validator, no Beacon Object for validator A will ever be created. There could be more realistic scenarios where we lose some fault tolerance where not all operators create the beacon object.
Fix
This PR changes the CommitteeRunner to allow signatures of unknown validators. For that, we made the following changes:
validatePartialSigMsgForSlotnow doesn't check if the validator index exists in the share map.validateValidatorIndexInPartialSigMsgfunction called to validate ValidatorIndex for validator runners.CommitteeRunner.ProcessPostConsensus, instead of returning an error in case of an unknown (validator, root) pair, we call "continue" to process remaining (root, validator) pairs. This is due to the edge case in which an operator may not be up to date and not have a (validator, root) pair, even though it received a quorum of signatures for such root.Tests: