Today, the JSON-RPC API exposes a few different methods to get blocks:
eth_getBlockByNumber
eth_getBlockByHash
When using this API, the common way to get the latest block is to repeatedly poll for getBlockByNumber
for the current_block_number + 1
.
We could gain additional performance for JSON-RPC consumers by allowing them a way to get an immediate notification upon the next block, via long polling, ie the request would not resolve until the result was ready. Proposed name: eth_getNextBlock
. Maybe it could take an argument for a known block, so the host could return a block that builds on it as soon as it’s available, allowing a graceful lazy walk up the block chain.
This doesn’t replace the utility of using Websocket based APIs, but can improve the performance for the JSON-RPC based interface.
Thoughts?