Skip to content
Snippets Groups Projects
  1. Jan 05, 2025
    • thiolliere's avatar
      Implement cumulus StorageWeightReclaim as wrapping transaction extension +... · 63c73bf6
      thiolliere authored
      Implement cumulus StorageWeightReclaim as wrapping transaction extension + frame system ReclaimWeight (#6140)
      
      (rebasing of https://github.com/paritytech/polkadot-sdk/pull/5234)
      
      ## Issues:
      
      * Transaction extensions have weights and refund weight. So the
      reclaiming of unused weight must happen last in the transaction
      extension pipeline. Currently it is inside `CheckWeight`.
      * cumulus storage weight reclaim transaction extension misses the proof
      size of logic happening prior to itself.
      
      ## Done:
      
      * a new storage `ExtrinsicWeightReclaimed` in frame-system. Any logic
      which attempts to do some reclaim must use this storage to avoid double
      reclaim.
      * a new function `reclaim_weight` in frame-system pallet: info and post
      info in arguments, read the already reclaimed weight, calculate the new
      unused weight from info and post info. do the more accurate reclaim if
      higher.
      * `CheckWeight` is unchanged and still reclaim the weight in post
      dispatch
      * `ReclaimWeight` is a new transaction extension in frame system. For
      s...
  2. Jan 04, 2025
    • thiolliere's avatar
      Make `TransactionExtension` tuple of tuple transparent for implication (#7028) · b5a5ac44
      thiolliere authored
      
      Currently `(A, B, C)` and `((A, B), C)` change the order of implications
      in the transaction extension pipeline. This order is not accessible in
      the metadata, because the metadata is just a vector of transaction
      extension, the nested structure is not visible.
      
      This PR make the implementation for tuple of `TransactionExtension`
      better for tuple of tuple. `(A, B, C)` and `((A, B), C)` don't change
      the implication for the validation A.
      
      This is a breaking change but only when using the trait
      `TransactionExtension` the code implementing the trait is not breaking
      (surprising rust behavior but fine).
      
      ---------
      
      Co-authored-by: command-bot <>
      Co-authored-by: default avatarBastian Köcher <git@kchr.de>
  3. Jan 03, 2025
  4. Jan 02, 2025
  5. Dec 30, 2024
  6. Dec 29, 2024
  7. Dec 27, 2024
  8. Dec 23, 2024
  9. Dec 22, 2024
  10. Dec 21, 2024
    • Dónal Murray's avatar
      [pallet-broker] add extrinsic to reserve a system core without having to wait... · f9cdf41a
      Dónal Murray authored
      [pallet-broker] add extrinsic to reserve a system core without having to wait two sale boundaries (#4273)
      
      When calling the reserve extrinsic after sales have started, the
      assignment will be reserved, but two sale period boundaries must pass
      before the core is actually assigned.
      
      Since this can take between 28 and 56 days on production networks, a new
      extrinsic is introduced to shorten the timeline.
      
      This essentially performs three actions:
      1. Reserve it (applies after two sale boundaries)
      2. Add it to the Workplan for the next sale period
      3. Add it to the Workplan for the rest of the current sale period from
      the next timeslice to be commmitted.
      
      The caller must ensure that a core is first added, with most relay chain
      implementations having a delay of two session boundaries until it comes
      into effect.
      
      Alternatively the extrinsic can be called on a core whose workload can
      be clobbered from now until the reservation kicks in (the sale period
      after the next). Any workplan entries for that core at other timeslices
      should be first removed by the caller.
      
      ---------
      
      Co-authored-by: command-bot <>
  11. Dec 20, 2024
  12. Dec 19, 2024
  13. Dec 18, 2024