See ethereum/EIPs#7154

This change adds 'any' as an alternate wildcard to '*'.

I have updated all doc references in the main erigon repo - let me know
if there is anywhere else that needs changing.

I realised that the term `checkpoint` is used in 2 different meanings in
the code, which are distinct. Renaming one of the to persistentSnapshots
to reduce confusion

This is another update to logging to replace the root logger with a
contextual logger

- do it only once in HistoryStateReader

…ce.senders` which enabling more verbose logging for given senders list (erigontech#7686)

When testing with `Bor` consensus turned on I discovered that
`SendRawTransaction` returns a 0x000... hash when transactions are
submitted during block transitions. This turns out to be spurious in the
sense that the transaction insertion is successful.

The cause is that `ReadCurrentBlockNumber` returns a nil block number.

This in turn is caused by the following: In `accessors_chain.go` there
are two methods: `WriteHeader` and `WriteHeadHeaderHash` when the first
is called the block number is written for the header. The second writes
the header has, but there is no guarantee when it does that the head
header will have been written yet. In fact it seems to happen sometime
later.

The problem for `SendRawTransation` is that it begins a transaction
after inserting into the txpool. And depending on timing this
transaction may see only the `WriteHeadHeaderHash` insertion, and hence
can't read the block number.

I have mitigated this by opening the db transaction before calling the
tx pool insertion, meaning that it is more likely to have a clean view
of the DB.

I have also moved the chain id check earlier in the code - as I think
that if this is invalid the method should not try to insert transactions
in the first place.

The `ReadCurrentBlockNumber` is only used to produce a log message - so
I've changed this to not fail the whole function but to just log an
unknown sender. Which means that the hash is still returned to the
sender after a successful txpool insertion

Added so now we can have version 3 payloads preparing for Deneb

Now you can configure:

Read timeout (default: 5s)
Write timeout  (default: 5s)
On/off (default: ON)
Port (default:5555)
Address (default:localhost)
Protocol (default: tcp)

erigontech#7684

start of abstracting the transition layer. 

incremental movements.

Fix: typos

…ech#7689)

This PR does the following things. 

- Optimises the get span for bor function. The function was responsible
to fetch span from heimdall and store in cache. If not found, it would
iterate back (or front) depending on the last found span in cache. In
this iteration it would also fetch the span every time it moves front /
back which is not necessary at all. As we know the `spanLength` we can
leverage it to directly jump to the required span ID without fetching
all the intermediate ones.
- Adds a check for `number > 255` in validating producers from headers'
extra data with ones in span. As bor fetches this data from contract, it
used to give correct results for 0th span (i.e. 0-255 blocks) and hence
no error occurs. Erigon on the other hand directly uses span to get
producers for all blocks. Hence, the data in 0th span turns out to be
wrong (as it's hardcoded in contract). We can skip validation for 0th
span blocks until we start fetching data from contract.
- As we're planning to use erigon as a validator, it will also be
responsible for preparing headers. It used to write all the validators
in the `header.Extra` field instead of just the selected producers. As
we have `GetCurrentProducers` function available now, we can use it
instead of `GetCurrentValidators`.

This request adds an additional logging flag to change the name of the
logfiles produced by erigon to be prefixed by a name other than
'erigon'.

This allows multiple nodes to log to the same directory without
overwriting each others files. It is requires so that the devnet when
running can maintain all of its log files in a single consolidated
directory which survives devnet restarts.

---------

Co-authored-by: Mark Holt <[email protected]>

…h#7720)

…checking invalid err variable (erigontech#7719)

attempt to address next issue: 

> when I'm having a lot of websocket connections the node is freezing
and then it needs like 10 mins to sync. Then if I keep pushing requests
it falls out of sync all the time

For legacy transactions ChainID is optional (missing in
pre-[EIP155](https://eips.ethereum.org/EIPS/eip-155) transactions) and
is derived from `V` anyway.

Also, cherry pick ethereum/go-ethereum#27452.

Fix some issues introduced in PR erigontech#7715

Post-fix after PR erigontech#7732

Co-authored-by: Alex Sharov <[email protected]>

This is an update to the devnet code which introduces the concept of
configurable scenarios. This replaces the previous hard coded execution
function.

The intention is that now both the network and the operations to run on
the network can be described in a data structure which is configurable
and composable.

The operating model is to create a network and then ask it to run
scenarios:

```go
network.Run(
		runCtx,
		scenarios.Scenario{
			Name: "all",
			Steps: []*scenarios.Step{
				&scenarios.Step{Text: "InitSubscriptions", Args: []any{[]requests.SubMethod{requests.Methods.ETHNewHeads}}},
				&scenarios.Step{Text: "PingErigonRpc"},
				&scenarios.Step{Text: "CheckTxPoolContent", Args: []any{0, 0, 0}},
				&scenarios.Step{Text: "SendTxWithDynamicFee", Args: []any{recipientAddress, services.DevAddress, sendValue}},
				&scenarios.Step{Text: "AwaitBlocks", Args: []any{2 * time.Second}},
			},
		})
```
The steps here refer to step handlers which can be defined as follows:

```go
func init() {
	scenarios.MustRegisterStepHandlers(
		scenarios.StepHandler(GetBalance),
	)
}

func GetBalance(ctx context.Context, addr string, blockNum requests.BlockNumber, checkBal uint64) {
...
```
This commit is an initial implementation of the scenario running - which
is working, but will need to be enhanced to make it more usable &
developable.

The current version of the code is working and has been tested with the
dev network, and bor withoutheimdall. There is a multi miner bor
heimdall configuration but this is yet to be tested.

Note that by default the scenario runner picks nodes at random on the
network to send transactions to. this causes the dev network to run very
slowly as it seems to take a long time to include transactions where the
nonce is incremented across nodes. It seems to take a long time for the
nonce to catch up in the transaction pool processing. This is yet to be
investigated.

- breaks dependency from staged_sync to package with block_reader
implementation
- breaks dependency from snap_sync to package with block_reader
implementation
- breaks dependency from mining to txpool implementation

Continuation of PR erigontech#7715