1. Oct 27, 2023
  2. Oct 26, 2023
    • yjh's avatar
      add `authorities_len` for aura (#2040) · 86228fa4
      yjh authored
      86228fa4
    • Alin Dima's avatar
      cumulus: fix test runtimes panic (#2039) · 1b08bdd2
      Alin Dima authored
      the min slot duration should be 0 only if the `experimental` feature is
      enabled. otherwise, the runtime will panic on a division by 0.
      1b08bdd2
    • Dastan's avatar
      Expose collection attributes from `Inspect` trait (#1914) · 0bcebac4
      Dastan authored
      # Description
      
      - What does this PR do?
      
      While working with `pallet_nfts` through `nonfungibles_v2` traits
      `Inspect, Mutate`, I found out that once you have set the collection
      attribute with `<Nfts as Mutate>::set_collection_attribute()`, it's not
      possible to read it with `<Nfts as Inspect>::collection_attribute()`
      since they use different `namespace` values. When setting the attribute,
      `AttributeNamespace::Pallet` is used, while
      `AttributeNamespace::CollectionOwner` is used when reading.
      
      more context:
      https://github.com/freeverseio/laos/issues/7#issuecomment-1766137370
      
      This PR makes `item` an optional parameter in
      `Inspect::system_attribute()`, to be able to read collection attributes.
      
      - Why are these changes needed?
      
      To be able to read collection level attributes when reading attributes
      of the collection. It will be possible to read collection attributes by
      passing `None` for `item`
      
      - How were these changes implemented and what do they affect?
      
      `NftsApi` is also affected and `NftsApi::system_attribute()` now accepts
      optional `item` parameter.
      
      ## Breaking change
      
      Because of the change in the `NftsApi::system_attribute()` method's
      `item` param, parachains who integrated the `NftsApi` need to update
      their API code and frontend integrations accordingly. AssetHubs are
      unaffected since the NftsApi wasn't released on those parachains yet.
      0bcebac4
  3. Oct 25, 2023
  4. Oct 24, 2023
    • Oliver Tale-Yazdi's avatar
      Improve features dev-ex (#1831) · 4a443567
      Oliver Tale-Yazdi authored
      Adds a config file that allows to run `zepter` without any arguments in
      the workspace to address all issues.
      A secondary workflow for the CI is provided as `zepter run check`. Both
      the formatting and linting are now in one check for efficiancy.
      
      The latest version also detects some more things that `featalign` was
      already showing.
      
      Error message [in the
      CI](https://gitlab.parity.io/parity/mirrors/polkadot-sdk/-/jobs/3916205)
      now looks like this:
      ```pre
      ...
      crate 'test-parachains' (/Users/vados/Documents/work/polkadot-sdk/polkadot/parachain/test-parachains/Cargo.toml)
        feature 'std'
          must propagate to:
            parity-scale-codec
      Found 55 issues (run with --fix to fix).
      Error: Command 'lint propagate-feature' failed with exit code 1
      
      Polkadot-SDK uses the Zepter CLI to detect abnormalities in the feature configuration.
      It looks like one more more checks failed; please check the console output. You can try to automatically address them by running `zepter`.
      Otherwise please ask directly in the Merge Request, GitHub Discussions or on Matrix Chat, thank you.
      
      For more information, see:
        - https://github.com/paritytech/polkadot-sdk/issues/1831
        - https://github.com/ggwpez/zepter
      
      
      ```
      
      TODO:
      - [x] Check that CI fails correctly
      
      ---------
      
      Signed-off-by: default avatarOliver Tale-Yazdi <[email protected]>
      4a443567
    • georgepisaltu's avatar
      Make `IdentityInfo` generic in `pallet-identity` (#1661) · 91851951
      georgepisaltu authored
      Fixes #179 
      
      # Description
      
      This PR makes the structure containing identity information used in
      `pallet-identity` generic through the pallet `Config`. Additionally, the
      old structure is now available in a separate module called `simple`
      (pending rename) and is compatible with the new interface.
      
      Another change in this PR is that while the `additional` field in
      `IdentityInfo` stays for backwards compatibility reasons, the associated
      costs are stil present in the pallet through the `additional` function
      in the `IdentityInformationProvider` interface. This function is marked
      as deprecated as it is only a temporary solution to the backwards
      compatibility problem we had. In short, we could have removed the
      additional fields in the struct and done a migration, but we chose to
      wait and do it off-chain through the genesis of the system parachain.
      After we move the identity pallet to the parachain, additional fields
      will be migrated into the existing fields and the `additional` key-value
      store will be removed. Until that happens, this interface will provide
      the necessary information to properly account for the associated costs.
      
      Additionally, this PR fixes an unrelated issue; the `IdentityField` enum
      used to represent the fields as bitflags couldn't store more than 8
      fields, even though it was marked as `#[repr(u64)]`. This was because of
      the `derive` implementation of `TypeInfo`, which assumed `u8` semantics.
      The custom implementation of this trait in
      https://github.com/paritytech/polkadot-sdk/commit/0105cc0396b7a53d0b290f48b1225847f6d17321
      
      
      fixes the issue.
      
      ---------
      
      Signed-off-by: default avatargeorgepisaltu <[email protected]>
      Co-authored-by: default avatarSam Johnson <[email protected]>
      Co-authored-by: default avatarjoe petrowski <[email protected]>
      91851951
    • Kian Paimani's avatar
      Ensure correct variant count in `Runtime[Hold/Freeze]Reason` (#1900) · 35eb133b
      Kian Paimani authored
      closes https://github.com/paritytech/polkadot-sdk/issues/1882
      
      
      
      ## Breaking Changes
      
      This PR introduces a new item to `pallet_balances::Config`:
      
      ```diff
      trait Config {
      ++    type RuntimeFreezeReasons;
      }
      ```
      
      This value is only used to check it against `type MaxFreeze`. A similar
      check has been added for `MaxHolds` against `RuntimeHoldReasons`, which
      is already given to `pallet_balances`.
      
      In all contexts, you should pass the real `RuntimeFreezeReasons`
      generated by `construct_runtime` to `type RuntimeFreezeReasons`. Passing
      `()` would also work, but it would imply that the runtime uses no
      freezes at all.
      
      ---------
      
      Signed-off-by: default avatarOliver Tale-Yazdi <[email protected]>
      Co-authored-by: default avatarOliver Tale-Yazdi <[email protected]>
      35eb133b
    • Bastian Köcher's avatar
      `CheckWeight`: Add more logging (#1996) · a5a2432d
      Bastian Köcher authored
      This adds more logging to `CheckWeight` to get a better understanding
      why a transaction exhausts resources.
      a5a2432d
  5. Oct 23, 2023
  6. Oct 20, 2023
    • Bastian Köcher's avatar
      `xcm`: Change `TypeInfo::path` to not include `staging` (#1948) · f3bf5c1a
      Bastian Köcher authored
      The `xcm` crate was renamed to `staging-xcm` to be able to publish it to
      crates.io as someone as squatted `xcm`. The problem with this rename is
      that the `TypeInfo` includes the crate name which ultimately lands in
      the metadata. The metadata is consumed by downstream users like
      `polkadot-js` or people building on top of `polkadot-js`. These people
      are using the entire `path` to find the type in the type registry. Thus,
      their code would break as the type path would now be [`staging_xcm`,
      `VersionedXcm`] instead of [`xcm`, `VersionedXcm`]. This pull request
      fixes this by renaming the path segment `staging_xcm` to `xcm`.
      
      This requires: https://github.com/paritytech/scale-info/pull/197
      
      
      
      ---------
      
      Co-authored-by: default avatarFrancisco Aguirre <[email protected]>
      f3bf5c1a
  7. Oct 19, 2023
  8. Oct 18, 2023
    • Keith Yeung's avatar
      Introduce XcmFeesToAccount fee manager (#1234) · 3dece311
      Keith Yeung authored
      
      
      Combination of paritytech/polkadot#7005, its addon PR
      paritytech/polkadot#7585 and its companion paritytech/cumulus#2433.
      
      This PR introduces a new XcmFeesToAccount struct which implements the
      `FeeManager` trait, and assigns this struct as the `FeeManager` in the
      XCM config for all runtimes.
      
      The struct simply deposits all fees handled by the XCM executor to a
      specified account. In all runtimes, the specified account is configured
      as the treasury account.
      
      XCM __delivery__ fees are now being introduced (unless the root origin
      is sending a message to a system parachain on behalf of the originating
      chain).
      
      # Note for reviewers
      
      Most file changes are tests that had to be modified to account for the
      new fees.
      Main changes are in:
      - cumulus/pallets/xcmp-queue/src/lib.rs <- To make it track the delivery
      fees exponential factor
      - polkadot/xcm/xcm-builder/src/fee_handling.rs <- Added. Has the
      FeeManager implementation
      - All runtime xcm_config files <- To add the FeeManager to the XCM
      configuration
      
      # Important note
      
      After this change, instructions that create and send a new XCM (Query*,
      Report*, ExportMessage, InitiateReserveWithdraw, InitiateTeleport,
      DepositReserveAsset, TransferReserveAsset, LockAsset and RequestUnlock)
      will require the corresponding origin account in the origin register to
      pay for transport delivery fees, and the onward message will fail to be
      sent if the origin account does not have the required amount. This
      delivery fee is on top of what we already collect as tx fees in
      pallet-xcm and XCM BuyExecution fees!
      
      Wallet UIs that want to expose the new delivery fee can do so using the
      formula:
      
      ```
      delivery_fee_factor * (base_fee + encoded_msg_len * per_byte_fee)
      ```
      
      where the delivery fee factor can be obtained from the corresponding
      pallet based on which transport you are using (UMP, HRMP or bridges),
      the base fee is a constant, the encoded message length from the message
      itself and the per byte fee is the same as the configured per byte fee
      for txs (i.e. `TransactionByteFee`).
      
      ---------
      
      Co-authored-by: default avatarBranislav Kontur <[email protected]>
      Co-authored-by: default avatarjoe petrowski <[email protected]>
      Co-authored-by: default avatarGiles Cope <[email protected]>
      Co-authored-by: command-bot <>
      Co-authored-by: default avatarFrancisco Aguirre <[email protected]>
      Co-authored-by: default avatarLiam Aharon <[email protected]>
      Co-authored-by: default avatarKian Paimani <[email protected]>
      3dece311
    • alexd10s's avatar
      Trading trait and deal with metadata in Mutate trait for nonfungibles_v2 (#1561) · 3aaf62ad
      alexd10s authored
      I have added some Traits that are missing and are useful for dealing
      with non-fungible tokens on other pallets and their implementations for
      NFTs pallet.
      
      - In the Mutate trait, added methods for dealing with the metadata:
      `set_metadata`, `set_collection_metadata`, `clear_metadata` and
      `clear_collection_metadata`.
      The motivation of adding this methods coming from a StackExchange
      question asking for it: [Setting metadata of an item of the Nfts pallet
      in a custom
      pallet](https://substrate.stackexchange.com/questions/9974/setting-metadata-of-an-item-of-the-nfts-pallet-in-a-custom-pallet)
      
      - A Trait for trading non-fungible items. The methods in that Trait are
      `buy_item`, `set_price` and `item_price`
      An example of where this Trait can be useful is a pallet that deals with
      [NFT
      Royalties](https://forum.polkadot.network/t/nfts-royalty-pallet/3766
      
      )
      and needs to perform this actions.
      
      ---------
      
      Co-authored-by: default avatarJegor Sidorenko <[email protected]>
      3aaf62ad
  9. Oct 17, 2023
  10. Oct 16, 2023
  11. Oct 15, 2023
    • Gonçalo Pestana's avatar
      Refactor staking ledger (#1484) · 8ee4042c
      Gonçalo Pestana authored
      This PR refactors the staking ledger logic to encapsulate all reads and
      mutations of `Ledger`, `Bonded`, `Payee` and stake locks within the
      `StakingLedger` struct implementation.
      
      With these changes, all the reads and mutations to the `Ledger`, `Payee`
      and `Bonded` storage map should be done through the methods exposed by
      StakingLedger to ensure the data and lock consistency of the operations.
      The new introduced methods that mutate and read Ledger are:
      
      - `ledger.update()`: inserts/updates a staking ledger in storage;
      updates staking locks accordingly (and ledger.bond(), which is synthatic
      sugar for ledger.update())
      - `ledger.kill()`: removes all Bonded and StakingLedger related data for
      a given ledger; updates staking locks accordingly;
      `StakingLedger::get(account)`: queries both the `Bonded` and `Ledger`
      storages and returns a `Option<StakingLedger>`. The pallet impl exposes
      fn ledger(account) as synthatic sugar for `StakingLedger::get(account)`.
      
      Retrieving a ledger with `StakingLedger::get()` can be done by providing
      either a stash or controller account. The input must be wrapped in a
      `StakingAccount` variant (Stash or Controller) which is treated
      accordingly. This simplifies the caller API but will eventually be
      deprecated once we completely get rid of the controller account in
      staking. However, this refactor will help with the work necessary when
      completely removing the controller.
      
      Other goals:
      
      - No logical changes have been introduced in this PR;
      - No breaking changes or updates in wallets required;
      - No new storage items or need to perform storage migrations;
      - Centralise the changes to bonds and ledger updates to simplify the
      OnStakingUpdate updates to the target list (related to
      https://github.com/paritytech/polkadot-sdk/issues/443)
      
      Note: it would be great to prevent or at least raise a warning if
      `Ledger<T>`, `Payee<T>` and `Bonded<T>` storage types are accessed
      outside the `StakingLedger` implementation. This PR should not get
      blocked by that feature, but there's a tracking issue here
      https://github.com/paritytech/polkadot-sdk/issues/149
      
      Related and step towards
      https://github.com/paritytech/polkadot-sdk/issues/443
      8ee4042c
    • S E R A Y A's avatar
      add link to rfc-0001 in broker README (#1862) · c9b51cd4
      S E R A Y A authored
      # Description
      - What does this PR do?
        - link added
      - Why are these changes needed?
        - improve docs
      - How were these changes implemented and what do they affect?
        - only concerns docs
      c9b51cd4
  12. Oct 14, 2023
    • Julian Eager's avatar
      Discard `Executor` (#1855) · 9f7656df
      Julian Eager authored
      
      
      closes #622 
      
      Pros:
      * simpler interface, just functions:
      `create_runtime_from_artifact_bytes()` and `execute_artifact()`
      
      Cons:
      * extra overhead of constructing executor semantics each time
      
      I could make it a combination of
      * `create_runtime_config(params)` (such that we could clone the
      constructed semantics)
      * `create_runtime(blob, config)`
      * `execute_artifact(blob, config, params)`
      
      Not sure if it's worth it though.
      
      ---------
      
      Co-authored-by: default avatarBastian Köcher <[email protected]>
      9f7656df
    • juangirini's avatar
      Macros to use path instead of ident (#1474) · 7c87d61f
      juangirini authored
      7c87d61f
  13. Oct 13, 2023
  14. Oct 12, 2023
  15. Oct 11, 2023
  16. Oct 10, 2023
    • Sam Johnson's avatar
      upgrade to macro_magic 0.4.3 (#1832) · 5adcb3e1
      Sam Johnson authored
      # Description
      
      Upgrades `macro_magic` to 0.4.3, which introduces the ability to have
      `export_tokens` use the same name as the underlying item for its
      auto-generated macro name. Ultimately this will allow for better dev ux
      in our derive_impl feature.
      5adcb3e1
    • Oliver Tale-Yazdi's avatar
      [FRAME] Warn on unchecked weight witness (#1818) · 64877492
      Oliver Tale-Yazdi authored
      Adds a warning to FRAME pallets when a function argument that starts
      with `_` is used in the weight formula.
      This is in most cases an error since the weight witness needs to be
      checked.
      
      Example:
      
      ```rust
      #[pallet::call_index(0)]
      #[pallet::weight(T::SystemWeightInfo::remark(_remark.len() as u32))]
      pub fn remark(_origin: OriginFor<T>, _remark: Vec<u8>) -> DispatchResultWithPostInfo {
      	Ok(().into())
      }
      ```
      
      Produces this warning:
      
      ```pre
      warning: use of deprecated constant `pallet::warnings::UncheckedWeightWitness_0::_w`: 
                       It is deprecated to not check weight witness data.
                       Please instead ensure that all witness data for weight calculation is checked before usage.
               
                       For more info see:
                           <https://github.com/paritytech/polkadot-sdk/pull/1818>
         --> substrate/frame/system/src/lib.rs:424:40
          |
      424 |         pub fn remark(_origin: OriginFor<T>, _remark: Vec<u8>) -> DispatchResultWithPostInfo {
          |                                              ^^^^^^^
          |
          = note: `#[warn(deprecated)]` on by default
      ```
      
      Can be suppressed like this, since in this case it is legit:
      
      ```rust
      #[pallet::call_index(0)]
      #[pallet::weight(T::SystemWeightInfo::remark(remark.len() as u32))]
      pub fn remark(_origin: OriginFor<T>, remark: Vec<u8>) -> DispatchResultWithPostInfo {
      	let _ = remark; // We dont need to check the weight witness.
      	Ok(().into())
      }
      ```
      
      Changes:
      - Add warning on uncheded weight witness
      - Respect `subkeys` limit in `System::kill_prefix`
      - Fix HRMP pallet and other warnings
      - Update`proc_macro_warning` dependency
      - Delete random folder `substrate/src/src` 🙈
      
       
      - Adding Prdoc
      
      ---------
      
      Signed-off-by: default avatarOliver Tale-Yazdi <[email protected]>
      Co-authored-by: default avatarjoe petrowski <[email protected]>
      64877492
    • David Emett's avatar
  17. Oct 09, 2023
    • David Emett's avatar
      Mixnet integration (#1346) · a808a3a0
      David Emett authored
      See #1345, <https://github.com/paritytech/substrate/pull/14207
      
      >.
      
      This adds all the necessary mixnet components, and puts them together in
      the "kitchen-sink" node/runtime. The components added are:
      
      - A pallet (`frame/mixnet`). This is responsible for determining the
      current mixnet session and phase, and the mixnodes to use in each
      session. It provides a function that validators can call to register a
      mixnode for the next session. The logic of this pallet is very similar
      to that of the `im-online` pallet.
      - A service (`client/mixnet`). This implements the core mixnet logic,
      building on the `mixnet` crate. The service communicates with other
      nodes using notifications sent over the "mixnet" protocol.
      - An RPC interface. This currently only supports sending transactions
      over the mixnet.
      
      ---------
      
      Co-authored-by: default avatarDavid Emett <[email protected]>
      Co-authored-by: default avatarJavier Viola <[email protected]>
      a808a3a0
  18. Oct 07, 2023
    • Muharem Ismailov's avatar
      Treasury spends various asset kinds (#1333) · cb944dc5
      Muharem Ismailov authored
      
      
      ### Summary 
      
      This PR introduces new dispatchables to the treasury pallet, allowing
      spends of various asset types. The enhanced features of the treasury
      pallet, in conjunction with the asset-rate pallet, are set up and
      enabled for Westend and Rococo.
      
      ### Westend and Rococo runtimes.
      
      Polkadot/Kusams/Rococo Treasury can accept proposals for `spends` of
      various asset kinds by specifying the asset's location and ID.
      
      #### Treasury Instance New Dispatchables:
      - `spend(AssetKind, AssetBalance, Beneficiary, Option<ValidFrom>)` -
      propose and approve a spend;
      - `payout(SpendIndex)` - payout an approved spend or retry a failed
      payout
      - `check_payment(SpendIndex)` - check the status of a payout;
      - `void_spend(SpendIndex)` - void previously approved spend;
      > existing spend dispatchable renamed to spend_local
      
      in this context, the `AssetKind` parameter contains the asset's location
      and it's corresponding `asset_id`, for example:
      `USDT` on `AssetHub`,
      ``` rust
      location = MultiLocation(0, X1(Parachain(1000)))
      asset_id = MultiLocation(0, X2(PalletInstance(50), GeneralIndex(1984)))
      ```
      
      the `Beneficiary` parameter is a `MultiLocation` in the context of the
      asset's location, for example
      ``` rust
      // the Fellowship salary pallet's location / account
      FellowshipSalaryPallet = MultiLocation(1, X2(Parachain(1001), PalletInstance(64)))
      // or custom `AccountId`
      Alice = MultiLocation(0, AccountId32(network: None, id: [1,...]))
      ```
      
      the `AssetBalance` represents the amount of the `AssetKind` to be
      transferred to the `Beneficiary`. For permission checks, the asset
      amount is converted to the native amount and compared against the
      maximum spendable amount determined by the commanding spend origin.
      
      the `spend` dispatchable allows for batching spends with different
      `ValidFrom` arguments, enabling milestone-based spending. If the
      expectations tied to an approved spend are not met, it is possible to
      void the spend later using the `void_spend` dispatchable.
      
      Asset Rate Pallet provides the conversion rate from the `AssetKind` to
      the native balance.
      
      #### Asset Rate Instance Dispatchables:
      - `create(AssetKind, Rate)` - initialize a conversion rate to the native
      balance for the given asset
      - `update(AssetKind, Rate)` - update the conversion rate to the native
      balance for the given asset
      - `remove(AssetKind)` - remove an existing conversion rate to the native
      balance for the given asset
      
      the pallet's dispatchables can be executed by the Root or Treasurer
      origins.
      
      ### Treasury Pallet
      
      Treasury Pallet can accept proposals for `spends` of various asset kinds
      and pay them out through the implementation of the `Pay` trait.
      
      New Dispatchables:
      - `spend(Config::AssetKind, AssetBalance, Config::Beneficiary,
      Option<ValidFrom>)` - propose and approve a spend;
      - `payout(SpendIndex)` - payout an approved spend or retry a failed
      payout;
      - `check_payment(SpendIndex)` - check the status of a payout;
      - `void_spend(SpendIndex)` - void previously approved spend;
      > existing spend dispatchable renamed to spend_local
      
      The parameters' types of the `spend` dispatchable exposed via the
      pallet's `Config` and allows to propose and accept a spend of a certain
      amount.
      
      An approved spend can be claimed via the `payout` within the
      `Config::SpendPeriod`. Clients provide an implementation of the `Pay`
      trait which can pay an asset of the `AssetKind` to the `Beneficiary` in
      `AssetBalance` units.
      
      The implementation of the Pay trait might not have an immediate final
      payment status, for example if implemented over `XCM` and the actual
      transfer happens on a remote chain.
      
      The `check_status` dispatchable can be executed to update the spend's
      payment state and retry the `payout` if the payment has failed.
      
      ---------
      
      Co-authored-by: default avatarjoe petrowski <[email protected]>
      Co-authored-by: command-bot <>
      cb944dc5
    • Dmitry Borodin's avatar
      migrate babe and authorship to use derive-impl (#1790) · 35ed272d
      Dmitry Borodin authored
      Moving a babe and authorship pallets to the latest and greatest
      derive_impl.
      
      Part of https://github.com/paritytech/polkadot-sdk/issues/171
      
      
      
      ---------
      
      Co-authored-by: default avatarKian Paimani <[email protected]>
      35ed272d
  19. Oct 06, 2023
  20. Oct 05, 2023