Gossip additional `LightClientFinalityUpdate` on new supermajority

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
This commit is contained in:
Etan Kissling 2023-11-14 22:28:16 -08:00
parent 36f0bb0ed6
commit dd65aa0cb2
No known key found for this signature in database
GPG Key ID: B21DA824C5A3D03D
2 changed files with 2 additions and 2 deletions

View File

@ -158,7 +158,7 @@ def create_light_client_finality_update(update: LightClientUpdate) -> LightClien
)
```
Full nodes SHOULD provide the `LightClientFinalityUpdate` with the highest `attested_header.beacon.slot` (if multiple, highest `signature_slot`) as selected by fork choice, and SHOULD support a push mechanism to deliver new `LightClientFinalityUpdate` whenever `finalized_header` changes.
Full nodes SHOULD provide the `LightClientFinalityUpdate` with the highest `attested_header.beacon.slot` (if multiple, highest `signature_slot`) as selected by fork choice, and SHOULD support a push mechanism to deliver new `LightClientFinalityUpdate` whenever `finalized_header` changes. If that `LightClientFinalityUpdate` does not have supermajority (> 2/3) sync committee participation, a second `LightClientFinalityUpdate` SHOULD be delivered for the same `finalized_header` once supermajority participation is obtained.
### `create_light_client_optimistic_update`

View File

@ -59,7 +59,7 @@ New global topics are added to provide light clients with the latest updates.
This topic is used to propagate the latest `LightClientFinalityUpdate` to light clients, allowing them to keep track of the latest `finalized_header`.
The following validations MUST pass before forwarding the `finality_update` on the network.
- _[IGNORE]_ The `finalized_header.beacon.slot` is greater than that of all previously forwarded `finality_update`s
- _[IGNORE]_ The `finalized_header.beacon.slot` is greater than that of all previously forwarded `finality_update`s, or it matches the highest previously forwarded slot and also has a `sync_aggregate` indicating supermajority (> 2/3) sync committee participation while the previously forwarded `finality_update` for that slot did not indicate supermajority
- _[IGNORE]_ The `finality_update` is received after the block at `signature_slot` was given enough time to propagate through the network -- i.e. validate that one-third of `finality_update.signature_slot` has transpired (`SECONDS_PER_SLOT / INTERVALS_PER_SLOT` seconds after the start of the slot, with a `MAXIMUM_GOSSIP_CLOCK_DISPARITY` allowance)
For full nodes, the following validations MUST additionally pass before forwarding the `finality_update` on the network.