eth2.0-specs/tests/formats/sync_protocol/README.md

# Light client sync protocol tests

This series of tests provides reference test vectors for the light client sync protocol spec.

Handlers:
- `light_client_sync`: see [Light client sync test format](./light_client_sync.md)
- `update_ranking`: see [`LightClientUpdate` ranking test format](./update_ranking.md)
Root `next_sync_committee` in `attested_header` `LightClientUpdate` structures currently use different merkle proof root depending on the presence of `finalized_header`. By always rooting it in the same state (the `attested_header.state_root`), logic gets simpler. Caveats: - In periods of extended non-finality, `update.finalized_header` may now be outdated by several sync committee periods. The old implementation rejected such updates as the `next_sync_committee` in them was stale, but the new implementation can properly handle this case. - The `next_sync_committee` can no longer be considered finalized based on `is_finality_update`. Instead, waiting until `finalized_header` is in the `attested_header`'s sync committee period is now necessary. - Because `update.finalized_header > store.finalized_header` no longer holds (for updates with finality), an `is_better_update` helper is added to improve `best_valid_update` tracking (in the past, finalized updates with supermajority participation would always directly apply) This PR builds on prior work from: - @hwwhww at https://github.com/ethereum/consensus-specs/pull/2829 2022-04-29 14:22:26 +00:00			`# Light client sync protocol tests`

			`This series of tests provides reference test vectors for the light client sync protocol spec.`

			`Handlers:`
Add functions for deriving light client data Adds `create_light_client_bootstrap` and `create_light_client_update` functions as a reference implementation for serving light client data. This also enables a new test harness to verify that light client data gets applied to a `LightClientStore` as expected. 2022-05-02 23:17:46 +00:00			- `light_client_sync`: see [Light client sync test format](./light_client_sync.md)
Root `next_sync_committee` in `attested_header` `LightClientUpdate` structures currently use different merkle proof root depending on the presence of `finalized_header`. By always rooting it in the same state (the `attested_header.state_root`), logic gets simpler. Caveats: - In periods of extended non-finality, `update.finalized_header` may now be outdated by several sync committee periods. The old implementation rejected such updates as the `next_sync_committee` in them was stale, but the new implementation can properly handle this case. - The `next_sync_committee` can no longer be considered finalized based on `is_finality_update`. Instead, waiting until `finalized_header` is in the `attested_header`'s sync committee period is now necessary. - Because `update.finalized_header > store.finalized_header` no longer holds (for updates with finality), an `is_better_update` helper is added to improve `best_valid_update` tracking (in the past, finalized updates with supermajority participation would always directly apply) This PR builds on prior work from: - @hwwhww at https://github.com/ethereum/consensus-specs/pull/2829 2022-04-29 14:22:26 +00:00			- `update_ranking`: see [`LightClientUpdate` ranking test format](./update_ranking.md)