Validator identities endpoint. #452
Conversation
In support of ethereum#449.
|
This looks good. Will cross-post and seek more opinions. |
| pubkey: | ||
| $ref: './primitive.yaml#/Pubkey' | ||
| description: "Public key of validator." | ||
| activation_epoch: |
There was a problem hiding this comment.
Why add the activation_epoch? It's a curious in-between of no epoch and all epochs in the validator record
There was a problem hiding this comment.
It's in case validator index reuse comes in, it will allow us to use (index,public key, activation epoch) as a unique identifier for a validator across all time regardless of reuse.
There was a problem hiding this comment.
Index re-use won't come until years down the line if ever. Is it better to do a v2 in 2030 when that happens?
There was a problem hiding this comment.
i was thinking there's no harm having it?
|
I support this. Our validator client currently needs to grab the full validator to get the index |
Curious, do you track the validator status on the VC side? This has a lot of benefits, e.g. not querying duties for exited validators, not registering to builder etc. but it would still require to query the full validator object if we don't include all information in this API to recalculate the status, or include the status itself here, preferably in a format that can be ssz-serialized. |
No, we don't. I agree it would allow for certain optimizations, but I am not sure if it's worth the extra complexity. |
|
I think i prefer the idea that this is a simple index lookup that would allow us to continue to use it in a post index being unique world, and for the rest of the data you have the indices you could look up further info... |
|
we can definitely add this to changes table though... |
Co-authored-by: Nico Flaig <nflaig@protonmail.com>
| match any known validator, no identity will be returned but this will not cause an error. There are no guarantees for the | ||
| returned data in terms of ordering. | ||
|
|
||
| Depending on `Accept` header data can be returned either as JSON or as bytes serialized by SSZ. |
There was a problem hiding this comment.
was wondering if we wanna state this here, seems a bit redundant considering we have a more general note about this now since #457 and it's already implied by the response content type + the Accept header is mentioned there as well.
The reason to add the note is that it seems consistent with other endpoint that support SSZ, however could consider cleaning those up a bit
There was a problem hiding this comment.
i'd be happy to just merge and cleanup as a separate task...
In support of #449.