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
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 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.
Added two new flags beacon.api.port and beacon.api.addr
Now we can listen for beacon api and get beacon genesis
---------
Co-authored-by: Giulio <giulio.rebuffo@gmail.com>
This PR does the following things:
- Updates the hardfork number of the upcoming Indore hardfork schedule
at block 36877056.
- Refactoring to `CommitStates` method of bor consensus
- Fixes a bug in triggering mining
I've added a non root logger to bor.ValidatorSet validator set. This
creates a signature change on a number of calling functions to propagate
the logger. This is mostly constrained to the bor package but impacts a
number of tests and utilities which call the validators set.
- allow store non-canonical blocks/senders
- optimize re-org: don't update/delete most of data
- allow mark chain as `Bad` - will be not visible by eth_getBlockByHash,
but can read if have hash+num
This branch is intended to allow the devnet to be used for testing
multiple consents types beyond the default clique. It is initially being
used to test Bor consensus for polygon.
It also has the following refactoring:
### 1. Network configuration
The two node arg building functions miningNodeArgs and nonMiningNodeArgs
have been replaced with a configuration struct which is used to
configure:
```go
network := &node.Network{
DataDir: dataDir,
Chain: networkname.DevChainName,
//Chain: networkname.BorDevnetChainName,
Logger: logger,
BasePrivateApiAddr: "localhost:9090",
BaseRPCAddr: "localhost:8545",
Nodes: []node.NetworkNode{
&node.Miner{},
&node.NonMiner{},
},
}
```
and start multiple nodes
```go
network.Start()
```
Network start will create a network of nodes ensuring that all nodes are
configured with non clashing network ports set via command line
arguments on start-up.
### 2. Request Routing
The `RequestRouter` has been updated to take a 'target' rather than
using a static dispatcher which routes to a single node on the network.
Each node in the network has its own request generator so command and
services have more flexibility in request routing and
`ExecuteAllMethods` currently takes the `node.Network` as an argument
and can pick which node (node 0 for the moment) to send requests to.
- stage_senders: don't re-calc existing senders
- stage_tx_lookup: prune less blocks per iteration - because
random-deletes are expensive. pruning must not slow-down sync.
- prune data even if --snap.stop is set
- "prune as-much-as-possible at startup" is not very good idea: at
initialCycle machine can be cold and prune will cause big downtime, no
reason to produce much freelist in 1 tx. People may also restart erigon
- because of some bug - and it will cause unexpected downtime (usually
Erigon startup very fast). So, I just remove all `initialSync`-related
logic in pruning.
- fix lost metrics about disk write byte/sec
