Introduce `get_lc_beacon_slot` and `get_lc_beacon_root` accessors
similar to `get_current_slot(state)` to account for future extensions
to the light client header structure that may override how those fields
are accessed. Idea is to extend with execution accessors in the future.
Future light client tests will also incorporate execution payload data.
To avoid confusion, rename the current `root` check to `beacon_root`.
Doing this now, as #3066 already requires LC test runners to update.
Currently, `test_single_merkle_proof` only supports `BeaconState` tests.
For future tests, different object classes are desirable. Update format
to allow testing other objects as well.
Replaces `process_slot_for_light_client_store` which force updates the
`LightClientStore` automatically based on `finalized_header` age with
`try_light_client_store_force_update` which may be manually called based
on use case dependent heuristics if light client sync appears stuck.
Not all use cases share the same risk profile.
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.
`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
The existing README has a reference to an alias type `Bytes[N]` that has been removed from the repo so it is not clear what it exactly refers to.
This PR updates the type to the equivalent `List[T, N]` using more recent SSZ typing syntax.
Building merkle proofs is required functionality for implementing light
client sync. Although the spec currently only defines a function to
verify merkle proofs (`is_valid_merkle_branch`) there are still a few
PySpec unit tests that produce merkle proofs. This patch adds a new
generator to extract test vectors from those static unit tests, so that
light client implementations can validate their merkle proof logic.
Note that to execute on_attestation after on_block
Output more checking field
Disable mainnet config test_filtered_block_tree
Fix after rectoring + use more run_on_block
Fix and refactor `tick_and_run_on_attestation`
1. Make sure that BLS -Verify APIs would only return `True` or `False` , no exceptions.
2. Use `eth2spec.utils.bls` instead of py_ecc for test generator
3. Add assertions in test generator
4. Add some special test cases for the -Verify APIs
5. Clean up the test format documents
* `block_header` operation to accept input of type `BeaconBlock`
* `voluntary_exit` operation to accept input of type
`SignedVoluntaryExit`.
* sanity/blocks to note that inputs are of type `SignedBeaconBlock`
Etan Kissling
Hsiao-Wei Wang
terence tsao
Mikhail Kalinin
Danny Ryan
Alex Stokes
protolambda
Dmitrii Shmatko
Hsiao-Wei Wang
Nathaniel Jensen