basic transaction fee mechanism

[tzemanovic]

related to #51

The initial fee mechanism can be simple:

• allow to set a fee for a transaction
• debit the fee before the transaction is executed
• credit the fee to the validator (this should be taken from the ABCI's block's header ProposerAddress given in BeginBlock method)

┆Issue is synchronized with this Asana task by Unito

[tzemanovic]

We discussed this topic in the ledger's meeting on 6/5/2021.

The transaction fees should be payable by implicit accounts. This would simplify the process for the validators, which have to check that the tx's source account have enough balance to cover the fees. It might still be possible to allow accounts with custom VPs to pay for fees, but it's not that important for now. The validators can choose to accept fees payed in different tokens, but in the ledger the fees should be payed in XAN.

For storage, instead of burning the storage fees we could add them to a "reward" pool, which in turn increases the block reward for validators for every future block. credit @A-Manning

We shouldn't need to charge storage fees for sending tokens to implicit accounts which don't yet exists on-chain, as the required storage for these is minimal (address + balance), so the transaction fees should be enough to prevent any spam.

We still need to consider how this will work on protocol upgrades, for which it might be necessary to re-pay storage fees for any migrated state. We should aim to make the tx and storage fees as low as possible to make this negligible.

[cwgoes]

The validators can choose to accept fees payed in different tokens, but in the ledger the fees should be paid in XAN.

I'm not really convinced that this is necessary - why not let validators accept fees in whichever tokens they like and perhaps convert it themselves later if and when they wish to (and perhaps more efficiently in batches)? Since validators can accept zero-fee transactions anyways, I don't see a particular advantage in requiring XAN.