- Nov 14, 2023
-
-
PG Herveou authored
This PR introduces: - XCM host functions `xcm_send`, `xcm_execute` - An Xcm trait into the config. that proxy these functions to to `pallet_xcm`, or disable their usage by using `()`. - A mock_network and xcm_test files to test the newly added xcm-related functions. --------- Co-authored-by: Keith Yeung <[email protected]> Co-authored-by: Sasha Gryaznov <[email protected]> Co-authored-by: command-bot <> Co-authored-by: Francisco Aguirre <[email protected]> Co-authored-by: Alexander Theißen <[email protected]>
-
Alin Dima authored
Adds a `NodeFeatures` bitfield value to the runtime `HostConfiguration`, with the purpose of coordinating the enabling of node-side features, such as: https://github.com/paritytech/polkadot-sdk/issues/628 and https://github.com/paritytech/polkadot-sdk/issues/598. These are features that require all validators enable them at the same time, assuming all/most nodes have upgraded their node versions. This PR doesn't add any feature yet. These are coming in future PRs. Also adds a runtime API for querying the state of the client features and an extrinsic for setting/unsetting a feature by its index in the bitfield. Note: originally part of: https://github.com/paritytech/polkadot-sdk/pull/1644, but posted as standalone to be reused by other PRs until the initial PR is merged
-
Kristian Sosnin authored
Fixes #1437 Co-authored-by: Sophia Gold <[email protected]>
-
jserrat authored
Co-authored-by: Marcin S <[email protected]>
-
Alexandru Vasile authored
Remove the genesis hash from tests: - Clippy was passing on the PR: https://github.com/paritytech/polkadot-sdk/pull/2296 - Clippy fails on master: https://gitlab.parity.io/parity/mirrors/polkadot-sdk/-/jobs/4328487 This was a race with merging: https://github.com/paritytech/polkadot-sdk/pull/2295, which introduced another test that used the `CHAIN_GENESIS` Signed-off-by: Alexandru Vasile <[email protected]>
-
PG Herveou authored
-
georgepisaltu authored
Fixes https://github.com/paritytech/polkadot-sdk/issues/106 Port of cumulus PR https://github.com/paritytech/cumulus/pull/2960 This PR adds the ability to bid for collator slots even after the max number of collators have already registered. This eliminates the first come, first served mechanism that was in place before. Key changes: - added `update_bond` extrinsic to allow registered candidates to adjust their bonds in order to dynamically control their bids - added `take_candidate_slot` extrinsic to try to replace an already existing candidate by bidding more than them - candidates are now kept in a sorted list in the pallet storage, where the top `DesiredCandidates` out of `MaxCandidates` candidates in the list will be selected by the session pallet as collators - if the candidacy bond is increased through a `set_candidacy_bond` call, candidates which don't meet the new bond requirements are kicked # Checklist - [ ] My PR includes a detailed description as outlined in the "Description" section above - [ ] My PR follows the [labeling requirements](https://github.com/paritytech/polkadot-sdk/blob/master/docs/CONTRIBUTING.md#process) of this project (at minimum one label for `T` required) - [ ] I have made corresponding changes to the documentation (if applicable) - [ ] I have added tests that prove my fix is effective or that my feature works (if applicable) - [ ] If this PR alters any external APIs or interfaces used by Polkadot, the corresponding Polkadot PR is ready as well as the corresponding Cumulus PR (optional) --------- Signed-off-by: georgepisaltu <[email protected]>
-
Alexandru Vasile authored
The method has been removed from the spec (https://github.com/paritytech/json-rpc-interface-spec/tree/main/src), this PR keeps the `chainHead` in sync with that change. @paritytech/subxt-team --------- Signed-off-by: Alexandru Vasile <[email protected]>
-
Alexandru Vasile authored
This PR adds support for multiple hashes being passed to the `chainHeda_unpin` parameters. The `hash` parameter is renamed to `hash_or_hashes` per https://github.com/paritytech/json-rpc-interface-spec/pull/111. While at it, a new integration test is added to check the unpinning of multiple hashes. The API is checked against a hash or a vector of hashes. cc @paritytech/subxt-team --------- Signed-off-by: Alexandru Vasile <[email protected]>
-
Lulu authored
Turns out to access environment secrets the workflow must explicitly opt in to the environment.
-
Marcin S. authored
-
Adrian Catangiu authored
- switch from Rococo<>Wococo to Rococo<>Westend bridge - add bidirectional simple tests - remove Wococo chains from xcm-emulator - added tests for assets transfers over Rococo<>Westend bridge fixes https://github.com/paritytech/parity-bridges-common/issues/2405
-
Hugo Trentesaux authored
add details in `--dev` flag to tell that it disables local peer discovery ### Context When adding automated end-to-end tests, we replaced `--dev` by ``` `--chain=dev`, `--force-authoring`, `--rpc-cors=all`, `--alice`, and `--tmp` flags ``` as stated in the command line documentation. But the tests started failing due to the nodes connecting to each other. ### Fix This PR includes additional command line documentation to explain more in detail what `--dev` flag inludes.
-
Liam Aharon authored
Closes https://github.com/paritytech/polkadot-sdk/issues/2241 See issue comments for more details about this storage.
-
Branislav Kontur authored
## Problem/Motivation The benchmark for the `ExpectPallet` XCM instruction uses a hard-coded version `4.0.0` for the `frame_system` pallet. Unfortunately, this doesn't work for the `polkadot-fellows/runtimes` repository, where we use dependencies from `crates.io`, e.g., [frame-system::23.0.0.0](https://github.com/polkadot-fellows/runtimes/blob/dd7f86f0d50064481ed0b7c0218494a5cfad997e/relay/kusama/Cargo.toml#L83). Closes: https://github.com/paritytech/polkadot-sdk/issues/2284 ## Solution This PR fixes the benchmarks that require pallet information and enables the runtime to provide the correct/custom pallet information. The default implementation provides `frame_system::Pallet` with index `0`, where the version is not hard-coded but read from the runtime. ## Local testing Added log for `T::valid_pallet` to the benchmarks like: ``` let valid_pallet = T::valid_pallet(); log::info!( target: "frame::benchmark::pallet", "valid_pallet: {}::{}::{}::{}::{}", valid_pallet.index, valid_pallet.module_name, valid_pallet.crate_version.major, valid_pallet.crate_version.minor, valid_pallet.crate_version.patch, ); ``` Run benchmarks for `westend`: ``` cargo run --bin=polkadot --features=runtime-benchmarks -- benchmark pallet --steps=2 --repeat=1 --extrinsic=* --heap-pages=4096 --json-file=./bench.json --chain=westend-dev --template=./polkadot/xcm/pallet-xcm-benchmarks/template.hbs --pallet=pallet_xcm_benchmarks::generic --output=./polkadot/runtime/westend/src/weights/xcm ``` --- For actual `frame_system` version: ``` [package] name = "frame-system" version = "4.0.0-dev" ``` Log dump: ``` 2023-11-13 12:56:45 Starting benchmark: pallet_xcm_benchmarks::generic::query_pallet 2023-11-13 12:56:45 valid_pallet: 0::frame_system::4::0::0 2023-11-13 12:56:45 valid_pallet: 0::frame_system::4::0::0 2023-11-13 12:56:45 valid_pallet: 0::frame_system::4::0::0 2023-11-13 12:56:45 Starting benchmark: pallet_xcm_benchmarks::generic::expect_pallet 2023-11-13 12:56:45 valid_pallet: 0::frame_system::4::0::0 2023-11-13 12:56:45 valid_pallet: 0::frame_system::4::0::0 2023-11-13 12:56:45 valid_pallet: 0::frame_system::4::0::0 ``` For changed `frame_system` version: ``` [package] name = "frame-system" version = "5.1.3-dev" ``` Log dump: ``` 2023-11-13 12:51:51 Starting benchmark: pallet_xcm_benchmarks::generic::query_pallet 2023-11-13 12:51:51 valid_pallet: 0::frame_system::5::1::3 2023-11-13 12:51:51 valid_pallet: 0::frame_system::5::1::3 2023-11-13 12:51:51 valid_pallet: 0::frame_system::5::1::3 2023-11-13 12:51:51 Starting benchmark: pallet_xcm_benchmarks::generic::expect_pallet 2023-11-13 12:51:51 valid_pallet: 0::frame_system::5::1::3 2023-11-13 12:51:51 valid_pallet: 0::frame_system::5::1::3 2023-11-13 12:51:51 valid_pallet: 0::frame_system::5::1::3 ``` ## References Closes: https://github.com/paritytech/polkadot-sdk/issues/2284
-
drskalman authored
BEEFY ECDSA signatures are on keccak has of the messages. As such we can not simply call `EcdsaBlsPair::verify(signature.as_inner_ref(), msg, self.as_inner_ref())` because that invokes ecdsa default verification which perfoms blake2 hash which we don't want. This bring up the second issue makes: This makes `sign` and `verify` function in `pair_crypto` useless, at least for BEEFY use case. Moreover, there is no obvious clean way to generate the signature given that pair_crypto does not exposes `sign_prehashed`. You could in theory query the keystore for the pair (could you?), invoke `to_raw` and re-generate each sub-pair and sign using each. But that sounds extremely anticlimactic and will be frow upon by auditors . So I appreciate any alternative suggestion. --------- Co-authored-by: Davide Galassi <[email protected]> Co-authored-by: Robert Hambrock <[email protected]>
-
Alin Dima authored
Collators were previously reencoding the available data and checking the erasure root. Replace that with just checking the PoV hash, which consumes much less CPU and takes less time. We also don't need to check the `PersistedValidationData` hash, as collators don't use it. Reason: https://github.com/paritytech/polkadot-sdk/issues/575#issuecomment-1806572230 After systematic chunks recovery is merged, collators will no longer do any reed-solomon encoding/decoding, which has proven to be a great CPU consumer. Signed-off-by: alindima <[email protected]>
-
- Nov 13, 2023
-
-
Javyer authored
Moved the review event of review-bot to only be triggered in approvals. Because we only update the required reviews when someone approves, this will stop the bot from immediately requesting a new review when someone comments or request changes as they should have been already notified in the first batch.
-
Assem authored
-
Lulu authored
-
Adrian Catangiu authored
## Motivation `pallet-xcm` is the main user-facing interface for XCM functionality, including assets manipulation functions like `teleportAssets()` and `reserve_transfer_assets()` calls. While `teleportAsset()` works both ways, `reserve_transfer_assets()` works only for sending reserve-based assets to a remote destination and beneficiary when the reserve is the _local chain_. ## Solution This PR enhances `pallet_xcm::(limited_)reserve_withdraw_assets` to support transfers when reserves are other chains. This will allow complete, **bi-directional** reserve-based asset transfers user stories using `pallet-xcm`. Enables following scenarios: - transferring assets with local reserve (was previously supported iff asset used as fee also had local reserve - now it works in all cases), - transferring assets with reserve on destination, - transferring assets with reserve on remote/third-party chain (iff assets and fees have same remote reserve), - transferring assets with reserve different than the reserve of the asset to be used as fees - meaning can be used to transfer random asset with local/dest reserve while using DOT for fees on all involved chains, even if DOT local/dest reserve doesn't match asset reserve, - transferring assets with any type of local/dest reserve while using fees which can be teleported between involved chains. All of the above is done by pallet inner logic without the user having to specify which scenario/reserves/teleports/etc. The correct scenario and corresponding XCM programs are identified, and respectively, built automatically based on runtime configuration of trusted teleporters and trusted reserves. #### Current limitations: - while `fees` and "non-fee" `assets` CAN have different reserves (or fees CAN be teleported), the remaining "non-fee" `assets` CANNOT, among themselves, have different reserve locations (this is also implicitly enforced by `MAX_ASSETS_FOR_TRANSFER=2`, but this can be safely increased in the future). - `fees` and "non-fee" `assets` CANNOT have **different remote** reserves (this could also be supported in the future, but adds even more complexity while possibly not being worth it - we'll see what the future holds). Fixes https://github.com/paritytech/polkadot-sdk/issues/1584 Fixes https://github.com/paritytech/polkadot-sdk/issues/2055 --------- Co-authored-by: Francisco Aguirre <[email protected]> Co-authored-by: Branislav Kontur <[email protected]>
-
gupnik authored
-
gupnik authored
Fixes https://github.com/paritytech/polkadot-sdk/issues/1725 This PR adds the following changes: 1. An attribute `pallet::feeless_if` that can be optionally attached to a call like so: ```rust #[pallet::feeless_if(|_origin: &OriginFor<T>, something: &u32| -> bool { *something == 0 })] pub fn do_something(origin: OriginFor<T>, something: u32) -> DispatchResult { .... } ``` The closure passed accepts references to arguments as specified in the call fn. It returns a boolean that denotes the conditions required for this call to be "feeless". 2. A signed extension `SkipCheckIfFeeless<T: SignedExtension>` that wraps a transaction payment processor such as `pallet_transaction_payment::ChargeTransactionPayment`. It checks for all calls annotated with `pallet::feeless_if` to see if the conditions are met. If so, the wrapped signed extension is not called, essentially making the call feeless. In order to use this, you can simply replace your existing signed extension that manages transaction payment like so: ```diff - pallet_transaction_payment::ChargeTransactionPayment<Runtime>, + pallet_skip_feeless_payment::SkipCheckIfFeeless< + Runtime, + pallet_transaction_payment::ChargeTransactionPayment<Runtime>, + >, ``` ### Todo - [x] Tests - [x] Docs - [x] Prdoc --------- Co-authored-by: Nikhil Gupta <> Co-authored-by: Oliver Tale-Yazdi <[email protected]> Co-authored-by: Francisco Aguirre <[email protected]> Co-authored-by: Liam Aharon <[email protected]>
-
Bastian Köcher authored
Remove the `GRANDPA_AUTHORITIES_KEY` key and its usage. Apparently this was used in the early days to communicate the grandpa authorities to the node. However, we have now a runtime api that does this for us. So, this pull request is moving from the custom managed storage item to a FRAME managed storage item. This pr also includes a migration for doing the switch on a running chain. --------- Co-authored-by: Davide Galassi <[email protected]>
-
Bastian Köcher authored
Optimizes the `rerun-if-changed` logic by ignoring `dev-dependencies` and also not outputting paths. Because outputting paths could lead to include unwanted crates in the rerun checks.
-
Marcin S. authored
Co-authored-by: Bastian Köcher <[email protected]>
-
Dmitry Markin authored
All `ChainSync` actions that `SyncingEngine` should perform are unified under one `ChainSyncAction`. Processing of these actions put into a single place after `select!` in `SyncingEngine::run` instead of multiple places where calling `ChainSync` methods.
-
- Nov 11, 2023
-
-
Daniel Olano authored
A utility function I consider quite useful to declare string literals that are backed by an array. --------- Co-authored-by: Bastian Köcher <[email protected]> Co-authored-by: Davide Galassi <[email protected]>
-
- Nov 10, 2023
-
-
PG Herveou authored
We are introducing a new set of `XcmController` traits (final name yet to be determined). These traits are implemented by `pallet-xcm` and allows other pallets, such as `pallet_contracts`, to rely on these traits instead of tight coupling them to `pallet-xcm`. Using only the existing Xcm traits would mean duplicating the logic from `pallet-xcm` in these other pallets, which we aim to avoid. Our objective is to ensure that when these APIs are called from `pallet-contracts`, they produce the exact same outcomes as if called directly from `pallet-xcm`. The other benefits is that we can also expose return values to `pallet-contracts` instead of just calling `pallet-xcm` dispatchable and getting a `DispatchResult` back. See traits integration in this PR https://github.com/paritytech/polkadot-sdk/pull/1248, where the traits are used as follow to define and implement `pallet-contracts` Config. ```rs // Contracts config: pub trait Config: frame_system::Config { // ... /// A type that exposes XCM APIs, allowing contracts to interact with other parachains, and /// execute XCM programs. type Xcm: xcm_executor::traits::Controller< OriginFor<Self>, <Self as frame_system::Config>::RuntimeCall, BlockNumberFor<Self>, >; } // implementation impl pallet_contracts::Config for Runtime { // ... type Xcm = pallet_xcm::Pallet<Self>; } ``` --------- Co-authored-by: Alexander Theißen <[email protected]> Co-authored-by: command-bot <>
-
Liam Aharon authored
As suggested by @ggwpez (https://github.com/paritytech/polkadot-sdk/pull/2142#discussion_r1388145872), remove the `VersionChecked` prefix from version checked migrations (but leave `VersionUnchecked` prefixes) --------- Co-authored-by: command-bot <>
-
Vincent Geddes authored
These changes are required so that the bridgehub system runtimes can more easily be configured with multiple message processors Example usage: ```rust use frame_support::traits::QueuePausedQuery; impl pallet_message_queue::Config for Runtime { type QueuePausedQuery = (A, B, C) }
-
PG Herveou authored
Small PR that introduce a new crate that will host RISC-V & wasm fixtures for testing pallet-contracts
-
- Nov 09, 2023
-
-
Lulu authored
The staging- rename commit was missing from the last PR for some reason.
-
Bastian Köcher authored
When warp syncing we import the target block with all its state. However, we didn't store the `LAST_PRUNED` block which would then lead to `pruning` to forget about the imported block after a restart of the node. We just set `LAST_PRUNED` to the parent block of the warp sync target block to fix this issue.
-
Lulu authored
-
Lulu authored
-
Oliver Tale-Yazdi authored
Missing descriptions (47): - [x] `cumulus/client/collator/Cargo.toml` - [x] `cumulus/client/relay-chain-inprocess-interface/Cargo.toml` - [x] `cumulus/client/cli/Cargo.toml` - [x] `cumulus/client/service/Cargo.toml` - [x] `cumulus/client/relay-chain-rpc-interface/Cargo.toml` - [x] `cumulus/client/relay-chain-interface/Cargo.toml` - [x] `cumulus/client/relay-chain-minimal-node/Cargo.toml` - [x] `cumulus/parachains/pallets/parachain-info/Cargo.toml` - [x] `cumulus/parachains/pallets/ping/Cargo.toml` - [x] `cumulus/primitives/utility/Cargo.toml` - [x] `cumulus/primitives/aura/Cargo.toml` - [x] `cumulus/primitives/core/Cargo.toml` - [x] `cumulus/primitives/parachain-inherent/Cargo.toml` - [x] `cumulus/test/relay-sproof-builder/Cargo.toml` - [x] `cumulus/pallets/xcmp-queue/Cargo.toml` - [x] `cumulus/pallets/dmp-queue/Cargo.toml` - [x] `cumulus/pallets/xcm/Cargo.toml` - [x] `polkadot/erasure-coding/Cargo.toml` - [x] `polkadot/statement-table/Cargo.toml` - [x] `polkadot/primitives/Cargo.toml` - [x] `polkadot/rpc/Cargo.toml` - [x] `polkadot/node/service/Cargo.toml` - [x] `polkadot/node/core/parachains-inherent/Cargo.toml` - [x] `polkadot/node/core/approval-voting/Cargo.toml` - [x] `polkadot/node/core/dispute-coordinator/Cargo.toml` - [x] `polkadot/node/core/av-store/Cargo.toml` - [x] `polkadot/node/core/chain-api/Cargo.toml` - [x] `polkadot/node/core/prospective-parachains/Cargo.toml` - [x] `polkadot/node/core/backing/Cargo.toml` - [x] `polkadot/node/core/provisioner/Cargo.toml` - [x] `polkadot/node/core/runtime-api/Cargo.toml` - [x] `polkadot/node/core/bitfield-signing/Cargo.toml` - [x] `polkadot/node/network/dispute-distribution/Cargo.toml` - [x] `polkadot/node/network/bridge/Cargo.toml` - [x] `polkadot/node/network/collator-protocol/Cargo.toml` - [x] `polkadot/node/network/approval-distribution/Cargo.toml` - [x] `polkadot/node/network/availability-distribution/Cargo.toml` - [x] `polkadot/node/network/bitfield-distribution/Cargo.toml` - [x] `polkadot/node/network/gossip-support/Cargo.toml` - [x] `polkadot/node/network/availability-recovery/Cargo.toml` - [x] `polkadot/node/collation-generation/Cargo.toml` - [x] `polkadot/node/overseer/Cargo.toml` - [x] `polkadot/runtime/parachains/Cargo.toml` - [x] `polkadot/runtime/common/slot_range_helper/Cargo.toml` - [x] `polkadot/runtime/metrics/Cargo.toml` - [x] `polkadot/xcm/pallet-xcm-benchmarks/Cargo.toml` - [x] `polkadot/utils/generate-bags/Cargo.toml` - [x] `substrate/bin/minimal/runtime/Cargo.toml` --------- Signed-off-by: Oliver Tale-Yazdi <[email protected]> Signed-off-by: alindima <[email protected]> Co-authored-by: ordian <[email protected]> Co-authored-by: Tsvetomir Dimitrov <[email protected]> Co-authored-by: Marcin S <[email protected]> Co-authored-by: alindima <[email protected]> Co-authored-by: Sebastian Kunert <[email protected]> Co-authored-by: Dmitry Markin <[email protected]> Co-authored-by: joe petrowski <[email protected]> Co-authored-by: Liam Aharon <[email protected]>
-
Keith Yeung authored
This was discovered during a debugging session, and it only served to mask the underlying error, which was not great.
-
- Nov 08, 2023
-
-
RadiumBlock authored
# Description We would like to add our bootnodes to the following parachains: Westend: Westmint, Bridgehub Kusama: Statemine, Bridgehub Polkadot: Statemint, Bridgehub, Collectives Thank you. --------- Co-authored-by: Oliver Tale-Yazdi <[email protected]>
-
Bastian Köcher authored
One for local networks with `fast-runtime` feature activated (1 minute sessions) and one without the feature activated that will be the default that runs with 1 hour long sessions.
-