When calling `get_sync_aggregate` with a `signature_slot - 1` in a
future fork, i.e., the first slot of the new fork is missed, it uses
a wrong fork version for the signature. Fix that by correctly applying
fork transitions to the `signature_state`, if a fork schedule is given.
The two functions `compute_start_slot_at_sync_committee_period` and
`compute_start_slot_at_next_sync_committee_period` are currently only
available during LC `test_sync`. Move them to the common LC test module
so that they can be used from future tests as well.
The helpers needed to migrate LC data across forks are generic enough to
allow extraction from a specific test into the common `light_client.py`
helper module. This way, it is possible to use them from future tests.
Also complete the missing functions for `LightClientFinalityUpdate`,
`LightClientOptimisticUpdate` and `LightClientHeader` in same style.
To assist with readability, use `_GINDEX` suffix when referring to
generalized index constants.
Does neither affect consensus, beacon-API nor builder API.
- Sync committee is determined by signature_slot
- Signature fork version is determined by max(signature_slot, 1) - 1
- Attested block fork version can be anything < signature_slot
Old logic incorrectly derived signature fork version from signature_slot
and did not subtract a slot. Extended tests to check this edge case.
In Altair, light client sync protocol exchanges `BeaconBlockHeader`
structures for tracking current progress. Wrapping `BeaconBlockHeader`
inside a `LightClientHeader` allows future extensions of this header,
e.g., to also track `ExecutionPayloadHeader`.
Note: This changes the JSON REST format by adding a `beacon` nesting.
For SSZ, the serialization format stays same (but overall root changes).
* Add @description decorator
* Unify test case naming style
* more clean ups
* Altair tests cleanup
* Clean up Altair and Bellatrix `process_deposit` tests
* Clean up Bellatrix tests
* Clean up Capella tests
* PR feedback from @ralexstokes
* Add comments on the deposit fork version tests
* Remove `test_incorrect_sig_other_version` since it is duplicate to `test_ineffective_deposit_with_bad_fork_version`
* Add `test_ineffective_deposit_with_current_fork_version`
While the light client sync protocol currently provides access to the
latest `BeaconBlockHeader`, obtaining the matching execution data needs
workarounds such as downloading the full block.
Having ready access to the EL state root simplifies use cases that need
a way to cross-check `eth_getProof` responses against LC data.
Access to `block_hash` unlocks scenarios where a CL light client drives
an EL without `engine_newPayload`. As of Altair, only the CL beacon
block root is available, but the EL block hash is needed for engine API.
Other fields in the `ExecutionPayloadHeader` such as `logs_bloom` may
allow light client applications to monitor blocks for local interest,
e.g. for transfers affecting a certain wallet. This enables to download
only the few relevant blocks instead of every single one.
A new `LightClientStore` is proposed into the Capella spec that may be
used to sync LC data that includes execution data. Existing pre-Capella
LC data will remain as is, but can be locally upgraded before feeding it
into the new `LightClientStore` so that light clients do not need to run
a potentially expensive fork transition at a specific time. This enables
the `LightClientStore` to be upgraded at a use case dependent timing at
any time before Capella hits. Smart contract and embedded deployments
benefit from reduced code size and do not need synchronization with the
beacon chain clock to perform the Capella fork.
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.
Introduce `block_to_light_client_header` helper function to enable
future forks to override it with additional info (e.g., execution),
without having to change the general light client logic.
Likewise, update existing light client data creation flow to use
`block_to_light_client_header` and default-initialize empty fields.
Furthermore, generalize `create_update` helper to streamline test code
using `block_to_light_client_header`.
Note: In Altair spec, LC header is the same as `BeaconBlockHeader`.
however; future forks will extend it with more information.
When defining a fork transition test, additional spec forks are made
available through `@with_phases(..., other_phases=...)`.
The `with_config_overrides` decorator only applies to the primary phase
so far, which can be unexpected. `with_config_overrides` is adjusted to
override config in subsequent `other_phases` as well.
