1. Nov 29, 2023
  2. Nov 28, 2023
  3. Nov 27, 2023
  4. Nov 25, 2023
  5. Nov 24, 2023
  6. Nov 23, 2023
  7. Nov 22, 2023
    • Joshy Orndorff's avatar
      Remove `#[macro_use]` annotation from `mod service` in all nodes. (#2456) · ec189333
      Joshy Orndorff authored
      
      
      This PR removes `#[macro_use]` from the service module in each of the
      Substrate nodes in the repo.
      
      * Parachain Template
      * Polkadot Parachain
      * Minimal Node
      * Node Template
      * Kitchen Sink Node
      
      IDK why this annotation was present, maybe from when we had the
      `new_partial!` macro?
      
      ---------
      
      Co-authored-by: default avatarJoshy Orndorff <[email protected]>
      ec189333
    • James Wilson's avatar
      Make TypeInfo for SkipCheckIfFeeless transparent, too (#2449) · 0d6dcb3f
      James Wilson authored
      
      
      The `SkipCheckifFeeless::IDENTIFIER` became transparent (ie was whatever
      the inner signed ext was). This PR just makes the `TypeInfo` transparent
      too, so that libraries that use said info to decode the data (ie subxt)
      can behave identically whether or not the `SkipCheckifFeeless` wrapper
      is used or not.
      
      ---------
      
      Co-authored-by: default avatarOliver Tale-Yazdi <[email protected]>
      0d6dcb3f
    • gupnik's avatar
      Fixes import path in benchmark macro (#2437) · 98f9e2ea
      gupnik authored
      Fully-qualified path was not being used in benchmark macro for one of
      the cases. This PR fixes this and removes the unnecessary import in a
      couple of files, which I believe was done to fix this issue.
      98f9e2ea
    • Ross Bulat's avatar
      Deprecate `RewardDestination::Controller` (#2380) · 7a32f4be
      Ross Bulat authored
      
      
      Deprecates `RewardDestination::Controller` variant.
      
      - [x] `RewardDestination::Controller` annotated with `#[deprecated]`.
      - [x] `Controller` variant is now handled the same way as `Stash` in
      `payout_stakers`.
      - [x] `set_payee` errors if `RewardDestination::Controller` is provided.
      - [x] Added `update_payee` call to lazily migrate
      `RewardDestination::Controller` `Payee` storage entries to
      `RewardDestination::Account(controller)` .
      - [x] `payout_stakers_dead_controller` has been removed from benches &
      weights - was not used.
      - [x] Tests no longer use `RewardDestination::Controller`.
      
      ---------
      
      Co-authored-by: command-bot <>
      Co-authored-by: default avatarGonçalo Pestana <[email protected]>
      Co-authored-by: default avatargeorgepisaltu <[email protected]>
      7a32f4be
  8. Nov 21, 2023
  9. Nov 20, 2023
  10. Nov 19, 2023
  11. Nov 18, 2023
  12. Nov 17, 2023
  13. Nov 15, 2023
    • Bastian Köcher's avatar
      frame-system: Add `last_runtime_upgrade_spec_version` (#2351) · ea4085ab
      Bastian Köcher authored
      
      
      Adds a function for querying the last runtime upgrade spec version. This
      can be useful for when writing runtime level migrations to ensure that
      they are not executed multiple times. An example would be a session key
      migration.
      
      ---------
      
      Co-authored-by: default avatarLiam Aharon <[email protected]>
      Co-authored-by: default avatarOliver Tale-Yazdi <[email protected]>
      ea4085ab
    • joe petrowski's avatar
      Identity Deposits Relay to Parachain Migration (#1814) · c79b234b
      joe petrowski authored
      The goal of this PR is to migrate Identity deposits from the Relay Chain
      to a system parachain.
      
      The problem I want to solve is that `IdentityOf` and `SubsOf` both store
      an amount that's held in reserve as a storage deposit. When migrating to
      a parachain, we can take a snapshot of the actual `IdentityInfo` and
      sub-account mappings, but should migrate (off chain) the `deposit`s to
      zero, since the chain (and by extension, accounts) won't have any funds
      at genesis.
      
      The good news is that we expect parachain deposits to be significantly
      lower (possibly 100x) on the parachain. That is, a deposit of 21 DOT on
      the Relay Chain would need 0.21 DOT on a parachain. This PR proposes to
      migrate the deposits in the following way:
      
      1. Introduces a new pallet with two extrinsics: 
      - `reap_identity`: Has a configurable `ReapOrigin`, which would be set
      to `EnsureSigned` on the Relay Chain (i.e. callable by anyone) and
      `EnsureRoot` on the parachain (we don't want identities reaped from
      there).
      - `poke_deposit`: Checks what deposit the pallet holds (at genesis,
      zero) and attempts to update the amount based on the calculated deposit
      for storage data.
      2. `reap_identity` clears all storage data for a `target` account and
      unreserves their deposit.
      3. A `ReapIdentityHandler` teleports the necessary DOT to the parachain
      and calls `poke_deposit`. Since the parachain deposit is much lower, and
      was just unreserved, we know we have enough.
      
      One awkwardness I ran into was that the XCMv3 instruction set does not
      provide a way for the system to teleport assets without a fee being
      deducted on reception. Users shouldn't have to pay a fee for the system
      to migrate their info to a more efficient location. So I wrote my own
      program and did the `InitiateTeleport` accounting on my own to send a
      program with `UnpaidExecution`. Have discussed an
      `InitiateUnpaidTeleport` instruction with @franciscoaguirre . Obviously
      any chain executing this would have to pass a `Barrier` for free
      execution.
      
      TODO:
      
      - [x] Confirm People Chain ParaId
      - [x] Confirm People Chain deposit rates (determined in
      https://github.com/paritytech/polkadot-sdk/pull/2281
      
      )
      - [x] Add pallet to Westend
      
      ---------
      
      Co-authored-by: default avatarBastian Köcher <[email protected]>
      c79b234b
    • Dmitry Markin's avatar
      Unify `ChainSync` actions under one enum (follow-up) (#2317) · 18165ebb
      Dmitry Markin authored
      
      
      Get rid of public `ChainSync::..._requests()` functions and return all
      requests as actions.
      
      ---------
      
      Co-authored-by: default avatarSebastian Kunert <[email protected]>
      18165ebb
  14. Nov 14, 2023