Merge: beacon block gossip verification restricts forking

[paulhauner]

In the p2p-interface specifications for The Merge, the following rule applies during beacon_block gossip verification:

• If the merge is complete with respect to the head state -- i.e. is_merge_complete(state) -- then validate the following:
  • [REJECT] The block's execution payload must be non-empty -- i.e. execution_payload != ExecutionPayload()

I'm curious about why a post-merge head state can prohibit the import of pre-merge blocks.

Consider the following scenario:

• A beacon proposer (BP1) is on a minority fork of the execution chain. That minority fork has crossed the total_terminal_difficulty (TTD) threshold.
• BP1 produces a block, validates it and sets it as its own head.
• The beacon proposer for the next slot (BP2) was not on the minority execution fork and therefore rejected the block from BP1
• BP2 produces a block that conflicts with the one from BP1 and does not trigger the merge.
• The execution node of BP1 converges with the network and reverts to the same chain as BP2
• BP1 will reject the block from BP2, even though it is valid and may be destined to become the majority chain.

I think that in practice BP1 would end up importing the block from BP2 via RPC, but it seems a little odd to rely on that procedure.

Ultimately, my question is:

Do we desire this "latching" which prevents us from importing and propagating a non-merge gossip block after we've elected a merge block as the head?

[mkalinin]

Good point! I am not sure what the original intention was but this rule should be applicable to descendants of the transition block and not every block in the system. It basically rejects post-merge blocks with empty payload.

[djrtwo]

resolved in #2621