Sync committee rewards specification is ambiguous in case of zero return #480
Description
When requesting curl -d '["125"]' http://localhost:3500/eth/v1/beacon/rewards/sync_committee/10172928, erigon returns:
{"data":[{"validator_index":"125","reward":"0"}],"execution_optimistic":false,"finalized":false}
Here, the fact that in this epoch this validator is not part of the committee is communicated by the 0 reward, but other implementations return:
$ curl -d '["125"]' https://ethereum-beacon-api.publicnode.com/eth/v1/beacon/rewards/sync_committee/10172928 ; echo
{"execution_optimistic":false,"finalized":false,"data":[]}
an empty array, so the fact that 125 is not member in this epoch is communicated by the missing item in the returned data array.
This ambiguity comes from the spec itself, as it's not explicitly written which is the correct one. This should be addressed, both solutions seems feasible for me, but one should be specified and required.
Both solutions have pros:
- returning zero has the advantage, that the client app can depend on the fact that whatever they requested is always presented in the array,
- returning no data has the advantage, that if somebody is asking for ALL validators, then a smaller data can be returned with only the non-zero values.
If I understand the beacon chain spec correctly, there is no way currently to earn zero rewards when part of the committee:
- you are doing your job: you get reward,
- you are offline: you get penalty.
But I think there is no guarantee that in the future Ethereum2 doesn't want to represent situations when the reward was exactly zero, for any reason. And in this sense returning no data for the case of "not member of committee" sounds better, as that differentiates between zero and no-member situation.