eth2.0-specs/tests/formats/light_client/update_ranking.md

# `LightClientUpdate` ranking tests

This series of tests provides reference test vectors for validating that `LightClientUpdate` instances are ranked in a canonical order.

## Test case format

### `meta.yaml`

```yaml
updates_count: int  -- integer, decimal
```

### `updates_<index>.ssz_snappy`

A series of files, with `<index>` in range `[0, updates_count)`, ordered by descending precedence according to `is_better_update` (best update at index 0).

Each file is a SSZ-snappy encoded `LightClientUpdate`.

## Condition

A test-runner should load the provided `update` objects and verify that the local implementation ranks them in the same order. Note that the `update` objects are not restricted to a single sync committee period for the scope of this test.
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			# `LightClientUpdate` ranking tests

			This series of tests provides reference test vectors for validating that `LightClientUpdate` instances are ranked in a canonical order.

			`## Test case format`

			### `meta.yaml`

			```yaml
			`updates_count: int -- integer, decimal`
			```

			### `updates_<index>.ssz_snappy`

			A series of files, with `<index>` in range `[0, updates_count)`, ordered by descending precedence according to `is_better_update` (best update at index 0).

			Each file is a SSZ-snappy encoded `LightClientUpdate`.

			`## Condition`

			A test-runner should load the provided `update` objects and verify that the local implementation ranks them in the same order. Note that the `update` objects are not restricted to a single sync committee period for the scope of this test.