Collect fixed fees for certain transactions

[ethanfrey]

Please read update at end....

The current fee module is designed to request a user-specified fee that can be used to control priority among multiple competing transactions. There is the idea of a global minimum fee, but this just works as a spam filter for transactions, rather than anything fine-grained to charge for specific transactions.

One essential part of the economics at launch is to charge for name registration, and especially for name-space registration. Eventually there should be a more dynamic fee definition, but for start, we can have a fixed fee for certain transactions that is defined in the genesis file. (This means it is stored in the kv store, and we can theoretically add a transaction to modify it later).

Please not answers were updated on 22.1.2019

Please use gconf style for configuring fees in genesis file. The message path can be used to lookup the fees. If a message is not configured, then this implies no product fees (no panic)

Answers:

• All fees in IOV token, (no different currencies)
• Are these fees auto-deducted from the signer's account, or do they come out of the fee section (failing if fees is smaller than required tx cost)
  • Fee section on tx includes anti-spam fee and the product fee, all fees that go to the validators. If we have other fees that go to other accounts (not validator pool), they will need a separate section.
  • It must be easy for a client to reliably query the cost before submitting a transaction. This is a UX requirement for both cases.
    Where do we store these fees? Is this defined on a per-package basis, or is there a global lookup table, separate module, that store all fee definitions.?
  • This is a development decision, but since we need an easy way to query expected fee for any transaction before submitting it, a unified format to query them is highly desirable and probably easier if this was all in one module.
  • Each registered transaction type should be able to register the fee.
  • All product fees go to same location as the anti-spam fees (maybe unify these in one module for easier config)
• Currently, we only consider cases of per message type fees, in the future, we will likely need per message fees, as registering a username under one namespace may have a different cost than under another. But that complexity is left for another story, as business requirements are still solidifying there, and will be well after launch in all cases.

This should provide a basic product fee implementation we can start using in the client, but this will be interated upon in the future, so please code for extensibility.

update

After discussion in #323 I have decided to break this into three tasks:

• Improve how existing fees are handled on error in fee decorator Improve fee deduction on errors #348
• Add Required Fee to Check/Deliver Result and enforce in fee decorator Add support for required fees #349
• Add generic decorator to add optional type-dependent required fees as set in genesis (or updated in bucket)

Note that this architecture makes the generic decorator just one way of adding fees, and we could instead use custom code in a handler to do deeper introspection of a type and use custom logic to determine required fee.

[ethanfrey]

SHould work with batch. eg. if I send a batch with 3 setName tx, it will deduct 3 times the cost of registering a setName (same as if I submitted those messages as three independent transactions).

This just means that the fee deduction should happen "downstream" from the batch decorator/middleware

[ruseinov]

@alpe @ethanfrey As I'm looking into this - it does not make much sense to use gconf directly for these values, as since we need to look them up from the client - it would make more sense to use initializer pattern and load all that into a bucket on startup.
I agree though that the format of this should be:
{"msg_path": {"whole": 12, "fractional":33}

Let me know if this makes sense

[ruseinov]

Also, whenever we need to extend this with lookups by message contents for dynamic fees - that'd be definitely stored in a bucket and communicated via transactions and not genesis.