Skip to content
Snippets Groups Projects
  1. Dec 12, 2024
  2. Dec 05, 2024
    • Francisco Aguirre's avatar
      Added fallback_max_weight to Transact for sending messages to V4 chains (#6643) · f31c70aa
      Francisco Aguirre authored
      
      Closes: https://github.com/paritytech/polkadot-sdk/issues/6585
      
      Removing the `require_weight_at_most` parameter in V5 Transact had only
      one problem. Converting a message from V5 to V4 to send to chains that
      didn't upgrade yet. The conversion would not know what weight to give to
      the Transact, since V4 and below require it.
      
      To fix this, I added back the weight in the form of an `Option<Weight>`
      called `fallback_max_weight`. This can be set to `None` if you don't
      intend to deal with a chain that hasn't upgraded yet. If you set it to
      `Some(_)`, the behaviour is the same. The plan is to totally remove this
      in V6 since there will be a good conversion path from V6 to V5.
      
      ---------
      
      Co-authored-by: default avatarGitHub Action <action@github.com>
      Co-authored-by: default avatarAdrian Catangiu <adrian@parity.io>
      f31c70aa
  3. Nov 06, 2024
    • Francisco Aguirre's avatar
      XCM v5 (#4826) · 85521e87
      Francisco Aguirre authored
      # Context
      
      This PR aims to introduce XCMv5, for now it's in progress and will be
      updated over time.
      This branch will serve as a milestone branch for merging in all features
      we want to add to XCM, roughly outlined
      [here](https://github.com/polkadot-fellows/xcm-format/issues/60).
      More features could be added.
      
      ## TODO
      - [x] Migrate foreign assets from v3 to v4
      - [x] Setup v5 skeleton
      - [x] Remove XCMv2
      - [x] https://github.com/paritytech/polkadot-sdk/pull/5390
      - [x] https://github.com/paritytech/polkadot-sdk/pull/5585
      - [x] https://github.com/paritytech/polkadot-sdk/pull/5420
      - [x] https://github.com/paritytech/polkadot-sdk/pull/5876
      - [x] https://github.com/paritytech/polkadot-sdk/pull/5971
      - [x] https://github.com/paritytech/polkadot-sdk/pull/6148
      - [x] https://github.com/paritytech/polkadot-sdk/pull/6228
      
      Fixes #3434 
      Fixes https://github.com/paritytech/polkadot-sdk/issues/4190
      Fixes https://github.com/paritytech/polkadot-sdk/issues/5209
      Fixes https://github.com/paritytech/polkadot-sdk/iss...
      85521e87
  4. Aug 29, 2024
    • ordian's avatar
      short-term fix for para inherent weight overestimation (#5082) · cc7ebe05
      ordian authored
      closes #849
      
      ## Context
      
      For the background on this and the long-term fix, see
      https://github.com/paritytech/polkadot-sdk/issues/849#issuecomment-2247895862.
      
      ## Changes
      
      * The weigh files are renamed from `runtime_(parachains|common).*` to
      `polkadot_runtime_(parachains|common).*`. The reason for it is the
      renaming introduced in #4633. The new weight command and files are
      generated now include `polkadot_` prefix.
      * The WeightInfo for `paras_inherent` now includes `enter_empty` which
      calculates the cost of processing an empty parachains inherent. This
      cost is subtracted dynamically when calculating other weights (so the
      other weights remain the same)
      
      ## Benefits
      
      See
      https://github.com/paritytech/polkadot-sdk/issues/849#issuecomment-2247895862,
      but TL;DR is that we are not blocked on weights for scaling the number
      of validators and cores further.
      
      Resolved questions:
      - [x] why new benchmarks for westend are doing fewer db IOPS?
      Is it due polkadot-sdk update (db IOPS diff)?
      or the bench setup is no longer valid?
      
      https://github.com/polkadot-fellows/runtimes/blob/7723274a2c5cbb10213379271094d5180716ca7d/relay/polkadot/src/weights/runtime_parachains_paras_inherent.rs#L131-L196
      Answer: see background section of #5270 
      
      TODOs:
      - [x] Rerun benchmarks for Rococo and Westend
      - [x] PRDoc
      
      ---------
      
      Co-authored-by: command-bot <>
      cc7ebe05
  5. Jul 15, 2024
    • Jun Jiang's avatar
      Remove most all usage of `sp-std` (#5010) · 7ecf3f75
      Jun Jiang authored
      
      This should remove nearly all usage of `sp-std` except:
      - bridge and bridge-hubs
      - a few of frames re-export `sp-std`, keep them for now
      - there is a usage of `sp_std::Writer`, I don't have an idea how to move
      it
      
      Please review proc-macro carefully. I'm not sure I'm doing it the right
      way.
      
      Note: need `/bot fmt`
      
      ---------
      
      Co-authored-by: default avatarBastian Köcher <git@kchr.de>
      Co-authored-by: command-bot <>
      7ecf3f75
  6. Jun 05, 2024
    • Oliver Tale-Yazdi's avatar
      Unify dependency aliases (#4633) · d2fd5364
      Oliver Tale-Yazdi authored
      
      Inherited workspace dependencies cannot be renamed by the crate using
      them (see [1](https://github.com/rust-lang/cargo/issues/12546),
      [2](https://stackoverflow.com/questions/76792343/can-inherited-dependencies-in-rust-be-aliased-in-the-cargo-toml-file)).
      Since we want to use inherited workspace dependencies everywhere, we
      first need to unify all aliases that we use for a dependency throughout
      the workspace.
      The umbrella crate is currently excluded from this procedure, since it
      should be able to export the crates by their original name without much
      hassle.
      
      For example: one crate may alias `parity-scale-codec` to `codec`, while
      another crate does not alias it at all. After this change, all crates
      have to use `codec` as name. The problematic combinations were:
      - conflicting aliases: most crates aliases as `A` but some use `B`.
      - missing alias: most of the crates alias a dep but some dont.
      - superfluous alias: most crates dont alias a dep but some do.
      
      The script that i used first determines whether most crates opted to
      alias a dependency or not. From that info it decides whether to use an
      alias or not. If it decided to use an alias, the most common one is used
      everywhere.
      
      To reproduce, i used
      [this](https://github.com/ggwpez/substrate-scripts/blob/master/uniform-crate-alias.py)
      python script in combination with
      [this](https://github.com/ggwpez/zepter/blob/38ad10585fe98a5a86c1d2369738bc763a77057b/renames.json)
      error output from Zepter.
      
      ---------
      
      Signed-off-by: default avatarOliver Tale-Yazdi <oliver.tale-yazdi@parity.io>
      Co-authored-by: default avatarBastian Köcher <git@kchr.de>
      d2fd5364
  7. Apr 24, 2024
  8. Mar 27, 2024
    • Francisco Aguirre's avatar
      pallet-xcm: Deprecate `execute` and `send` in favor of `execute_blob` and `send_blob` (#3749) · feee773d
      Francisco Aguirre authored
      
      `execute` and `send` try to decode the xcm in the parameters before
      reaching the filter line.
      The new extrinsics decode only after the filter line.
      These should be used instead of the old ones.
      
      ## TODO
      - [x] Tests
      - [x] Generate weights
      - [x] Deprecation issue ->
      https://github.com/paritytech/polkadot-sdk/issues/3771
      - [x] PRDoc
      - [x] Handle error in pallet-contracts
      
      This would make writing XCMs in PJS Apps more difficult, but here's the
      fix for that: https://github.com/polkadot-js/apps/pull/10350.
      Already deployed! https://polkadot.js.org/apps/#/utilities/xcm
      
      Supersedes https://github.com/paritytech/polkadot-sdk/pull/1798/
      
      ---------
      
      Co-authored-by: default avatarPG Herveou <pgherveou@gmail.com>
      Co-authored-by: command-bot <>
      Co-authored-by: default avatarAdrian Catangiu <adrian@parity.io>
      feee773d
  9. 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 <kungfukeith11@gmail.com>
      8428f678
  10. Nov 30, 2023
  11. Nov 15, 2023
    • 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 <git@kchr.de>
      c79b234b