Add REST implementation for ValidatorStatus
#11757
Merged
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
What type of PR is this?
Feature
Related gitHub issue:
#11580
What does this PR do? Why is it needed?
This adds an implementation for the
ValidatorStatus
validator client method by calling the Beacon Node REST API instead of the gRPC one.Notes for reviewers:
Eth1DepositBlockNumber
&DepositInclusionSlot
:In gRPC implementation, the beacon node returns
Eth1DepositBlockNumber
&DepositInclusionSlot
.As far as I know, the Beacon API does not offers easy way to retrieve these data.
Unless I'm mistaken, these data are not used in the Validator Client.
I chose to skip them. Please tell me if this decision is not valid.
Ordered validators
I assumed the call to
/eth/v1/beacon/states/head/validators
returns a sorted (by index) list of validators.However, I was not able to find such a sort requirement in the specification, even if Prysm, Teku and Lighthouse (did not test Nimbus) seem to respect this sort standard.
The advantage of this assumption is, in order to retrieve the last active validator, we just have to get the last element of the list.
(O(1))
Please tell me if such an assumption is not valid.
Position in active queue
I tried to mimic the behaviour of https://github.com/prysmaticlabs/prysm/blob/develop/beacon-chain/rpc/prysm/v1alpha1/validator/status.go#L272.
This implementation assumes that the position in active queue for a given validator is the difference between the index of the validator and the highest index in the set of currently active validators.
If we consider the following case:
Then:
our validator
will be1004 - 1002 = 2
our validator
will be1004 - 1001 = 3
(But I think it's still a good proxy)