Open
Description
This is a tracking issue of all of the beacon portal network hive test that we would like to get implemented.
1. Test light client sync
Provide valid bootstrap, few light client updates, optimistic and finality updates in order to allow syncing
- Test that the latest optimistic and finalized beacon state roots match the expected
2. Test LightClientBootstrap
interop and validations
- Reject bootstraps if not in sync
Tests that require lc sync:
- Reject bootstraps older than 4 months
- Reject bootstraps with invalid fork digest
- Reject invalid
LightClientHeader
- Reject invalid
current_sync_committee
object - Reject non-canonical
BeaconBlockHeader
- Accept a valid
LightClientBootstrap
3. Test LightClientUpdatesByRange
interop and validations
- Reject updates if not in sync
Tests that require lc sync:
- Reject content if content key
count
field doesn't match the light client updates count in the content value - Reject invalid
attested_header
- Reject invalid
next_sync_committee
- Reject invalid
finalized_header
- Reject non-canonical
attested_header
- Reject non-canonical
finalized_header
- Reject updates with invalid fork digest
- Accept a valid
LightClientUpdate
4. Test HistoricalSummariesWithProof
interop and validations
- Reject content if not in sync
Tests that require lc sync:
- Reject
HistoricalSummariesWithProof
with invalid fork digest - Reject
HistoricalSummariesWithProof
with invalid proof - Accept
HistoricalSummariesWithProof
with a valid proof
5. Test LightClientFinalityUpdate
interop and validations
- Reject content if the key's finalized slot doesn't match the
LightClientFinalityUpdate
finalized slot - Reject update with invalid fork digest
- Accept a valid
LightClientFinalityUpdate
6. Test LightClientOptimisticUpdate
interop and validations
- Reject content if the key's signature slot doesn't match the
LightClientOptimisticUpdate
signature slot - Reject update with invalid fork digest
- Accept a valid
LightClientOptimisticUpdate