Extend Deneb with Execution layer cross-validation

[dapplion]

Add spec for routes introduced by @karalabe in https://gist.github.com/karalabe/47c906f0ab4fdc5b8b791b74f084e5f9

In summary, these routes allow one to request witnesses from an execution client, and submit them to another for stateless execution.

Refer to Peter's doc for more detailed rationale https://gist.github.com/karalabe/47c906f0ab4fdc5b8b791b74f084e5f9#engine-api-specs

[karalabe]

Based on the discussions on discord, I've converted the witness to a fully opaque blob on the engine API. I.e.

• The StatelessWitnessV1 type was dropped altogether, as the CL doesn't need to interpret anything inside.
• Wherever the StatelessWitnessV1 type was used, it's now an opaque DATA type.
  • For reference, the content of the opaque data is an RLP encoded witness, as defined in my spec doc.

This should both make the api diff smaller, as well as more performant by avoiding witness parsing CL side.

[mkalinin]

We used to have src/engine/experimental folder to keep specs of the feature that aren’t yet scoped for any HF. I think it is better to move this spec there, and once we’re ready include it in Prague or another HF.

[dapplion]

We used to have src/engine/experimental folder to keep specs of the feature that aren’t yet scoped for any HF. I think it is better to move this spec there, and once we’re ready include it in Prague or another HF.

This change is not part of any hard-fork, and can be enabled at any time (including before Pectra) by some clients without coordination. Given that where would you place it?

[mkalinin]

This change is not part of any hard-fork, and can be enabled at any time (including before Pectra) by some clients without coordination. Given that where would you place it?

It seems that we would need to update newPayloadWithWitness and executeStatelessPayload every time when the payload struct changes. Can we have newPayload response to be extended with the witness field which is optional? Something like:

PayloadStatusV2:

• status: enum - "VALID" | "INVALID" | "SYNCING" | “ACCEPTED"
• latestValidHash: DATA|null, 32 Bytes - the hash of the most recent valid block in the branch defined by payload and its ancestors
• validationError: String|null - a message providing additional details on the validation error if the payload is classified as INVALID
• witness: DATA|null - Opaque blob containing witness data RLP encoded if provided.

In this case it can become a part of the API since Prague. If we want to make this functionality parallel to the main payload processing flow (i.e. always be implemented via separate methods) then it can be introduced in Cancun I believe, and updated accordingly in Prague.