Take into account proof size for transaction payment and priority

[Ank4n]

closes #13898.

Currently, TargetedFeeAdjustment takes into account only ref_time dimension of the weight. This is not an issue with relay chain since we should not charge transactions for proof_size on the relay chain. On parachain though, PoV size is limited to 5 MB and an attacker could fill the block with storage size without paying an appropriate fee.

These changes will take into account proof_size while adjusting the fee. It does so by first taking a ratio of dimension/max_dimension and taking the largest ratio. We call it limiting dimension as it is the scarcer resource and use this dimension for the calculation of the next fee multiplier.

The PR also takes into account proof_size for calculation of transaction priority. We look into how many transactions we can fill in the block by looking at the resource (dimension) that is depleted more (hence called limiting dimension) while filling the block.

Considerations for parachains using pallet transaction-payment

Care needs to be taken to set the max PoV size for a chain. A really high value would mean block is never full based on the proof_size dimension, while a too low value would mean block is constantly full and transaction fees would keep increasing for the chain. An optimal maximum PoV size would ensure a high correlation between the block fullness based on each weight dimension.

[Ank4n]

bot rebase

[paritytech-processbot]

Rebased

[Ank4n]

bot rebase

[paritytech-processbot]

Rebased

[paritytech-processbot]

Rebased

[Ank4n]

I would like to see some empirical numbers here: what is the proof size going to be in Polkadot? should we even take it into account in Polkadot?

The ref time is limited to 2sec currently while proof size has no limit (u64::Max). The ideal block fullness with normal transactions is set to 25% (0.5 sec, 4.6 * 10^6 terabytes). With current values, practically ref time will always be the limiting dimension and proof size will never be taken into account.

Update: Received feedback that we should not charge for proof size on relay chain so the above makes sense.

[Ank4n]

bot rebase

[paritytech-processbot]

Rebased

[ggwpez]

LGTM codewise

[Ank4n]

And what is the average proof size weight in a parachain right now? Will the new dimension cause the tx-fees to skyrocket, if the proof size is always more than the targeted 25% that is used?

I looked at statemine and bifrost and they seem to have pretty empty blocks averaging less than 1% fullness by both ref_time and proof_size. They shouldn't cause any issue in the near future. But fine tuning tx fees would be a matter of setting correct max bounds for the proof_size such that block fullness by each dimensions are not too far away from each other.

The full results are here.

[kianenigma]

Code LGTM but I think the labeling is wrong here: This PR will significantly affect parachains and should be labled as note-worthy and have direction for parachain teams to consider.

[Ank4n]

Code LGTM but I think the labeling is wrong here: This PR will significantly affect parachains and should be labled as note-worthy and have direction for parachain teams to consider.

Does each parachain use separate PoV limits? Cumulus picks the PoV limit from here https://github.com/paritytech/polkadot/blob/master/primitives/src/v5/mod.rs#L385.

[kianenigma]

https://github.com/paritytech/polkadot/blob/master/primitives/src/v5/mod.rs#L385

Yes I think still different parachains assign different PoV limit via frame_system::Config::BlockWeight's second dimension.