Etan Kissling c4dbd241ac
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-07-01 14:49:24 -07:00

22 lines
765 B
Markdown

# `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.