-
Notifications
You must be signed in to change notification settings - Fork 927
Description
Overview
There could be some optimizations made in BLS verification in our attestation processing. As this consumes the majority of our processing time, optimizations here could have significant impact on Lighthouse's performance.
Current Design
As attestations come in we queue them in the beacon processor. The beacon processor greedily tries to process anything in its queue, but we order objects based on priority. For a fast processor, the queue's can be relatively empty. For attestations, if we can process them individually without the queue's filling up, we do this. If we check the queue and more than one attestation has queued up, we batch process it.
See here: https://github.com/sigp/lighthouse/blob/stable/beacon_node/beacon_processor/src/lib.rs#L1072-L1080
And the actual processing here: https://github.com/sigp/lighthouse/blob/stable/beacon_node/beacon_processor/src/lib.rs#L1547-L1560
Potential Optimisations
A fast host, may be able to process individual attestations all the time, but batch processing attestations will significantly reduce the total amount of processing. We start to see gains in slower machines that are forced into batch processing and potentially we might stand to gain adding artificial delays into the attestation queue to force more batch BLS verification.
One strategy might be to check the time throughout the slot. If we have time before the attestation deadline, then we should group attestations more aggressively. As the time runs out we revert back towards single attestation processing.
A caveat here is that the more we group attestations, the more we have "burst" like traffic on the network. Although we can verify batches faster, we may not be able to forward them in batches as fast on the network, so the grouping may need some fine tuning.