Upgrade Geth to v1.14+

[AnnaShaleva]

Rationale

Fetch Geth v1.14+, we need to be up-to-date.

Implementation

We have to deal with at least two major problems (see the release notes for more details):

1. Geth v1.14.0 stops automatically constructing the pending block (miner: refactor the miner, make the pending block on demand ethereum/go-ethereum#28623).

2. Geth v1.14.0 drops support for running pre-merge networks (consensus, eth: remove support for non-merge mode of operation ethereum/go-ethereum#29169).

[AnnaShaleva]

One more problem introduced by ac0ff044. Shanghai (and other post-merge hardforks) are not acceptable before the merge anymore even if configured from the genesis block:

   	IsMerge:          isMerge,
   	IsShanghai:       isMerge && c.IsShanghai(num, timestamp),
   	IsCancun:         isMerge && c.IsCancun(num, timestamp),
   	IsPrague:         isMerge && c.IsPrague(num, timestamp),
   	IsVerkle:         isMerge && c.IsVerkle(num, timestamp),

The problem is connected with the way how the merge is defined:

isPostMerge := header.Difficulty.Cmp(common.Big0) == 0

dBFT always sets non-zero difficulty (ref. #58 and #117) and zero difficulty is not possible without significant changes in the beacon engine. The problem is: dBFT is integrated as a pre-merge engine, and pre-merge engines are not supposed to have zero difficulty (we've already discussed this problem in ).

[txhsl]

Can we ignore or revert the Merge things? Because we are not going to have a beacon chain or a beacon node.

[AnnaShaleva]

Can we ignore or revert the Merge things?

We can't ignore them because we need them, new features are introduced and users will expect it to work proterly. We can revert some of them, but it's not that simple and it's a way that will end in larger and larger efforts from our side to keep our codebase at least working. We need Geth 1.14+, and the last described problem is relatively easy to solve (just revert these isMerge changes). But first two problems go deep in the protocol, we'll stuck in reverting them and making the rest of the code work properly, because Geth is actively developing and there is new code written over the new post-merge base, and we need this new code.

Because we are not going to have a beacon chain or a beacon node.

To be honest, I'm starting to think about it. May be it's not that bad to migrate dBFT to post-merge consensus scheme, because it will allow us to easily be in sync with all Geth changes. But for now I agree that it's not the first priority since we have to complete DKG firstly.

[AnnaShaleva]

Within the scope of this issue we need to consider reverting changes made for temporal compatibility of earlier Geth versions:

• 9d380aa
• core/vm: let opRandom handle nil #289

We can't just revert these changes without any additional workarounds because it'll lead to state differences in existing chains. Instead, we need something like N3 hardforks where we get the original Geth behaviour back.

[txhsl]

Ref bnb-chain/bsc#2761.