Add endpoints for block and attestation rewards

[kevinbogner]

Issue: sigp/lighthouse#3661

Currently, there is no way to get block rewards paid on the consensus side. Therefore, we propose two endpoints.

/eth/v1/beacon/rewards/blocks/{block_id}

Get block rewards

{
  "execution_optimistic": false,
  "finalized": false,
  "data": {
    "proposer_index": "123",
    "total": "123",
    "attestations": "123",
    "sync_aggregate": "123",
    "proposer_slashings": "123",
    "attester_slashings": "123"
  }
}

---

/eth/v1/beacon/rewards/attestations/{epoch}

Get attestation rewards

{
  "execution_optimistic": false,
  "finalized": false,
  "data": [
    {
      "ideal_rewards": [
        {
          "effective_balance": "1000000000",
          "head": "2500",
          "target": "5000",
          "source": "5000"
        }
      ],
      "total_rewards": [
        {
          "validator_index": "0",
          "head": "2000",
          "target": "2000",
          "source": "4000",
          "inclusion_delay": "2000"
        }
      ]
    }
  ]
}

[michaelsproul]

This is awesome! Thanks @naviechan & @kevinbogner!

In addition to the minor edits I've proposed the main thing missing is an API for the sync committee rewards. I didn't describe one in my original messages, but it should be similar to the others, maybe something like:

/eth/v1/beacon/blocks/{block_id}/sync_committee_rewards?id=...

{
    "data": [
        {
            "validator_index": "0",
            "reward": "-1000",
        },
        {
            "validator_index": "1",
            "reward": "1000",
        },
    ]
}

The function that defines these rewards is here: https://github.com/ethereum/consensus-specs/blob/dev/specs/altair/beacon-chain.md#sync-aggregate-processing

I'd be open to speccing that endpoint in a separate PR if you like! Maybe one of you could take that on while the other updates the existing endpoints

[michaelsproul]

We're getting super close to being ready to merge. I think this is probably the final round of review from me before we can pass it to the other maintainers for merging!

[michaelsproul]

Ship it!

[rolfyone]

as a nit, can we updated the endpoints to :
/eth/v1/beacon/rewards/blocks/{block_id}
/eth/v1/beacon/rewards/attestations/{epoch}

[kevinbogner]

Thanks @rolfyone
I changed the endpoints and the folder structure. It should look cleaner now

[zah]

In the Nimbus codebase, we have a set of routines which can produce not only the obtained rewards, but also the maximum reward that was possible if your attestations were perfect. This allows the creation of UIs and reports which focus on the deviation from perfect behavior. In other words, if a validator produces a wrong head vote for example (while hitting source and target correctly), this can be seen as an opportunity cost (a negative score) instead of as a positive increase of the balance.

[michaelsproul]

@zah Great idea! I think all the clients will end up with that data on-hand while computing the attestation rewards, it's just a matter of how to present it.

We could take advantage of the fact that the rewards are fixed per effective balance with something like:

{
    "ideal_rewards": [
        {
            "effective_balance": "1000000000",
            "head": "2500",
            "target": "5000",
            "source": "5000"
        },
        {
            "effective_balance": "2000000000",
            "head": "2500",
            "target": "5000",
            "source": "5000"
        }
    ],
    "rewards": [
        {
            "validator_index": "0",
            "effective_balance": "32000000000",
            "head": "0",
            "target": "5000",
            "source": "5000",
        }
    ],
}

Or maybe a null-able field per reward component?

{
    "rewards": [
        {
            "validator_index": "0",
            "head": "0",
            "ideal_head": "2500",
            "target": "5000",
            "source": "5000",
        },
        {
            "validator_index": "1",
            "head": "0",
            "ideal_head": "2500",
            "target": "-5000",
            "ideal_target": "5000",
            "source": "-5000",
            "ideal_source": "5000",
        }
    ],
}

This has the advantage of being smaller over the wire when the majority of requested validators are behaving optimally, however it introduces more duplication when there is a lot of sub-optimal voting. I think I have a slight preference for the first effective_balance approach.

Another option would be an entirely separate API for the ideal reward information. However I don't think this would really be simpler, and it would likely be less efficient.

[rolfyone]

LGTM