[BUG] Downloader could got a wrong blockHash in a reorg situation

[joanestebanr]

Bug Report

When downloader receive no logs create a 'empty' block. The empty block hash is obtaniner requesting this to RPC . But the hash maybe is not aligned with the logs call. Example:

1. GetLogs100, 110) [ Hash(110) -> X ] --> return empty list
2. ⚡ (reorg!! now Hash(110) = Z and also have logs
3. ❌ GetBlockHeader(110) -> Z

Description

This bug is reproduced in case of reorg between getLogs call and getBlockHeader

Expected behavior

The empty block must belong to the same 'chain' as the GetLogs calls

Proposed solutions

To be sure that all the blocks belong to the same chain we propose next solution:

• Ask for finalized block number fbn

• Ask logs for current range [ n - m ]
  - Returns log block x -> next_range = [ x - ( x+ block_chunk) ]
  - Returns empty:
  - if ( fbn - n > block_chunck ) -> create empty block with getHeader(fbn+block_chunk)
  - we have enough blocks on finalized zone to create a empty block
  - next_range = [ (fbn + block_chunck) - m + block_chunck ]
  - else
  - We just increase the range:
  - next_range = [ n - m + block_chunck ]

• We also suggest to add a new field to EVMBlockHeader struct to say if this block is in finalized zone or not (to avoid sending to reorgDetector)

Pros:

• Reduce the number of calls to RPC
• Reduce the load to reorg detector (specially in the initial stage of syncing from scratch)

Cons:

• The chunckSize it's not always respected and the maxnium request range is going to be greater
• Increase complexity