headerCache miss in BlockByTimeStamp()

[jmozah]

💎 Issue

Background

As part of debug session for the GetBlock() optimisation, this issue was found and needs to be looked in to.

Description

GetBlock() -> eth1DataMajorityVote() -> BlockByTimeStamp()

• BlockByTimeStamp(): This is a search function which tries to minimize the access rate by using a header cache during normal operation. This function somehow misses the headerCache and proceeds to fetch the header from the eth1POW chain (external call) which is inside the search iteration. Even if the call takes 200ms every time, it adds up and crosses a second easily.
• scenario 1
  
• scenario 2
  

[jmozah]

Summary: After running some experimentation i have come to a conclusion that this will not be a issue during normal block proposals. Spoke about this with @nisdas and he thinks the same too. Some explanations below

• This version was modified such that GetBlock() will be called as soon the validator calls WaitForActivation. This is to monitor the performance of GetBlock() function as a whole and find issues.

• During Start() of the POWService, Eth1BlockHeaders are loaded in the header cache from the previous Eth1 voting period start to the present. This is done in parallel while other services are running.

• Because of how GetBlock() is called, sometimes BlockByTimeStamp() is called even before the cache is loaded. So we saw few header cache misses in the beginning. Also depending upon the machine spec, this initial duration would last few seconds (our setup shows 15 seconds).

• Once the caches are hot, the misses are virtually not existant even in a longer duration test which spanned more than 3 Eth1VotingPeriod.

So i am in recommendation of closing this issue as we wiil have very few probability to propose blocks in the first few seconds of starting the beacon node.