Engine API: Strict message ordering

[djrtwo]

Avoid degenerate race conditions via the following:

• Require caller to utilize strictly increasing JSON RPC message IDs
• Require callee to respect absolute ordering in execution of calls

Note, there might be optimizations depending on message type (e.g. if multiple forkhcoice calls, only execute the latest) but these are left to implementation details

[mkalinin]

What do you think about enforcing CL to define a logical order of all messages in Engine API. I don't think it increases the complexity comparing to the original proposal but it could be used by EL in syncing process when it received a batch of executePayload and uses only the last one skipping the old ones. Also, EL respecting the order is good in general as it would reduce the surface of potential inconsistency, if there are two executePayload messages received at the same with a parent and a child then they could be processed in correct order if such order can be derived

[djrtwo]

I'm not 100% sure here. Respecting order is different depending on the operation and the context.

executePayload order should be respected and each executed (!) because otherwise when in lock-step mode you could miss a dependency.

Whereas forkchoice order only requires the latest message to be applied and earlier RPC IDs can be ignored

[mkalinin]

I'm not 100% sure here. Respecting order is different depending on the operation and the context.

Absolutely. What I am thinking about is CL signalling the order of all (not only some) messages to EL, and EL then decides what to do with the order. For getPayload the order might not matter at all while for executePayload and forkchoiceUpdated it matters but has different semantics -- and deciding on that should be up to EL.

[mkalinin]

Another thing that worries me a bit is hijacking on the JSON-RPC request id. It looks fine but having double semantics for this ID might be inconvenient in some cases. But we should see the need of separate ID in practice before introducing it.

[djrtwo]

done