`pallet_transaction_payment`'s `TransactionByteFee` is completely inflexible

[notlesh]

pallet_transaction_payment provides only one input for scaling length fees, namely type TransactionByteFee: Get<BalanceOf<Self>>. In fee calculation, this value is used strictly as a multiplier on a transaction's length in bytes. The result is basically a compile-time constant modifier.

I believe this lacks the flexibility needed to create a fee structure that is both reasonably cheap for most txns and also expensive enough to prevent txn spam with large transactions (e.g. runtime upgrades).

In addition, this does not provide any mechanism for the cost of such a fee to respond to market pricing/demand, although this is potentially a distinct problem.

There are many ways this problem could be approached. I have introduced a small PR (#10785 ) which uses the same Vec<WeightToFeeCoefficient> mechanism used by the pallet's weight fee system. I include this mostly because I was able to solve the small-vs-large txn dilemma above using it, but I'm more interested in feedback about the issue.

[ggwpez]

I generally like the idea of making it more flexible.
Having a polynomial here would introduce some additional arithmetic operations for each Extrinsic, which we would need to account for when calculating the weight.
What do you think? @shawntabrizi

[notlesh]

...would introduce some additional arithmetic operations for each Extrinsic...

Yes, this approach would probably raise the inclusion fee slightly.

Another approach would be to create a callback for the runtime to do the entire calculation, passing the length and requiring an adjusted fee to be returned. This would be even more flexible and could be reduced to a cheap operation when needed.

[shawntabrizi]

@notlesh in general your PR looks fine to me.

I think an even more generic callback function could be okay, but note that this also risks users implementing something too complex, where fee calculation must really be super simple logic, as to not take too much resources.

If someone starts to implement storage lookups, this can be really damaging for the chain. In those cases, I think we are better off gatekeeping the API, unless otherwise needed.

[notlesh]

Closing this as #10785 was merged some time ago.