Choose which Ethereum headers to track in Ethereum light client

[cor]

Either Finalized or Justified (@aeryz will expand this issue)

[aeryz]

Let me explain first on how the data is generated and, how it is used during the verification.

Generation phase

Lodestar stores three checkpoints:

• finalized_checkpoint: 2 epochs behind the current head
• current_justified_checkpoint: 1 epoch behind the current head
• previous_justified_checkpoint: I expect this to be the same as the finalized but I need to look at why this exists. It might be because of checking if we would be able to justify a new block after a new epoch (edge case but possible).

Currently in the update data, we get these two fields:

• finalized_header: lodestar puts finalized_checkpoint's data here
• finality_branch: lodestar generates the merkle path to the index at get_generalized_index(attested_block, 'finalized_header', 'root'). See it on the spec.

Since there is no use case to use both of the finality checkpoints at a single time, we don't need to provide both of them in the update data. Changing the update data generation process to return the info about justified header by keeping the data type the same is easiest to handle in lodestar and also in voyager and the ethereum-light-client.

Therefore, I changed lodestar to do the following:

1. Use current_justified_checkpoint when generating the finalized_header data.
2. When generating finality_branch, use the correct index. Currently this index is referred to FINALIZED_ROOT_INDEX which is 105. This is calculated by using the function that I talked about previously. So, by using the python spec (which is used to programmatically test the spec, which is very cool), I calculated the index for the justified header by calling this: get_generalized_index(BeaconState, 'current_justified_checkpoint', 'root) which is 103. And I generated the merkle path for this index.

Verification phase

The only difference is when we check the merkle root. Currently, we have attested_header and finalized_header in the update data. And state_root of attested_header can be used to verify that finalized_header is present at a specific index (which is 105 for finalized). We do this check like this:

   let finalized_root = update.finalized_header.beacon.tree_hash_root();

    validate_merkle_branch(
        &finalized_root.into(),
        &update.finality_branch,
        floorlog2(FINALIZED_ROOT_INDEX),
        get_subtree_index(FINALIZED_ROOT_INDEX),
        &update.attested_header.beacon.state_root,
    )?;

So to create a verifier that is capable of verifying both the justified and the finalized checkpoints, we are going to add this choice to the LightClientContext trait so that the light clients can specify which one they want to track.

enum Finality {
    Justified,
    Finalized,
}

trait LightClientContext {
    fn finality_choice(&self) -> Finality;
}

By adding this capability to the context trait, we won't have to deploy two different contracts each time to track finalized and justified headers but we will specify the finality that we want to track during the instantiation of the light client by putting it to the ethereum::ClientState.

[aeryz]

We are going to support both headers