You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
In the p2p-interface specifications for The Merge, the following rule applies during
beacon_block
gossip verification:I'm curious about why a post-merge head state can prohibit the import of pre-merge blocks.
Consider the following scenario:
BP1
) is on a minority fork of the execution chain. That minority fork has crossed thetotal_terminal_difficulty
(TTD) threshold.BP1
produces a block, validates it and sets it as its own head.BP2
) was not on the minority execution fork and therefore rejected the block fromBP1
BP2
produces a block that conflicts with the one fromBP1
and does not trigger the merge.BP1
converges with the network and reverts to the same chain asBP2
BP1
will reject the block fromBP2
, 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 fromBP2
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?
The text was updated successfully, but these errors were encountered: