Attestation rewards API doesn't account for justification and finalization

[michaelsproul]

Description

The attestation rewards calculator has a bug where it doesn't update justification and finalization (process_justification_and_finalization) prior to calculating attestation rewards.

This causes faulty output for epoch N - 1 when finality is restored at the end of epoch N. In this case, the is_in_inactivity_leak predicate should be false (because finality has just been restored), but our code will set it to true because it hasn't computed justification & finalization.

On mainnet this occurs at epoch 200759 (i.e. finality restored at the end of 200760).

Relevant code (see earlier in this function for the lack of justification/finalization processing):

lighthouse/beacon_node/beacon_chain/src/attestation_rewards.rs

Lines 169 to 174 in 441fc16

	if !state.is_in_inactivity_leak(previous_epoch, spec)? {
	ideal_rewards_hashmap
	.insert((flag_index, effective_balance), (ideal_reward, penalty));
	} else {
	ideal_rewards_hashmap.insert((flag_index, effective_balance), (0, penalty));
	}

Version

Lighthouse v4.5.0

Steps to resolve

We should probably just run process_justification_and_finalization at the start of attestation rewards calculation. I don't think this should interfere with the block v3 API, as it only needs to calculate the proposer's block reward, which is independent of is_in_inactivity_leak, and shouldn't share code with the attestation rewards calculations.

[zack-scott]

@michaelsproul @jimmygchen I would like to work on this

[michaelsproul]

Closed by #4877