Trait transaction_pool::scoring::Scoring

pub trait Scoring<T>: Debug {
    type Score: Ord + Clone + Default + Debug;
    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

type Score: Ord + Clone + Default + Debug

A score of a transaction.

type Event: Debug

Custom scoring update event type.

Required Methods

fn compare(&self, old: &T, other: &T) -> Ordering

Decides on ordering of Ts from a particular sender.

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

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

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

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)

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

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

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

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