Verification of beacon LightClientUpdate objects

[kdeme]

This issue is similar as the one created for LightClientBootstrap (https://github.com/ethereum/portal-network-specs/issues/296), but for the LightClientUpdate object.

Similar as for bootstraps, several of the fields can be verified with data from the object. The attested_header can be verified as described in is_valid_light_client_header call.

The next_sync_committee can be verified with a is_valid_merkle_branch check with the provided next_sync_committee_branch against the attested_header.beacon.state_root.

And the finalized_header with the finality_branch against the attested_header.beacon.state_root.

But just as for bootstraps, the additional verification for canonicalness is required.

And as described for the bootstrap, there can be a step 1 and an optional step 2, which allows for backfill.

Step 1

• Don't accept any offered updates when not synced
• Request required updates during sync & store if they are valid
• Once synced, accept, verify and re-gossip new updates

Step 2

Optionally, if we want to support backfill, the same type of proof as explained in the related bootstrap issue could be added.

But differently from bootstraps, this still allows for ambiguity as there are different updates possible due to the sync_aggregate + signature_slot. The best one should be selected based on the is_better_update call. But providing a proof that such update is the best update is not that easy.

This is explained very well in this Light client roadmap document from @etan-status at the section Light client data backfill, where a solution is also proposed on how to do this, but it requires the addition of a field in the BeaconState.

[kdeme]

where a solution is also proposed on how to do this, but it requires the addition of a field in the BeaconState.

There exists an EIP for this: https://eips.ethereum.org/EIPS/eip-7658