Skip to content

Conversation

hopinheimer
Copy link
Member

addresses #7820

I haven't done benches for the change in kurtosis but post results soon

@hopinheimer hopinheimer self-assigned this Aug 18, 2025
@hopinheimer hopinheimer added the val-client Relates to the validator client binary label Aug 18, 2025
event_result.map_err(|e| format!("Head event stream error: {:?}", e))?;
match event {
EventKind::Head(_) => {
trace!("Received head event, triggering early attestation processing");
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This could probably be a debug log (we almost never show trace logs), and could include the slot and block root from the event, as well as something identifying the BN

beacon_nodes: &Arc<BeaconNodeFallback<T>>,
) -> Result<(), String> {
beacon_nodes
.first_success(|beacon_node| async move {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Related, this function is not parallel currently, so this function likely won't work very well if the first BN takes too long:

An alternative would be to maintain event streams from all BNs, and trigger the attestation process as soon as we receive a head event from one of them. However this also has an issue in that we might use a BN to create the attestation that hasn't yet imported the block. E.g. if we have BNs bn1,bn2,bn3 and we get a head event from bn2, then we'll try to attest using bn1, and build an attestation to the previous block because bn1 hasn't imported the new head yet.

This also raises a related issue, which is that we need to keep track of the slot of the head event, because the BNs could be lagging and sending us head events for old slots.

A new design that handles both of these problems might be:

  • Maintain head event streams from all BNs.
  • Begin the attestation process once a head event arrives that is superior to our current best known head (need to keep track of this).
  • Option 1: Just try to attest using the BN(s) that sent you the head event (probably just 1 BN). Or, if we track the latest head on each BN in the background, some more BNs might be in this category.
  • Option 2: Request attestations from all BNs, and only accept ones that match the latest known head.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I went with the Option 1 but with an extra fail-safe branch to origin first_success if it encounters a race condition with the BN index that sent the latest head

@jimmygchen jimmygchen added the waiting-on-author The reviewer has suggested changes and awaits thier implementation. label Sep 10, 2025
@hopinheimer hopinheimer added ready-for-review The code is ready for review waiting-on-author The reviewer has suggested changes and awaits thier implementation. and removed waiting-on-author The reviewer has suggested changes and awaits thier implementation. ready-for-review The code is ready for review labels Sep 19, 2025
@hopinheimer hopinheimer removed the waiting-on-author The reviewer has suggested changes and awaits thier implementation. label Sep 20, 2025
@hopinheimer hopinheimer added the ready-for-review The code is ready for review label Sep 20, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
ready-for-review The code is ready for review val-client Relates to the validator client binary
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants