stagedsync: fix bor heimdall mining flow #9149
Conversation
…reader-span-and-loggers
|
|
||
| // Whitelist service is called to check if the bor chain is on the canonical chain according to milestones | ||
| whitelistService := whitelist.GetWhitelistingService() | ||
| if whitelistService != nil && !whitelistService.IsValidChain(headerNum, []*types.Header{header}) { |
There was a problem hiding this comment.
As discussed, we might not need this check at all in the mining stage as the block passes through sync stages anyways. But, if the plan is to refactor that part and prevent the block from going to every sync staged when it's mined by the node itself, then yeah we can keep this.
There was a problem hiding this comment.
@manav2401 blocks are broadcast to the p2p network when they are freshly out of the mining loop (in addition to being communicated to the sync loop) - think this check is here to prevent the miner from broadcasting a bad block, ive left it in to maintain same logic as before my refactor
There was a problem hiding this comment.
Alright yeah makes sense. Although, it's very rare for this to happen but if the node is out of sync and still tries to produce a block, it may happen. Thanks!
There was a problem hiding this comment.
yes, we can always revise this later once we do bigger refactors - will keep it in mind
This PR fixes 2 things which are more commonly visible in multi client devnet setups for polygon. Context: The span logic is a bit different when it comes to first 2 spans. Bor/Erigon makes the first commit for a span during the start of sprint (i.e. if sprint length is 16, it will call `commitSpan` at block 16 in bor consensus for the first time). Span 0 is hard coded in genesis contracts so it needs to commit span with `id=1` on that block (see equivalent code in bor [here](https://github.com/maticnetwork/bor/blob/v1.2.3/consensus/bor/bor.go#L1150-L1152)). At that time, it needs to have 1st span available. Bor fetches it on the go while erigon processes it in a separate stage and stores in a snapshot. Hence, we'd need to fetch 1st span as an exception in erigon while we're still in span 0 but also need to make sure that it doesn't block processing of any previous blocks. Based on #9149, the span ID used to fetch and commit span was wrong and the span 1 needs to be loaded explicitly in 1st sprint.
Currently the mining loop is broken for the polygon chain. This PR fixes this.
High level changes:
mineflag for the Bor<->Heimdall sync stageStartMiningfunction to prefetch span zero if needed before the mining loop is startedTest with devnet "state-sync" scenario:
