Electra introduces two changes that affect light client data handling:
1. The `ExecutionPayloadHeader` is extended with new fields.
This is handled similarly as before with the Deneb fork.
2. The `BeaconState` generalized indices change due to lack of EIP-6493.
This is handled by making the generalized index be fork dependent via
a helper function that computes it dynamically. Furthermore, the case
where pre-Electra light client data is consumed by an Electra based
`LightClientStore` requires normalizing the shorter proof of the
pre-Electra data to fit into the Electra data structure by prepending
a zero hash.
When new finality is reached without supermajority sync committee
support, trigger another event push on beacon-API and libp2p once
the new finality gains supermajority support.
Without this, if the first `LightClientFinalityUpdate` that advances
finality has low participation, light clients monitoring gossip would
likely get stuck until the next time when finality advances (1 epoch).
Thanks to @DragonDev1906 for reporting this issue to Nimbus:
- https://github.com/status-im/nimbus-eth2/issues/5491
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`
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.
Future light client protocol extensions may include data from the block
in addition to data from the state, e.g., `ExecutionPayloadHeader`.
To prepare for this, also pass the block to the corresponding functions.
In practice, blocks access is easier than historic state access, meaning
there are no practical limitations due to this change.
Add more detailed LC object documentation to explain that the various
merkle proofs are relative to the beacon block's state root.
Likewise, clarify that sync committees relate to the finalized header
(not to the optimistic header, which can be a period ahead).
For LC gossip, the documentation did not specify what slot number to use
for deriving the gossip objects. This missing documentation is now added
to document using `attested_header.slot`.
Etan Kissling
Hsiao-Wei Wang
dapplion
terence tsao
Danny Ryan
Mikhail Kalinin
GeemoCandama
Michael Sproul
Michael Sproul
Alex Stokes