Integrate request validation in EngineValidator

[mattsse]

Describe the feature

I think this is an alternative to

#13831

and

alloy-rs/op-alloy#395

currently we do:

reth/crates/rpc/rpc-engine-api/src/engine_api.rs

Line 271 in 5db0129

validate_execution_requests(&execution_requests)?;

empty requests should be enforced anyway via the hash check but makes sense to add an additional check for this directly in engine API validation

we should move validate_execution_requests into

reth/crates/engine/primitives/src/lib.rs

Line 116 in 5db0129

pub trait EngineValidator<Types: EngineTypes>: PayloadValidator {

cc @emhane

Additional context

No response

[hoank101]

Hi i can do it

[mattsse]

assigned, ty!

[emhane]

@mattsse can you please explain how this makes the code run differently for optimism and ethereum? this check would have to be moved into reth-optimism-payload-builder and reth-ethereum-payload-builder in order to run a different validation on EL requests wrt network

as for the linked issue #13831, this is smthg we want in the end anyway, even if it doesn't block inclusion of the EL req eip in next op hf. eventually we want to use the op-alloy trait engine api in op-reth, not the same as ethereum, so it needs to be exposed at sdk level. low priority though, but very helpful if impl ♡

as for the linked op-alloy issue, to fix the blanket impl of OpEngineApi is still relevant, otherwise it breaks spec. EL reqs must be checked to be empty. Ref ethereum-optimism/specs#525.

[Elite-tch]

Is it okay if I tackle this?

[chiscookeke11]

Can I jump on this task?

[emhane]

@Elite-tch @chiscookeke11 there is already a pr in progress for this issue. check out anything else tagged good-first-issue! thanks!

opened follow-up to solve what I pointed out above #13908 cc @mattsse