[Feature] Add support for fetching block receipts using eth_getBlockReceipts

[tornadocontrib]

Description

Currently Graph Node requires syncing block receipts and this would cause overload on RPC since it would call like from 50 requests to 100 requests of eth_getTransactionReceipt for high throughput networks like BSC or Polygon.

See related issues here https://github.com/graphprotocol/graph-node/issues?q=is%3Aissue+receipt+is%3Aclosed.

Have created a PR on rust-web3 to support this graphprotocol/rust-web3#15

Are you aware of any blockers that must be resolved before implementing this feature? If so, which? Link to any relevant GitHub issues.

No response

Some information to help us out

• Tick this box if you plan on implementing this feature yourself.
• I have searched the issue tracker to make sure this issue is not a duplicate.

[tornadocontrib]

cc @lutter @incrypto32 could you please check? I think this is a must have feature to run subgraphs on the top of serviced nodes.

[azf20]

Thanks @tornadocontrib, this does indeed look interesting. Checking specs for support for this method, it seems like it is pretty widely adopted but might not work for all EVM clients? (just thinking about whether configuration might be required)

[tornadocontrib]

@azf20 Yeah, but it has been adopted to major EVM chains like Ethereum ethereum/go-ethereum#27702, BSC ( bnb-chain/bsc#2068 ), Polygon ( They use Erigon so it is already implemented ), Avalanche ( ava-labs/coreth#429 ), Op-stack chains ( They use the latest Geth ) , and this is the only method to enable running graph-node with serviced nodes like Infura or Quicknode especially for the high throughput chains like BSC or Mainnet.

I think the best would be enabling it by default, and add the ENV to disable it. ( Also, I think we don't need to support erigon_ or any other non standard methods as this has been already standardized ethereum/execution-apis#393 ).

[maoueh]

I think it would be fairly easy to detect if the method is supported on boot time. We do already eth_chainId and a few others when loading up a RPC provider.

We could easily make the call for the genesis block and see if it works. If it works, it's supported otherwise fallback to "default" behavior.

[tornadocontrib]

@maoueh Yeah but the problem is eth_getBlockReceipts is not a chain dependent method but it relies whether the node would support it or not ( For example some people could run old nodes that doesn't support this method yet, or the provider simply didn't whitelisted this method on their load balancer, etc. ) So think it should be disabled by users manually.

[maoueh]

I'm not sure I understand your concern. My proposition is to make eth_getBlockReceipts{num: <genesis|0>} and if it fails, it's not supported otherwise it is.

Network is indeed not related but making the call and have it succeed means it's available.

[tornadocontrib]

@azf20 @maoueh Is there any plans to implement those? I think it is an important feature that would be able to cut expenses and speedup sync drastically

[azf20]

hey @tornadocontrib yes thanks for this, we are investigating and plan to implement, will keep this thread up to date