# 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`)