feat:
1. `erigon_getLatestLogs` doesn't have to match the exact position of
the topics. It will match logs that contain the topics regardless of the
topics' position with original bloom filter. And it accepts `blockCount`
& `crit.ToBlock` params for better pagination.
One simple change to send the header in rather than the body allowing
re-use in a loop which saves the copy call when looping.
The other one for a reusable evm seems potentially dangerous so feedback
more than welcome on that one, local testing shows it gains me around
6k±rps so if it's safe is a good win, but I feel it will need more work.
I could only validate against goerli chain which seems to always return
the same value for eth_estimateGas so if anybody could validate it
against another chain that would be awesome.
For example, see https://gnosisscan.io/block/24938312.
This fixes the following errors:
```
t=2022-11-11T12:39:01+0000 lvl=dbug msg="Handling incoming message" stream=RecvMessage err="newBlock66: too large block difficulty: bitlen 128"
t=2022-11-11T12:39:01+0000 lvl=dbug msg="Handling incoming message" stream=RecvMessage err="newBlock66: too large block difficulty: bitlen 128"
t=2022-11-11T12:39:01+0000 lvl=dbug msg="Handling incoming message" stream=RecvMessage err="newBlock66: too large block difficulty: bitlen 128"
```
this pr has two things in it
1. changed filter logs to use a map for the topics. this will speed up
queries with many topics in them. I still don't have a use case for this
though. i put is as a method of Logs, since that made sense to me, happy
to move it back out though.
2. allows json-rpc over http get request. since firefox is a great json
viewer (can search through, collapse large results) i often use it to
debug. it is also useful for sharing data with those who are less
familiar with command line / programming.
example get request:
http://rpcdaemon/?method=eth_getLogs¶ms=[{"fromBlock":"0xf2316b","toBlock":"0xf2316b"}]
it is based on the old jsonrpc http specification
https://www.jsonrpc.org/historical/json-rpc-over-http.html#encoded-parameters
except we also accept not base64 encoded params. since every eth rpc
request has a [], it will immediately fail validation for base64 and
attempt to use the parameters as a they are. otherwise it will attempt
to parse the rest of the payload as base64 and use that.
Co-authored-by: a <a@a.a>
Co-authored-by: gfx <86091021+gfxlabs@users.noreply.github.com>
While main thread is idle (apply is on RoTx now):
- periodically still hisotry/index etl collectors and load them to db
- prune old history/index in db
Also:
- fixed RAM estimation calculation of State22
BaseFee is required in AuRa headers when
[EIP-1559](https://eips.ethereum.org/EIPS/eip-1559) is activated.
Also:
- Basic AuRa header verification
- Extract some common RLP methods
- Tiny log clean-up
