Remove pubkey property from duties

[dapplion]

All duties objects include the pubkey of the relevant validator

https://github.com/ethereum/beacon-APIs/blob/b901afdb33a11d30afb9f614cf522ae548508374/types/validator.yaml#L35-L39

https://github.com/ethereum/beacon-APIs/blob/b901afdb33a11d30afb9f614cf522ae548508374/types/validator.yaml#L65-L69

https://github.com/ethereum/beacon-APIs/blob/b901afdb33a11d30afb9f614cf522ae548508374/types/validator.yaml#L80-L84

The validator index that is always available in the response should be sufficient. Adding the pubkey has a non-trivial cost to the response in serialization time and response data size.

Opening this issue to collect feedback on how other teams are using the pubkey property if any.

[mcdee]

JSON isn't built for speed or size of response, so I'm not sure that attempting to optimize for that within any JSON response is a useful path to go down. And the return sizes of the duty calls is small overall compared to other common calls such as fetching all validators, so not sure that there would be any significant overall gain. I would certainly be very wary about removing items from a public API for these reasons, given that there is no way of knowing who out there may be using it.

There has been discussion around supporting SSZ across the entire range of API calls, which in my opinion seems like a better way to go. If someone cares about size and speed of response they can choose SSZ, if they care about human readability they can use JSON.

[dapplion]

@mcdee The main reason is not the JSON cost itself but

non-trivial cost to the response

Which is mapping validator indexes to serialized pubkeys. At least Lodestar only has a fast cache of validator index to de-serialized pubkeys, so it must use some state to get those keys. Given that we represent the state as a tree navigating the tree say 1000 times per response has a non-trivial cost. It's not critical at all, but I wonder why do we have to pay this price.

There has been discussion around supporting SSZ across the entire range of API calls

Agree this would have a much greater positive impact for the sake of performance.

[ralexstokes]

there is also some interest to eventually move to a world where we can re-use validator slots so that different pubkeys could have the same index. obviously it would not be possible for conflicting pub keys to exist in the state at any single time but there could be software around the protocol that tries to manage indices and accidentally mixes things up due to a stale cache, etc.

[dapplion]

Closing, stale issue without enough traction