mirror of
https://gitlab.com/pulsechaincom/erigon-pulse.git
synced 2024-12-22 11:41:19 +00:00
1da4d3abbf
In context of https://github.com/ledgerwatch/erigon/issues/5694, this PR adds some fixes and improvement in the mining flow. Also, a relevant change in txpool (present in erigon-lib) is made here: https://github.com/ledgerwatch/erigon-lib/pull/737 #### Changes in triggering mining in `startMining()` The mining module didn't honour the block time as a simple 3 second timer and a notifier from txpool was used to trigger mining. This would cause inconsistencies, at least with the bor consensus. Hence, a geth like approach is used instead for simplicity. A new head channel subscription is added in the `startMining()` loop which would notify the addition of new block. Hence, this would make sure that the block time is being honoured. Moreover, the fixed 3 second timer is replaced by the `miner.recommit` value set using flags. #### Changes in the arrangement of calls made post mining When all the mining stages are completed, erigon writes all the data in a cache. It then processes the block through all the stages as it would process a block received from P2P. In this case, some of the stages aren't really required. Like the block header and body download stage is not required as the block was mined locally. Even execution stage is not required as it already went through it in the mining stages. Now, we encountered an issue where the chain was halted and kept mining the same block again and again (liveness issue). The root cause is because of an error in a stage of it's parent block. This stage turns out to be the 4th stage which is "Block body download" stage. This stage tries to download the block body from peers using the headers. As, we mined this block locally we don't really need to download anything (or process anything again). Hence, it reaches out to the cache which we store for the block body. Interestingly that cache turned out to be empty for some blocks. This was because post mining, before adding block header and body to a cache, we call the broadcast method which starts the staged sync. So, technically it’s a bit uncertain at any stage if the block header and body has been written or not.(see [this](https://github.com/ledgerwatch/erigon/blob/devel/eth/backend.go#L553-L572)). To achieve complete certainty, we rearranged the calls with the write to cache being called first and broadcast next. This pretty much solves the issue as now we’re sure that we’d always have a block body in the cache when we reach the body download stage. #### Misc changes This PR also adds some logs in bor consensus. |
||
|---|---|---|
| .. | ||
| aura | ||
| bor | ||
| clique | ||
| db | ||
| ethash | ||
| misc | ||
| parlia | ||
| serenity | ||
| consensus.go | ||
| errors.go | ||
| result.go | ||