Implement eth_syncing RPC method

[DrZoltanFazekas]

https://www.quicknode.com/docs/ethereum/eth_syncing

[shawn-zil]

Reading the specs, this is what I intend to do. Let me know if I'm wrong @DrZoltanFazekas @JamesHinshelwood

• startingBlock: reflects the block number when we started Phase 1.
• currentBlock: whatever the highest block number is currently in the DB.
• highestBlock: highest seen block number of broadcast Proposals.

If we're in Phase 1, startingBlock and currentBlock will be constant, while highestBlock should be increasing.

If we're in Phase 2/3, currentBlock and highestBlock should be increasing, albeit at different rates - with currentBlock faster than highestBlock (otherwise, it'll never catch up). startingBlock should stay constant.

Sounds about right?

[JamesHinshelwood]

Sounds about right to me @shawn-zil 👍

[DrZoltanFazekas]

If I understand correctly, startingBlock would be set to the block number that has a missing parent which triggered phase 1. Then we go backwards and end up syncing potentially thousands of older blocks in phase 2, starting at the block number were phase 1 hits the chain that we already have. Intuitively, I'd expected startingBlock to be the block number where phase 2 started.

[DrZoltanFazekas]

When we're in phase 2, currentBlock = eth_blockNumber shall reflect the progress going forward. Not sure if this is the same as what you defined above. Re highestBlock I agree with the definition.

[DrZoltanFazekas]

The definitions here are clearer than in the Quicknode docs imo: https://docs.chainstack.com/reference/ethereum-syncing

[shawn-zil]

So, just to confirm:
startingBlock <= currentBlock <= highestBlock.

Example, when a new node joins and sees the newest Block = 100, the situation at the beginning of Phase 1 will be:

startingBlock = 0
currentBlock = 0
highestBlock = 100