fix: add special logic to handle ancestor errors[BNB-3]

[welkin22]

Description

The function block_validator.go:ValidateBody() executes validateFuns concurrently using gopool . Under normal circumstances, ValidateBody() waits for all validateFuns to complete. However, if any of the validateFuns returns an error,
ValidateBody() promptly returns with that error. Consequently, if more than one validation function returns an error, it can lead to non-deterministic selection of which error is returned.
After examining the flow and call sources of ValidateBody() , we discovered that certain errors, specifically consensus.ErrUnknownAncestor and consensus.ErrPrunedAncestor , are returned before any errors related to transactions or withdrawals. This sequence could cause the client database to store invalid blocks. To clarify with an example: If a block contains invalid transactions or withdrawals (meaning the hashes in the header don't match the expected calculations) and it also references an unrecognized parent block, there's a risk. If the third goroutine is the first to respond, the main calling function might wrongly assume the block's transactions and withdrawals are correct because it didn't detect the anticipated errors.
These errors receive special handling in blockchain.go:insertChain()#L1721-1736 . For instance, the code attempts to insert the side-chain, recover the ancestor chain, or add it to a future block candidate. While most processes involve re-insertion of the block using the same function ( insertChain() ), a particularly concerning scenario occurs in the blockchain.go:insertSideChain() function, as it may call bc.writeBlockWithoutState() to write the invalid block data into the database.

Rationale

Prevent Race Condition Can Lead to Storing Invalid Blocks in DB

Example

none

Changes

• Fix problematic code in ValidateBody function