Investigate potential performance improvements to eth_getBlockByNumber/eth_getBlockByHash

[lukelee-sl]

Problem

Issue #840 describes a bug where calls to eth_getBlockByNumber/eth_getBlockByHash when specifying a block that contains lots of contract results can lead to performance issues and 502 errors being returned to the user.

One example of such a case is described in #827

FIxing Issue #840 may improve performance in the case where the showDetails parameter is false but does not improve performance sufficiently for blocks with a large set of contract results when the parameter is true.

Solution

Investigate existing or new ways to batch contract results from the mirror node to improve performance.

Alternatives

No response

[mshakeg]

Hi @lukelee-sl , would it not be better to simply get all transactions in a block using the following mirror node endpoint:

/api/v1/contracts/results?limit={contractResults.results.length}&order=asc&block.{number|hash}={blockHashOrNumber}&internal={false??}

instead of doing batches on the existing call:

/api/v1/contracts/results/{txHash}

[lukelee-sl]

Hi @mshakeg. Thanks for the suggestion. I'd have to look into it further but looks like that should work.

[Nana-EC]

We made some advancements here and no longer have large perf concerns. However, we should also see how to add this consideration of large blocks to the load testing flow