fix: parentBeaconBlockRoot fallback in engine_newPayloadV4

[forkfury]

Fix

Fixes #9921 - Occasional "Parent beacon block root must be set" error when processing engine_newPayloadV4 requests from op-node.

Changes

• Modified ExecutionPayloadParams.ValidateParams() to fall back to executionPayload.ParentBeaconBlockRoot when the parentBeaconBlockRoot parameter is null
• Parameter value still takes precedence when provided (backward compatible)
• Allows valid op-node requests that set parentBeaconBlockRoot in the payload object instead of as a method parameter

[LukaszRozmej]

but normally executionPayload.ParentBeaconBlockRoot is null and is set few lines below. Unless the mechanism is different in Optimism and it comes from PayloadDecoder?

@emlautarom1 @deffrian ?

[emlautarom1]

I've been taking a look at our implementation of the OP-CL and also in OP-node, and in both cases the ParentBeaconBlockRoot sent as parameter is the same in the executionPayload.ParentBeaconBlockRoot parameter, so the assignment is a no-op (this is the case for all post-Ecotone blocks).

The proposed fix most likely does not work as intended. Have you tested this @forkfury ?

[LukaszRozmej]

@emlautarom1 What about others op-cl implementations?

[emlautarom1]

AFAIK there are only two implementations: op-node (official CL) and ours.

[emlautarom1]

We are looking into this as a potential fix but we're not fully sure that it's the correct approach or even if it will have any semantic effect.

Could you add the following logs:

• When the input executionPayload does have a non null ParentBeaconBlockRoot as "info"
• When the input executionPayload does have a non null ParentBeaconBlockRoot and it does not match the input parentBeaconBlockRoot as "warning"
• When the finalParentBeaconBlockRoot variable is null as "error".

[LukaszRozmej]

@forkfury please add above logging