Co-authored-by: giuliorebuffo <giuliorebuffo@system76-pc.localdomain>

Added no disconnecting with metadata requests, and we answer now with a
bogus status call and proper prefix for both status and metadata
request. This changes allows for nimbus nodes to connect to us and
actually stay connected.

Co-authored-by: giuliorebuffo <giuliorebuffo@system76-pc.localdomain>

Co-authored-by: Alexey Sharp <alexeysharp@Alexeys-iMac.local>

Adds bare minimum, base kubernetes manifests for running erigon in
kubernetes.

Does not include crucial beacon chain, persistent volumes, etc.

I currently use this as a base for 5 erigon Pods, each with an erigon
execution node and prysm beacon node, along with 10 rpcdaemon pods, a
TLS-terminated Ingress with a cert-manager issued TLS certificate. I
would like to give back to the community then use this as an upstream
kustomized base. See: https://kustomize.io

Co-authored-by: giuliorebuffo <giuliorebuffo@system76-pc.localdomain>

Co-authored-by: giuliorebuffo <giuliorebuffo@system76-pc.localdomain>

Co-authored-by: giuliorebuffo <giuliorebuffo@system76-pc.localdomain>

Co-authored-by: giuliorebuffo <giuliorebuffo@system76-pc.localdomain>

Co-authored-by: giuliorebuffo <giuliorebuffo@system76-pc.localdomain>

Co-authored-by: giuliorebuffo <giuliorebuffo@system76-pc.localdomain>

[Nethermind/Chains/xdai.json](https://github.com/NethermindEth/nethermind/blob/master/src/Nethermind/Chains/xdai.json)
does not contain `maxCodeSize`, so it defaults to 2^63-1 (virtually
unlimited).


https://gnosisscan.io/tx/0x3bfa6631d0a3a845c16674f56771de30bc840e828ea8ead21dbea04541a30173
is a transaction example on Gnosis Chain where the code size exceed the
mainnet `maxCodeSize` of 24576.

Co-authored-by: Alexey Sharp <alexeysharp@Alexeys-iMac.local>

Co-authored-by: giuliorebuffo <giuliorebuffo@system76-pc.localdomain>

Co-authored-by: giuliorebuffo <giuliorebuffo@system76-pc.localdomain>

Co-authored-by: Alexey Sharp <alexeysharp@Alexeys-iMac.local>

Issue :
https://github.com/ledgerwatch/erigon/actions/runs/3202785385/jobs/5232131489

Reason : There is no go-releaser version with v1.18.5
https://hub.docker.com/r/goreleaser/goreleaser-cross/tags

Updated it to v1.18.1 which we use in matic-fork/erigon.

-  Fixed commitment issues both erigon3/erigon4
-  get back update-based commitments approach
-  partially fixed state seeking

This PR brings support for BSC Moran fork

Co-authored-by: Timur Mustafin <timur@mustafin.dev>

Setup calls for rpc testing
- Added call requests for testing rpc calls
- Added new methods getBalance and txPool content

Previously "in-memory" MDBX instances for fork validation and mining
were created inside `os.TempDir()`. We should create them inside
Erigon's datadir so that the file permissions and the disk are the same
as for the main database.

Prerequisite: ledgerwatch/erigon-lib#676.

…5701)

Seems simple enough, don't stop on interrupt but start a timer instead
and check on each loop if we should stop now or allow the block to
finish on its own

Co-authored-by: dc <dctrlbox@gmail.com>

feat: add `erigon_getLatestLogs` as a new feature API.
1. `erigon_getLatestLogs` returns latest logs that match the filter with
`logCount` length. Implementation is similar to `erigon_getLogs` but it
uses `ReverseIterator` which makes it more efficient to fetch the latest
logs.

Also cherry-pick ethereum/go-ethereum#24666.

Co-authored-by: Felix Lange <fjl@twurst.com>

See NethermindEth/nethermind#3930

Co-authored-by: Alexey Sharp <alexeysharp@Alexeys-iMac.local>

Co-authored-by: Alexey Sharp <alexeysharp@Alexeys-iMac.local>

Will gain more perf improvements when the change for kvcache goes in
from erigon-lib.

Hopefully can be validated with hive? My main concern is the re-use of
the state reader, I couldn't find any manipulation of it so it looks
safe to re-use.

refactor: add `erigon_getLatestLogs` & fix typo

…le) (#6007)

Co-authored-by: Alexey Sharp <alexeysharp@Alexeys-iMac.local>

Iteration order over go maps is random.

Part of #5884 defined in the
spec
https://github.com/ethereum/consensus-specs/blob/dev/specs/phase0/p2p-interface.md#status.

We need this functionality to continue
#5965 because we need to
determine how many blocks to request from the checkpoint block.

Code news up an oracle for every call so existing cache checks always
came back as 0. Moved cache up a layer and pass in via the new
`gasprice.Cache` interface. Looked at putting the oracle instance onto
the ethApi itself to re-use it that way, but the backend transaction
made it a little hard work as we can't re-use that. This seemed cleaner
but happy to take feedback.

Locally takes me from ±2.5k rps to ±43k rps so quite a difference there.
(k6 with 1000 virtual users)

write trace transaction errors to json and continue

lightclient cl is default, for external cl, run `--externalcl`

Co-authored-by: Alexey Sharp <alexeysharp@Alexeys-iMac.local>

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"
```

Co-authored-by: Alexey Sharp <alexeysharp@Alexeys-iMac.local>

Pick up
erigontech/interfaces@813d816
& erigontech/interfaces#131.