eth, les: add error when accessing missing block state

[holiman]

Supersedes #15762 . It was not properly goimport-formatted, so I fixed that and refactored it a bit more. Thanks @shbli for the PR!

---

For release notes:

This change makes getBalance, getCode, getStorageAt, getProof, call, getTransactionCount return an error if the block number in the request doesn't exist. getHeaderByNumber still returns null for missing headers.

[gballet]

LGTM

[karalabe]

This might break the RPC APIs. I did a similar refactor a while back and it borked a lot of higher level client libraries which relied on missing blocks returning null.

[ryanschneider]

BTW, there is more recent discussion at #18254 since #3483 had been marked deprecated.

@karalabe do you remember which client libraries were impacted? We could look at them and see if a) they still make that assumption and b) any work-arounds that could be implemented.

Ideally we can come up with a clever way forward that allows for an explicit error without breaking these clients too badly.

[xiaods]

cloud you please add testing to stub the case. the project missing many testing , please don't miss it anymore.

[danfinlay]

This might break the RPC APIs. I did a similar refactor a while back and it borked a lot of higher level client libraries which relied on missing blocks returning null.

I agree that API breaking should be a last resort, and maybe querying the future block can retain its current behavior. The concern raised in #18254 is more general than this method: There is currently inconsistent behavior across different methods when querying future blocks, and some of those error responses are indistinguishable from successful responses, which should be the subject of possible breaking changes here.

A good example is the case of calling getCode for an address at a future block. Returning null or 0x in this case is indistinguishable from a contract that has not been published yet, meaning there is no correct way for client software to interpret this behavior, and so breaking current code relying on these flawed responses will universally lead to improvements in that client software.

While returning null in response to a future block request might be acceptable as it's arguably true (there is no block for that number known), there is really no substitute for errors being thrown on a variety of other methods requested at the future block, as presented in issue #18254.

For that reason I hope this PR's concerns aren't blocking a more general "default to error when querying an unknown block" solution which would only be breaking things that are already broken, for the sake of fixing them.

[xiaods]

any update? i don't clear howto in process doing on this patch?

[fjl]

This impacts: getBalance, getCode, getStorageAt, getProof, call, getTransactionCount.

[fjl]

Please change StateAndHeaderByNumber in les/api_backend.go to include the same treatment of header == nil.

[holiman]

done, ptal @fjl

[holiman]

ping @fjl to add tests to this one, and merge it in

[fjl]

rebased and tests added