1. Oct 15, 2023
    • drskalman's avatar
      Paired-key Crypto Scheme (#1705) · 1b34571c
      drskalman authored
      
      
      BEEFY needs two cryptographic keys at the same time. Validators should
      sign BEEFY payload using both ECDSA and BLS key. The network will gossip
      a payload which contains a valid ECDSA key. The prover nodes aggregate
      the BLS keys if aggregation fails to verifies the validator which
      provided a valid ECDSA signature but an invalid BLS signature is subject
      to slashing.
      
      As such BEEFY session should be initiated with both key. Currently there
      is no straight forward way of doing so, beside having a session with
      RuntimeApp corresponding to a crypto scheme contains both keys.
      
      This pull request implement a generic paired_crypto scheme as well as
      implementing it for (ECDSA, BLS) pair.
      
      ---------
      
      Co-authored-by: default avatarDavide Galassi <[email protected]>
      Co-authored-by: default avatarRobert Hambrock <[email protected]>
      1b34571c
    • 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
  2. 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
  3. Oct 13, 2023
    • 0xmovses's avatar
      Refactor alliance benchmarks to v2 (#1868) · 24840290
      0xmovses authored
      - This PR refactors `alliance/src/benchmarkings.rs` to use benchmarking
      v2. These changes are needed to improve the readability and
      maintainability of the benchmarking code.
      
      - No known issue to backlink.
      
      ## Local Testing 
      1. `cargo build --features runtime-benchmarks` 
      2. `cargo run --locked --release -p node-cli --bin substrate-node
      --features runtime-benchmarks -- benchmark pallet --execution wasm
      --wasm-execution compiled --chain dev --pallet "*" --extrinsic "*"
      --steps 2 --repeat 1`
      24840290
    • Adrian Catangiu's avatar
      frame: use derive-impl for beefy and mmr pallets (#1867) · 82bfe284
      Adrian Catangiu authored
      Part of #171
      82bfe284
    • Adrian Catangiu's avatar
      sc-consensus-beefy: improve gossip logic (#1852) · 83206000
      Adrian Catangiu authored
      - Remove cached messages used for deduplication in `GossipValidator`
      since they're already deduplicated in upper layer `NetworkGossip`.
      - Add cache for "justified rounds" to quickly discard any further (even
      if potentially different) justifications at the gossip level, once a
      valid one (for a respective round) is submitted to the worker.
      - Add short-circuit in worker `finalize()` method to not attempt to
      finalize same block multiple times (for example when we get
      justifications for same block from multiple components like
      block-import, gossip or on-demand).
      - Change a test which had A LOT of latency in syncing blocks for some
      weird reason and would only run after ~150seconds. It now runs
      instantly.
      
      Fixes https://github.com/paritytech/polkadot-sdk/issues/1728
      83206000
    • gupnik's avatar
      Adds instance support for composite enums (#1857) · 6b27dad3
      gupnik authored
      Fixes https://github.com/paritytech/polkadot-sdk/issues/1839
      
      Currently, `composite_enum`s do not support pallet instances. This PR
      allows the following:
      ```rust
      	#[pallet::composite_enum]
      	pub enum HoldReason<I: 'static = ()> {
      		SomeHoldReason
      	}
      ```
      
      ### Todo
      
      - [x]  UI Test
      6b27dad3
  4. Oct 12, 2023
  5. Oct 11, 2023
  6. 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
    • 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
    • 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
    • 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
  7. 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
  8. 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
  9. Oct 06, 2023
  10. Oct 05, 2023
  11. Oct 03, 2023
  12. Oct 02, 2023
    • Liam Aharon's avatar
      Init System Parachain storage versions and add migration check jobs to CI (#1344) · db3fd687
      Liam Aharon authored
      Makes SPs first class citizens along with the relay chains in the
      context of our CI runtime upgrade checks.
      
      ## Code changes
      
      - Sets missing current storage version in `uniques` pallet
      - Adds multisig V1 migration to run where it was missing
      - Removes executed migration whos pre/post hooks were failing from
      collectives runtime
      - Initializes storage versions for SP pallets added after genesis
      - Originally I was going to wait for
      https://github.com/paritytech/polkadot-sdk/pull/1297 to be merged so
      this wouldn't need to be done manually, but it doesn't seem like it'll
      be merged any time soon so I've decided to set them manually to unblock
      this
      
      ## CI changes
      
      - Removed dependency of `westend` runtime upgrades being complete prior
      to other ones running. I assume it is supposed to cache the
      `try-runtime` build for a performance benefit, but it seems it wasn't
      working. Maybe someone from the CI team can look into this or explain
      why it needs to be there?
      
      - Adds check-runtime-migration jobs for Parity asset-hubs, bridge-hubs
      and contract chains
      
      - Updated VARIABLES to accomodate the `kusama-runtime` package being
      renamed to `staging-kusama-runtime` in
      https://github.com/paritytech/polkadot-sdk/pull/1241
      
      - Added `EXTRA_ARGS` variable to `check-runtime-migration`, and set
      `--no-weight-warnings` to the relay chain runtime upgrade checks (relay
      chains don't have weight restrictions).
      db3fd687
  13. Oct 01, 2023
  14. Sep 30, 2023
  15. Sep 29, 2023
  16. Sep 28, 2023
    • btwiuse's avatar
      Fix `subkey inspect` output text padding (#1744) · 7b9861a2
      btwiuse authored
      
      
      This pull request is to fix the output text misalignment of `subkey
      inspect` command:
      
      (the `Network ID` line has an extra space at the end, and the `Secret
      seed` line lacks a leading space)
      
      ```
      [btwiuse@railway ~]$ subkey inspect '' | cat -A
      Secret Key URI `` is account:$
        Network ID:        substrate $
       Secret seed:       0xfac7959dbfe72f052e5a0c3c8d6530f202b02fd8f9f5ca3580ec8deb7797479e$
        Public key (hex):  0x46ebddef8cd9bb167dc30878d7113b7e168e6f0646beffd77d69d39bad76b47a$
        Account ID:        0x46ebddef8cd9bb167dc30878d7113b7e168e6f0646beffd77d69d39bad76b47a$
        Public key (SS58): 5DfhGyQdFobKM8NsWvEeAKk5EQQgYe9AydgJ7rMB6E1EqRzV$
        SS58 Address:      5DfhGyQdFobKM8NsWvEeAKk5EQQgYe9AydgJ7rMB6E1EqRzV$
      ```
      
      The output should be in the same YAML-like format as `subkey generate`:
      
      ```
      [btwiuse@railway ~]$ subkey generate  | cat -A
      Secret phrase:       awkward eagle survey resemble novel resist modify memory pistol shed flower run$
        Network ID:        substrate$
        Secret seed:       0x20502f79366325b7dc7620664e8844ae69d441baf6e5b571a57d3b3ff28e9586$
        Public key (hex):  0x468874b9e5b6b77333fa702b9201b924d6834bf956e33e2bbe37d131134ca830$
        Account ID:        0x468874b9e5b6b77333fa702b9201b924d6834bf956e33e2bbe37d131134ca830$
        Public key (SS58): 5DfBkAMg5xQmsePFr3BWLZm99smiNyy9axWSgembvFgDKh9v$
        SS58 Address:      5DfBkAMg5xQmsePFr3BWLZm99smiNyy9axWSgembvFgDKh9v$
      ```
      
      This change will fix `subkey` as well as all binaries that embed it as
      the `key` subcommand, for example: `substrate key`, `polkadot key`, etc.
      
      ---------
      
      Co-authored-by: default avatarLiam Aharon <[email protected]>
      7b9861a2
    • Alexandru Vasile's avatar
      archive: Implement height, hashByHeight and call (#1582) · 945ebbbc
      Alexandru Vasile authored
      This PR implements:
      - `archive_unstable_finalized_height`: Get the height of the most recent
      finalized block
      - `archive_unstable_hash_by_height`: Get the hashes (possible empty) of
      blocks from the given height
      - `archive_unstable_call`: Call into the runtime of a block
      
      Builds on top of: https://github.com/paritytech/polkadot-sdk/pull/1560
      
      ### Testing Done
      - unit tests for the methods with custom block tree for different
      heights / forks
      
      Closes: https://github.com/paritytech/polkadot-sdk/issues/1510
      Closes: https://github.com/paritytech/polkadot-sdk/issues/1513
      Closes: https://github.com/paritytech/polkadot-sdk/issues/1511
      
      
      
      @paritytech/subxt-team
      
      ---------
      
      Signed-off-by: default avatarAlexandru Vasile <[email protected]>
      Co-authored-by: default avatarSebastian Kunert <[email protected]>
      945ebbbc