Calvin ETHGas:

We are concerned that the current spec exposes the Tx details to the validators thus allowing them to front-run, MEV, etc.. whether it’s Inclusion Preconfs or potentially Execution Preconfs down the line, it sets a precedent that the Validators now have full Tx details albeit with some constraints that they’ve committed to. If:

• all TXs are attached to constraints (i.e. no mempool/other order flow) then there’s nothing the Validator can do
• only some portion of the TXs have constraints then it allows room for Validator MEV with those trades from the mempools

We’re wondering if there’s an approach that doesn’t expose these details, for example, modifying the current preconf API standard to: i) disable the validators ability to GET /constraints, and instead, ii) add a gateway signature on the Preconf Tx hashes in get_header_with_proof call