1. 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
  2. Oct 13, 2023
  3. Oct 12, 2023
  4. Oct 11, 2023
  5. 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
    • Keith Yeung's avatar
      3f5edc52
    • Liam Aharon's avatar
      remote-ext: fix state download stall on slow connections and reduce memory usage (#1295) · 55f35442
      Liam Aharon authored
      Original PR https://github.com/paritytech/substrate/pull/14746
      
      ---
      
      ## Fixing stall
      
      ### Introduction
      I experienced an apparent stall downloading state from
      `https://rococo-try-runtime-node.parity-chains.parity.io:443` which was
      having networking difficulties only responding to my JSONRPC requests
      with 50-200KB/s of bandwidth.
      
      This PR fixes the issue causing the stall, and generally improves
      performance remote-ext when it downloads state by greatly reducing the
      chances of a timeout occuring.
      
      ### Description
      Introduces a new `REQUEST_DURATION_TARGET` constant and modifies
      `get_storage_data_dynamic_batch_size` to
      
      - Increase or decrease the batch size of the next request depending on
      whether the elapsed time of the last request was gt or lt the target
      - Reset the batch size to 1 if the request times out
      
      This fixes an issue on slow connections that can otherwise cause
      multiple timeouts and a stalled download when:
      
      1. The batch size increases rapidly as remote-ext downloads keys with
      small associated storage values
      2. remote-ext tries to process a large series of subsequent keys all
      with extremely large associated storage values (Rococo has a series of
      keys 1-5MB large)
      3. The huge storage values download for 5 minutes until the request
      times out
      4. The partially downloaded keys are thrown out and remote-ext tries
      again with a smaller batch size, but the batch size is still far too
      large and takes 5 minutes to be reduced again
      5. The download will be essentially stalled for many hours while the
      above step cycles
      
      
      After this PR, the request size will
      
      - Not grow as large to begin with, as it is regulated downwards as the
      request duration exceeds the target
      - Drop immediately to 1 if the request times out. A timeout indicates
      the keys next in line to download have extremely large storage values
      compared to previously downloaded keys, and we need to reset the batch
      size to figure out what our new ideal batch size is. By not resetting
      down to 1, we risk the next request timing out again.
      
      ## Reducing memory
      
      As suggested by @bkchr, I adjusted `get_storage_data_dynamic_batch_size`
      from being recursive to a loop which allows removing a bunch of clones
      that were chewing through a lot of memory. I noticed actually it was
      using up to 50GB swap previously when downloading Polkadot keys on a
      slow connection, because it needed to recurse and clone a lot.
      
      After this change it uses only ~1.5GB memory.
      55f35442
    • Bulat Saifullin's avatar
      Update testnet bootnode dns name (#1712) · 373b8ac7
      Bulat Saifullin authored
      # Description
      Update the DNS name of bootnodes to unify the deployment. 
      
      Each bootnode have 3 port exposed: `30333, 30334, 443`. Before, we had
      different DNS names for `30333, 30334` and `443` ports. It may confuse
      people and give the impression that it is two different nodes. Fixing it
      by using a single domain for all
      373b8ac7
    • 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
    • Branislav Kontur's avatar
      [xcm] Use `Weight::MAX` for `reserve_asset_deposited`,... · e3c97e48
      Branislav Kontur authored
      [xcm] Use `Weight::MAX` for `reserve_asset_deposited`, `receive_teleported_asset` benchmarks (#1726)
      
      # Description
      
      ## Summary
      
      Previously, the `pallet_xcm::do_reserve_transfer_assets` and
      `pallet_xcm::do_teleport_assets` functions relied on weight estimation
      for remote chain execution, which was based on guesswork derived from
      the local chain. This approach led to complications for runtimes that
      did not provide or support specific [XCM
      configurations](https://github.com/paritytech/polkadot-sdk/blob/7cbe0c76ef8fd2aabf9f07de0156941ce3ed44b0/polkadot/xcm/xcm-executor/src/config.rs#L43-L47)
      for `IsReserve` or `IsTeleporter`. Consequently, such runtimes had to
      resort to implementing hard-coded weights for XCM instructions like
      `reserve_asset_deposited` or `receive_teleported_asset` to support
      extrinsics such as `pallet_xcm::reserve_transfer_assets` and
      `pallet_xcm::teleport_assets`, which depended on remote weight
      estimation.
      
      The issue of remote weight estimation was addressed and resolved by
      [Pull Request
      #1645](https://github.com/paritytech/polkadot-sdk/pull/1645), which
      removed the need for remote weight estimation.
      
      ## Solution
      
      As a continuation of this improvement, the current PR proposes further
      cleanup by removing unnecessary hard-coded values and rectifying
      benchmark results with `Weight::MAX` that previously used
      `T::BlockWeights::get().max_block` as an override for unsupported XCM
      instructions like `ReserveAssetDeposited` and `ReceiveTeleportedAsset`.
      
      
      ## Questions
      
      - [x] Can we remove now also `Hardcoded till the XCM pallet is fixed`
      for `deposit_asset`? E.g. for AssetHubKusama
      [here](https://github.com/paritytech/polkadot-sdk/blob/7cbe0c76ef8fd2aabf9f07de0156941ce3ed44b0/cumulus/parachains/runtimes/assets/asset-hub-kusama/src/weights/xcm/mod.rs#L129-L134)
      - [x] Are comments like
      [this](https://github.com/paritytech/polkadot-sdk/blob/7cbe0c76ef8fd2aabf9f07de0156941ce3ed44b0/polkadot/runtime/kusama/src/weights/xcm/mod.rs#L94)
      `// Kusama doesn't support ReserveAssetDeposited, so this benchmark has
      a default weight` still relevant? Shouldnt be removed/changed?
      
      
      ## TODO
      
      - [x] `bench bot` regenerate xcm weights for all runtimes
      - [x] remove hard-coded stuff from system parachain weight files
      - [ ] when merged, open `polkadot-fellow/runtimes` PR
      
      ## References
      
      Fixes #1132
      Closes #1132
      Old polkadot repo [PR](https://github.com/paritytech/polkadot/pull/7546)
      
      ---------
      
      Co-authored-by: command-bot <>
      e3c97e48
    • Svyatoslav Nikolsky's avatar
      Update bridges subtree (#1803) · ebf44233
      Svyatoslav Nikolsky authored
      ebf44233
    • Rahul Subramaniyam's avatar
      Check for parent of first ready block being on chain (#1812) · 2b4b33d0
      Rahul Subramaniyam authored
      When retrieving the ready blocks, verify that the parent of the first
      ready block is on chain. If the parent is not on chain, we are
      downloading from a fork. In this case, keep downloading until we have a
      parent on chain (common ancestor).
      
      Resolves https://github.com/paritytech/polkadot-sdk/issues/493
      
      .
      
      ---------
      
      Co-authored-by: default avatarAaro Altonen <[email protected]>
      2b4b33d0
    • David Emett's avatar
  6. Oct 09, 2023
  7. 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
    • Javier Viola's avatar
      chore: bump zombienter version (#1806) · 5a691260
      Javier Viola authored
      Bump zombiente version. This version includes the fixes needed for
      `mixnet`.
      Thx!
      5a691260
    • 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
  8. Oct 06, 2023
  9. Oct 05, 2023
  10. Oct 04, 2023