feat: Include support for getblockreceipts

[konstantinabl]

Description:

This PR implements the eth_getBlockReceipts JSON-RPC method, which returns an array of all transaction receipts for a given block.

Implementation details:

• New getBlockReceipts route added to ethRoutes
• Added validation for the new endpoint
• Added new getBlockReceipts method in EthImpl
• Created unit tests in getBlockReceipts.spec.ts
• Created e2e acceptance tests

Related issue(s):

Fixes #2613

Notes for reviewer:

Current implementation does not include synthtetic transactions

Checklist

• Documented (Code comments, README, etc.)
• Tested (unit, integration, etc.)

[github-actions]

Test Results

 19 files   -   4  245 suites   - 70   38m 55s ⏱️ - 34m 23s
623 tests +  4  617 ✅ + 15  4 💤 ±0  2 ❌  - 11 
722 runs   - 220  716 ✅  - 203  4 💤  - 2  2 ❌  - 15 

For more details on these failures, see this check.

Results for commit 8c39bea. ± Comparison against base commit d6d04e2.

This pull request removes 1 and adds 5 tests. Note that renamed tests count towards both.

"before all" hook in "Debug API Test Suite" ‑ RPC Server Acceptance Tests Acceptance tests @api-batch-3 RPC Server Acceptance Tests Debug API Test Suite "before all" hook in "Debug API Test Suite"

should execute "eth_getBlockReceipts" with block hash successfully ‑ RPC Server Acceptance Tests Acceptance tests @api-batch-1 RPC Server Acceptance Tests RPC Server Acceptance Tests Block related RPC calls should execute "eth_getBlockReceipts" with block hash successfully
should execute "eth_getBlockReceipts" with block number successfully ‑ RPC Server Acceptance Tests Acceptance tests @api-batch-1 RPC Server Acceptance Tests RPC Server Acceptance Tests Block related RPC calls should execute "eth_getBlockReceipts" with block number successfully
should execute "eth_getBlockReceipts" with tag "earliest" successfully ‑ RPC Server Acceptance Tests Acceptance tests @api-batch-1 RPC Server Acceptance Tests RPC Server Acceptance Tests Block related RPC calls should execute "eth_getBlockReceipts" with tag "earliest" successfully
should execute "eth_getBlockReceipts" with tag "latest" successfully ‑ RPC Server Acceptance Tests Acceptance tests @api-batch-1 RPC Server Acceptance Tests RPC Server Acceptance Tests Block related RPC calls should execute "eth_getBlockReceipts" with tag "latest" successfully
should throw error on "eth_getBlockReceipts" with invalid parameter passed ‑ RPC Server Acceptance Tests Acceptance tests @api-batch-1 RPC Server Acceptance Tests RPC Server Acceptance Tests Block related RPC calls should throw error on "eth_getBlockReceipts" with invalid parameter passed

♻️ This comment has been updated with latest results.

[quiet-node]

LG left some questions.

Also, didn't see this eth_getBlockReceipts added to the list of rate limit methodConfig

[quiet-node]

I’ve noticed that execution time is quite long. I haven’t analyzed it in depth yet, but I tested eth_getBlockReceipts with the hash 0xec04afbe85d980c67723e18121499dd9c32fce65ca06522baf4433d39ef00164, and it takes around 3000ms for e2e execution. eth_getBlockByHash with the same hash takes roughly 250ms.

I understand that retrieving receipts requires additional operations, but 3000ms is still quite high. Our performance tests show that most methods complete within a few hundred milliseconds.

Let’s review the implementation to ensure there are no unnecessary calls or inefficiencies.

Also with that said please add this to k6 as well.

[konstantinabl]

I’ve noticed that execution time is quite long. I haven’t analyzed it in depth yet, but I tested eth_getBlockReceipts with the hash 0xec04afbe85d980c67723e18121499dd9c32fce65ca06522baf4433d39ef00164, and it takes around 3000ms for e2e execution. eth_getBlockByHash with the same hash takes roughly 250ms.

I understand that retrieving receipts requires additional operations, but 3000ms is still quite high. Our performance tests show that most methods complete within a few hundred milliseconds.

Let’s review the implementation to ensure there are no unnecessary calls or inefficiencies.

Also with that said please add this to k6 as well.

The request took 1 second for me with this hash. How did you send it ?
@quiet-node

Also added a k6 test, tell me if its good enough https://github.com/hashgraph/hedera-json-rpc-relay/pull/3521/files#diff-ea2bf404fda3277c2324aa1ca400f86a65e4a433dc59a4710e086dfdc39f2bdcR9

[quiet-node]

I’ve noticed that execution time is quite long. I haven’t analyzed it in depth yet, but I tested eth_getBlockReceipts with the hash 0xec04afbe85d980c67723e18121499dd9c32fce65ca06522baf4433d39ef00164, and it takes around 3000ms for e2e execution. eth_getBlockByHash with the same hash takes roughly 250ms.
I understand that retrieving receipts requires additional operations, but 3000ms is still quite high. Our performance tests show that most methods complete within a few hundred milliseconds.
Let’s review the implementation to ensure there are no unnecessary calls or inefficiencies.
Also with that said please add this to k6 as well.

The request took 1 second for me with this hash. How did you send it ? @quiet-node

Also added a k6 test, tell me if its good enough https://github.com/hashgraph/hedera-json-rpc-relay/pull/3521/files#diff-ea2bf404fda3277c2324aa1ca400f86a65e4a433dc59a4710e086dfdc39f2bdcR9

@konstantinabl Hmmm I tried it with a random hash 0x94621f0983144976ef7636314e755535185220ade81e0a9b7bd91c78d17be9e3 and got to 2900ms

edited: Might have been network congestion or something similar. Tested it again and got around 1200 ms. I was pretty sure it consistently reached up to 3000 ms back then. Your new updates might have reduced the end-to-end time.

[konstantinabl]

I’ve noticed that execution time is quite long. I haven’t analyzed it in depth yet, but I tested eth_getBlockReceipts with the hash 0xec04afbe85d980c67723e18121499dd9c32fce65ca06522baf4433d39ef00164, and it takes around 3000ms for e2e execution. eth_getBlockByHash with the same hash takes roughly 250ms.
I understand that retrieving receipts requires additional operations, but 3000ms is still quite high. Our performance tests show that most methods complete within a few hundred milliseconds.
Let’s review the implementation to ensure there are no unnecessary calls or inefficiencies.
Also with that said please add this to k6 as well.

The request took 1 second for me with this hash. How did you send it ? @quiet-node
Also added a k6 test, tell me if its good enough https://github.com/hashgraph/hedera-json-rpc-relay/pull/3521/files#diff-ea2bf404fda3277c2324aa1ca400f86a65e4a433dc59a4710e086dfdc39f2bdcR9

@konstantinabl Hmmm I tried it with a random hash 0x94621f0983144976ef7636314e755535185220ade81e0a9b7bd91c78d17be9e3 and got to 2900ms

edited: Might have been network congestion or something similar. Tested it again and got around 1200 ms. I was pretty sure it consistently reached up to 3000 ms back then. Your new updates might have reduced the end-to-end time.

So are we fine with this or should I try improving it, its kinda slow really, but could be worse @quiet-node @Ferparishuertas

[quiet-node]

Left some questions and suggestions

[quiet-node]

Great! Definitely less cluttered now! Just left some small suggestions and we should be good to go