-
Notifications
You must be signed in to change notification settings - Fork 83
Monitor Random Beacon sortition pool status: join pool and update pool #3077
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
Conversation
Moved `local.go` to `sortition/internal/local` to keep it in a separate package from `sortition`. `connectLocal` renamed to `Connect`, `registerOperator` and `setEligibleStake` are now exported.
MonitorPool periodically checks the status of the operator in the sortition pool. If the operator is supposed to be in the sortition pool but is not there yet, the function attempts to add the operator to the pool. If the operator is already in the pool and its status is no longer up to date, the function attempts to update the operator's status in the pool.
Simplified if/else condition in IsOperatorUpToDate. The behavior is the same as before.
Two errors were not handled properly: one from JoinSortitionPool and another from UpdateOperatorStatus. Now, they are handled just by logging them. The operation will be retried on the next monitoring loop pass.
The new file name clearly indicates what is inside of the file.
The client monitors the sortition pool status now. There is a complication with ethereum chain - the v2 implementation does not support v1 ethereum chain functions and the v1 implementation does not support v2 functions. For now, both instances are passed. In the future, we will decide if we want to port features to v2 gradually or cut the entire v1 chain in one move altogether. Note that from now on, `RandomBeacon` contract address must be specified in the config file. Old contract addresses still need to be there but the values do not matter.
|
All changes pushed, I am undrafting this PR @lukasz-zimnoch |
It makes sense to make the Chain structure exported because the exported Connect function returns it anyway.
This makes more sense given we have `ethereum_v1` package. We will also avoid conflicts in the set of next PRs.
In the previous commit, we renamed `legacyChainProvider` to `chainProviderV1` so `beaconChainV1` makes more sense. This will also allow us avoid conflicts in the next PRs.
|
|
||
| if isOperatorUpToDate { | ||
| if isOperatorInPool { | ||
| logger.Infof("sortition pool operator status is up to date") |
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 can use just logger.Info, not logger.Infof cause there's nothing to format here. Same comment for other places like this in this file.
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.
Yeah, good point. Let's fix it when working on #3008.
Depends on #3070Closes #3006
Closes #3007
MonitorPoolperiodically checks the status of the operator in the sortition pool. If the operator is supposed to be in the sortition pool but is not there yet, the function attempts to add the operator to the pool. If the operator is already in the pool and its status is no longer up to date, the function attempts to update the operator's status in the pool.There was a complication with
ethereumchain - the v2 implementation does not support v1ethereumchain functions and the v1 implementation does not support v2 functions. For now, both instances are passed when creating aNode. In the future, we will decide if we want to port features to v2 gradually or cut the entire v1 chain in one move altogether.