Rework Transaction Priority Calculation

[apopiak]

substrate/frame/transaction-payment/src/lib.rs

Lines 563 to 569 in 279369e

	fn get_priority(len: usize, info: &DispatchInfoOf<T::Call>, final_fee: BalanceOf<T>) -> TransactionPriority {
	let weight_saturation = T::BlockWeights::get().max_block / info.weight.max(1);
	let max_block_length = *T::BlockLength::get().max.get(DispatchClass::Normal);
	let len_saturation = max_block_length as u64 / (len as u64).max(1);
	let coefficient: BalanceOf<T> = weight_saturation.min(len_saturation).saturated_into::<BalanceOf<T>>();
	final_fee.saturating_mul(coefficient).saturated_into::<TransactionPriority>()
	}

Tomek's Comments about Transaction Priority

• @tomusdrw in Asset Transaction Payment cumulus#488 (comment)_

Why is [the priority] always Normal? Maybe we should get a total length instead? With current implementation we might have large non-normal transactions getting their priority heavily reduced compared to normal transactions.

• @tomusdrw in Asset Transaction Payment cumulus#488 (comment)_

I think this should be at least 1. For larger-than-block transactions (Mandatory) the coefficient might end up being 0.

• @tomusdrw here:

I'm not sure if having linear relation here is good. For super small transactions (both len and weight) the priority increase seems to be extremely high (absolute values of min(block_length, block_weight). Given that the only way to counter that is with a tip, I feel it might not be tuned well (like there is no relation between extra tip cost to frontrun such transaction and absolute value of block_weight/block_length).