Consider extending specs to engine api methods

[kevaundray]

Opening this issue to see whether it makes to extend the execution-specs to also include and test the engine api methods too.

Rationale

The responsibility of the EL is not only the core validate_block/execute method, but also the engine api methods. A block may be valid according to validate_block but the CL may see it as invalid because the version hashes do not match for example

[kevaundray]

This came up in the context of zkEVM because the boundary for the zkEVM is not validate_block but engine_newPayload

[fselmo]

@kevaundray we generate blockchain engine tests which test via engine methods engine_newPayload and FCU. Do you think this simulator needs an extension to support other engine methods, etc? More info here in case this helps 👀

[kevaundray]

ne tests which test via e

This was useful!

I think the ask would be that we are able to read the execution-specs and see what the implementation of newPayload does like we are able to for the core execution layer STF -- my understanding is that execution-specs does not specify this and is not the source of truth for this part of the EL? (probably for good reason I'm guessing)

[fselmo]

I think the ask would be that we are able to read the execution-specs and see what the implementation of newPayload does

Ah yes I see. Not just test these interactions but be the engine API spec source 👍🏼. I think it's a good idea for this to live somewhere, whether here as a new workspace package inside packages/ or elsewhere. Good food for thought.