Allow zero safeBlockHash and finalizedBlockHash after finalization

[dapplion]

Summary

• Remove the restriction that safeBlockHash and finalizedBlockHash must be non-zero once the transition block is finalized
• When set to zero, the EL defaults to the latest known value (or genesis)
• The -38002 invalid forkchoice state check now only applies to non-zero hashes

Motivation

During extended non-finality periods, a CL client checkpoint-syncing from a non-finalized state may not yet know the network's finalized or safe block hash. The current spec forces the CL to provide non-zero values post-merge, which is not always possible. This change lets the CL signal "unknown" by sending zeroes, with the EL falling back to its last known state.

The other options are:

• The CL tells the EL "fake" safe and finalized hashes (the checkpoint root), breaking the meaning of those block tags in the first place
• The CL tries to fetch the execution hashes of the finalized and justified checkpoints from its p2p or checkpointz server. Possible, (and we want to implement it) but this PR is still helpful. If checkpointz faults and can't provide the blocks for finalized and justified checkpoint the network can't sync, potentially killing liveness on a catastrophic event.

See also: sigp/lighthouse#8382

[mkalinin]

The safeBlockHash with FCR implementation may point to an already unsafe block on the EL side. In this case EL should rather revert it to finalizedBlockHash

[dapplion]

How would you phrase that?

[mkalinin]

Suggested change

	*Note:* `safeBlockHash` and `finalizedBlockHash` fields are allowed to have `0x0000000000000000000000000000000000000000000000000000000000000000` value. When set to zero, the client **MUST** default to the latest known value for the corresponding field, or the genesis block hash if no value is known.
	*Note:* `safeBlockHash` and `finalizedBlockHash` fields are allowed to have `0x0000000000000000000000000000000000000000000000000000000000000000` value. When set to zero, the client **MUST** default both values to the latest known `finalizedBlockHash` value, or the genesis block hash if no `finalizedBlockHash` value is known.

Will the above work?

[mkalinin]

I think we should make this an explicit statement in the fcU spec below to aid visibility.

[jochem-brouwer]

I think the zero case is especially important for the transition period, changing this now is possible since we have transitioned, but it does not feel very "clean" to "change" the behavior at the transition. I also realize that not being backwards compatible should not be a big problem (assume chains have already transitioned or new chains start in PoS mode) so not a super strong opinion here, but one suggestion:

How about adding this rule to forkchoiceUpdatedV2 and all FcUs after, instead of forkchoiceUpdatedV1? This would keep the "old" behavior and ship new behavior to a fork after the transition.

[mkalinin]

I think that zero hash would work for both situations:

• When transition block isn’t yet finalized, there is yet no known finalized block on EL side and it’s fine to mark genesis block as final
• When there is already a finalized block, EL will stick with it unless a non-zero hash comes from the CL side