From dd65aa0cb2b74e8ac7639737fa164b70e6439578 Mon Sep 17 00:00:00 2001 From: Etan Kissling Date: Tue, 14 Nov 2023 22:28:16 -0800 Subject: [PATCH] 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 --- specs/altair/light-client/full-node.md | 2 +- specs/altair/light-client/p2p-interface.md | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/specs/altair/light-client/full-node.md b/specs/altair/light-client/full-node.md index 27651af01..612faafe7 100644 --- a/specs/altair/light-client/full-node.md +++ b/specs/altair/light-client/full-node.md @@ -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` diff --git a/specs/altair/light-client/p2p-interface.md b/specs/altair/light-client/p2p-interface.md index 63e1ac437..c33d887a5 100644 --- a/specs/altair/light-client/p2p-interface.md +++ b/specs/altair/light-client/p2p-interface.md @@ -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.