Relax Trait Bounds on TransactionPool and EthPoolTransaction

[ewoolsey]

I'm working on the World Coin Block builder and ran into a problem implementing TransactionPool which currently requires

    PoolTransaction<
        Consensus = TransactionSignedEcRecovered,
        Pooled = PooledTransactionsElementEcRecovered
    >

which is unnecessarily restrictive. I've created a super trait which looks like this:

/// Super trait for transactions that can be converted to and from Eth transactions
pub trait EthPoolTransaction:
    PoolTransaction<
        Consensus: From<TransactionSignedEcRecovered> + Into<TransactionSignedEcRecovered>,
        Pooled: From<PooledTransactionsElementEcRecovered>
                    + Into<PooledTransactionsElementEcRecovered>,
    > + IntoRecoveredTransaction
{
    /// Extracts the blob sidecar from the transaction.
    fn take_blob(&mut self) -> EthBlobTransactionSidecar;

    /// Returns the number of blobs this transaction has.
    fn blob_count(&self) -> usize;

    /// Validates the blob sidecar of the transaction with the given settings.
    fn validate_blob(
        &self,
        blob: &BlobTransactionSidecar,
        settings: &KzgSettings,
    ) -> Result<(), BlobTransactionValidationError>;

    /// Returns the number of authorizations this transaction has.
    fn authorization_count(&self) -> usize;
}

which should be far more versatile for anyone else looking to implement the trait.

I was considering removing IntoRecoveredTransaction since it seems unnecessary since now you can simply call .into_consensus().into() in every case where you would have called .to_recovered_transaction But I decided to leave it since I wasn't sure if there were any other use cases for it. If you guys want to remove it we can do that in another PR.

Additionally perhaps we should consider renaming trait TransactionPool to trait EthTransactionPool to better illustrate it's bounds.

Would love your feedback, and looking forward to getting this merged in. Thanks!

[emhane]

honestly prefer if we leave this completely without trait bounds for now, following design in #10616 and #10997

smthg like

trait PoolTransaction {
    type Error;
    type BlobSideCar;
    etc.
}

associated types for all types used in trait methods except KzgSettings probably

pls change title of pr, it mentions the wrong trait

[ewoolsey]

@emhane I've named the PR because this is specifically the trait bound on TransactionPool I am attempting to relax

[ewoolsey]

@emhane thanks so much for taking a look.

I'm not 100% sure what you're suggesting though. Are you saying to remove type Consensus from PoolTransaction entirely?

Or are you suggesting removing all bounds from EthPoolTransaction in favour of requiring Into/From on methods only where required?

I had a look at the 2 PRs you linked and I'm not entirely sure how they relate. Thanks for clarification!

[emhane]

Or are you suggesting removing all bounds from EthPoolTransaction in favour of requiring Into/From on methods only where required?

this :)

[emhane]

@mattsse tried to move away from those Into/From trait bounds recently, so don't think we want to reintroduce them now

imo worth exploring if it's possible to delay those trait bounds to where you need them and not have them on the trait definition