# Consensus Rewards - Meeting 1 Notes
## Background
We want to hook into the state transition, which takes a _state_ (type `BeaconState`), and mutates it by applying a block (type `SignedBeaconBlock`).
## Implementation
We want to implement the APIs in the `beacon_node/http_api` crate.
The process for each API will be something like:
- Copy the structure of an existing API handler, e.g. `get_lighthouse_block_rewards`.
- This gives us a `chain` of type `Arc<BeaconChain>` which is our handle to everything
- Using the `chain` we can load the data we need:
- Load a block with [`chain.get_blinded_block(block_root)`](https://github.com/sigp/lighthouse/blob/6d5a2b509fac7b6ffe693866f58ba49989f946d7/beacon_node/beacon_chain/src/beacon_chain.rs#L974-L979).
- Load a state with [`chain.get_state(state_root, None)`](https://github.com/sigp/lighthouse/blob/6d5a2b509fac7b6ffe693866f58ba49989f946d7/beacon_node/beacon_chain/src/beacon_chain.rs#L986-L992)
- Convert a _slot_ into the canonical _block root_ from that slot: `block_id.root(&chain)`.
- Once we have the `block`(s) and `state` that we need, we can compute the rewards using snippets of logic extracted from `consensus/state_processing`.
- We want to avoid modifying `consensus/state_processing` because that code needs to be fast (no extra calculations) and correct (modifying it is medium-risk).
- To keep things clean we should write functions like:
```rust
pub fn compute_sync_committee_rewards<T: BeaconChainTypes>(
chain: &BeaconChain<T>,
state: BeaconState<T::EthSpec>,
block: SignedBlindedBeaconBlock<T::EthSpec>,
) -> Result<SyncCommitteeRewards, Error> {
...
}
```
- For some of the APIs we might want to use the [`BlockReplayer`](https://github.com/sigp/lighthouse/blob/unstable/consensus/state_processing/src/block_replayer.rs). This will be useful if we want to diff the pre-state against the post-state. In hindsight I think this will probably only be relevant for the attestation rewards API where we need to replay multiple blocks.
## Which parts of state processing?
Starting with sync committees, because they're the most straight-forward:
- Spec: https://github.com/ethereum/consensus-specs/blob/dev/specs/altair/beacon-chain.md#sync-aggregate-processing
- Lighthouse: https://github.com/sigp/lighthouse/blob/564d7da656803f5e06e53a303972580be54500bf/consensus/state_processing/src/per_block_processing/altair/sync_committee.rs#L9-L63
The existing `compute_sync_aggregate_reward` function might be useful! (It's fine to call functions from `state_processing`)