-
Notifications
You must be signed in to change notification settings - Fork 324
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
chore: deprecate earningsReceiver #562
Conversation
require( | ||
_operatorDetails[msg.sender].earningsReceiver == address(0), | ||
"DelegationManager.registerAsOperator: operator has already registered" | ||
); |
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 think we should default to setting the value of this deprecated field to zero.
We dont need to keep this require here, but if we plan to repurpose this field later, we need to make sure people aren't already setting it to a nonzero value.
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.
it has already been set to a nonzero value by all existing users 😞
one option I suggested was setting it to the operator's own address, but I think setting it to zero could also be fine.
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.
Since all existing registered operators have nonzero values I thought its best to not make assumptions on whatever value this field is and let it be whatever people have it set to.
If we use this field later, we need to allow for a period for operators to update it and then assume afterwards that it's configured.
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.
ah right i missed that we currently require this to be nonzero. yikes!
if we use this field later... we could do that or we might want to migrate and set it to 0. or set it to a sane default.
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.
See comment above - if we want to leave the option to use this field, we need to ensure it stays zeroed out.
Looks like this PR breaks a Prover rule |
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 personally OK with this, but I would like to see the Prover error fixed prior to merging, as it seems like merging this as-is would cause our CI to fail consistently
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
Description
IDelegationManager.OperatorDetails.earningsReceiver
is not being used as part of payments so to avoid confusion with the upcoming release of Payments we are deprecating this address slot in theOperatorDetails
struct.Since a non-zero address of
earningsReceiver
is being used to check whether an address is an operator or not, theisOperator(operator)
function is now changed to simply checkdelegatedTo[operator] == operator
. That is a operator is an operator iff they are delegated to themselves.Changes
earningsReceiver
to__deprecated_earningsReceiver
isOperator
checks an address is self delegated now_delegate()
no longer checks thestaker
is not delegated and thatoperator
is an operator. It assumes these checks are made prior to the internal call. This was needed to fix operator registration because of howisOperator
was changed.Delegation.t.sol