1. Jan 17, 2024
  2. 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
  3. 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
  4. Jan 07, 2024
  5. Jan 05, 2024
  6. Jan 04, 2024
  7. Dec 22, 2023