feature: Using eth_getBlockReceipts

[khaidarkairbek]

Currently in sync-historical, to check for reverted transactions and to include tx receipts, we fetch receipts via eth_getTransactionReceipt method on ethereum API. However, when the number of transactions after filtering is large, would it be more efficient to use eth_getBlockReceipts to lower the number of requests made to the RPC?

// Request transactionReceipts to check for reverted transactions.
    const transactionReceipts = await Promise.all(
      Array.from(transactionHashes).map((hash) =>
        _eth_getTransactionReceipt(args.requestQueue, {
          hash,
        }),
      ),
    );

[kyscott18]

The problem with eth_getBlockReceipts is that it is super expensive in terms of rpc credits and not as widely supported.

https://docs.alchemy.com/reference/compute-unit-costs

We're strongly considering moving from trace_filter to debug_traceBlockByHash. I'm pretty sure that once you have the entire block of traces, you don't need to check the transaction receipt to see if the transaction reverted ?? Could be wrong.

[khaidarkairbek]

From what I see on the compute costs, eth_getTransactionReceipt is at 15 CU and eth_getBlockReceipt is at 500 CU. Since block includes > 100 txs and well over that, there are scenarios when eth_getBlockReceipt is cheaper than eth_getTransactionReceipt. Would it make sense to add conditional fetching, depending on what method is cheaper to use for a specific scenario. (This relates to log filters too in cases when transaction receipts are included)

[kyscott18]

There are definitely some specific scenarios where this method might be more efficient, but practically speaking I think this is kind of a local max.

[khaidarkairbek]

Agreed, this was an issue when I tried to index all the transactions in a block interval. Definitely rare to happen, but was not sure if it should be supported.

[kyscott18]

What do you think about the debug namespace idea?

[khaidarkairbek]

If the traces are rare to satisfy the filter, trace_filter with eth_getTransactionReceipt makes more sense. However, for cases when the traces are more frequent to occur, debug_traceBlockByHash would be a better way to do so. What I am thinking currently is initial query to trace_filter and then subsequent calls to debug_traceBlockByHash/eth_getTransactionReceipt depending on whether the block includes sufficient number of traces to make it worthwhile. Would be happy to hear what you think about it.

[kyscott18]

I think we should only use debug_traceBlockByHash and index every block. In practice, the debug namespace is more widely supported and often an order of magnitude faster.

If you factor in the skipped eth_getTransactionReceipt calls, I bet this strategy would improve wall clock speed by a noticeable amount.

I can create an issue to track all the different components of migrating to the debug namespace. The filter issue #1198 will also be relevant.

[typedarray]

Just chiming in to note that Alchemy's eth_getBlockReceipts pricing looks like an major outlier at 33x the price of eth_getTransactionReceipt.

On QuickNode eth_getTransactionReceipt and eth_getBlockReceipts both cost 20 CU (docs) and on Chainstack they appear to be the same as well (docs).