Tracking: Transaction Pool

[mattsse]

Progess here #22

Todos

• implement new erigon style pool design, with several subpool
• Good abstractions and interfaces for p2p and RPC
• Implement tx pool traits for reth's concrete pool types
• simplify types where possible
• Good Test Coverage
• Fuzzing?

Lower prio

• Integrate metrics (prometheus)

Questions

• Ideal sorting design: As discussed here wip: feat(txpool): new txpool design #22 (comment)

There are currently two generic abstraction over:

the Transaction type itself: this would allow adding arbitrary additional context on top of required info like nonce, gas price, etc.. (maybe like a marker that this tx is part of a bundle)
Priority which is an arbitrary value that determines the best transactions in the pending pool (which contains tx that can be executed on the current state)
currently, the priority is expected to be determined like: fn Ordering::priority(tx: &Transaction) -> Priority I think ideally this should also allow gaining access to other transactions that are currently pending, so priority can be determined in relation to other txs.

perhaps sorting should be changed to be an operation on the entire pending pool instead.

I think "multiple pools" would basically be this: instead of dividing the pending pool, we add pay for order flow as an Ordering function applied to the entire pool, like fn Ordering::best(&pendingpool) -> impl Iterator< Transaction>

The representation of dependencies in transactions is probably a kind of graph, need to have a closure look at how mev bundles are handled now.

[mattsse]

closing this since most of this has landed already.

need to reevaluate again and open dedicated issues for missing parts of TxPool