Skip to content
  1. Jan 30, 2024
    • Oliver Tale-Yazdi's avatar
      Revert "[Runtime] Bound XCMP queue" (#3117) · fafe2722
      Oliver Tale-Yazdi authored
      Reverts paritytech/polkadot-sdk#2302. 🤦‍♂️ should have checked the
      migration CI first.
      
      We either need to reduce the `max_message_size` for the open HRMP
      channels on the failing chains or increase the `PageSize` of the XCMP
      queue.
      Both would be fine on a test-net, but i assume this will also fail
      before the next SP runtime upgrade so first need to think what best to
      do.
      AFAIK its not possible currently to change the `max_message_size` of an
      open HRMP channel.
      fafe2722
  2. Jan 29, 2024
  3. Jan 24, 2024
  4. Jan 23, 2024
  5. Jan 22, 2024
  6. Jan 18, 2024
  7. Jan 17, 2024
  8. Jan 16, 2024
    • Francisco Aguirre's avatar
      XCMv4 (#1230) · 8428f678
      Francisco Aguirre authored
      
      
      # Note for reviewer
      
      Most changes are just syntax changes necessary for the new version.
      Most important files should be the ones under the `xcm` folder.
      
      # Description 
      
      Added XCMv4.
      
      ## Removed `Multi` prefix
      The following types have been renamed:
      - MultiLocation -> Location
      - MultiAsset -> Asset
      - MultiAssets -> Assets
      - InteriorMultiLocation -> InteriorLocation
      - MultiAssetFilter -> AssetFilter
      - VersionedMultiAsset -> VersionedAsset
      - WildMultiAsset -> WildAsset
      - VersionedMultiLocation -> VersionedLocation
      
      In order to fix a name conflict, the `Assets` in `xcm-executor` were
      renamed to `HoldingAssets`, as they represent assets in holding.
      
      ## Removed `Abstract` asset id
      
      It was not being used anywhere and this simplifies the code.
      
      Now assets are just constructed as follows:
      
      ```rust
      let asset: Asset = (AssetId(Location::new(1, Here)), 100u128).into();
      ```
      
      No need for specifying `Concrete` anymore.
      
      ## Outcome is now a named fields struct
      
      Instead of
      
      ```rust
      pub enum Outcome {
        Complete(Weight),
        Incomplete(Weight, Error),
        Error(Error),
      }
      ```
      
      we now have
      
      ```rust
      pub enum Outcome {
        Complete { used: Weight },
        Incomplete { used: Weight, error: Error },
        Error { error: Error },
      }
      ```
      
      ## Added Reanchorable trait
      
      Now both locations and assets implement this trait, making it easier to
      reanchor both.
      
      ## New syntax for building locations and junctions
      
      Now junctions are built using the following methods:
      
      ```rust
      let location = Location {
          parents: 1,
          interior: [Parachain(1000), PalletInstance(50), GeneralIndex(1984)].into()
      };
      ```
      
      or
      
      ```rust
      let location = Location::new(1, [Parachain(1000), PalletInstance(50), GeneralIndex(1984)]);
      ```
      
      And they are matched like so:
      
      ```rust
      match location.unpack() {
        (1, [Parachain(id)]) => ...
        (0, Here) => ...,
        (1, [_]) => ...,
      }
      ```
      
      This syntax is mandatory in v4, and has been also implemented for v2 and
      v3 for easier migration.
      
      This was needed to make all sizes smaller.
      
      # TODO
      - [x] Scaffold v4
      - [x] Port github.com/paritytech/polkadot/pull/7236
      - [x] Remove `Multi` prefix
      - [x] Remove `Abstract` asset id
      
      ---------
      
      Co-authored-by: command-bot <>
      Co-authored-by: default avatarKeith Yeung <[email protected]>
      8428f678
  9. Jan 10, 2024
    • joe petrowski's avatar
      Unique Usernames in Identity Pallet (#2651) · d1f678c0
      joe petrowski authored
      
      
      This PR allows _username authorities_ to issue unique usernames that
      correspond with an account. It also provides two-way lookup, that is
      from `AccountId` to a single, "primary" `Username` (alongside
      `Registration`) and multiple unique `Username`s to an `AccountId`.
      
      Key features:
      
      - Username Authorities added (and removed) via privileged origin.
      - Authorities have a `suffix` and an `allocation`. They can grant up to
      `allocation` usernames. Their `suffix` will be appended to the usernames
      that they issue. A suffix may be up to 7 characters long.
      - Users can ask an authority to grant them a username. This will take
      the form `myusername.suffix`. The entire name (including suffix) must be
      less than or equal to 32 alphanumeric characters.
      - Users can approve a username for themselves in one of two ways (that
      is, authorities cannot grant them arbitrarily):
      - Pre-sign the entire username (including suffix) with a secret key that
      corresponds to their `AccountId` (for keyed accounts, obviously); or
      - Accept the username after it has been granted by an authority (it will
      be queued until accepted) (for non-keyed accounts like pure proxies or
      multisigs).
      - The system does not require any funds or deposits. Users without an
      identity will be given a default one (presumably all fields set to
      `None`). If they update this info, they will need to place the normal
      storage deposit.
      - If a user does not have any username, their first one will be set as
      `Primary`, and their `AccountId` will map to that one. If they get
      subsequent usernames, they can choose which one to be their primary via
      `set_primary_username`.
      - There are some state cleanup functions to remove expired usernames
      that have not been accepted and dangling usernames whose owners have
      called `clear_identity`.
      
      TODO:
      
      - [x] Add migration to runtimes
      - [x] Probably do off-chain migration into People Chain genesis
      - [x] Address a few TODO questions in code (please review)
      
      ---------
      
      Co-authored-by: default avatarLiam Aharon <[email protected]>
      Co-authored-by: default avatarGonçalo Pestana <[email protected]>
      Co-authored-by: default avatarOliver Tale-Yazdi <[email protected]>
      Co-authored-by: default avatarDónal Murray <[email protected]>
      d1f678c0
  10. Jan 07, 2024
  11. Jan 05, 2024
  12. Jan 04, 2024
  13. Dec 22, 2023