Audit charging of per-kilobyte fees

[vikramrajkumar]

From @theoreticalbts on July 31, 2015 15:22

Any operation with potentially unbounded size needs to charge a size fee. Determining whether an operation is variable-size is non-trivial. An operation is variable size if it contains a vector, flat_set or other potentially variable-size element.

Note that this containment may be through any number of intermediate structs. For example, any operation which contains an authority has potentially unbounded size.

We should be able to audit this in a semi-automatic way with logic similar to js_operation_serializer which traverses all operations, and noting any variable-size types found (in any number of sub-structures), allowing us to flag each operation as variable-sized (or not). We will still have to manually specify whether any base type is variable-size or not.

Copied from original issue: cryptonomex/graphene#216

[vikramrajkumar]

From @theoreticalbts on July 31, 2015 15:28

It makes more sense to charge size-based fees on an operation-wide basis, i.e. you serialize the operation, see how big it is, and then charge based on that. Which would give a single size-based fee for all operations, instead of placing size-based fees on each operation. This makes more sense, as size fees are not meant to raise revenue, merely to protect network resources. Therefore size-based fees should be the same for all operation types -- there is no reason to allow them to be settable for each operation individually.

Moreover, as pointed out in the OP, setting size-based fees for each operation individually requires careful auditing to be sure that every operation of potentially unbounded size includes a size-based fee. Having unified size-fee logic would ensure that if an operation with a large serialization occurred, an appropriate fee would always be charged.

[vikramrajkumar]

From @theoreticalbts on July 31, 2015 15:32

The transaction signatures can potentially grow very large, e.g. if you create a large number of multisig accounts with maximum fan-out and use a custom_operation to require them all to sign. A size fee needs to be charged for signatures as well. What this suggests is that the size fee should be charged based on transaction size, including signatures!

[vikramrajkumar]

From @theoreticalbts on August 26, 2015 21:41

Some fee members are share_type, others are uint64_t or even uint32_t. We should be consistent and always use the same type; I recommend share_type