Addresses issue #4833
Removes implemented methods from the forbidden method list. The
forbidden list seems to have been created as a bugfix before the filters
methods were implemented. Now that the filter methods are implemented,
these entries are causing unexpected behaviour.
This is the first PR in support of
https://github.com/ledgerwatch/erigon/issues/5824.
The phase 0 sepc
https://github.com/ethereum/consensus-specs/blob/dev/specs/phase0/p2p-interface.md#global-topics
specifies 6 global pubsub topics that CL nodes need to handle.
This PR implements the `beacob_aggregate_and_proof` topic:
https://github.com/ethereum/consensus-specs/blob/dev/specs/phase0/p2p-interface.md#beacon_aggregate_and_proof.
The `AggregateAndProof` and `SignedAggregateAndProof` types are defined
here:
https://github.com/ethereum/consensus-specs/blob/dev/specs/phase0/validator.md#aggregateandproof.
I followed the implementation of `SignedBeaconBlockBellatrix`, which has
the following references:
1. cmd/lightclient/cltypes/types.go: defines the struct with relevant
SSZ annotations on the fields.
2. cmd/lightclient/cltypes/clone.go: this just returns a reference to an
empty object, so not super clear to me if it is necessary:
3. cmd/lightclient/rpc/common.go: this decodes gossip data, switching on
the type of gossip message that is received.
4. cmd/lightclient/sentinel/service/service.go: this listens on the
pubsub channel and notifies when a packet of the relevant type comes in.
5. cmd/lightclient/sentinel/pubsub.go: this defines the gossip topic
struct.
6. cmd/lightclient/lightclient/subscriber.go: this is the lightclient
interface for the incoming messages that come from the sentinel.
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
- lives in internal/logging
- all log flags moved to internal/logging/flags
- allows continued use of root logger via log.Info etc.
- update logger to take change allowing string to lvl for 'trace'
Verbosity flag is overridden by log.console.verbosity. Logs will be
colocated if all run as one process, only split where progs are run as
separate processes, in a future update this will be addressed so for
example rpcdeamon will always log to it's own file
this pr changes filterLogs to use a pre computed hashset of addresses,
instead of iterating across the list of addresses once per log.
this greatly increases the speed of filter queries that use many
addresses and also return a large number of logs. In our case, we are
performing a query for all the trades performed in a uniswap v3 pool in
a 250 block range.
my benchmarks were performed with the data & code below:
address list gist is here
[addrs](2c30b0df43/gistfile1.txt)
```
c := NewRpcClient()
addrs := []common.Address{AddressListGist}
logs, err := c.FilterLogs(context.TODO(), ethereum.FilterQuery{
FromBlock:big.NewInt(15640000),
ToBlock: big.NewInt(15640250),
Addresses: addrs,
Topics: [][]common.Hash{
{
common.HexToHash("c42079f94a6350d7e6235f29174924f928cc2ac818eb64fed8004e115fbcca67"),
},
},
```
the query contains 8442 addresses, while the response contains 1277 logs
On average, current devel averages a 15.57 second response time on my machine after 10 runs, while the new filterLogs averages 1.05 seconds.
for CURRENT DEVEL, the profile is here: https://pprof.aaaaa.news/cd8dkv0tidul37sctmi0/flamegraph
for the filterLogs branch, the profile is here: https://pprof.aaaaa.news/cd8dlmgtidul37sctmig/flamegraph
while the tests pass with this branch, I am not really sure why filterLogs was originally programmed the way it was. Is there some sort of edge case / compatibility thing that I am missing with this change?
Co-authored-by: a <a@a.a>
