Improve the performance of eth_getLogs

[JukLee0ira]

Proposed changes

Not all fields of a receipt are persisted to disk. Some are re-computed on read. The most expensive field to re-compute is the bloom filter which will not even be returned in eth_getLogs. Here we define a new decoding of receipts specifically for this use-case which avoids extra processing.

Test 'eth_getLogs'

Vertical comparison

Before optimization, run the command and save the result to file1.log:

curl -X POST -H "Content-Type: application/json" --data '{  "method":"eth_getLogs",  "params":[{ "fromBlock":"0x1010d", "toBlock":"0x11a400",    address":"xdc0000000000000000000000000000000000000088",    "topics":[ ]  }],  "id":1,  "jsonrpc":"2.0"}' http://127.0.0.1:8545 | jq > file1.log

After optimization, run the same command and save the result to file2.log:

curl -X POST -H "Content-Type: application/json" --data '{  "method":"eth_getLogs",  "params":[{ "fromBlock":"0x1010d", "toBlock":"0x11a400",    address":"xdc0000000000000000000000000000000000000088",    "topics":[ ]  }],  "id":2,  "jsonrpc":"2.0"}' http://127.0.0.1:8545| jq > file2.log

Here are their diff results:

3c3
<   "id": 1,
---
>   "id": 2,

Horizontal comparison

After the modification, sync the block data, run the command, and save the result to file3.log:

curl -X POST -H "Content-Type: application/json" --data '{  "method":"eth_getLogs",  "params":[{ "fromBlock":"0x1010d", "toBlock":"0x11a400",    address":"xdc0000000000000000000000000000000000000088",    "topics":[ ]  }],  "id":3,  "jsonrpc":"2.0"}' http://127.0.0.1:8545 | jq > file3.log

Run the command to read the log from the public RPC node and save the result to file4.log:

curl -X POST -H "Content-Type: application/json" --data '{  "method":"eth_getLogs",  "params":[{ "fromBlock":"0x1010d", "toBlock":"0x11a400",    address":"xdc0000000000000000000000000000000000000088",    "topics":[ ]  }],  "id":4,  "jsonrpc":"2.0"}' https://apothem.xdcrpc.com | jq > file4.log

Here are their diff results:

3c3
<   "id": 3,
---
>   "id": 4,

Types of changes

What types of changes does your code introduce to XDC network?
Put an ✅ in the boxes that apply

• Bugfix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to not work as expected)
• Documentation Update (if none of the other choices apply)
• Regular KTLO or any of the maintaince work. e.g code style
• CICD Improvement
• Performance

Impacted Components

Which part of the codebase this PR will touch base on,

Put an ✅ in the boxes that apply

• Consensus
• Account
• Network
• Geth
• Smart Contract
• External components
• Not sure (Please specify below)

Checklist

Put an ✅ in the boxes once you have confirmed below actions (or provide reasons on not doing so) that

• This PR has sufficient test coverage (unit/integration test) OR I have provided reason in the PR description for not having test coverage
• Provide an end-to-end test plan in the PR description on how to manually test it on the devnet/testnet.
• Tested the backwards compatibility.
• Tested with XDC nodes running this version co-exist with those running the previous version.
• Relevant documentation has been updated as part of this PR
• N/A

[gzliudan]

Please rebase on the latest dev-upgrade branch.

[gzliudan]

LGTM

[gzliudan]

The new parameter timeout is not used. Please refer to: ethereum#22178