1. Feb 19, 2024
  2. Feb 18, 2024
  3. Feb 17, 2024
  4. Feb 16, 2024
  5. Feb 15, 2024
  6. Feb 14, 2024
  7. Feb 13, 2024
  8. Feb 12, 2024
  9. 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
    • PG Herveou's avatar
      Contracts update doc.rs metadata (#3241) · bc5a758c
      PG Herveou authored
      Adding Rust metadata for doc
      see https://docs.rs/about/metadata
      
      
      
      ---------
      
      Co-authored-by: default avatarAlexander Theißen <[email protected]>
      bc5a758c
    • Alexander Theißen's avatar
      contracts: Remove no longer enforced limits from the `Schedule` (#3184) · d54412ce
      Alexander Theißen authored
      When switching from the instrumented gas metering to the wasmi gas
      metering we also removed all imposed limits regarding Wasm module
      internals. All those things do not interact with the host and have to be
      handled by wasmi. For example, Wasmi charges additional gas for
      parameters to each function because as they incur some overhead.
      
      Back then we took the opportunity to remove the dependency on the
      deprecated `parity-wasm` which was used to enforce those limits.
      
      This PR merely removes them from the `Schedule` they aren't enforced for
      a while.
      d54412ce
    • Alexander Theißen's avatar
      contracts: Remove unused benchmarks (#3185) · 7fa05518
      Alexander Theißen authored
      Those were used for some adhoc comparison of solang vs ink! with regards
      to ERC20 transfers. Not been used for a while.
      
      Benchmarking is done here now:
      [smart-bench](https://github.com/paritytech/smart-bench): Weight based
      benchmark to test how much transaction actually fit into a block with
      the current Weights
      [schlau](https://github.com/ascjones/schlau): Time based benchmarks to
      compare performance
      7fa05518
    • Alexander Theißen's avatar
      contracts: Don't fail fast if the `Weight` limit of a cross contract call is too big (#3243) · 28463a12
      Alexander Theißen authored
      
      
      When doing a cross contract call you can supply an optional Weight limit
      for that call. If one doesn't specify the limit (setting it to 0) the
      sub call will have all the remaining gas available. If one does specify
      the limit we subtract that amount eagerly from the Weight meter and fail
      fast if not enough `Weight` is available.
      
      This is quite annoying because setting a fixed limit will set the
      `gas_required` in the gas estimation according to the specified limit.
      Even if in that dry-run the actual call didn't consume that whole
      amount. It effectively discards the more precise measurement it should
      have from the dry-run.
      
      This PR changes the behaviour so that the supplied limit is an actual
      limit: We do the cross contract call even if the limit is higher than
      the remaining `Weight`. We then fail and roll back in the cub call in
      case there is not enough weight.
      
      This makes the weight estimation in the dry-run no longer dependent on
      the weight limit supplied when doing a cross contract call.
      
      ---------
      
      Co-authored-by: default avatarPG Herveou <[email protected]>
      28463a12
    • dharjeezy's avatar
      Try State Hook for Ranked Collective (#3007) · 9cd02a07
      dharjeezy authored
      
      
      Part of: paritytech/polkadot-sdk#239
      
      Polkadot address: 12GyGD3QhT4i2JJpNzvMf96sxxBLWymz4RdGCxRH5Rj5agKW
      
      ---------
      
      Co-authored-by: default avatarLiam Aharon <[email protected]>
      9cd02a07
    • Dónal Murray's avatar
      [pallet_broker] Remove leases that have already expired in rotate_sale (#3213) · 2ea6bcf1
      Dónal Murray authored
      Leases can be force set, but since `Leases` is a `StorageValue`, if a
      lease misses its sale rotation in which it should expire, it can never
      be cleared.
      
      This can happen if a lease is added with an `until` timeslice that lies
      in a region whose sale has already started or has passed, even if the
      timeslice itself hasn't passed.
      
      This solves that issue in a minimal way, with all expired leases being
      cleaned up in each sale rotation, not just the ones that are expiring in
      the coming region.
      
      TODO:
      - [x] Write test
      2ea6bcf1
  10. 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
    • Squirrel's avatar
      sp-std -> core (#3199) · bc2e5e1f
      Squirrel authored
      First in a series of PRs that reduces our use of sp-std with a view to
      deprecating it.
      
      This is just looking at /substrate and moving some of the references
      from `sp-std` to `core`.
      These particular changes should be uncontroversial.
      
      Where macros are used `::core` should be used to remove any ambiguity.
      
      part of https://github.com/paritytech/polkadot-sdk/issues/2101
      bc2e5e1f
    • Oliver Tale-Yazdi's avatar
      Ranked collective `Add`+`Remove` origins (#3212) · c552fb54
      Oliver Tale-Yazdi authored
      Superseeds https://github.com/paritytech/polkadot-sdk/pull/1245  
      
      This PR is a migration of the
      https://github.com/paritytech/substrate/pull/14577
      
      .
      
      The PR added associated types (`AddOrigin` & `RemoveOrigin`) to
      `Config`. It allows you to decouple types and areas of responsibility,
      since at the moment the same types are responsible for adding and
      promoting(removing and demoting). This will improve the flexibility of
      the pallet configuration.
      
      ```
      /// The origin required to add a member.
      type AddOrigin: EnsureOrigin<Self::RuntimeOrigin, Success = ()>;
      
      /// The origin required to remove a member. The success value indicates the
      /// maximum rank *from which* the removal may be.
      type RemoveOrigin: EnsureOrigin<Self::RuntimeOrigin, Success = Rank>;
      ```
      To achieve the backward compatibility, the users of the pallet can use
      the old type via the new morph:
      
      ```
      type AddOrigin = MapSuccess<Self::PromoteOrigin, Ignore>;
      type RemoveOrigin = Self::DemoteOrigin;
      ```
      
      ---------
      
      Signed-off-by: default avatarOliver Tale-Yazdi <[email protected]>
      Co-authored-by: default avatarPraetorP <[email protected]>
      Co-authored-by: default avatarPavel Orlov <[email protected]>
      c552fb54
  11. Feb 05, 2024