proposal(fct_block_proposer_head): OR-group block sources to extend history (~2023-03, not merge-ready) - #294
Draft
samcm wants to merge 1 commit into
Draft
Conversation
…istory Proposal / not merge-ready — see caveats below. The model reads three redundant block-observation sources (gossip event, block event, libp2p gossipsub) but declares them as plain AND dependencies, so beacon_api_eth_v1_events_block_gossip — which only begins once a network has live collection (2025-05-14 on mainnet) — pins the model's backfill floor to 2025-05-14 even though beacon_api_eth_v1_events_block has continuous data from 2023-03 and libp2p_gossipsub from 2024-05. Grouping the three into one OR-group makes the floor the earliest member instead of the latest, mirroring the existing proposer-duty OR-group. This would extend the downstream chain that surfaces the May-2025 cutoffs on the lab consensus overview (fct_block_proposer -> fct_reorg / fct_missed_slot_rate / fct_block_proposal_status / fct_attestation_inclusion_delay) back to ~2023-03 -- roughly two years, not to genesis. These metrics need head-time block observation (orphan/reorg detection), which does not exist before 2023, so 2023-03 is a physical floor, not a modelling choice. BLOCKER: beacon_api_eth_v1_events_block and libp2p_gossipsub_beacon_block each carry a handful of stray pre-collection rows (2020-12: 8800 and 4 rows respectively, then zero until real collection starts). Production runs EXTERNAL_MODEL_MIN_TIMESTAMP=0, so CBT's external min(position) reads those as genesis. With this change the floor would drop to genesis and backfill 2020-12 -> 2023-03 with no block data at all, writing every slot as "missed" -- garbage. This must be paired with excluding those stray rows for the two block sources specifically (the global EXTERNAL_MODEL_MIN_TIMESTAMP is not a safe lever: canonical sources genuinely reach genesis and must not be floored). Claude-Session: https://claude.ai/code/session_01Mp4aKNXPmN6NfMuNGbf3Qm
samcm
force-pushed
the
fix/block-proposer-head-gossip-optional
branch
from
July 13, 2026 03:47
2fa0d3e to
65addbe
Compare
samcm
changed the title
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
1 participant
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.
Proposal, not merge-ready — read the blocker.
fct_block_proposer_headreads three redundant block-observation sources (gossip event, block event, libp2p gossipsub) but declares them as plain AND dependencies, sobeacon_api_eth_v1_events_block_gossip— which only starts once a network has live collection (2025-05-14 on mainnet) — pins the model's backfill floor to 2025-05-14. OR-grouping the three makes the floor the earliest member instead of the latest (confirmed against the engine: an OR-group's range isMIN(members)), mirroring the existing proposer-duty OR-group.How far this actually reaches:
beacon_api_eth_v1_events_blockhas continuous data from 2023-03,libp2p_gossipsub_beacon_blockfrom 2024-05,block_gossipfrom 2025-05. So the real floor this unlocks is ~2023-03, not genesis — a ~2-year gain forfct_block_proposer→fct_reorg/fct_missed_slot_rate/fct_block_proposal_status/fct_attestation_inclusion_delay. These metrics need head-time block observation (to distinguish orphaned/reorged from missed), which does not exist before live collection, so 2023-03 is a physical floor, not a modelling choice. (The canonical-sourced sections — attestation participation, head-vote correctness — already reach genesis and are unaffected by this.)Blocker (why this must not be merged alone):
beacon_api_eth_v1_events_blockandlibp2p_gossipsub_beacon_blockeach carry a few stray pre-collection rows — 8,800 and 4 rows in Dec 2020 respectively, then zero until real collection begins. Production runsEXTERNAL_MODEL_MIN_TIMESTAMP=0, so CBT's externalmin(position)reads those stray rows as genesis. With this change the floor would drop to genesis and backfill 2020-12 → 2023-03 with no block data at all, writing every slot as "missed" — garbage that then propagates downstream. This change only becomes safe once those stray rows are excluded for the two block sources specifically. The globalEXTERNAL_MODEL_MIN_TIMESTAMPis not a safe lever, because the canonical sources genuinely reach genesis and must not be floored.One further semantics note for whoever picks this up: forward-fill uses union bounds, so at the head the model would advance to the fastest of the three block sources rather than waiting for the slowest. That is safe in practice (the proposer-duty completeness gate with its 1h settling window is the binding head constraint, and block roots are deterministic content), but it is a behavior change worth a conscious sign-off.