Trait transaction_pool::scoring::Scoring [−][src]
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
Score
s should match ordering ofcompare
method. compare
will be called only within a context of transactions from the same sender.choose
may be called even ifcompare
returnsOrdering::Equal
should_replace
is used to decide if new transaction should push out an old transaction already in the queue.Score
s andcompare
should align withReady
implementation.
Example: Natural ordering of Ethereum transactions.
compare
: compares transactionnonce
()choose
: compares transactionsgasPrice
(decides if old transaction should be replaced)update_scores
: score defined asgasPrice
ifn==0
andmax(scores[n-1], gasPrice)
ifn>0
should_replace
: comparesgasPrice
(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 T
s 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>
)
&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.