-
Notifications
You must be signed in to change notification settings - Fork 30
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
Updated sweep calculation #577
base: feat/oracle-v5
Are you sure you want to change the base?
Conversation
70897c6
to
d0cf8f4
Compare
d0cf8f4
to
1725e61
Compare
1725e61
to
5d3d2d2
Compare
fb335f7
to
0160038
Compare
0160038
to
8e089b3
Compare
74b8b8e
to
41e6a6f
Compare
@@ -286,19 +279,31 @@ def _get_latest_exit_epoch(self, blockstamp: ReferenceBlockStamp) -> tuple[Epoch | |||
def _get_sweep_delay_in_epochs(self, blockstamp: ReferenceBlockStamp) -> int: |
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.
Maybe just split function into two
_get_sweep_delay_in_epochs_v1
_get_sweep_delay_in_epochs_v3
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.
OK, done.
return [ | ||
v | ||
for v in self.w3.cc.get_validators(blockstamp) | ||
if is_partially_withdrawable_validator(v) or is_fully_withdrawable_validator(v, blockstamp.ref_epoch) |
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.
Would we like to tweak the is_partially_withdrawable_validator
function a bit to take into account validators with balances 32 ETH exactly?
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.
No. In the current approach it looks like it's better to not add such an assumption for prediction.
Thing to consider: the spec-like logic is heavy, but has almost the same results as the current approach with no pending withdrawals; pending withdrawals have meaningful effect when there are thousands of them which doesn't seem to me as a case for mainnet.
It seems the old algo has an error due to rounding down via
int()
.Next steps: I would decide to go or not to go with the new algo. From my perspective it's better to abandon it and use the old approach with an updated multiplier to cover the case with pending withdrawals.