network: make the pubsub topic whitelist slot-aware (#2968 item 3) - #2971
Open
momosh-ssv wants to merge 1 commit into
Open
network: make the pubsub topic whitelist slot-aware (#2968 item 3)#2971momosh-ssv wants to merge 1 commit into
momosh-ssv wants to merge 1 commit into
Conversation
commons.Topics gated the Alan topic set on the coarse BooleFork() epoch snapshot while subscriptions derive per slot from the transition-window predicate, so a node started inside the ~34-slot subsequent window whitelisted Boole-only yet legitimately subscribed to Alan topics for late pre-fork committee traffic - working only incidentally because topicsCtrl.Subscribe self-registers. Take the evaluation slot explicitly and include Alan topics whenever Alan traffic can still be valid at that slot, matching the subscription policy. Item 3 of #2968.
Contributor
Greptile SummaryUpdates the pubsub topic whitelist to use the current slot when deciding whether Alan topics remain valid.
Confidence Score: 5/5The PR appears safe to merge with the topic whitelist correctly aligned to the slot-aware subscription policy. The changed predicate matches the existing transition behavior, its boundary cases are covered, and all callers of the modified Topics signature are updated.
|
| Filename | Overview |
|---|---|
| network/commons/subnets.go | Makes topic selection slot-aware and aligns Alan inclusion with the existing Boole transition-window predicates. |
| network/commons/subnets_test.go | Adds comprehensive topic-set tests covering the fork transition phases and the first slot after the subsequent window. |
| network/topics/pubsub.go | Passes the estimated startup slot into the topic-whitelist construction; the repository's sole production caller is updated. |
Flowchart
%%{init: {'theme': 'neutral'}}%%
flowchart TD
A[NewPubSub startup] --> B[Estimate current slot]
B --> C{Before Boole fork or in transition window?}
C -->|Yes| D[Whitelist Alan and Boole topics]
C -->|No| E[Whitelist Boole topics only]
D --> F[Construct GossipSub filter]
E --> F
Reviews (1): Last reviewed commit: "network: make the pubsub topic whitelist..." | Re-trigger Greptile
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Item 3 of #2968.
commons.Topicsgated the Alan topic set on the coarseBooleFork()epoch snapshot while subscriptions derive per-slot from the transition-window predicate — so a node started inside the ~34-slot subsequent window whitelisted Boole-only yet legitimately subscribes to Alan topics for late pre-fork committee traffic, working only incidentally becausetopicsCtrl.Subscribeself-registers.Topicsnow takes the evaluation slot explicitly and includes the Alan set whenever Alan traffic can still be valid at that slot (!BooleForkAtSlot(slot) || InBooleTransitionWindow(slot)), always including Boole; the sole caller (NewPubSub) passesEstimatedCurrentSlot(). The startup-snapshot design is unchanged — the snapshot just now matches the subscription policy at the same instant.Deep review notes (passed): the include-Alan condition is logically identical to all three per-slot subscription-derivation sites in
network/p2p; the whitelist gates subscriptions/peer-announcements (mesh membership), not message validation, and the widening is confined to the subsequent window where the fork design requires Alan traffic to flow; a node started past the window gets Boole-only with no Alan leak (Boole==0guard verified). Five-phase table test covers pre-fork steady state, prior window, subsequent window (the bug), the exact first slot past the window (the boundary that closes Alan), and well post-fork.