eth_blockNumber is one of the two RPCs that is available to users from the sequencer so-called relays. Because these relays are key components of our infrastructure, I proposed in a previous changeset to optimize its implementation, but I am now convinced that this change has a potential drawback that is not worth the performance gains: load balancing inconsistency.

That is, with the current implementation, it is technically possible for two nodes running in RPC mode for the same data dir to return inconsistent result to the eth_blockNumber RPC. Imagine that for any reason, node B is lagging a bit behind wrt. consuming its blueprints stream. In this case, node A can return N, and directly after node B can return N-1 for instance. If we rely on the default implementation, the result is fetched from the on-disk state, which makes it not possible (as far as I can tell) to see this scenario when eth_blockNumber is not greater or equal than its previous result, even with a load balancer setup.

Checklist

Document the interface of any function added or modified (see the coding guidelines)
Document any change to the user interface, including configuration parameters (see node configuration)
Provide automatic testing (see the testing guide).
For new features and bug fixes, add an item in the appropriate changelog (docs/protocols/alpha.rst for the protocol and the environment, CHANGES.rst at the root of the repository for everything else).
Select suitable reviewers using the Reviewers field below.
Select as Assignee the next person who should take action on that MR

EVM Node: Have RPC mode fetches current number from the store

Checklist

Merge request reports