# Dev Update #4
Hi :wave:,
In my [last update](https://hackmd.io/@lODlsf2CR9uWlyIyEdjjPQ/HJhEF6wVj), I concentrated on the *rewards structure for validators*. Since then, I have primarily worked on two things:
1. Wrote a guide for the [Lighthouse book](https://lighthouse-book.sigmaprime.io/intro.html) on how to [**run a node**](https://github.com/sigp/lighthouse/pull/3681).
2. Created a [**pull request**](https://github.com/ethereum/beacon-APIs/pull/260) with two ```per-validator reward``` endpoints for the [```beacon-APIs```](https://github.com/ethereum/beacon-APIs).

*This* development update is about the implementation of the endpoints, while the guide was more of a side quest.

## Preface
I started the [EPF](https://github.com/eth-protocol-fellows/cohort-three) by building a [dashboard](https://kevinbogner-data-analysis-consensus-clients-app-lz484x.streamlit.app/) for consensus client data. However, currently, there is no source to get ```per-validator rewards```. Therefore, [sproul](https://github.com/michaelsproul) created an [issue](https://github.com/sigp/lighthouse/issues/3661) to describe the problem with possible solutions.

I quickly decided to team up with [naviechan](https://github.com/naviechan), who is also part of the [EPF](https://github.com/eth-protocol-fellows/cohort-three), to work on this problem. Our work this week consisted of two parts:
1. Discussing and answering the [design questions](https://github.com/sigp/lighthouse/issues/3661#issuecomment-1304482857).
2. Working on the [pull request](https://github.com/ethereum/beacon-APIs/pull/260) for the [```beacon-APIs```](https://github.com/ethereum/beacon-APIs).

In the following sections, I will explain on how we proceeded with these tasks.

## [Design questions](https://github.com/sigp/lighthouse/issues/3661#issuecomment-1304482857)
There are *three* main design questions (DQs) that [naviechan](https://github.com/naviechan) and I iterated on:

> Should the new reward APIs operate on a single block/epoch or a range?

The reward API *should* operate on a single block/epoch for consistency with the rest of the [```beacon-APIs```](https://github.com/ethereum/beacon-APIs). Running on a range may be more efficient on the Lighthouse side, but it might be different for other clients. Further, there might be upcoming updates to the Lighthouses database, which reduce the size of archive nodes.

> Should attestation rewards include a breakdown by head/target/source?

For the granularity of the data returned from the API, a breakdown of source/target/head vote reward is valuable. Additionally, the technical difficulty of implementing each of the three should be similar. Attestation rewards are *84.4%* of the total validator reward, so that a breakdown would be handy.

> Should block rewards include a breakdown by included attestations, sync aggregate, slashings?

For block reward data (i.e., sync committee and proposer), it is desirable to provide such a breakdown. From [```beacon-APIs'```](https://github.com/ethereum/beacon-APIs) perspective, including the block reward is ideal for completeness. However, if we believe such data is useless and not worth the development effort, we can forget about it.

The [comment](https://github.com/sigp/lighthouse/issues/3661#issuecomment-1304482857) got approved by sproul, so we moved on with creating a draft pull request with two endpoints to the [```beacon-APIs```](https://github.com/ethereum/beacon-APIs).

## [Pull request](https://github.com/ethereum/beacon-APIs/pull/260) for [```beacon-APIs```](https://github.com/ethereum/beacon-APIs)
Our two proposed endpoints look like the following:

---

*Get block rewards*

{
"proposer_index": "123",
"total": "5000",
"attestations": "3000",
"sync_aggregate": "2000",
"proposer_slashings": "0",
"attester_slashings": "0",
}

---

*Get attestation rewards*

{
  "data": [
    {
      "validator_index": 0,
      "head": 2000,
      "target": 4000,
      "source": 4000
    }
  ]
}

---

While we already got some work done, there is still a lot of stuff to do, especially the implementation into Lighthouse.

## Next steps
Once the PR gets approved and merged, the next logical step would be to implement the endpoints to Lighthouse. It is hard to predict how long this will take, but it is the next major milestone in my [EPF](https://github.com/eth-protocol-fellows/cohort-three) journey. Midterm, I plan to use the API to display the data in my [dashboard](https://kevinbogner-data-analysis-consensus-clients-app-lz484x.streamlit.app/).

So far, the [EPF](https://github.com/eth-protocol-fellows/cohort-three) has been an exceptional experience. People like [sproul](https://github.com/michaelsproul) and [naviechan](https://github.com/naviechan) make the work exciting and enjoyable. I'm looking forward to the following weeks :blush:.