Refactor Optimism Transaction Validator: Extract OP-Specific Checks & Enable Batch Processing

[Aideepakchaudhary]

This PR refactors the Optimism transaction validation(#13902). The changes decouple the Ethereum (ETH) standard validation from the additional Optimism-specific logic (i.e., ensuring the sender can cover the L1 gas fee). In addition, batch validation is now optimized by delegating to the inner validator’s batch method and then applying the OP-specific checks on the resulting outcomes.

Detailed Changes

1. Extracted OP-Specific Validation Logic

   • Introduced a new private helper method apply_op_checks that encapsulates the Optimism-specific checks.
   • The method verifies, for transactions deemed valid by the inner validator, that the sender’s balance is sufficient to cover both the intrinsic cost and the additional L1 data fee.
   • If the fee calculation fails or the total cost exceeds the balance, an appropriate error is returned.

2. Simplified Single Transaction Validation

   • The validate_one method now:
     • First checks if the transaction is of type EIP-4844, immediately rejecting unsupported transactions.
     • Delegates initial validation to the inner (ETH) validator.
     • Applies the additional OP checks via the newly created apply_op_checks method.
   • This cleanly separates standard ETH validation from the Optimism-specific fee requirements.

3. Optimized Batch Transaction Validation

   • Updated the validate_all method to use the inner validator’s batch validation (validate_all) which internally use ('validate_batch') instead of iterating over transactions one-by-one.
   • After obtaining batch results, each outcome is passed through apply_op_checks, ensuring that the extra L1 gas fee validation is applied consistently and efficiently.

This is my first contribution to reth, and I'm eager to receive any feedback or suggestions for improvement.

[emhane]

we want to do the tx type check here first to bail early if it's eip4844. it's a bit tricky. I think we need an intermediary enum here

enum IntermediaryTxValidationOutcome {
    InvalidEip4844(TransactionValidationOutcome),
    Pending { origin: TransactionOrigin, tx: Tx },
}

so we can do

1. iterate through tuples, check if eip4844. if true, map to

IntermediaryTxValidationOutcome::InvalidEip4844(TransactionValidationOutcome::Invalid(transaction, InvalidTransactionError::TxTypeNotSupported.into()))

else map to

IntermediaryTxValidationOutcome::Pending { origin, tx }

and collect
2. iterate through collected IntermediaryTxValidationOutcomes,
(i) map those of Pending variant to self.inner.validate_one and in turn map the result of that call to apply_op_checks
(ii) map those of variant InvalidEip4844 to peel the wrapper off, i.e. extract the inner TransactionValidationOutcome
collect, we end up with a Vec<TransactionValidationOutcome<Tx>>