-
Notifications
You must be signed in to change notification settings - Fork 910
Use events API to eager send attestations #7892
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: unstable
Are you sure you want to change the base?
Conversation
event_result.map_err(|e| format!("Head event stream error: {:?}", e))?; | ||
match event { | ||
EventKind::Head(_) => { | ||
trace!("Received head event, triggering early attestation processing"); |
There was a problem hiding this comment.
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 { |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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
addresses #7820
I haven't done benches for the change in kurtosis but post results soon