Trait transaction_pool::scoring::Scoring[−][src]

pub trait Scoring<T>: Debug {
    type Score: Ord + Clone + Default + Debug + Send + LowerHex;
    type Event: Debug;
    fn compare(&self, old: &T, other: &T) -> Ordering;

    fn choose(&self, old: &T, new: &T) -> Choice;

    fn update_scores(
        &self, 
        txs: &[Transaction<T>], 
        scores: &mut [Self::Score], 
        change: Change<Self::Event>
    );

    fn should_replace(&self, old: &T, new: &T) -> Choice;

    fn should_ignore_sender_limit(&self, _new: &T) -> bool { ... }
}

A transaction ordering.

The implementation should decide on order of transactions in the pool. Each transaction should also get assigned a Score which is used to later prioritize transactions in the pending set.

Implementation notes:

  • Returned Scores should match ordering of compare method.
  • compare will be called only within a context of transactions from the same sender.
  • choose may be called even if compare returns Ordering::Equal
  • should_replace is used to decide if new transaction should push out an old transaction already in the queue.
  • Scores and compare should align with Ready implementation.

Example: Natural ordering of Ethereum transactions.

  • compare: compares transaction nonce ()
  • choose: compares transactions gasPrice (decides if old transaction should be replaced)
  • update_scores: score defined as gasPrice if n==0 and max(scores[n-1], gasPrice) if n>0
  • should_replace: compares gasPrice (decides if transaction from a different sender is more valuable)

Associated Types

A score of a transaction.

Custom scoring update event type.

Required Methods

Decides on ordering of Ts from a particular sender.

Decides how to deal with two transactions from a sender that seem to occupy the same slot in the queue.

Updates the transaction scores given a list of transactions and a change to previous scoring. NOTE: you can safely assume that both slices have the same length. (i.e. score at index i represents transaction at the same index)

Decides if new should push out old transaction from the pool.

NOTE returning InsertNew here can lead to some transactions being accepted above pool limits.

Provided Methods

Decides if the transaction should ignore per-sender limit in the pool.

If you return true for given transaction it's going to be accepted even though the per-sender limit is exceeded.

Implementors