feat: automated ejector #146
Conversation
- trailing window - try/catch ejection
- adds operatorId on reg and dereg events - adds function to OperatorStateRetriever to get bitmaps for a set of operators at a timestamp
| * @dev This function will eject as many operators as possible without reverting | ||
| * @param _operatorIds The ids of the operators to eject for each quorum | ||
| */ | ||
| function ejectOperators(bytes32[][] memory _operatorIds) external { |
There was a problem hiding this comment.
i feel like ejectOperators(uint8 quorumNumber, bytes32[] calldata _operatorIds) is more in line with our style
There was a problem hiding this comment.
you caught me red handed. now i realize why i wanted that is we want to eject from multiple quorums at the same time
There was a problem hiding this comment.
we could do that outside of the contract too, but ok
| break; | ||
| } | ||
|
|
||
| try registryCoordinator.ejectOperator( |
There was a problem hiding this comment.
why would we not revert if this failed? why would this fail?
There was a problem hiding this comment.
Would fail if the operator leaves the set before ejection is called
src/EjectionManager.sol
Outdated
|
|
||
| /** | ||
| * @notice Ejects operators from the AVSs RegistryCoordinator under a ratelimit | ||
| * @param _operatorIds The ids of the operators to eject for each quorum |
There was a problem hiding this comment.
What's assumed in this parameter by this function?
From the impl below it looks: 1) the caller provides all operators eligible for ejection, but delegate to this function for rate limiting; 2) the operators in each quorum are ordered by priority to eject (in case not all can be ejected, it'll just eject a leading prefix of the array)
Might be good to document the assumptions so the caller knows how to pass the params.
| //if caller is ejector enforce ratelimit | ||
| if( | ||
| msg.sender == ejector && | ||
| quorumEjectionParams[quorumNumber].rateLimitWindow > 0 && |
There was a problem hiding this comment.
seems like this means that no limit will be enforced for new quorums until a limit is explicitly set on this contract for the quorum?
possibly a bit of a "footgun"?
please correct me if I'm reading this wrong though.
There was a problem hiding this comment.
That is correct. My thinking here is that when adding a new quorum, while it is finding its footing we will not want to run automated ejection but reserve the ability to eject without ratelimit in that period. Once the set is more stable the quorum params can be set and offchain can be turned on to run regularly.
| quorumEjectionParams[quorumNumber].rateLimitWindow > 0 && | ||
| stakeForEjection + operatorStake > amountEjectable | ||
| ){ | ||
| stakeEjectedForQuorum[quorumNumber].push(StakeEjection({ |
There was a problem hiding this comment.
why are we pushing and not continuing here?
There was a problem hiding this comment.
Because we do not want to revert if the stake of the ops in the input is greater than the ratelimit. Here we checkpoint the stake ejected inside the ratelimit and then end execution
There was a problem hiding this comment.
oh my bad, i completely misread this
nit: else
Here we introduce the EjectionManager contract, the purpose of which is to enforce a ratelimit on stake for ejections called automatically by an offchain component. The contract prioritizes successful execution over the race conditions of changes in total stake and regular operator deregistration.