Block fullness targeting with fee multiplier

[soulofamachine]

Detailed research here

Motivation

• We want to target block saturation level of s* = 0.25 (adjustable). The allows the system to handle 4x transaction spikes, with room for crucial transactions, e.g. misbehavior reports.
• We introduce v a fee variability (multiplier) factor, which controls how quickly the transaction fees adjust. Where: v≤ p / (k * (1−s∗)).

Fast vs Slow fee mechanisms
There are two options to consider when it comes to the fee adjustment rate

1. Slow adjusting with tipping (recommended): Adjusts slowly, at the pace of long term tendencies, and uses tipping to deal with long queues at peak hours. V is small.

2. Fast adjusting: Adjusts the price very quickly, at the same pace as the peaks and valleys of activity.

from: @gavofyork

[kianenigma]

So one fundamental, non-changing part of this task is to communicate some sense of weight from each transaction to a centralized store: probably executive module or write system module directly.

Ideally, I think this weight should be some enum like

pub enum Weight {
    /// Simple tx, irrelavent of the inputs
    Constant,
    /// Weighted 
    Weighted(u32),
    /// Red flag.
    Maximum,
     /// Transaction is actually helpful and should be rewarded (indices module etc.)
     ShouldReward(u32)
    ....
}

But for now, we can assume we just need to communicate one u32 value back.

I see a few options to do that:

• Return it via the default Ok(). I don't know where it goes exactly atm but I expect it to be easily capturable.
• pass a secondary, optional argument into each transaction (after origin) which has the type Fn(w: Weight) -> (). Essentially pas a setter for weight into each tx. If not used, then Default implementation of Weight will be used.
• Similar to the above but with a global function which will be reserved keyword like set_weight(w).

If it is possible, I returning Ok(something) seems quite simple and gets the job done.

Any initial feedback? @bkchr @gavofyork @shawntabrizi

[xlc]

@kianenigma we had a primitive implementation of this centralized transaction fee/weight store. I wonder if you guys can take a look to see if it helps in this case? The ultimate goal is same that use transaction fee to control the target block fullness. As the first step we developed a fees registry (based on the srml-fees module I developed which got removed from substrate).

You can take a code at https://github.com/cennznet/plug-blockchain (our fork of Substrate).

A few more traits
https://github.com/cennznet/plug-blockchain/blob/67ed189597ecbd50cf080fdf3584059fcbdc98fc/srml/support/src/additional_traits.rs

Fees module and decl_fee to declare a fee enum
https://github.com/cennznet/plug-blockchain/blob/67ed189597ecbd50cf080fdf3584059fcbdc98fc/prml/fees/src/lib.rs#L46-L53

Another usage of decl_fee
https://github.com/cennznet/plug-blockchain/blob/67ed189597ecbd50cf080fdf3584059fcbdc98fc/prml/generic-asset/src/lib.rs#L213-L218

Implementation of the traits, which needs refactor so the calculation part are in each individual module instead of a single file.
https://github.com/cennznet/plug-blockchain/blob/67ed189597ecbd50cf080fdf3584059fcbdc98fc/srml/support/src/additional_traits.rs

Our implementation definitely needs a lot of improvements, but I believe it is a good start.

Note that one requirement we have is be able to know the max fee upfront before calling into the runtime method. This is required for our DEX integration. The fee can usually can be calculated based on the input parameter and for the case that cannot be easily estimated (e.g. contract call), user will need to supply a max value (max gas).

[gui1117]

I'm reading the doc:

A transaction fee includes a base fee and a variable fee that is proportional to the number of bytes to be put on chain. That is,

f(tx):=fbase+size(tx)⋅fbyte,

for some parameters fbaseand fbyte and where size(tx) is the number of bytes of transaction. The base fee will depend on the type of transaction, while the per-byte fee may be the same for all types.

what is a type here ? should contract_put_code_extrinsic be its own type for instance ?
considering this statement it seems, maybe we should allow modules to defines there own types (like we do for origin) and they must specify for each call a type. (with an attribute maybe or somewhere else)

[4meta5]

The derived formula for v seems to be valid, but it is a very loose bound. From here, we have

\frac{f_{final byte} - f_{initial byte}}{f_{initial byte}} ~= vk(s_avg - s*) \leq vk(1-s*) \leq p

This makes sense because s_avg \leq 1, but we use it to derive the bound v \leq \frac{p}{k(1-s*)} and while that is correct, it is not as strict a bound as if we replace 1 with s_avg => our new, more strict bound is v \leq \frac{p}{k(s_avg - s*)}.

My only concern is that now v can be negative; specifically v is negative if the average saturation is below the target saturation. This still doesn't mean the fee multiplier itself is ever negative. For clarification, the actual fee multiplier is NOT v, it is

1 + v(s-s*) + v^{2}(s-s*)^{2}/2

where s* is the target saturation and s is the current block's saturation

[kianenigma]

closed via #2854