• Gonçalo Pestana's avatar
    Implements a variable deposit base calculation for EPM signed submissions (#1547) · 614aa31b
    Gonçalo Pestana authored
    **Note**: This is a lift-and-shift PR from the old substrate and
    polkadot repos, both PRs have been reviewed and audited
    (https://github.com/paritytech/substrate/pull/13983,
    https://github.com/paritytech/polkadot/pull/7140)
    
    ---
    
    This PR implements a generic `BaseDeposit` calculation for signed
    submissions, based on the size of the submission queue.
    
    It adds a new associated type to EPM's config, `type SignedDepositBase`,
    that implements `Convert<usize, BalanceOf<T>>`, which is used to
    calculate the base deposit for signed submissions based on the size of
    the signed submissions queue.
    
    `struct GeometricDepositBase<Balance, Fixed, Inc>` implements the
    convert trait so that the deposit value increases as a geometric
    progression. The deposit base is calculated by `deposit_base =
    fixed_deposit_base * (1 + increase_factor)^n`, where `n` is the term of
    the progression (i.e. the number of signed submissions in the queue).
    `Fixed` and `Inc` generic params are getters for `Balance` and
    `IncreaseFactor` to compute the geometric progression. If
    `IncreaseFactor = 0`, then the signed deposit is constant and equal to
    `Fixed` regardless of the size of the queue.
    
    ### Runtime configs
    
    In Kusama, the progression with 10% increase without changing the
    current signed fixed deposit is: (term == size of the queue)
    
    Term 1: `1,333,333,332,000`
    Term 2: `1,333,333,332,000 * 1.10 = 1,466,666,665,200`
    Term 3: `1,333,333,332,000 * 1.10^2 = 1,613,333,331,200`
    Term 4: `1,333,333,332,000 * 1.10^3 = 1,774,666,664,320`
    Term 5: `1,333,333,332,000 * 1.10^4 = 1,952,133,330,752`
    Term 6: `1,333,333,332,000 * 1.10^5 = 2,147,346,663,827.20`
    Term 7: `1,333,333,332,000 * 1.10^6 = 2,362,081,330,210.92`
    Term 8: `1,333,333,332,000 * 1.10^7 = 2,598,289,463,231.01`
    Term 9: `1,333,333,332,000 * 1.10^8 = 2,858,118,409,554.11`
    Term 10: `1,333,333,332,000 * 1.10^9 = 3,143,930,250,509.52`
    
    Westend:
    
    Term 1: `2,000,000,000,000`
    Term 2: `2,000,000,000,000 * 1.10 = 2,200,000,000,000`
    Term 3: `2,000,000,000,000 * 1.10^2 = 2,420,000,000,000`
    Term 4: `2,000,000,000,000 * 1.10^3 = 2,662,000,000,000`
    Term 5: `2,000,000,000,000 * 1.10^4 = 2,928,200,000,000`
    Term 6: `2,000,000,000,000 * 1.10^5 = 3,221,020,000,000`
    Term 7: `2,000,000,000,000 * 1.10^6 = 3,543,122,000,000`
    Term 8: `2,000,000,000,000 * 1.10^7 = 3,897,434,200,000`
    Term 9: `2,000,000,000,000 * 1.10^8 = 4,287,177,620,000`
    Term 10: `2,000,000,000,000 * 1.10^9 = 4,715,895,382,000`
    
    and in Polkadot, the deposit increase is disabled in the current state
    of the PR, as the increase factor is 0% -- so nothing changes from the
    current behaviour.
    
    Closes https://github.com/paritytech-secops/srlabs_findings/issues/189
    614aa31b