Skip to content
  • Peter Goodspeed-Niklaus's avatar
    Reduce the inclusion inherent's actual weight if the block is already heavy (#2060) · fcc0fca1
    Peter Goodspeed-Niklaus authored
    
    
    * don't modify inherent data on heavy block
    
    * write up current thinking on block weight detection
    
    * extract inherent inclusion check into its own function
    
    * put heavy block check into runtime
    
    * the `inclusion` inherent call is Operational, not Mandatory
    
    This resolves a lot of the trickiness about this issue, because
    we no longer need to override or supplant any existing proposer
    logic; the existing logic should exhibit these behaviors:
    
    - the `inclusion` inherent is prioritized over standard transactions
    - but if it's too heavy, i.e. in case of runtime upgrade, it'll be
      dropped in favor of that.
    
    It is my belief that allowing the proposer to just not include
    this data won't have any adverse effects: it's equivalent to replacing
    them with empty versions of themselves, which the `ProvideInherent`
    impl already does.
    
    * Revert "the `inclusion` inherent call is Operational, not Mandatory"
    
    This reverts commit e58858d109b18b84e7af3ac47981c6900b2d9a3e.
    
    * Revert "write up current thinking on block weight detection"
    
    This reverts commit fd587b80c46761b2a2b62448193348237863f99f.
    
    * Revert "don't modify inherent data on heavy block"
    
    This reverts commit 38299d3c23e9efb5a354d8cfa658e62a5c8c7ddf.
    
    * add backed candidate block weight assumption to configuration
    
    * Limit backed candidates according to a candidate weight heuristic.
    
    This approach replaces making the inclusion inherent non-mandatory.
    It's still not ideal in that we have to configure a heuristic for
    how much each backed candidate 'weighs', instead of directly
    measuring it somehow.
    
    This approach also never truncates the signed bitfields. The
    rationale for that depends on some assumptions:
    
    - processing the signed bitfields is cheap compared to the
      backed candidates
    - it is beneficial to the progress of the relay chain
      to update the signed bitfields even if not all backed candidates
      are updated
    
    * simplify limit_backed_candidates and weight assumption
    
    * don't trust the provisioner to fairly distribute candidates
    
    * use saturating subtraction
    
    * empty commit to restart ci
    
    * use new mechanism for getting max block weight
    
    * apply weight refunds to the inclusion inherent
    
    This makes some assumptions about fundamental weights, which are
    encapsulated as constants. From there, it lets Substrate know
    what the actual computed weight of the inherent is.
    
    * use a correct fixed weight for the inclusion inherent
    
    Co-authored-by: default avatarGuillaume Thiolliere <[email protected]>
    
    * use dynamic inclusion weight so we reduce calculated weight when excluding candidates
    
    * don't double-count this intrinsic's weight in the block weight
    
    * add unit tests of fn limit_backed_candidates
    
    * add tests that the inclusion inherent's weight correctly updates
    
    Co-authored-by: default avatarGuillaume Thiolliere <[email protected]>
    fcc0fca1