Does `CheckWeight` interfere with `pallet_transaction_payment` and others in terms of priority?

[JoshOrndorff]

Pallet transaction payment, according to its [own docs](https://github.com/paritytech/substrate/blob/master/frame/transaction-payment/src/lib.rs#L565-L586, tries to assign priorities by considering both the weight and space that the transaction takes in the block.

/// This will try and optimise the fee/weight fee/length, whichever is consuming more of the
/// maximum corresponding limit.
///
/// For example, if a transaction consumed 1/4th of the block length and half of the weight, its
/// final priority is fee * min(2, 4) = fee * 2. If it consumed 1/4th of the block length
/// and the entire block weight (1/1), its priority is fee * min(1, 4) = fee * 1. This means
/// that the transaction which consumes more resources (either length or weight) with the same
/// fee ends up having lower priority.

There is also the CheckWeight signed extension which assigns priorities based only on weight (except for operation class) and does not consider length at all.

In many runtimes, including Polkadot, the node template, and Moonbeam, both of these are used. And when multiple priorities are assigned, they are summed. This problem is particularly bad in the case of smart contracts, where no reasonable pre-dispatch weight is known.

For frontier-based chains like Moonbeam, evm transactions have priority according to gas price. Because CheckWeight adds additional weight-based priority, and the pre-dispatch weight is the gas_limit, which may overestimate the actual weight needed by several orders of magnitude, this added priority completely confuses the pool.

I've considered the following solutions, and I'd like feedback, especially from @kianenigma since he wrote pallet transaction payment.

• Change CheckWeight so it doesn't assign priority
• Do ^^^, and also make a new SignedExtension called PrioritizeByWeight for those who want the old behavior
• Combine priorities by using the maximum, not the sum - Not a total solution, but helps
• When considering a tuple of SignedExtension the last one sets the priority. (Con: this will be hard to document)

[kianenigma]

I belive #9596 is exactly what you need (and was initiated by a feedback from --if I am not mistaking-- Alan from moonbeam).