Sync committee rewards specification is ambiguous in case of zero return

[errge]

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.

[nflaig]

Doesn't the description clarify this already?

beacon-APIs/apis/beacon/rewards/sync_committee.yaml

Line 4 in 02d595d

description: Retrieves rewards info for sync committee members specified by array of public keys or validator index. If no array is provided, return reward info for every committee member.

"for sync committee members" and "for every committee member", I would not expect this api to return any data for a validator that is not part of the sync committee

[errge]

I would say if erigon got it wrong, then maybe the clarification is not good enough.

Would it hurt to be explicit? Do we want to keep the specification as small as possible?

[nflaig]

Would it hurt to be explicit?

seems like a good idea to add more explicit note

[errge]

erigontech/erigon#12302

In the meantime I fixed this in erigon, so no urgency at all, thanks for the comments!