Merge side-effect: duplicate execution state-root concern

[protolambda]

As far as I'm aware, the state-root in the eth1 block structure is of a MPT of the world-state, a tree of accounts, no data that changes regardless of block contents, with the exception of the block-reward. @djrtwo was asking about a repeat of the state root in PR #2380 and pointed out EIP 210 (block hash history) as something that could touch the state unconditionally (but this EIP isn't actually deployed on mainnet)

With the Merge transition to Eth2, we get a fun new edge-case, due to the move of block-rewards from execution layer (block coinbase) to consensus layer (proposer reward), the tree can stay completely untouched if there are no transactions in the block.

Questions:

• Is this indeed the case, or is there some additional content in the tree of this state-root?
• Is this tested in Eth1 / future execution engine?
• Are there other ethereum forks that have live examples of duplicate state roots, due to different block reward approach and empty blocks? Maybe a PoA testnet?

Tracking:

• Add test case for Merge with multiple beacon blocks, but with the same state-root in the execution-payload, in eth2 consensus tests.

[mkalinin]

We have been discussing this side-effect recently during one of the merge calls. It's been said that Clique also tends to have state_root unchanged in case if block has no transactions. As a result, a good example of Ethereum network with duplicated state roots is Rinkeby, look at its earliest blocks: #1 and #2. This is also the case for the merge testnets.

Related edge case we get is two beacon blocks point to identical execution blocks (the same block from execution engine perspective) as a result of forking. But as long as this case is processed correctly, i.e. execution block stays valid if imported the second time and stays in the canonical chain even if the second beacon block is orphaned, I think we're OK with that.

EDT
If we decide to mix randao into execution block structure to maintain randomness then two identical execution blocks won't be the case unless there are two blocks from the same proposer which is a slashable offense.

[mkalinin]

I think we should also take the fact that state trie node is immutable and is either removed entirely or persisted by the canonical chain. IMO, it makes it easier to reason about this edge. The case when a block is dereferenced and removed from the storage should be analysed, in particular, client must not remove the state or a part of it if there is another reference to it from the other block.

From what I know, state pruning algorithms must not remove state nodes that persisted in the canonical chain, because block execution from a fork might insert the same trie nodes as the canonical blocks did. So, when orphaned trie nodes are removed their persistence in the canonical chain is taken in account. These algorithms must either support a ref counting or some alternative technique to handle these cases.

[mkalinin]

It worth mentioning that #2479 (difficulty = randao_mix) makes the situation when two beacon blocks referencing the same execution block no longer the case