Question about transaction pool parameter source and ordering mechanism in op-rbuilder

[Arisawa-v]

Hi team,

I have a question about the transaction pool implementation in op-rbuilder and would appreciate some clarification:

I'm trying to understand where the pool parameter comes from in the spawn_payload_builder_service function. From my code analysis, I can see:

// In flashblocks/service.rs line 75-80
async fn spawn_payload_builder_service(
    self,
    ctx: &BuilderContext<Node>,
    pool: Pool,  // <-- Where does this pool come from?
    _: OpEvmConfig,
) -> eyre::Result<PayloadBuilderHandle<<Node::Types as NodeTypes>::Payload>>

It appears that the pool is configured in launcher.rs using OpPoolBuilder<FBPooledTransaction> and then passed by the Reth framework during node initialization. Is this understanding correct? So, the pool is PendingPool in Reth?

[owizdom]

hey fren, interesting discovery;

well, the short answer — your reading is basically right with one small clarification: the pool argument is the transaction-pool instance that reth builds from your oppoolbuilder<...> (a reth::transaction_pool::pool<...>). that pool internally contains sub-pools (like pendingpool, queued, basefee, etc.), but the value passed into spawn_payload_builder_service is the composed, high-level pool object reth constructs and hands to the payload builder — not a raw pendingpool itself.

how it flows (step-by-step), this will help you visualize it and understadn it better,

in your launcher you configure an oppoolbuilder<fppooletransaction> (or the appropriate oppoolbuilder variant). that builder is used by reth's components builder when constructing node components.

the reth componentsbuilder calls the pool builder to create the concrete pool instance. the result is the pool<...> implementation that implements the transaction-pool api.

when reth spawns payload / payload-builder services it passes that pool instance into spawn_payload_builder_service(...) as the pool parameter — so your flashblocks/service.rs receives the same pool object reth created.

so: is it pendingpool?

not exactly. pendingpool is one internal sub-pool (the ready/pending subset). the pool parameter you get is the higher-level pool object that composes pendingpool, queued, basefee, etc. think of the passed pool as the txpool you interact with (it exposes methods to query best/ready txs) and it manages/contains pendingpool internally.