Faster head block lookup for attn verification

[paulhauner]

Issue Addressed

NA

Proposed Changes

Reduce attestation process by several ms (approx 6ms in my experiments) by avoiding fork_choice.get_block when an attestation points to the canonical head.

When reading blocks from fork choice, we presently check to ensure the block is a known, valid descendant of (or equal to) the finalised checkpoint
with is_finalized_checkpoint_or_descendant. This involves some iterations through ancestors and can get somewhat expensive.

In this PR, I make the assumption that if the attestation head block is either:

• our canonical head, or,
• in our early attester cache

then it's safe to assume that the block is known, valid and descends from the finalised checkpoint. This negates the need to query fork_choice.get_block entirely.

This optimisation works for the "happy path" without adding additional cost to the "sad path". I.e., when the network is happy we expect all attestations to point to our head block, so we make consistent gainz. Conversely, when the network is sad and voting for another block, this optimisation won't help but it also won't hurt.

Additional Info

NA

TODO

• Graphs to prove this is worthwhile.

[dapplion]

A related idea we discussed with @michaelsproul is to run a pruning routine with the finalized checkpoint advances such that the proto array only contains nodes that are descendants of finalized. Then those checks are no longer necessary.

[paulhauner]

A related idea we discussed with @michaelsproul is to run a pruning routine with the finalized checkpoint advances such that the proto array only contains nodes that are descendants of finalized. Then those checks are no longer necessary.

That makes sense, it would likely help other code paths too. I'd still expect that the change in this PR is useful (perhaps to a minor degree) as it reduces lock contention for fork_choice.

With the pruning routine, I wonder how we'd do that such that:

1. It's 100% reliable that all nodes are finalised descendants, and,
2. We don't add that pruning time onto the fork choice "insert block" path, which is important for attestation performance.

To satisfy (1) I would expect to run the pruning whenever we add a finality-inducing block to fork choice, however I think that would impact (2). Perhaps the impact is not too bad?

[dapplion]

That makes sense, it would likely help other code paths too. I'd still expect that the change in this PR is useful (perhaps to a minor degree) as it reduces lock contention for fork_choice.

Right

It's 100% reliable that all nodes are finalised descendants, and,

What type of challenges do you anticipate there?

We don't add that pruning time onto the fork choice "insert block" path, which is important for attestation performance.

That's the biggest issue yes. On a timely finalizing network we just need to iterate 96 nodes, maybe it's not too bad.