-
Notifications
You must be signed in to change notification settings - Fork 171
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
POST endpoints for validators
and validator_balances
#367
Conversation
+1 to this, Rocket Pool uses this and runs into the limitation on |
I'd be happy for this, i do wonder if endpoints like this should support ssz or at least gzip compression, as the response would compress very well... |
GET /eth/v1/beacon/states/{state_id}/validator_balances has same problem with |
can we add this to changelog then I'll approve and merge... |
POST /eth/v1/beacon/states/{state_id}/validators
validators
and validator_balances
Updated the changelog and added a POST for |
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.
Strict improvement, looking forward to adopt in Lodestar
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 - thanks everyone!
Some API users want to fetch large chunks of the validator set, and currently do so using the
id
param in the query string forGET /eth/v1/beacon/states/{state_id}/validators
. However, query strings are usually subject to length limits on both the client and server side. For Lighthouse, we can't extend the length limit without forking our HTTP server (see sigp/lighthouse#4333 (comment)).To remedy this situation, this PR introduces a POST variant of the endpoint which is semantically identical, but passes the IDs and statuses in the request body. This is preferable to a GET request with body, as GETs with bodies do not conform to HTTP standards.
Currently, the only alternatives are sub-optimal:
BeaconState
.I don't think this is a client-engineering problem, because designing a database around its ability to load partial states is not likely to be space-efficient. The most space-efficient schemes known currently use state diffs, which don't (usually) provide the ability to be partially applied. Lighthouse's
tree-states
release track uses a variant of the state diffs described by Anton Nashatyrev here.Hacking query string limits across clients is also unlikely to provide a long-term fix, as every new HTTP client that interacts with the beacon API may impose its own length-limit that breaks compatibility.