When a new block arrives, a transaction pool must recheck its transactions: some senders' nonces moved, some balances changed, and some transactions are now included. Until 2026-11-15 the xOneRS pool reread every queued and pending account after every block. Since PR #1062 it rechecks only the senders the block touched, and falls back to a full reset whenever that shortcut could be wrong. A second change, PR #1108, makes transaction gossip replayable for tests. Neither PR reports a speed number.

For what happens to transactions in a reorg, see reorg reinjection.

What does the pool do after an ordinary block?

On an ordinary extension of the canonical chain:

  • The node collects the accounts each imported block changed and hands their union to the pool once.
  • The pool drops the cached nonces of those accounts, promotes and demotes only their transactions, and rebuilds their pending nonce.
  • Every other sender keeps its lists and its cached nonce: an account the block did not change cannot change them.

When does it still do a full reset?

Whenever the touched set cannot describe the change (ResetKind::Full):

  • a reorg, or a head that is not above the old one;
  • a different gas limit or different fork rules;
  • a different fee tier or a different TRC21 fee table;
  • a change of the masternode candidates;
  • the first reset after the pool starts, and after a side branch, an adoption, an unwind or a failed import.

A reorg arrives as a branch delta or an unwind, so the reorg path is the same full reset as before.

How do we know the shortcut gives the same answer?

incremental_equals_full_over_generated_blocks runs two pools side by side, one reset incrementally and one fully, over 24 seeds of 60 steps each: admissions with nonce gaps, blocks that change random nonces and balances, and gas-limit changes. After every step it compares the pending and queued sets, the stats, the nonces and the status of every transaction. The PR names one limit: a fee-tier boundary and a TRC21 table change are covered by equality checks in the code, not by the generated test.

What is the gossip scheduler?

xone_builder::txpool::gossip_sched::Scheduler wraps the existing fetch, intake and broadcast functions with a controllable clock and an event log (PR #1108). replay(seed, schedule) gives the same result every time, so a test can check that a failed fetch moves to another announcer, that admission stays inside its queue bound, that a hash is not imported twice and that cancel stops further work. It changes how gossip is tested, not what the node sends.

Frequently asked questions

Does the xOne txpool recheck every account after each block?

Not on an ordinary extension since PR #1062: only the senders the block changed. Reorgs, fork or fee changes and restarts still trigger a full reset.

Is the incremental reset faster?

The PR does not report a measurement. It reads fewer accounts per block; how much that saves depends on the pool size and the block.

How is the incremental reset tested?

Against a fully reset pool, over 24 random seeds of 60 steps each, comparing every transaction's status after every step.

Sources