eth_syncing returns false, when not synced

[eniko1556]

Describe the bug

The endpoint returns false when sync is not started. It also randomly returns any value when a different consensus client is used on a stalled network.

curl -s -X POST --data '{"jsonrpc":"2.0","method":"eth_syncing","params":[],"id":0}' -H "Content-Type: application/json" http://localhost:8545

{"jsonrpc":"2.0","result":false,"id":0}

Steps to reproduce

The easiest way to reproduce is.

1. Start reth

reth node  --chain sepolia --datadir $HOME/.run-a-node/sepolia --http --http.port 8545 --http.api eth --http.corsdomain localhost --authrpc.addr 127.0.0.1 --authrpc.port 8551 --authrpc.jwtsecret $HOME/.run-a-node/sepolia/jwt.hex

2. check status

curl -s -X POST --data '{"jsonrpc":"2.0","method":"eth_syncing","params":[],"id":0}' -H "Content-Type: application/json" http://localhost:8545

{"jsonrpc":"2.0","result":false,"id":0}

Alternatively, his happens only with two consensus clients (lodestar/nimbus-eth2). See raised issue on besu: https://github.com/hyperledger/besu/issues/7338

Running reth against lighthouse/prysm/teku, reth will return sync status on the stalled network.

Also, this would be relevant as well: https://github.com/ethereum/execution-apis/issues/428

Node logs

No response

Platform(s)

Linux (x86)

What version/commit are you on?

1.0.0, 1.0.1

What database version are you on?

Current database version: 2 Local database is uninitialized

Which chain / network are you on?

sepolia

What type of node are you running?

Archive (default)

What prune config do you use, if any?

No response

If you've built Reth from source, provide the full command you used

No response

Code of Conduct

• [X] I agree to follow the Code of Conduct

[mattsse]

I believe this can happen when the CL client is also syncing

[eniko1556]

@mattsse I'm not concerned about internal behavior; I'm looking from an outside perspective as a node operator. I see that geth/nethermind/erigon does not return false for either consensus client, while besu/reth does in some cases. I'm running against the same minimal settings; I would expect the same behavior. So for geth/nethermind/erigon, the sync endpoint always returns sync status. Whichever way this is implemented, I'm okay with it being consistent between clients.

[github-actions[bot]]

This issue is stale because it has been open for 21 days with no activity.

[corn-potage]

Hi there. I'm currently implementing sync status in NiceNode, and seeing this difference in eth_syncing response behavior compared to other clients, where they usually return an object in the beginning stages of syncing.

Geth

{
    "currentBlock": "0x0",
    "healedBytecodeBytes": "0x0",
    "healedBytecodes": "0x0",
    "healedTrienodeBytes": "0x0",
    "healedTrienodes": "0x0",
    "healingBytecode": "0x0",
    "healingTrienodes": "0x0",
    "highestBlock": "0x0",
    "startingBlock": "0x0",
    "syncedAccountBytes": "0x0",
    "syncedAccounts": "0x0",
    "syncedBytecodeBytes": "0x0",
    "syncedBytecodes": "0x0",
    "syncedStorage": "0x0",
    "syncedStorageBytes": "0x0",
    "txIndexFinishedBlocks": "0x0",
    "txIndexRemainingBlocks": "0x1"
}

Nethermind:

{
    "startingBlock": "0x0",
    "currentBlock": "0x0",
    "highestBlock": "0x0"
}

Are there any plans to make this consistent within reth? Thank you!

[mattsse]

in the beginning stages of syncing.

can you unpack what you mean by this?

I guess since other clients return this on start we should also start out as syncing, even though the node isn't syncing (yet)...

[corn-potage]

in the beginning stages of syncing. can you unpack what you mean by this?

From what I've seen with other clients, right after the node is started by the user, and eth_syncing RPC is called, they usually return an object with currentBlock, highestBlock, and startingBlock, and continue to do so, until the node is considered fully synced, where eth_syncing returns false instead of an object.

[jenpaff]

will investigate how other clients handle this