getLogs shall return error when fromBlock or toBlock does not exist

[jpnovais]

Description

When calling eth_getLogs with fromBlock or toBlock greater than the node's chain head, a response is returned. However, this seems semantically inaccurate because the execution client (EC) does not have all the blocks specified in the request to provide a complete answer.

Imagine a eth_getLogs request between fromBlock=50 and toBlock=150 and EC head is at block 100, the returned response may suffer from:

• incompleteness: 50 blocks are missing to provide a complete response until block 150.
• inconsistency: the same request may yield different responses. If logs are emitted after block 100, the same request will yield different results depending on when in time the EC handles the request. The same request should yield the same results (except when reorgs happen). Also, this is not in line with other methods that use specific block numbers, e.g eth_getStorageAt returns error block does not exist, Geth "error":{"code":-32000,"message":"header not found"}, Besu "error":{"code":-32000,"message":"Block not found"}.

Furthermore, the response does not have enough information to allow the API client to easily infer whether the response may be invalid/incomplete and needs to be retried later. It would be easy to identify if the response had EC's current head block number. However, adding an extra field (e.g. lastBlockNumber) would require breaking backward compatibility and significant changes in all the tooling.

Proposed Solution

Return an error "error":{"code":-32000,"message":"Block not found"} when the specified fromBlock or toBlock are greater than EC chain head block.

Expected Behaviour

Imagine the EC chain head is at block 300. eth_getLogs should behave as

fromBlock	toBlock	expected response
earliest	latest	result - keep current behaviour
200	latest	result - keep current behaviour
301	latest	error - block not found
200	301	error - block not found
earliest	301	error - block not found

[lightclient]

Thanks for the issue @jpnovais! This makes a lot of sense to me. Can you open a PR to the spec with this change?

[jpnovais]

Sure, I will create the PR to the spec soon. Thanks for the feedback.

[tornadocontrib]

Oppose of changes because this will crash many DApps relying on queries ( Tornado Cash UI https://tornadocash-eth.ipns.dweb.link/ for example )