It will be useful to create a transaction fee module
Some requirements
I am keen to start working on this if this is the right direction
This would replace MakePayment? Or it would implement MakePayment? Could you sketch the API you see it having?
It will replace MakePayment as I feel the current MakePayment is too specific.
I also thinking about have the gas meter code moved from contract module to here as it is general enough to be useful by other modules with dynamic tx fee. Any runtime method with computational complexity that is not near O(1) should use GasMeter to ensure the upper bound of the computation.
A draft API:
Generic parameters:
FeeAmount: SimpleArithmeticBalance for simple implementationstruct FeeAmount(Vec<(AssetId, Balance)>) for multi token implementationStorage & Config
BaseFee: FeeAmountByteFee: FeeAmountFees: mapping u32 => FeeAmountInternal methods (public to other modules):
charge_base_bytes_fee(who: &AccountId, len: usize) -> Resultcharge_fee(who: &AccountId, fee: FeeAmount) -> Resultrefund_fee(who: &AccountId, fee: FeeAmount)Events
ChargeFee(u32, FeeAmount)Other method
on_finalise()One tricky part is make this works with contracts overlay storage, which I need to spend some time to understand the details first.
Edit: Removed the gas fee related part
(AccountId is alreeady in system::Trait, so no need for that.)
If MakePayment is replaced by this, then we'd be introducing a dependency to executive which includes the concept of gas which is a no-go.
@gavofyork What is the reason to avoid introduce concept of gas to be dependent of executive? Just keep it simple because contract module won't be included in many chains including polkadot chain?
Anyhow I can remove the gas part and only do the static tx fee part.
Correct. Neither Gas nor Balance are first-class concepts on Substrate and I want to keep it that way. This also means that Executive should not know about fee structures and balances in general.
Understood. I have updated the proposal above and planning start working on this next.
On the other hand, I still think a reusable gas meter is a useful module. But I don't have a concrete requirement for it so I will leave it alone.
Most helpful comment
It will replace
MakePaymentas I feel the currentMakePaymentis too specific.I also thinking about have the gas meter code moved from contract module to here as it is general enough to be useful by other modules with dynamic tx fee. Any runtime method with computational complexity that is not near
O(1)should use GasMeter to ensure the upper bound of the computation.A draft API:
Generic parameters:
FeeAmount: SimpleArithmeticBalancefor simple implementationstruct FeeAmount(Vec<(AssetId, Balance)>)for multi token implementationStorage & Config
BaseFee: FeeAmountByteFee: FeeAmountFees: mapping u32 => FeeAmountInternal methods (public to other modules):
charge_base_bytes_fee(who: &AccountId, len: usize) -> Resultcharge_fee(who: &AccountId, fee: FeeAmount) -> Resultrefund_fee(who: &AccountId, fee: FeeAmount)Events
ChargeFee(u32, FeeAmount)Other method
on_finalise()One tricky part is make this works with contracts overlay storage, which I need to spend some time to understand the details first.
Edit: Removed the gas fee related part