1. Feb 15, 2024
  2. Feb 14, 2024
  3. Feb 13, 2024
  4. Feb 12, 2024
  5. Feb 08, 2024
    • Oliver Tale-Yazdi's avatar
      [FRAME] Parameters pallet (#2061) · e53ebd8c
      Oliver Tale-Yazdi authored
      Closes #169  
      
      Fork of the `orml-parameters-pallet` as introduced by
      https://github.com/open-web3-stack/open-runtime-module-library/pull/927
      
      
      (cc @xlc)
      It greatly changes how the macros work, but keeps the pallet the same.
      The downside of my code is now that it does only support constant keys
      in the form of types, not value-bearing keys.
      I think this is an acceptable trade off, give that it can be used by
      *any* pallet without any changes.
      
      The pallet allows to dynamically set parameters that can be used in
      pallet configs while also restricting the updating on a per-key basis.
      The rust-docs contains a complete example.
      
      Changes:
      - Add `parameters-pallet`
      - Use in the kitchensink as demonstration
      - Add experimental attribute to define dynamic params in the runtime.
      - Adding a bunch of traits to `frame_support::traits::dynamic_params`
      that can be re-used by the ORML macros
      
      ## Example
      
      First to define the parameters in the runtime file. The syntax is very
      explicit about the codec index and errors if there is no.
      ```rust
      #[dynamic_params(RuntimeParameters, pallet_parameters::Parameters::<Runtime>))]
      pub mod dynamic_params {
      	use super::*;
      
      	#[dynamic_pallet_params]
      	#[codec(index = 0)]
      	pub mod storage {
      		/// Configures the base deposit of storing some data.
      		#[codec(index = 0)]
      		pub static BaseDeposit: Balance = 1 * DOLLARS;
      
      		/// Configures the per-byte deposit of storing some data.
      		#[codec(index = 1)]
      		pub static ByteDeposit: Balance = 1 * CENTS;
      	}
      
      	#[dynamic_pallet_params]
      	#[codec(index = 1)]
      	pub mod contracts {
      		#[codec(index = 0)]
      		pub static DepositPerItem: Balance = deposit(1, 0);
      
      		#[codec(index = 1)]
      		pub static DepositPerByte: Balance = deposit(0, 1);
      	}
      }
      ```
      
      Then the pallet is configured with the aggregate:  
      ```rust
      impl pallet_parameters::Config for Runtime {
      	type AggregratedKeyValue = RuntimeParameters;
      	type AdminOrigin = EnsureRootWithSuccess<AccountId, ConstBool<true>>;
      	...
      }
      ```
      
      And then the parameters can be used in a pallet config:
      ```rust
      impl pallet_preimage::Config for Runtime {
      	type DepositBase = dynamic_params::storage::DepositBase;
      }
      ```
      
      A custom origin an be defined like this:  
      ```rust
      pub struct DynamicParametersManagerOrigin;
      
      impl EnsureOriginWithArg<RuntimeOrigin, RuntimeParametersKey> for DynamicParametersManagerOrigin {
      	type Success = ();
      
      	fn try_origin(
      		origin: RuntimeOrigin,
      		key: &RuntimeParametersKey,
      	) -> Result<Self::Success, RuntimeOrigin> {
      		match key {
      			RuntimeParametersKey::Storage(_) => {
      				frame_system::ensure_root(origin.clone()).map_err(|_| origin)?;
      				return Ok(())
      			},
      			RuntimeParametersKey::Contract(_) => {
      				frame_system::ensure_root(origin.clone()).map_err(|_| origin)?;
      				return Ok(())
      			},
      		}
      	}
      
      	#[cfg(feature = "runtime-benchmarks")]
      	fn try_successful_origin(_key: &RuntimeParametersKey) -> Result<RuntimeOrigin, ()> {
      		Ok(RuntimeOrigin::Root)
      	}
      }
      ```
      
      ---------
      
      Signed-off-by: default avatarOliver Tale-Yazdi <[email protected]>
      Co-authored-by: default avatarNikhil Gupta <[email protected]>
      Co-authored-by: default avatarKian Paimani <[email protected]>
      Co-authored-by: command-bot <>
      e53ebd8c
    • Gonçalo Pestana's avatar
      Fixes `TotalValueLocked` out of sync in nomination pools (#3052) · aac07af0
      Gonçalo Pestana authored
      The `TotalLockedValue` storage value in nomination pools pallet may get
      out of sync if the staking pallet does implicit withdrawal of unlocking
      chunks belonging to a bonded pool stash. This fix is based on a new
      method in the `OnStakingUpdate` traits, `on_withdraw`, which allows the
      nomination pools pallet to adjust the `TotalLockedValue` every time
      there is an implicit or explicit withdrawal from a bonded pool's stash.
      
      This PR also adds a migration that checks and updates the on-chain TVL
      if it got out of sync due to the bug this PR fixes.
      
      **Changes to `trait OnStakingUpdate`**
      
      In order for staking to notify the nomination pools pallet that chunks
      where withdrew, we add a new method, `on_withdraw` to the
      `OnStakingUpdate` trait. The nomination pools pallet filters the
      withdraws that are related to bonded pool accounts and updates the
      `TotalValueLocked` accordingly.
      
      **Others**
      - Adds try-state checks to the EPM/staking e2e tests
      - Adds tests for auto withdrawing in the context of nomination pools
      
      **To-do**
      - [x] check if we need a migration to fix the current `TotalValueLocked`
      (run try-runtime)
      - [x] migrations to fix the current on-chain TVL value 
      
        **Kusama**:
      ```
      TotalValueLocked: 99.4559 kKSM
      TotalValueLocked (calculated) 99.4559 kKSM
      ```
      ️ **Westend**:
      ```
      TotalValueLocked: 18.4060 kWND
      TotalValueLocked (calculated) 18.4050 kWND
      ```
      **Polkadot**: TVL not released yet.
      
      Closes https://github.com/paritytech/polkadot-sdk/issues/3055
      
      
      
      ---------
      
      Co-authored-by: command-bot <>
      Co-authored-by: default avatarRoss Bulat <[email protected]>
      Co-authored-by: default avatarDónal Murray <[email protected]>
      aac07af0
    • Oliver Tale-Yazdi's avatar
      `bench pallet`: only require `Hash` instead of `Block` (#3244) · c36c51ca
      Oliver Tale-Yazdi authored
      Preparation for https://github.com/paritytech/polkadot-sdk/issues/2664
      
      
      
      Changes:
      - Only require `Hash` instead of `Block` for the benchmarking
      - Refactor DB types to do the same
      
      ## Integration
      
      This breaking change can easily be integrated into your node via:  
      ```patch
      - cmd.run::<Block, ()>(config)
      + cmd.run::<HashingFor<Block>, ()>(config)
      ```
      
      Status: waiting for CI checks
      
      ---------
      
      Signed-off-by: default avatarOliver Tale-Yazdi <[email protected]>
      Co-authored-by: default avatarBastian Köcher <[email protected]>
      Co-authored-by: default avatarcheme <[email protected]>
      c36c51ca
    • drskalman's avatar
      Make BEEFY client keystore generic over BEEFY `AuthorityId` type (#2258) · 0a94124d
      drskalman authored
      
      
      This is the significant step to make BEEFY client able to handle both
      ECDSA and (ECDSA, BLS) type signature. The idea is having BEEFY Client
      generic on crypto types makes migration to new types smoother.
      
      This makes the BEEFY Keystore generic over AuthorityId and extends its
      tests to cover the case when the AuthorityId is of type (ECDSA,
      BLS12-377)
      
      ---------
      
      Co-authored-by: default avatarDavide Galassi <[email protected]>
      Co-authored-by: default avatarRobert Hambrock <[email protected]>
      0a94124d
    • Louis Merlin's avatar
      Add try_state and integrity_test to XCM simulator fuzzer (#3222) · 84d89e37
      Louis Merlin authored
      This adds `try_state()` and `integrity_test()` to the four runtimes of
      the XCM-simulator fuzzer.
      
      With this, we are able to stress-test [message-queue's
      try_state](https://github.com/paritytech/polkadot-sdk/blob/7df1ae3b8111d534cce108b2b405b6a33fcdedc3/substrate/frame/message-queue/src/lib.rs#L1245-L1347).
      
      This also adds the `Transact` block-listing from #2424 to avoid
      false-positives.
      
      Thank you @ggwpez for the help with the runtime configurations.
      84d89e37
  6. Feb 06, 2024
    • Koute's avatar
      Build more runtimes targeting PolkaVM (#3209) · 402b64ca
      Koute authored
      This PR improves compatibility with RISC-V and PolkaVM, allowing more
      runtimes to successfully compile.
      
      In particular, it makes the following changes:
      
      - The `sp-mmr-primitives` and `sp-consensus-beefy` crates
      unconditionally required an `std`-only dependency; now they only require
      those dependencies when the `std` feature is actually enabled. (Our
      RISC-V target is, unlike WASM, a true `no_std` target where you can't
      accidentally use stuff from `std` anymore.)
      - One of our dependencies (the `bitvec` trace) uses a crate called
      `radium` which doesn't compile under RISC-V due to incomplete
      autodetection logic in their `build.rs` file. The good news is that this
      is already fixed in the newest upstream version of `radium`, and the
      newest version of `bitvec` uses it. The bad news is that the newest
      version of `bitvec` is not currently released on crates.io, so we can't
      use it. I've [created an
      issue](https://github.com/ferrilab/ferrilab/issues/5) asking for a new
      release, but in the meantime I forked the currently used `radium` 0.7,
      [fixed the faulty
      logic](https://github.com/paritytech/radium-0.7-fork/commit/ed66c8a294b138c67f93499644051d97d4c7fbda)
      and used cargo's patching capabilities to use it for the RISC-V runtime
      builds. This might be a little hacky, but it is the least intrusive way
      to fix the problem, doesn't affect WASM builds at all, and we can
      trivially remove it once a new `bitvec` is released.
      - The new runtimes are added to the CI to make sure their compilation
      doesn't break.
      402b64ca
  7. Feb 05, 2024
  8. Feb 03, 2024
    • Koute's avatar
      Initial support for building RISC-V runtimes targeting PolkaVM (#3179) · e349fc9e
      Koute authored
      This PR adds initial support for building RISC-V runtimes targeting
      PolkaVM.
      
      - Setting the `SUBSTRATE_RUNTIME_TARGET=riscv` environment variable will
      now build a RISC-V runtime instead of a WASM runtime.
      - This only adds support for *building* runtimes; running them will need
      a PolkaVM-based executor, which I will add in a future PR.
      - Only building the minimal runtime is supported (building the Polkadot
      runtime doesn't work *yet* due to one of the dependencies).
      - The builder now sets a `substrate_runtime` cfg flag when building the
      runtimes, with the idea being that instead of doing `#[cfg(not(feature =
      "std"))]` or `#[cfg(target_arch = "wasm32")]` to detect that we're
      building a runtime you'll do `#[cfg(substrate_runtime)]`. (Switching the
      whole codebase to use this will be done in a future PR; I deliberately
      didn't do this here to keep this PR minimal and reviewable.)
      - Further renaming of things (e.g. types, environment variables and proc
      macro attributes having "wasm" in their name) to be target-agnostic will
      also be done in a future refactoring PR (while keeping backwards
      compatibility where it makes sense; I don't intend to break anyone's
      workflow or create unnecessary churn).
      - This PR also fixes two bugs in the `wasm-builder` crate:
      * The `RUSTC` environment variable is now removed when invoking the
      compiler. This prevents the toolchain version from being overridden when
      called from a `build.rs` script.
      * When parsing the `rustup toolchain list` output the `(default)` is now
      properly stripped and not treated as part of the version.
      - I've also added a minimal CI job that makes sure this doesn't break in
      the future. (cc @paritytech/ci)
      
      cc @athei
      
      
      
      ------
      
      Also, just a fun little tidbit: quickly comparing the size of the built
      runtimes it seems that the PolkaVM runtime is slightly smaller than the
      WASM one. (`production` build, with the `names` section substracted from
      the WASM's size to keep things fair, since for the PolkaVM runtime we're
      currently stripping out everything)
      
      - `.wasm`: 625505 bytes
      - `.wasm` (after wasm-opt -O3): 563205 bytes
      - `.wasm` (after wasm-opt -Os): 562987 bytes
      - `.wasm` (after wasm-opt -Oz): 536852 bytes
      - `.polkavm`: ~~580338 bytes~~ 550476 bytes (after enabling extra target
      features; I'll add those in another PR once we have an executor working)
      
      ---------
      
      Co-authored-by: default avatarBastian Köcher <[email protected]>
      e349fc9e
  9. Feb 02, 2024
  10. Jan 31, 2024
  11. Jan 30, 2024
  12. Jan 29, 2024
  13. Jan 28, 2024
  14. Jan 26, 2024
  15. Jan 25, 2024
  16. Jan 24, 2024
  17. Jan 23, 2024
  18. Jan 22, 2024
    • Davide Galassi's avatar
      Move cryptographic hashing procedures to crypto folder. (#2306) · 4c10fd2a
      Davide Galassi authored
      Step towards https://github.com/paritytech/polkadot-sdk/issues/1975
      
      As reported
      https://github.com/paritytech/polkadot-sdk/issues/1975#issuecomment-1774534225
      
      
      I'd like to encapsulate crypto related stuff in a dedicated folder.
      
      Currently all cryptographic primitive wrappers are all sparsed in
      `substrate/core` which contains "misc core" stuff.
      
      To simplify the process, as the first step with this PR I propose to
      move the cryptographic hashing there.
      
      The `substrate/crypto` folder was already created to contains `ec-utils`
      crate.
      
      Notes:
      - rename `sp-core-hashing` to `sp-crypto-hashing`
      - rename `sp-core-hashing-proc-macro` to `sp-crypto-hashing-proc-macro`
      - As the crates name is changed I took the freedom to restart fresh from
      version 0.1.0 for both crates
      
      ---------
      
      Co-authored-by: default avatarRobert Hambrock <[email protected]>
      4c10fd2a
    • dependabot[bot]'s avatar
      Bump wasm-instrument from 0.3.0 to 0.4.0 (#1294) · bbfff668
      dependabot[bot] authored
      Bumps [wasm-instrument](https://github.com/paritytech/wasm-instrument)
      from 0.3.0 to 0.4.0.
      <details>
      <summary>Changelog</summary>
      <p><em>Sourced from <a
      href="https://github.com/paritytech/wasm-instrument/blob/master/CHANGELOG.md">wasm-instrument's
      changelog</a>.</em></p>
      <blockquote>
      <h1>Changelog</h1>
      <p>All notable changes to this project will be documented in this
      file.</p>
      <p>The format is based on <a
      href="https://keepachangelog.com/en/1.0.0/">Keep a Changelog</a>,
      and this project adheres to <a
      href="https://semver.org/spec/v2.0.0.html">Semantic Versioning</a>.</p>
      <p>The semantic versioning guarantees cover the interface to the
      substrate runtime which
      includes this pallet as a dependency. This module will also add storage
      migrations whenever
      changes require it. Stability with regard to offchain tooling is
      explicitly excluded from
      this guarantee: For example adding a new field to an in-storage data
      structure will require
      changes to frontends to properly display it. However, those changes will
      still be regarded
      as a minor version bump.</p>
      <p>The interface provided to smart contracts will adhere to semver with
      one exception: Even
      major version bumps will be backwards compatible with regard to already
      deployed contracts.
      In other words: Upgrading this pallet will not break pre-existing
      contracts.</p>
      <h2>[Unreleased]</h2>
      <h3>New</h3>
      <ul>
      <li>Add new gas metering method: mutable global + local gas function
      <a
      href="https://redirect.github.com/paritytech/wasm-instrument/pull/34">#34</a></li>
      <li>Account for locals initialization costs
      <a
      href="https://redirect.github.com/paritytech/wasm-instrument/pull/38">#38</a></li>
      </ul>
      </blockquote>
      </details>
      <details>
      <summary>Commits</summary>
      <ul>
      <li>See full diff in <a
      href="https://github.com/paritytech/wasm-instrument/commits/v0.4.0">compare
      view</a></li>
      </ul>
      </details>
      <br />
      
      
      [![Dependabot compatibility
      score](https://dependabot-badges.githubapp.com/badges/compatibility_score?dependency-name=wasm-instrument&package-manager=cargo&previous-version=0.3.0&new-version=0.4.0)](https://docs.github.com/en/github/managing-security-vulnerabilities/about-dependabot-security-updates#about-compatibility-scores
      
      )
      
      You can trigger a rebase of this PR by commenting `@dependabot rebase`.
      
      [//]: # (dependabot-automerge-start)
      [//]: # (dependabot-automerge-end)
      
      ---
      
      <details>
      <summary>Dependabot commands and options</summary>
      <br />
      
      You can trigger Dependabot actions by commenting on this PR:
      - `@dependabot rebase` will rebase this PR
      - `@dependabot recreate` will recreate this PR, overwriting any edits
      that have been made to it
      - `@dependabot merge` will merge this PR after your CI passes on it
      - `@dependabot squash and merge` will squash and merge this PR after
      your CI passes on it
      - `@dependabot cancel merge` will cancel a previously requested merge
      and block automerging
      - `@dependabot reopen` will reopen this PR if it is closed
      - `@dependabot close` will close this PR and stop Dependabot recreating
      it. You can achieve the same result by closing it manually
      - `@dependabot show <dependency name> ignore conditions` will show all
      of the ignore conditions of the specified dependency
      - `@dependabot ignore <dependency name> major version` will close this
      group update PR and stop Dependabot creating any more for the specific
      dependency's major version (unless you unignore this specific
      dependency's major version or upgrade to it yourself)
      - `@dependabot ignore <dependency name> minor version` will close this
      group update PR and stop Dependabot creating any more for the specific
      dependency's minor version (unless you unignore this specific
      dependency's minor version or upgrade to it yourself)
      - `@dependabot ignore <dependency name>` will close this group update PR
      and stop Dependabot creating any more for the specific dependency
      (unless you unignore this specific dependency or upgrade to it yourself)
      - `@dependabot unignore <dependency name>` will remove all of the ignore
      conditions of the specified dependency
      - `@dependabot unignore <dependency name> <ignore condition>` will
      remove the ignore condition of the specified dependency and ignore
      conditions
      
      
      </details>
      
      > **Note**
      > Automatic rebases have been disabled on this pull request as it has
      been open for over 30 days.
      
      Signed-off-by: default avatardependabot[bot] <[email protected]>
      Co-authored-by: default avatardependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>
      bbfff668