Workaround for https://github.com/ledgerwatch/erigon/issues/6308
Very inefficient, because it get 1 single header from the request of 192
headers, so moves quite slowly
Co-authored-by: Alexey Sharp <alexeysharp@Alexeys-iMac.local>
Embedded CL is not supported for Gnosis Chain, so it makes sense to set
`externalcl` to true by default for it.
Also, this PR sets `terminalTotalDifficultyPassed` for Gnosis Chain &
Chiado (see https://docs.gnosischain.com/updates/20221210-merge).
FIrst of all, thanks in advance for your advice.
I've found that `trace_replayTransaction` is having trouble tracing some
Polygon State Sync transactions such as
[`0xd5f4f8c3cd85cf65e8df23a2c1ae02aefda1e6293db0c3a9ddcc08cee8ca1131`](https://polygonscan.com/tx/0xd5f4f8c3cd85cf65e8df23a2c1ae02aefda1e6293db0c3a9ddcc08cee8ca1131),
just like [the case of the previous PR][p].
[p]: https://github.com/ledgerwatch/erigon/pull/6286
```shell
$ curl -XPOST 'http://localhost:8545' \
-H 'Content-Type: application/json' \
--data '{"method":"trace_replayTransaction","params":["0xd5f4f8c3cd85cf65e8df23a2c1ae02aefda1e6293db0c3a9ddcc08cee8ca1131",["trace","stateDiff"]],"id":1,"jsonrpc":"2.0"}'
{"jsonrpc":"2.0","id":1,"result":null}
```
This is because RPCDaemon doesn't query for blocks by Bor Hash, even
though `api.txnLookup` has failed. Same as #6286.
Same as #6286 and #6288
This patch closes#6276
```shell
$ curl -XPOST 'http://localhost:8545' \
-H 'Content-Type: application/json' \
--data '{"method":"eth_getTransactionReceipt","params":["0x31ce15ce9a1ff347f4204a1ed3625861165c53ae08743c1f36a32865c62744c6"],"id":1,"jsonrpc":"2.0"}'
{"jsonrpc":"2.0","id":1,"error":{"code":-32000,"message":"block has less receipts than expected: 0 \u003c= 0, block: 36635776"}}
```
cc. @0xKrishna
FIrst of all, thanks in advance for your advice.
I've found that `eth_getTransactionByHash` is having trouble retrieving
some Polygon State Sync transactions such as
[`0xd5f4f8c3cd85cf65e8df23a2c1ae02aefda1e6293db0c3a9ddcc08cee8ca1131`](https://polygonscan.com/tx/0xd5f4f8c3cd85cf65e8df23a2c1ae02aefda1e6293db0c3a9ddcc08cee8ca1131),
while `eth_getBlockByNumber` can retrieve them without problem.
```shell
$ curl -XPOST 'http://localhost:8545' \
-H 'Content-Type: application/json' \
--data '{"method":"eth_getTransactionByHash","params":["0xd5f4f8c3cd85cf65e8df23a2c1ae02aefda1e6293db0c3a9ddcc08cee8ca1131"],"id":1,"jsonrpc":"2.0"}'
{"jsonrpc":"2.0","id":1,"result":null}
```
This is because RPCDaemon doesn't query for blocks by Bor Hash, even
though `api.txnLookup` has failed.
Regarding https://github.com/ledgerwatch/erigon/issues/6260
added flag `--p2p.allowed-ports=<porta>,<portb>` to restrict which ports
to use for sentries for different protocol versions.
Default for this flag is `30303, 30304` (first port is inherited from
`--port` flag defaults.
If `--port` is changed and it's new value is not presented in allowed
port list, provided port will be allowed as well as list provided via
`--p2p.allowed-ports`
Port picking is straightforward, we create sentry gRPC server for
protocol over first allowed port that is not already taken.
If there are no allowed ports left, erigon exits with hint.
Works around a flaw in the upgrade logic of the system contracts. Since
they are updated directly, without first being self-destructed and then
re-created, the usual incarnation logic does not get activated, and all
historical records of the code of these contracts are retrieved as the
most recent version. This problem will not exist in erigon3, but until
then, a workaround will be used to access code of such contracts through
a special structure, `SystemContractCodeLookup`
Fixes https://github.com/ledgerwatch/erigon/issues/5865
Co-authored-by: Alexey Sharp <alexeysharp@Alexeys-iMac.local>
