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.
- Implement all the required glue code to make things executable
- Implement a dummy KZG trusted setup
Co-authored-by: Hsiao-Wei Wang <hsiaowei.eth@gmail.com>
- Move more code into polynomial-commitments.md
- Implement aggregated sidecar verification logic from PR #2915
- Rename `kzgs` to `kzg_commitments`
Co-authored-by: Hsiao-Wei Wang <hsiaowei.eth@gmail.com>
Introduces a new `LightClientBootstrap` structure to allow setting up a
`LightClientStore` with the initial sync committee and block header from
a user-configured trusted block root.
This leads to new cases where the `LightClientStore` is only aware of
the current but not the next sync committee. As a side effect of these
new cases, the store's `finalized_header` may now advance into the next
sync committee period before a corresponding `LightClientUpdate` with
the new sync committee is obtained, improving responsiveness.
Note that so far, `LightClientUpdate.attested_header.slot` needed to be
newer than `LightClientStore.finalized_header.slot`. However, it is now
necessary to also consider certain older updates to try and backfill the
`next_sync_committee`. The `is_better_update` helper is also updated to
improve `best_valid_update` tracking.
`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
Various cleanups and minor fixes:
- Consistent terminology:
- `signed_block` -> `attested_block`
- `finalized_block_header` -> `finalized_header`
- `snapshot_period` -> `store_period`
- Use correct block in finality test (`blocks[-1]` instead of new one)
- Add `signed_block_header` func to get header from `SignedBeaconBlock`
- Remove `block_header` from `get_sync_aggregate` helper arguments
- Use `state_transition_with_full_block` as shortcut for multiple calls
- Have `finalized_header` actually be header instead of full block body
- Consistent ordering of `assert` to match structure definition
Etan Kissling
Hsiao-Wei Wang
Danny Ryan
George Kadianakis
Alex Stokes