• Post merge block downloader originally does not allow header only forward sync. I've modified it to allow it, which then reveal an undisired behaviour where it does not switch to full sync unless the state sync finished at exactly the best suggested header.
  • This is because, the full sync will start exactly at the block after it the best suggested header (downloaded by the header only forward fast sync), which is also the downloaded state, so it need to be exact. Unless bodies is also downloaded, in which case IBlockchainProcessor will process its parents also.
  • Also state sync should only finish once now.
  • Anyway, I'm inclined to just remove the header only forward sync as per previous post merge behaviour as it significantly clears up which part of the code is PoW header related.
• Additionally, this ensure that pos SyncPivot, all block is available, an assumption that make it simple to reason about when SyncPivot is movable.
• Additionally, this make the behaviour of why starting fast sync with --Sync.DownloadBodiesInFastSync false, then restart with true after finished state sync will result in gap of block after the sync pivot to no longer be the case. The same is true with receipts, which I'm also inclined to just always download receipt for block after SyncPivot.
• Fix on long range state sync (restart on very old node) BlockchainProcessor will load all pending blocks anyway resulting in a very high memory and processing a lot of blocks.

Types of changes

What types of changes does your code introduce?

• Bugfix?
• Refactoring

Testing

Requires testing

• Yes
• No

If yes, did you write tests?

• Yes
• No

Notes on testing

• Mainnet sync
• Mainnet full sync
• Long range state sync catch up still works.
• Energyweb sync
• Hive engine tests.
• Sync github action.