bring back fees module

[peektism]

There once was a fees module, but it was removed -- see #1993 for more details. I agree with the Gav's comment in which he mentioned that, because Substrate is not a fixed-function state-transition, transaction fees are not so clearly defined:

Substrate is not designed to provide fees to the block author and in some consensus methods, there may not even be a singular identifiable "block author". Some chains may choose to burn fees, others may pass them to one or more entities involved in block authorship, others (like Polkadot) may do a combination. Some more complex modules in Substrate may reserve "fees" and return them (or not) in the same block or some number of blocks later. None of this fits trivially and absolutely into a traditional definition of "transaction fees". src

I understand that #2048 introduces new types to handle situations in which currency must be minted or burned, but I don't think this renders a fees module completely useless. For Kusama, we have been using a Weight type to calculate transaction fees according to this research. If we really want Substrate to be generic, we ought to consider creating a separate module for managing fees instead of coding the Polkadot preferences as defaults into node/runtime and sr-primitives/weights.rs.

Not sure exactly how to do this yet, but we might consider the following:

• Transaction Weight and something to convert between weight and fees => see Transaction Fee Multiplier #2854
• include the types that depend on the Imbalance type (TransactionPayment, TransferPayment, DustRemoval) to fix this hack
• OnFeeCharged for defining default behavior that occurs after a fee is charged (but first see here)
• worth checking out the old fees module, git reset --hard 45824913c980bb1ba3963f9bba67775a507d8624 works for that purpose and git reset --hard HEAD gets you back to head of master
• maybe include a collateral management system like Balance

cc @kianenigma @xlc @joepetrowski

[kianenigma]

If we really want Substrate to be generic, we ought to consider creating a separate module for managing fees instead of coding the Polkadot preferences as defaults into node/runtime and sr-primitives/weights.rs.

I agree with the general statement here, there are for sure many ways to make this 1- more generic 2- nicer in terms of API. But, for clarification:

• The #[weight = x] that we can now use for dispatch functions can be any struct/enum + it is totally optional. All you, as a substrate user need to care about is the have a default impl for it.
• For now I assume: Since we don't have a fee module: Balances is in charge of fees. Balances will receive the annotation data (#weight things) and decides what to do with it and it is customisable by the user. I agree that at the end of the day, in Transaction Fee Multiplier #2854 maybe we should just fill this Convert type as () and only implement it in Polkadot's runtime, for the sake of your argument and keeping them separated.

What I aimed for during this whole weight/fee is that for everything that whatever we implement for Kusama: it should be easily possible to just turn it off. and I think we can do that now. () as WeightToFee and your have a free of charge chain. See the default implementation now and there you see how to implement a simple per-byte fee (#2854 might change this thou').

[xlc]

Now there is an option tip field in extrinsic, which is not accessible other than reading from extrinsic data. This means it is very hard for frontend/SDK to calculate the transaction fee for a particular transaction. It have to know the call, know the weight, know all the parameter, do the weight adjustment, and decode the extrinsic to read the tip and add it.

I still think it will be very useful to at least emit a MakePayment event with how much transaction payment fee is been applied. It could be an optional feature not enabled by default, but I believe a lot of chains will want this feature.

[kianenigma]

Given the transaction_payment module, this should be closed IMO.