ethereum / ethereum/beacon-APIs

Sync committee rewards specification is ambiguous in case of zero return

Open
#480 5 comments 0 reactions 0 assignees View on GitHub
Dominant language
HTML
Stars
389
Forks
224
Avg merge
8h 29m
Merged PRs (30d)
3

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.

Contributor guide

No contributing guide indexed for this repository

Research direction

Review the sync_committee rewards endpoint example in the issue and the corresponding beacon API specification. Compare the two observed response shapes and check how the specification describes non-members and zero rewards. Done means the specification explicitly defines one required response behavior and distinguishes committee membership from an actual zero reward.

Written by the indexing model from the issue text.

Assessment

Tech stack
openapi
Domain
api, documentation
Issue type
Documentation
Difficulty
5/5
Estimated time
Over a week
Activity status
Stale
Clarity
Mostly clear
Newbie friendliness
25/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.