feat: reregistration delay #246
Conversation
| if( | ||
| operatorInfo.status == OperatorStatus.REGISTERED && | ||
| !quorumsToRemove.isEmpty() && | ||
| quorumsToRemove.isSubsetOf(currentBitmap) | ||
| ){ |
There was a problem hiding this comment.
so there's still some weird race condition where an operator can deregister from a subset of quorums to avoid being ejected for more, right?
I guess I can accept that, but it would certainly be nice to resolve if there's an easy solution.
There was a problem hiding this comment.
perhaps we can just take the submitted 'quorumNumbers' and actually pass on a combination ('and'ing) of them with the operator's current quorums in the subsequent call?
|
I could see merging this now. Am pushing a bit on fixing the remaining race condition here, at least if it's easy enough, because it would be a nice improvement. |
| * @dev The owner can eject operators without recording of stake ejection | ||
| */ | ||
| function ejectOperators(bytes32[][] memory _operatorIds) external returns (uint32[] memory){ | ||
| function ejectOperators(bytes32[][] memory _operatorIds) external { |
There was a problem hiding this comment.
wdyt about refactoring the ejection logic
- That doesn't enforce the rate limit that is callable by the owner
- That is callable by the ejector and enforces the rate limit
This should clean up some of the branchy conditionals in this function
Adds a delay for registration to any quorum after an operator has been ejected