Closed sduchesneau closed 1 year ago
Before FastFinality is enabled, the fork choice is based on the TD(TotalDifficulty). The blocks that you marked BAD are taken as a side chain, see: https://github.com/bnb-chain/bsc/blob/master/eth/fetcher/block_fetcher.go#L380 So this the current code logic, if a remote peer broadcast "BAD" blocks with height >= (currentHeight - 11), these blocks will be imported.
I think, we can add the Finality check here, i.e. if the LastFinalizedBlock is 31,030,257, we can stop import blocks before it.
Our Firehose tracer traces side chains and this was causing errors later downstream because our invariant is that forked blocks (side blocks) will never be emitted/imported if the fork height <= final block height.
We implemented a similar fix as yours in our geth
Firehose tracer to avoid importing forked blocks that are below final height.
Thank you @brilliant-lx!
System information
Geth version:
v1.2.10
with firehose instrumentation on top of it OS & Version: Linux Commit hash :github.com/streamingfast/go-ethereum
7535e671a0303f3c327f065d69da1ca558849420
Expected behaviour
Reorgs from block X to another version of block X should not import blocks X-2, X-1, etc. from a bad reorg. This is causing issues with our instrumentation, but we see this mostly as an odd behavior and are trying to get to the bottom of this.
Actual behaviour
We saw the following logs when block
260
caused a reorg (drop=1, add=1). See the disordered block numbers. I have anotated the logs withX
next to the surprising block numbers, and appendedGOOD
orBAD
to see which blocks are now actually canonical.When block 31,030,260 came out, the LastFinalizedBlock was 31,030,257. Then, processing a wrong version of block
31,030,255
makes no sense to me.Steps to reproduce the behaviour