Synchronization: why startingBlock is ahead of currentBlock?

Question

> eth.syncing
{
  currentBlock: 908716,
  highestBlock: 928604,
  knownStates: 0,
  pulledStates: 0,
  startingBlock: 908891
}

It looks like synchronization started from block 908891, though the current block is 908716. How blocks 908717..908890 get synced then?

startingBlock: QUANTITY - The block at which the import started (will only be reset, after the sync reached his head)

currentBlock: QUANTITY - The current block, same as eth_blockNumber

@SamuelDare I used Geth/v1.8.7 when saw it for the first time, then upgraded to Geth/v1.9.1, but still seeing the same. — Aliaksandr Adzinets, Jul 29 '19 at 19:14

score 2 · Accepted Answer · edited Jun 16 '20 at 10:58

2

Look at the Geth Source code,

# StartingBlock is the block number at which synchronisation started.
    startingBlock: Long!
# CurrentBlock is the point at which synchronisation has presently reached.
    currentBlock: Long!

So the startingBlock is the point at which you originally started syncing i.e. when you first loaded your client , while the current block the progress you have made. When you started syncing your client, highestBlock == startingBlock.

In other words when you start the sync

currentBlock <= startingBlock<= highestBlock

However as the sync progresses, you would expect as the current block (the one on which you chain has synced ) passes the starting point .

startingBlock <= currentBlock <= highestBlock

Eventually,

currentBlock === highestBlock

and the eth.syncing will return nill

Reference:

edited Jun 16 '20 at 10:58

Community

1

answered Jul 29 '19 at 20:56

0xsegfault

1,260
9
24

Doesn't it mean that startingBlock <= currentBlock <= highestBlock? – Aliaksandr Adzinets Jul 29 '19 at 22:31
It’s the same thing but I guess my answer is way too verbose will update – 0xsegfault Jul 29 '19 at 22:32
But then in my case, why startingBlock > currentBlock ? – Aliaksandr Adzinets Jul 30 '19 at 06:52
sorry i must be totally confusing you.. will make one more attempt – 0xsegfault Jul 30 '19 at 08:10
Aah, got it now.. I assumed that the logic should be "startingBlock = currentBlock on startup", but it makes sense if it's actually "startingBlock = highestBlock on startup". – Aliaksandr Adzinets Jul 30 '19 at 11:53
Precisely will update the answer to show that nuance . We go there eventually! – 0xsegfault Jul 30 '19 at 11:55

Synchronization: why startingBlock is ahead of currentBlock?

1 Answers1

Reference: