During syncing, we might transiently have enough malicious blaming
blocks to consider a correct header incorrect. For this reason, we
first wait for enough header to accumulate before checking blaming.
TODO(thegaram): review value and expose this as a parameter
The threshold controlling whether a node is in catch-up mode.
A node is in catch-up mode if its local best epoch number is
CATCH_UP_EPOCH_LAG_THRESHOLD behind the median of the epoch
numbers of peers.
(Maximum) number of items requested in a single request.
During log filtering, we stream a set of items (blooms, receipts, txs)
to match against. To make the process faster, we need to make sure that
there’s always plenty of items in flight. This way, we can reduce idle
time when we’re waiting to receive an item.
Max number of epochs/headers/txs to send to a light peer in a response.
Maximum number of in-flight items at any given time.
If we reach this limit, we will not request any more.
Maximum number of in-flight epoch requests at any given time.
Similar to MAX_HEADERS_IN_FLIGHT. However, it is hard to match
hash responses to epoch requests, so we count the requests instead.
Number of epochs to request in one round (in possibly multiple batches).
Minimum number of missing items in the sync pipeline.
If we have fewer, we will try to request some more.