-
Notifications
You must be signed in to change notification settings - Fork 65
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
Return metadata fields for relevant endpoints #35
Comments
I'd like to give that some priority as the metadata fields are a important part of these endpoints. |
We also require these fields for correct operation. If we can discuss a plan for the best way to handle these then we can probably contribute time to implement the work. Reading the data from the server is trivial, but the current interface for clients does not provide any way to surface these fields. Listing possible solutions from the top of my head, let's use the API for
Option 1.
Option 2
Option 2a
Option 3
Option 4
My preference would be to do option 3 + 2a. @mcdee would love to hear your thoughts and see if we can align on a direction |
2a is close to my thinking, but we can't have a hard-coded 3 I'm less of a fan of. I'd be more inclined to take the one-off hit of a change in function signatures rather than have multiple functions that do much the same thing. A more radical option is to have a single call that takes a pointer to an empty struct that is then filled by the relevant call; see #67 (comment) for something similar on the submission side. I'm still pondering this, but recognize that the metadata is useful and do want to incorporate it somehow. |
Here is a draft PoC which covers 2a but uses a generic map for metadata. Hopefully it gets the ball rolling a bit - I can continue to work on it if you are happy going in this direction. Let me know how you feel about it. |
#80 has been merged and addresses this item. |
As per the latest beacon-APIs spec, some endpoints contain
execution_optimistic
anddependent_root
fields as part of their response object. This field was added as part of this PR.As of now go-eth2-client doesn't support these fields in some of the relevant endpoints.
dependent_root
field is required to detect reorgs where all validator clients compare thedependent_root
returned fromgetAttesterDuties
beacon API response with the dependent roots received from SSE events forhead
topic. If both of these are different they callgetAttesterDuties
again.In order to support all validator clients and to conform with latest spec, we are suggesting to return these fields as part of response of all the relevant endpoints.
For more details:
getAttesterDuties
: https://ethereum.github.io/beacon-APIs/#/Validator/getAttesterDutiesThe text was updated successfully, but these errors were encountered: