Use events API to eager send attestations #7892
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.
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.
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
headevent streams from all BNs. - Begin the attestation process once a
headevent 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.
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
added
the
waiting-on-author
hopinheimer
added
ready-for-review
hopinheimer
removed
the
waiting-on-author
validator_client/validator_services/src/head_monitor_service.rs
Outdated
Show resolved
Hide resolved
validator_client/validator_services/src/head_monitor_service.rs
Outdated
Show resolved
Hide resolved
validator_client/validator_services/src/head_monitor_service.rs
Outdated
Show resolved
Hide resolved
validator_client/validator_services/src/head_monitor_service.rs
Outdated
Show resolved
Hide resolved
validator_client/validator_services/src/head_monitor_service.rs
Outdated
Show resolved
Hide resolved
macladson
added
waiting-on-author
hopinheimer
added
ready-for-review
validator_client/validator_services/src/head_monitor_service.rs
Outdated
Show resolved
Hide resolved
validator_client/validator_services/src/head_monitor_service.rs
Outdated
Show resolved
Hide resolved
validator_client/validator_services/src/head_monitor_service.rs
Outdated
Show resolved
Hide resolved
|
Some required checks have failed. Could you please take a look @hopinheimer? 🙏 |
mergify
bot
added
waiting-on-author
while working on this #7892 @michaelsproul pointed it might be a good metric to measure the delay from start of the slot instead of the current `slot_duration / 3`, since the attestations duties start before the `1/3rd` mark now with the change in the link PR. Co-Authored-By: hopinheimer <[email protected]> Co-Authored-By: hopinheimer <[email protected]>
5 participants
addresses #7820
I haven't done benches for the change in kurtosis but post results soon