- Apr 17, 2024
-
-
Sergej Sakac authored
This PR introduces changes enabling the transfer of coretime regions via XCM. TL;DR: There are two primary issues that are resolved in this PR: 1. The `mint` and `burn` functions were not implemented for coretime regions. These operations are essential for moving assets to and from the XCM holding register. 2. The transfer of non-fungible assets through XCM was previously disallowed. This was due to incorrectly benchmarking non-fungible asset transfers via XCM, which led to assigning it a weight of `Weight::Max`, effectively preventing its execution. ### `mint_into` and `burn` implementation This PR addresses the issue with cross-chain transferring regions back to the Coretime chain. Remote reserve transfers are performed by withdrawing and depositing the asset to and from the holding registry. This requires the asset to support burning and minting functionality. This PR adds burning and minting; however, they work a bit differently than usual so that the associated region record is not lost when burning. Instead of removing all the data, burning will set the owner of the region to `None`, and when minting it back, it will set it to an actual value. So, when cross-chain transferring, withdrawing into the registry will remove the region from its original owner, and when depositing it from the registry, it will set its owner to another account This was originally implemented in this PR: #3455, however we decided to move all of it to this single PR (https://github.com/paritytech/polkadot-sdk/pull/3455#discussion_r1547324892) ### Fixes made in this PR - Update the `XcmReserveTransferFilter` on coretime chain since it is meant as a reserve chain for coretime regions. - Update the XCM benchmark to use `AssetTransactor` instead of assuming `pallet-balances` for fungible transfers. - Update the XCM benchmark to properly measure weight consumption for nonfungible reserve asset transfers. ATM reserve transfers via the extrinsic do not work since the weight for it is set to `Weight::max()`. Closes: https://github.com/paritytech/polkadot-sdk/issues/865 --------- Co-authored-by:
Branislav Kontur <[email protected]> Co-authored-by:
Francisco Aguirre <[email protected]> Co-authored-by:
Dónal Murray <[email protected]>
-
- Apr 16, 2024
-
-
Muharem Ismailov authored
Introduce types to define 1:1 balance conversion for different relative asset ids/locations of native asset. Examples: native asset on Asset Hub presented as `VersionedLocatableAsset` type in the context of Relay Chain is ``` { `location`: (0, Parachain(1000)), `asset_id`: (1, Here), } ``` and it's balance should be converted 1:1 by implementations of `ConversionToAssetBalance` trait. --------- Co-authored-by:
Branislav Kontur <[email protected]>
-
- Apr 14, 2024
-
-
Bastian Köcher authored
Co-authored-by:
Liam Aharon <[email protected]>
-
Jonathan Udd authored
Verified by running a node using `--reserved-only` and `--reserved-nodes`.
-
- Apr 12, 2024
-
-
Branislav Kontur authored
This PR mainly removes `xcm::v3` stuff from `assets-common` to make it more generic and facilitate the transition to newer XCM versions. Some of the implementations here used hard-coded `xcm::v3::Location`, but now it's up to the runtime to configure according to its needs. Additional/consequent changes: - `penpal` runtime uses now `xcm::latest::Location` for `pallet_assets` as `AssetId`, because we don't care about migrations here - it pretty much simplify xcm-emulator integration tests, where we don't need now a lots of boilerplate conversions: ``` v3::Location::try_from(...).expect("conversion works")` ``` - xcm-emulator tests - split macro `impl_assets_helpers_for_parachain` to the `impl_assets_helpers_for_parachain` and `impl_foreign_assets_helpers_for_parachain` (avoids using hard-coded `xcm::v3::Location`)
-
Adrian Catangiu authored
# Description Add `transfer_assets_using()` for transferring assets from local chain to destination chain using explicit XCM transfer types such as: - `TransferType::LocalReserve`: transfer assets to sovereign account of destination chain and forward a notification XCM to `dest` to mint and deposit reserve-based assets to `beneficiary`. - `TransferType::DestinationReserve`: burn local assets and forward a notification to `dest` chain to withdraw the reserve assets from this chain's sovereign account and deposit them to `beneficiary`. - `TransferType::RemoteReserve(reserve)`: burn local assets, forward XCM to `reserve` chain to move reserves from this chain's SA to `dest` chain's SA, and forward another XCM to `dest` to mint and deposit reserve-based assets to `beneficiary`. Typically the remote `reserve` is Asset Hub. - `TransferType::Teleport`: burn local assets and forward XCM to `dest` chain to mint/teleport assets and deposit them to `beneficiary`. By default, an asset's reserve is its origin chain. But sometimes we may want to explicitly use another chain as reserve (as long as allowed by runtime `IsReserve` filter). This is very helpful for transferring assets with multiple configured reserves (such as Asset Hub ForeignAssets), when the transfer strictly depends on the used reserve. E.g. For transferring Foreign Assets over a bridge, Asset Hub must be used as the reserve location. # Example usage scenarios ## Transfer bridged ethereum ERC20-tokenX between ecosystem parachains. ERC20-tokenX is registered on AssetHub as a ForeignAsset by the Polkadot<>Ethereum bridge (Snowbridge). Its asset_id is something like `(parents:2, (GlobalConsensus(Ethereum), Address(tokenX_contract)))`. Its _original_ reserve is Ethereum (only we can't use Ethereum as a reserve in local transfers); but, since tokenX is also registered on AssetHub as a ForeignAsset, we can use AssetHub as a reserve. With this PR we can transfer tokenX from ParaA to ParaB while using AssetHub as a reserve. ## Transfer AssetHub ForeignAssets between parachains AssetA created on ParaA but also registered as foreign asset on Asset Hub. Can use AssetHub as a reserve. And all of the above can be done while still controlling transfer type for `fees` so mixing assets in same transfer is supported. # Tests Added integration tests for showcasing: - transferring local (not bridged) assets from parachain over bridge using local Asset Hub reserve, - transferring foreign assets from parachain to Asset Hub, - transferring foreign assets from Asset Hub to parachain, - transferring foreign assets from parachain to parachain using local Asset Hub reserve. --------- Co-authored-by:
Branislav Kontur <[email protected]> Co-authored-by: command-bot <>
-
Andrei Sandu authored
Fixes https://github.com/paritytech/polkadot-sdk/issues/3576 Required by elastic scaling collators. Deprecates old API: `candidate_pending_availability`. TODO: - [x] PRDoc --------- Signed-off-by:
Andrei Sandu <[email protected]>
-
Svyatoslav Nikolsky authored
As requested in https://github.com/paritytech/parity-bridges-common/pull/2873#discussion_r1558974215
-
- Apr 11, 2024
-
-
Liam Aharon authored
Completes the removal of `try-runtime-cli` logic from `polkadot-sdk`.
-
s0me0ne-unkn0wn authored
This is phase 2 of async backing enablement for the system parachains on the production networks. ~~It should be merged after polkadot-fellows/runtimes#228 is enacted. After it is released,~~ all the system parachain collators should be upgraded, and then we can proceed with phase 3, which will enable async backing in the runtimes. UPDATE: Indeed, we don't need to wait for the runtime upgrade enactions. The lookahead collator handles the transition by itself, so we can upgrade ASAP. ## Scope of changes Here, we eliminate the dichotomy of having "generic Aura collators" for the production system parachains and "lookahead Aura collators" for the testnet system parachains. Now, all the collators are started as lookahead ones, preserving the logic of transferring from the shell node to Aura-enabled collators for the asset hubs. So, indeed, it simplifies the parachain service logic, which cannot but rejoice.
-
- Apr 10, 2024
-
-
Milos Kriz authored
Dear team, dear @NachoPal @joepetrowski @bkchr @ggwpez , This is a retry of #3957, after merging master as advised!, Many thanks! **_Milos_** --------- Signed-off-by:
Oliver Tale-Yazdi <[email protected]> Co-authored-by:
Oliver Tale-Yazdi <[email protected]>
-
Bulat Saifullin authored
The plain `people-kusama` and `coretime-kusama` chainspecs were uploaded at https://github.com/paritytech/polkadot-sdk/pull/3961. Only binaries with compatible runtime versions can run with plain chainspec. For example: One of the latest master builds fails: ``` docker run paritypr/polkadot-parachain-debug:master-216509db --chain coretime-kusama ... Error: Service(Client(Storage("wasm call error Other: Exported method GenesisBuilder_get_preset is not found")) ``` Master build from 5 days ago: ``` docker run paritypr/polkadot-parachain-debug:master-68cdb126 --chain coretime-kusama ... 2024-04-08 16:51:02 [Parachain]
🔨 Initializing Genesis block/state (state: 0xc418…889c, header-hash: 0x638c…d050) 2024-04-08 16:51:03 [Relaychain]🔨 Initializing Genesis block/state (state: 0xb000…ef6b, header-hash: 0xb0a8…dafe) 2024-04-08 16:51:03 [Relaychain]👴 Loading GRANDPA authority set from genesis on what appears to be first startup. 2024-04-08 16:51:03 [Relaychain]👶 Creating empty BABE epoch changes on what appears to be first startup. 2024-04-08 16:51:03 [Relaychain]🏷 Local node identity is: 12D3KooWQEp2uPow3FnngGmy9dYQ3qxY1GkmumS5MqBWEQscwTyy 2024-04-08 16:51:03 [Relaychain]📦 Highest known block at #0 ... ``` ## Changes: 1. Rename: ``` coretime-kusama.json -> coretime-kusama-genesis.json people-kusama.json -> people-kusama-genesis.json ``` 2. Generate raw chainspec: ``` docker run --rm -v $(pwd):/dir paritypr/polkadot-parachain-debug:master-68cdb126 build-spec --raw --chain /dir/people-kusama-genesis.json > people-kusama.json docker run --rm -v $(pwd):/dir paritypr/polkadot-parachain-debug:master-68cdb126 build-spec --raw --chain /dir/coretime-kusama-genesis.json > coretime-kusama.json ``` ## Tests: New chainspec can run on the latest master build: ``` docker run -it --rm -v $(pwd):/dir paritypr/polkadot-parachain-debug:master-216509db --chain /dir/coretime-kusama.json ... 2024-04-09 16:44:39 [Relaychain]⚙ ️ Syncing, target=#22665488 (8 peers), best: #2371 (0x19f8…5f3a), finalized #2048 (0xede6…f879),⬇ 388.6kiB/s⬆ 87.0kiB/s 2024-04-09 16:44:39 [Parachain]💤 Idle (6 peers), best: #0 (0x638c…d050), finalized #0 (0x638c…d050),⬇ 6.3kiB/s⬆ 2.8kiB/s ``` Plain chainspec will fail: ``` docker run -it --rm -v $(pwd):/dir paritypr/polkadot-parachain-debug:master-216509db --chain /dir/coretime-kusama-genesis.json ... Error: Service(Client(Storage("wasm call error Other: Exported method GenesisBuilder_get_preset is not found"))) ``` -
Egor_P authored
This PR backports `spec_version`, `node_version` bumps and reordering of the prdocs from the 1.10.0 release branch
-
- Apr 09, 2024
-
-
Sebastian Kunert authored
Cumulus test-parachain node and test runtime were still using relay chain consensus and 12s blocktimes. With async backing around the corner on the major chains we should switch our tests too. Also needed to nicely test the changes coming to collators in #3168. ### Changes Overview - Followed the [migration guide](https://wiki.polkadot.network/docs/maintain-guides-async-backing) for async backing for the cumulus-test-runtime - Adjusted the cumulus-test-service to use the correct import-queue, lookahead collator etc. - The block validation function now uses the Aura Ext Executor so that the seal of the block is validated - Previous point requires that we seal block before calling into `validate_block`, I introduced a helper function for that - Test client adjusted to provide a slot to the relay chain proof and the aura pre-digest
-
Adrian Catangiu authored
We are exploring [allowing this for Kusama](https://github.com/polkadot-fellows/runtimes/pull/261) as well, disallowing on test chains seems unnecessarily limiting.
-
Facundo Farall authored
# Description - What does this PR do? 1. Upgrades `trie-db`'s version to the latest release. This release includes, among others, an implementation of `DoubleEndedIterator` for the `TrieDB` struct, allowing to iterate both backwards and forwards within the leaves of a trie. 2. Upgrades `trie-bench` to `0.39.0` for compatibility. 3. Upgrades `criterion` to `0.5.1` for compatibility. - Why are these changes needed? Besides keeping up with the upgrade of `trie-db`, this specifically adds the functionality of iterating back on the leafs of a trie, with `sp-trie`. In a project we're currently working on, this comes very handy to verify a Merkle proof that is the response to a challenge. The challenge is a random hash that (most likely) will not be an existing leaf in the trie. So the challenged user, has to provide a Merkle proof of the previous and next existing leafs in the trie, that surround the random challenged hash. Without having DoubleEnded iterators, we're forced to iterate until we find the first existing leaf, like so: ```rust // ************* VERIFIER (RUNTIME) ************* // Verify proof. This generates a partial trie based on the proof and // checks that the root hash matches the `expected_root`. let (memdb, root) = proof.to_memory_db(Some(&root)).unwrap(); let trie = TrieDBBuilder::<LayoutV1<RefHasher>>::new(&memdb, &root).build(); // Print all leaf node keys and values. println!("\nPrinting leaf nodes of partial tree..."); for key in trie.key_iter().unwrap() { if key.is_ok() { println!("Leaf node key: {:?}", key.clone().unwrap()); let val = trie.get(&key.unwrap()); if val.is_ok() { println!("Leaf node value: {:?}", val.unwrap()); } else { println!("Leaf node value: None"); } } } println!("RECONSTRUCTED TRIE {:#?}", trie); // Create an iterator over the leaf nodes. let mut iter = trie.iter().unwrap(); // First element with a value should be the previous existing leaf to the challenged hash. let mut prev_key = None; for element in &mut iter { if element.is_ok() { let (key, _) = element.unwrap(); prev_key = Some(key); break; } } assert!(prev_key.is_some()); // Since hashes are `Vec<u8>` ordered in big-endian, we can compare them directly. assert!(prev_key.unwrap() <= challenge_hash.to_vec()); // The next element should exist (meaning there is no other existing leaf between the // previous and next leaf) and it should be greater than the challenged hash. let next_key = iter.next().unwrap().unwrap().0; assert!(next_key >= challenge_hash.to_vec()); ``` With DoubleEnded iterators, we can avoid that, like this: ```rust // ************* VERIFIER (RUNTIME) ************* // Verify proof. This generates a partial trie based on the proof and // checks that the root hash matches the `expected_root`. let (memdb, root) = proof.to_memory_db(Some(&root)).unwrap(); let trie = TrieDBBuilder::<LayoutV1<RefHasher>>::new(&memdb, &root).build(); // Print all leaf node keys and values. println!("\nPrinting leaf nodes of partial tree..."); for key in trie.key_iter().unwrap() { if key.is_ok() { println!("Leaf node key: {:?}", key.clone().unwrap()); let val = trie.get(&key.unwrap()); if val.is_ok() { println!("Leaf node value: {:?}", val.unwrap()); } else { println!("Leaf node value: None"); } } } // println!("RECONSTRUCTED TRIE {:#?}", trie); println!("\nChallenged key: {:?}", challenge_hash); // Create an iterator over the leaf nodes. let mut double_ended_iter = trie.into_double_ended_iter().unwrap(); // First element with a value should be the previous existing leaf to the challenged hash. double_ended_iter.seek(&challenge_hash.to_vec()).unwrap(); let next_key = double_ended_iter.next_back().unwrap().unwrap().0; let prev_key = double_ended_iter.next_back().unwrap().unwrap().0; // Since hashes are `Vec<u8>` ordered in big-endian, we can compare them directly. println!("Prev key: {:?}", prev_key); assert!(prev_key <= challenge_hash.to_vec()); println!("Next key: {:?}", next_key); assert!(next_key >= challenge_hash.to_vec()); ``` - How were these changes implemented and what do they affect? All that is needed for this functionality to be exposed is changing the version number of `trie-db` in all the `Cargo.toml`s applicable, and re-exporting some additional structs from `trie-db` in `sp-trie`. --------- Co-authored-by:
Bastian Köcher <[email protected]>
-
Bastian Köcher authored
Also while doing this, move slot duration fetching into the AURA code.
-
Branislav Kontur authored
Co-authored-by:
Bastian Köcher <[email protected]>
-
- Apr 08, 2024
-
-
Aaro Altonen authored
[litep2p](https://github.com/altonen/litep2p) is a libp2p-compatible P2P networking library. It supports all of the features of `rust-libp2p` that are currently being utilized by Polkadot SDK. Compared to `rust-libp2p`, `litep2p` has a quite different architecture which is why the new `litep2p` network backend is only able to use a little of the existing code in `sc-network`. The design has been mainly influenced by how we'd wish to structure our networking-related code in Polkadot SDK: independent higher-levels protocols directly communicating with the network over links that support bidirectional backpressure. A good example would be `NotificationHandle`/`RequestResponseHandle` abstractions which allow, e.g., `SyncingEngine` to directly communicate with peers to announce/request blocks. I've tried running `polkadot --network-backend litep2p` with a few different peer configurations and there is a noticeable reduction in networking CPU usage. For high load (`--out-peers 200`), networking CPU usage goes down from ~110% to ~30% (80 pp) and for normal load (`--out-peers 40`), the usage goes down from ~55% to ~18% (37 pp). These should not be taken as final numbers because: a) there are still some low-hanging optimization fruits, such as enabling [receive window auto-tuning](https://github.com/libp2p/rust-yamux/pull/176 ), integrating `Peerset` more closely with `litep2p` or improving memory usage of the WebSocket transport b) fixing bugs/instabilities that incorrectly cause `litep2p` to do less work will increase the networking CPU usage c) verification in a more diverse set of tests/conditions is needed Nevertheless, these numbers should give an early estimate for CPU usage of the new networking backend. This PR consists of three separate changes: * introduce a generic `PeerId` (wrapper around `Multihash`) so that we don't have use `NetworkService::PeerId` in every part of the code that uses a `PeerId` * introduce `NetworkBackend` trait, implement it for the libp2p network stack and make Polkadot SDK generic over `NetworkBackend` * implement `NetworkBackend` for litep2p The new library should be considered experimental which is why `rust-libp2p` will remain as the default option for the time being. This PR currently depends on the master branch of `litep2p` but I'll cut a new release for the library once all review comments have been addresses. --------- Signed-off-by:
Alexandru Vasile <[email protected]> Co-authored-by:
Dmitry Markin <[email protected]> Co-authored-by:
Alexandru Vasile <[email protected]> Co-authored-by:
Alexandru Vasile <[email protected]>
-
Oliver Tale-Yazdi authored
This MR contains two major changes and some maintenance cleanup. ## 1. Free Standing Pallet Benchmark Runner Closes https://github.com/paritytech/polkadot-sdk/issues/3045, depends on your runtime exposing the `GenesisBuilderApi` (like https://github.com/paritytech/polkadot-sdk/pull/1492). Introduces a new binary crate: `frame-omni-bencher`. It allows to directly benchmark a WASM blob - without needing a node or chain spec. This makes it much easier to generate pallet weights and should allow us to remove bloaty code from the node. It should work for all FRAME runtimes that dont use 3rd party host calls or non `BlakeTwo256` block hashing (basically all polkadot parachains should work). It is 100% backwards compatible with the old CLI args, when the `v1` compatibility command is used. This is done to allow for forwards compatible addition of new commands. ### Example (full example in the Rust docs) Installing the CLI: ```sh cargo install --locked --path substrate/utils/frame/omni-bencher frame-omni-bencher --help ``` Building the Westend runtime: ```sh cargo build -p westend-runtime --release --features runtime-benchmarks ``` Benchmarking the runtime: ```sh frame-omni-bencher v1 benchmark pallet --runtime target/release/wbuild/westend-runtime/westend_runtime.compact.compressed.wasm --all ``` ## 2. Building the Benchmark Genesis State in the Runtime Closes https://github.com/paritytech/polkadot-sdk/issues/2664 This adds `--runtime` and `--genesis-builder=none|runtime|spec` arguments to the `benchmark pallet` command to make it possible to generate the genesis storage by the runtime. This can be used with both the node and the freestanding benchmark runners. It utilizes the new `GenesisBuilder` RA and depends on having https://github.com/paritytech/polkadot-sdk/pull/3412 deployed. ## 3. Simpler args for `PalletCmd::run` You can do three things here to integrate the changes into your node: - nothing: old code keeps working as before but emits a deprecated warning - delete: remove the pallet benchmarking code from your node and use the omni-bencher instead - patch: apply the patch below and keep using as currently. This emits a deprecated warning at runtime, since it uses the old way to generate a genesis state, but is the smallest change. ```patch runner.sync_run(|config| cmd - .run::<HashingFor<Block>, ReclaimHostFunctions>(config) + .run_with_spec::<HashingFor<Block>, ReclaimHostFunctions>(Some(config.chain_spec)) ) ``` ## 4. Maintenance Change - `pallet-nis` get a `BenchmarkSetup` config item to prepare its counterparty asset. - Add percent progress print when running benchmarks. - Dont immediately exit on benchmark error but try to run as many as possible and print errors last. --------- Signed-off-by:
Oliver Tale-Yazdi <[email protected]> Co-authored-by:
Liam Aharon <[email protected]>
-
Tsvetomir Dimitrov authored
With Coretime enabled we can no longer assume there is a static 1:1 mapping between core index and para id. This mapping should be obtained from the scheduler/claimqueue on block by block basis. This PR modifies `para_id()` (from `CoreState`) to return the scheduled `ParaId` for occupied cores and removes its usages in the code. Closes https://github.com/paritytech/polkadot-sdk/issues/3948 --------- Co-authored-by:
Andrei Sandu <[email protected]>
-
HongKuang authored
Signed-off-by:
hongkuang <[email protected]>
-
- Apr 05, 2024
-
-
Sergej Sakac authored
Defines a runtime api for `pallet-broker` for getting the current price of a core if there is an ongoing sale. Closes: #3413 --------- Co-authored-by:
Bastian Köcher <[email protected]>
-
Andrei Sandu authored
Signed-off-by:
Andrei Sandu <[email protected]>
-
- Apr 04, 2024
-
-
Kutsal Kaan Bilgin authored
## Verify Coretime Westend: ``` polkadot-parachain --chain=coretime-westend --tmp --relay-chain-rpc-url wss://rpc.ibp.network/westend --reserved-only --reserved-nodes /dns/boot-node.helikon.io/tcp/9420/p2p/12D3KooWFBPartM873MNm1AmVK3etUz34cAE9A9rwPztPno2epQ3 polkadot-parachain --chain=coretime-westend --tmp --relay-chain-rpc-url wss://rpc.ibp.network/westend --reserved-only --reserved-nodes /dns/boot-node.helikon.io/tcp/9422/wss/p2p/12D3KooWFBPartM873MNm1AmVK3etUz34cAE9A9rwPztPno2epQ3 ``` People Westend: ``` polkadot-parachain --chain=/path/to/people-westend.json --tmp --relay-chain-rpc-url wss://rpc.ibp.network/westend --reserved-only --reserved-nodes /dns/boot-node.helikon.io/tcp/9520/p2p/12D3KooWHhZk21Wzvsd3Un1Cp63diXqr6idbG1MEiUWaitUZuX4c polkadot-parachain --chain=/path/to/people-westend.json --tmp --relay-chain-rpc-url wss://rpc.ibp.network/westend --reserved-only --reserved-nodes /dns/boot-node.helikon.io/tcp/9522/wss/p2p/12D3KooWHhZk21Wzvsd3Un1Cp63diXqr6idbG1MEiUWaitUZuX4c ``` Thanks.
-
Michal Kucharczyk authored
The runtime now can provide a number of predefined presets of `RuntimeGenesisConfig` struct. This presets are intended to be used in different deployments, e.g.: `local`, `staging`, etc, and should be included into the corresponding chain-specs. Having `GenesisConfig` presets in runtime allows to fully decouple node from runtime types (the problem is described in #1984). **Summary of changes:** - The `GenesisBuilder` API was adjusted to enable this functionality (and provide better naming - #150): ```rust fn preset_names() -> Vec<PresetId>; fn get_preset(id: Option<PresetId>) -> Option<serde_json::Value>; //`None` means default fn build_state(value: serde_json::Value); pub struct PresetId(Vec<u8>); ``` - **Breaking change**: Old `create_default_config` method was removed, `build_config` was renamed to `build_state`. As a consequence a node won't be able to interact with genesis config for older runtimes. The cleanup was made for sake of API simplicity. Also IMO maintaining compatibility with old API is not so crucial. - Reference implementation was provided for `substrate-test-runtime` and `rococo` runtimes. For rococo new [`genesis_configs_presets`](https://github.com/paritytech/polkadot-sdk/blob/3b41d66b97c5ff0ec4a1989da5ffd8b9f3f588e3/polkadot/runtime/rococo/src/genesis_config_presets.rs#L530) module was added and is used in `GenesisBuilder` [_presets-related_](https://github.com/paritytech/polkadot-sdk/blob/3b41d66b97c5ff0ec4a1989da5ffd8b9f3f588e3/polkadot/runtime/rococo/src/lib.rs#L2462-L2485) methods. - The `chain-spec-builder` util was also improved and allows to ([_doc_](https://github.com/paritytech/polkadot-sdk/blob/3b41d66b97c5ff0ec4a1989da5ffd8b9f3f588e3/substrate/bin/utils/chain-spec-builder/src/lib.rs#L19)): - list presets provided by given runtime (`list-presets`), - display preset or default config provided by the runtime (`display-preset`), - build chain-spec using named preset (`create ... named-preset`), - The `ChainSpecBuilder` is extended with [`with_genesis_config_preset_name`](https://github.com/paritytech/polkadot-sdk/blob/3b41d66b97c5ff0ec4a1989da5ffd8b9f3f588e3/substrate/client/chain-spec/src/chain_spec.rs#L447) method which allows to build chain-spec using named preset provided by the runtime. Sample usage on the node side [here](https://github.com/paritytech/polkadot-sdk/blob/2caffaae803e08a3d5b46c860e8016da023ff4ce/polkadot/node/service/src/chain_spec.rs#L404 ). Implementation of #1984. fixes: #150 part of: #25 --------- Co-authored-by:
Sebastian Kunert <[email protected]> Co-authored-by:
Kian Paimani <[email protected]> Co-authored-by:
Oliver Tale-Yazdi <[email protected]>
-
Branislav Kontur authored
## Running `./polkadot-parachain --chain coretime-kusama` works now: **Parachain genesis state and header** match expected ones from https://gist.github.com/bkontur/f74fc00fd726d09bc7f0f3a9f51ec113?permalink_comment_id=5009857#gistcomment-5009857 ``` 2024-04-03 12:03:58 [Parachain]
🔨 Initializing Genesis block/state (state: 0xc418…889c, header-hash: 0x638c…d050) ... 2024-04-03 12:04:04 [Parachain]💤 Idle (0 peers), best: #0 (0x638c…d050), finalized #0 (0x638c…d050) ``` **Relaychain genesis state and header** match expected ones: https://polkadot.js.org/apps/?rpc=wss%3A%2F%2Fkusama-rpc.polkadot.io#/explorer/query/0 ``` 2024-04-03 12:03:59 [Relaychain]🔨 Initializing Genesis block/state (state: 0xb000…ef6b, header-hash: 0xb0a8…dafe) ``` **Full logs:** ``` bparity@bkontur-ThinkPad-P14s-Gen-2i:~/parity/polkadot-sdk$ ./target/debug/polkadot-parachain --chain coretime-kusama 2024-04-03 12:03:52 Polkadot parachain 2024-04-03 12:03:52✌ ️ version 4.0.0-665e3654 2024-04-03 12:03:52❤ ️ by Parity Technologies <[email protected]>, 2017-2024 2024-04-03 12:03:52📋 Chain specification: Kusama Coretime 2024-04-03 12:03:52🏷 Node name: subsequent-quicksand-2382 2024-04-03 12:03:52👤 Role: FULL 2024-04-03 12:03:52💾 Database: RocksDb at /home/bparity/.local/share/polkadot-parachain/chains/coretime-kusama/db/full 2024-04-03 12:03:54 Parachain id: Id(1005) 2024-04-03 12:03:54 Parachain Account: 5Ec4AhPakEiNWFbAd26nRrREnaGQZo3uukPDC5xLr6314Dwg 2024-04-03 12:03:54 Is collating: no 2024-04-03 12:03:58 [Parachain]🔨 Initializing Genesis block/state (state: 0xc418…889c, header-hash: 0x638c…d050) 2024-04-03 12:03:59 [Relaychain]🔨 Initializing Genesis block/state (state: 0xb000…ef6b, header-hash: 0xb0a8…dafe) 2024-04-03 12:03:59 [Relaychain]👴 Loading GRANDPA authority set from genesis on what appears to be first startup. 2024-04-03 12:03:59 [Relaychain]👶 Creating empty BABE epoch changes on what appears to be first startup. 2024-04-03 12:03:59 [Relaychain]🏷 Local node identity is: 12D3KooWSfXNBZYimwSKBqfKf7F1X6adNQQD5HVQbdnvSyBFn8Wd 2024-04-03 12:03:59 [Relaychain]💻 Operating system: linux 2024-04-03 12:03:59 [Relaychain]💻 CPU architecture: x86_64 2024-04-03 12:03:59 [Relaychain]💻 Target environment: gnu 2024-04-03 12:03:59 [Relaychain]💻 CPU: 11th Gen Intel(R) Core(TM) i7-1185G7 @ 3.00GHz 2024-04-03 12:03:59 [Relaychain]💻 CPU cores: 4 2024-04-03 12:03:59 [Relaychain]💻 Memory: 31797MB 2024-04-03 12:03:59 [Relaychain]💻 Kernel: 5.15.0-101-generic 2024-04-03 12:03:59 [Relaychain]💻 Linux distribution: Ubuntu 20.04.6 LTS 2024-04-03 12:03:59 [Relaychain]💻 Virtual machine: no 2024-04-03 12:03:59 [Relaychain]📦 Highest known block at #0 2024-04-03 12:03:59 [Relaychain]〽 ️ Prometheus exporter started at 127.0.0.1:9616 2024-04-03 12:03:59 [Relaychain] Running JSON-RPC server: addr=127.0.0.1:9945, allowed origins=["http://localhost:*", "http://127.0.0.1:*", "https://localhost:*", "https://127.0.0.1:*", "https://polkadot.js.org"] 2024-04-03 12:03:59 [Relaychain]🏁 CPU score: 1.40 GiBs 2024-04-03 12:03:59 [Relaychain]🏁 Memory score: 15.42 GiBs 2024-04-03 12:03:59 [Relaychain]🏁 Disk score (seq. writes): 1.39 GiBs 2024-04-03 12:03:59 [Relaychain]🏁 Disk score (rand. writes): 690.56 MiBs 2024-04-03 12:03:59 [Parachain] Using default protocol ID "sup" because none is configured in the chain specs 2024-04-03 12:03:59 [Parachain]🏷 Local node identity is: 12D3KooWAAvNqXn8WPmvnEj36j7HsdbtpRpmWDPT9xtp4CuphvxW 2024-04-03 12:03:59 [Parachain]💻 Operating system: linux 2024-04-03 12:03:59 [Parachain]💻 CPU architecture: x86_64 2024-04-03 12:03:59 [Parachain]💻 Target environment: gnu 2024-04-03 12:03:59 [Parachain]💻 CPU: 11th Gen Intel(R) Core(TM) i7-1185G7 @ 3.00GHz 2024-04-03 12:03:59 [Parachain]💻 CPU cores: 4 2024-04-03 12:03:59 [Parachain]💻 Memory: 31797MB 2024-04-03 12:03:59 [Parachain]💻 Kernel: 5.15.0-101-generic 2024-04-03 12:03:59 [Parachain]💻 Linux distribution: Ubuntu 20.04.6 LTS 2024-04-03 12:03:59 [Parachain]💻 Virtual machine: no 2024-04-03 12:03:59 [Parachain]📦 Highest known block at #0 2024-04-03 12:03:59 [Parachain]〽 ️ Prometheus exporter started at 127.0.0.1:9615 2024-04-03 12:03:59 [Parachain] Running JSON-RPC server: addr=127.0.0.1:9944, allowed origins=["http://localhost:*", "http://127.0.0.1:*", "https://localhost:*", "https://127.0.0.1:*", "https://polkadot.js.org"] 2024-04-03 12:03:59 [Parachain]🏁 CPU score: 1.40 GiBs 2024-04-03 12:03:59 [Parachain]🏁 Memory score: 15.42 GiBs 2024-04-03 12:03:59 [Parachain]🏁 Disk score (seq. writes): 1.39 GiBs 2024-04-03 12:03:59 [Parachain]🏁 Disk score (rand. writes): 690.56 MiBs 2024-04-03 12:03:59 [Parachain] discovered: 12D3KooWSfXNBZYimwSKBqfKf7F1X6adNQQD5HVQbdnvSyBFn8Wd /ip4/192.168.1.100/tcp/30334/ws 2024-04-03 12:03:59 [Relaychain] discovered: 12D3KooWAAvNqXn8WPmvnEj36j7HsdbtpRpmWDPT9xtp4CuphvxW /ip4/192.168.1.100/tcp/30333/ws 2024-04-03 12:03:59 [Relaychain] discovered: 12D3KooWAAvNqXn8WPmvnEj36j7HsdbtpRpmWDPT9xtp4CuphvxW /ip4/172.18.0.1/tcp/30333/ws 2024-04-03 12:03:59 [Parachain] discovered: 12D3KooWSfXNBZYimwSKBqfKf7F1X6adNQQD5HVQbdnvSyBFn8Wd /ip4/172.17.0.1/tcp/30334/ws 2024-04-03 12:03:59 [Relaychain] discovered: 12D3KooWAAvNqXn8WPmvnEj36j7HsdbtpRpmWDPT9xtp4CuphvxW /ip4/172.17.0.1/tcp/30333/ws 2024-04-03 12:03:59 [Parachain] discovered: 12D3KooWSfXNBZYimwSKBqfKf7F1X6adNQQD5HVQbdnvSyBFn8Wd /ip4/172.18.0.1/tcp/30334/ws 2024-04-03 12:04:00 [Relaychain]🔍 Discovered new external address for our node: /ip4/178.41.176.246/tcp/30334/ws/p2p/12D3KooWSfXNBZYimwSKBqfKf7F1X6adNQQD5HVQbdnvSyBFn8Wd 2024-04-03 12:04:00 [Relaychain] Sending fatal alert BadCertificate 2024-04-03 12:04:00 [Relaychain] Sending fatal alert BadCertificate 2024-04-03 12:04:04 [Relaychain]⚙ ️ Syncing, target=#22575321 (7 peers), best: #738 (0x1803…bbef), finalized #512 (0xb9b6…7014),⬇ 328.5kiB/s⬆ 102.9kiB/s 2024-04-03 12:04:04 [Parachain]💤 Idle (0 peers), best: #0 (0x638c…d050), finalized #0 (0x638c…d050),⬇ 0⬆ 0 2024-04-03 12:04:09 [Relaychain]⚙ ️ Syncing 169.5 bps, target=#22575322 (8 peers), best: #1586 (0x405b…a8aa), finalized #1536 (0x55d1…fb04),⬇ 232.3kiB/s⬆ 55.9kiB/s 2024-04-03 12:04:09 [Parachain]💤 Idle (0 peers), best: #0 (0x638c…d050), finalized #0 (0x638c…d050),⬇ 0⬆ 0 2024-04-03 12:04:14 [Relaychain]⚙ ️ Syncing 168.0 bps, target=#22575323 (8 peers), best: #2426 (0x155f…d083), finalized #2048 (0xede6…f879),⬇ 235.8kiB/s⬆ 67.2kiB/s 2024-04-03 12:04:14 [Parachain]💤 Idle (0 peers), best: #0 (0x638c…d050), finalized #0 (0x638c…d050),⬇ 0⬆ 0 2024-04-03 12:04:19 [Relaychain]⚙ ️ Syncing 170.0 bps, target=#22575324 (8 peers), best: #3276 (0x94d8…097e), finalized #3072 (0x0e4c…f587),⬇ 129.0kiB/s⬆ 34.0kiB/s ... ``` ## Running `./polkadot-parachain --chain people-kusama` works now: **Parachain genesis state and header** match expected ones from https://gist.github.com/bkontur/f74fc00fd726d09bc7f0f3a9f51ec113?permalink_comment_id=5011798#gistcomment-5011798 ``` 2024-04-04 10:26:24 [Parachain]🔨 Initializing Genesis block/state (state: 0x023a…2733, header-hash: 0x07b8…2645) ... 2024-04-04 10:26:30 [Parachain]💤 Idle (0 peers), best: #0 (0x07b8…2645), finalized #0 (0x07b8…2645),⬇ 0⬆ 0 ``` **Relaychain genesis state and header** match expected ones: https://polkadot.js.org/apps/?rpc=wss%3A%2F%2Fkusama-rpc.polkadot.io#/explorer/query/0 ``` 2024-04-04 10:26:25 [Relaychain]🔨 Initializing Genesis block/state (state: 0xb000…ef6b, header-hash: 0xb0a8…dafe) ``` **Full logs:** ``` bparity@bkontur-ThinkPad-P14s-Gen-2i:~/parity/aaa/polkadot-sdk$ ./target/debug/polkadot-parachain --chain people-kusama 2024-04-04 10:26:18 Polkadot parachain 2024-04-04 10:26:18✌ ️ version 4.0.0-39274bb7 2024-04-04 10:26:18❤ ️ by Parity Technologies <[email protected]>, 2017-2024 2024-04-04 10:26:18📋 Chain specification: Kusama People 2024-04-04 10:26:18🏷 Node name: knotty-flight-5398 2024-04-04 10:26:18👤 Role: FULL 2024-04-04 10:26:18💾 Database: RocksDb at /home/bparity/.local/share/polkadot-parachain/chains/people-kusama/db/full 2024-04-04 10:26:21 Parachain id: Id(1004) 2024-04-04 10:26:21 Parachain Account: 5Ec4AhPaYcfBz8fMoPd4EfnAgwbzRS7np3APZUnnFo12qEYk 2024-04-04 10:26:21 Is collating: no 2024-04-04 10:26:24 [Parachain]🔨 Initializing Genesis block/state (state: 0x023a…2733, header-hash: 0x07b8…2645) 2024-04-04 10:26:25 [Relaychain]🔨 Initializing Genesis block/state (state: 0xb000…ef6b, header-hash: 0xb0a8…dafe) 2024-04-04 10:26:25 [Relaychain]👴 Loading GRANDPA authority set from genesis on what appears to be first startup. 2024-04-04 10:26:25 [Relaychain]👶 Creating empty BABE epoch changes on what appears to be first startup. 2024-04-04 10:26:25 [Relaychain]🏷 Local node identity is: 12D3KooWPoTVhnrFNzVYJPR42HE9rYjXhkKHFDL9ut5nafDqJHKB 2024-04-04 10:26:25 [Relaychain]💻 Operating system: linux 2024-04-04 10:26:25 [Relaychain]💻 CPU architecture: x86_64 2024-04-04 10:26:25 [Relaychain]💻 Target environment: gnu 2024-04-04 10:26:25 [Relaychain]💻 CPU: 11th Gen Intel(R) Core(TM) i7-1185G7 @ 3.00GHz 2024-04-04 10:26:25 [Relaychain]💻 CPU cores: 4 2024-04-04 10:26:25 [Relaychain]💻 Memory: 31797MB 2024-04-04 10:26:25 [Relaychain]💻 Kernel: 5.15.0-101-generic 2024-04-04 10:26:25 [Relaychain]💻 Linux distribution: Ubuntu 20.04.6 LTS 2024-04-04 10:26:25 [Relaychain]💻 Virtual machine: no 2024-04-04 10:26:25 [Relaychain]📦 Highest known block at #0 2024-04-04 10:26:25 [Relaychain]〽 ️ Prometheus exporter started at 127.0.0.1:9616 2024-04-04 10:26:25 [Relaychain] Running JSON-RPC server: addr=127.0.0.1:9945, allowed origins=["http://localhost:*", "http://127.0.0.1:*", "https://localhost:*", "https://127.0.0.1:*", "https://polkadot.js.org"] 2024-04-04 10:26:25 [Relaychain]🏁 CPU score: 1.18 GiBs 2024-04-04 10:26:25 [Relaychain]🏁 Memory score: 15.61 GiBs 2024-04-04 10:26:25 [Relaychain]🏁 Disk score (seq. writes): 1.49 GiBs 2024-04-04 10:26:25 [Relaychain]🏁 Disk score (rand. writes): 650.01 MiBs 2024-04-04 10:26:25 [Parachain] Using default protocol ID "sup" because none is configured in the chain specs 2024-04-04 10:26:25 [Parachain]🏷 Local node identity is: 12D3KooWS2WPQgtiZZYT6bLGjwGcJU7QVd5EeQvb4jHN3NVSWDdj 2024-04-04 10:26:25 [Parachain]💻 Operating system: linux 2024-04-04 10:26:25 [Parachain]💻 CPU architecture: x86_64 2024-04-04 10:26:25 [Parachain]💻 Target environment: gnu 2024-04-04 10:26:25 [Parachain]💻 CPU: 11th Gen Intel(R) Core(TM) i7-1185G7 @ 3.00GHz 2024-04-04 10:26:25 [Parachain]💻 CPU cores: 4 2024-04-04 10:26:25 [Parachain]💻 Memory: 31797MB 2024-04-04 10:26:25 [Parachain]💻 Kernel: 5.15.0-101-generic 2024-04-04 10:26:25 [Parachain]💻 Linux distribution: Ubuntu 20.04.6 LTS 2024-04-04 10:26:25 [Parachain]💻 Virtual machine: no 2024-04-04 10:26:25 [Parachain]📦 Highest known block at #0 2024-04-04 10:26:25 [Parachain]〽 ️ Prometheus exporter started at 127.0.0.1:9615 2024-04-04 10:26:25 [Parachain] Running JSON-RPC server: addr=127.0.0.1:9944, allowed origins=["http://localhost:*", "http://127.0.0.1:*", "https://localhost:*", "https://127.0.0.1:*", "https://polkadot.js.org"] 2024-04-04 10:26:25 [Parachain]🏁 CPU score: 1.18 GiBs 2024-04-04 10:26:25 [Parachain]🏁 Memory score: 15.61 GiBs 2024-04-04 10:26:25 [Parachain]🏁 Disk score (seq. writes): 1.49 GiBs 2024-04-04 10:26:25 [Parachain]🏁 Disk score (rand. writes): 650.01 MiBs 2024-04-04 10:26:25 [Parachain] discovered: 12D3KooWPoTVhnrFNzVYJPR42HE9rYjXhkKHFDL9ut5nafDqJHKB /ip4/172.17.0.1/tcp/30334/ws 2024-04-04 10:26:25 [Relaychain] discovered: 12D3KooWS2WPQgtiZZYT6bLGjwGcJU7QVd5EeQvb4jHN3NVSWDdj /ip4/172.18.0.1/tcp/30333/ws 2024-04-04 10:26:25 [Relaychain] discovered: 12D3KooWS2WPQgtiZZYT6bLGjwGcJU7QVd5EeQvb4jHN3NVSWDdj /ip4/192.168.1.100/tcp/30333/ws 2024-04-04 10:26:25 [Parachain] discovered: 12D3KooWPoTVhnrFNzVYJPR42HE9rYjXhkKHFDL9ut5nafDqJHKB /ip4/172.18.0.1/tcp/30334/ws 2024-04-04 10:26:25 [Relaychain] discovered: 12D3KooWS2WPQgtiZZYT6bLGjwGcJU7QVd5EeQvb4jHN3NVSWDdj /ip4/172.17.0.1/tcp/30333/ws 2024-04-04 10:26:25 [Parachain] discovered: 12D3KooWPoTVhnrFNzVYJPR42HE9rYjXhkKHFDL9ut5nafDqJHKB /ip4/192.168.1.100/tcp/30334/ws 2024-04-04 10:26:26 [Relaychain]🔍 Discovered new external address for our node: /ip4/178.41.176.246/tcp/30334/ws/p2p/12D3KooWPoTVhnrFNzVYJPR42HE9rYjXhkKHFDL9ut5nafDqJHKB 2024-04-04 10:26:27 [Relaychain] Sending fatal alert BadCertificate 2024-04-04 10:26:27 [Relaychain] Sending fatal alert BadCertificate 2024-04-04 10:26:30 [Relaychain]⚙ ️ Syncing, target=#22588722 (8 peers), best: #638 (0xa9cd…7c30), finalized #512 (0xb9b6…7014),⬇ 345.6kiB/s⬆ 108.7kiB/s 2024-04-04 10:26:30 [Parachain]💤 Idle (0 peers), best: #0 (0x07b8…2645), finalized #0 (0x07b8…2645),⬇ 0⬆ 0 2024-04-04 10:26:35 [Relaychain]⚙ ️ Syncing 174.4 bps, target=#22588722 (9 peers), best: #1510 (0xec0b…72f0), finalized #1024 (0x3f17…fd7f),⬇ 203.1kiB/s⬆ 45.0kiB/s 2024-04-04 10:26:35 [Parachain]💤 Idle (0 peers), best: #0 (0x07b8…2645), finalized #0 (0x07b8…2645),⬇ 0⬆ 0 2024-04-04 10:26:40 [Relaychain]⚙ ️ Syncing 168.9 bps, target=#22588723 (9 peers), best: #2355 (0xa68b…3a64), finalized #2048 (0xede6…f879),⬇ 201.6kiB/s⬆ 47.4kiB/s 2024-04-04 10:26:40 [Parachain]💤 Idle (0 peers), best: #0 (0x07b8…2645), finalized #0 (0x07b8…2645),⬇ 0⬆ 0 ``` ## TODO - [x] double check `cumulus/polkadot-parachain/chain-specs/coretime-kusama.json` (safeXcmVersion=3) see [comment](https://github.com/paritytech/polkadot-sdk/pull/3961#discussion_r1549473587 ) - [x] check if ~~`start_generic_aura_node`~~ or `start_generic_aura_lookahead_node` - [x] generate chain-spec for `people-kusama` --------- Co-authored-by:Dónal Murray <[email protected]>
-
Liam Aharon authored
Part of https://github.com/paritytech/polkadot-sdk/issues/226 Related https://github.com/paritytech/polkadot-sdk/issues/1833 - Deprecate `CurrencyAdapter` and introduce `FungibleAdapter` - Deprecate `ToStakingPot` and replace usage with `ResolveTo` - Required creating a new `StakingPotAccountId` struct that implements `TypedGet` for the staking pot account ID - Update parachain common utils `DealWithFees`, `ToAuthor` and `AssetsToBlockAuthor` implementations to use `fungible` - Update runtime XCM Weight Traders to use `ResolveTo` instead of `ToStakingPot` - Update runtime Transaction Payment pallets to use `FungibleAdapter` instead of `CurrencyAdapter` - [x] Blocked by https://github.com/paritytech/polkadot-sdk/pull/1296, needs the `Unbalanced::decrease_balance` fix
-
Liam Aharon authored
Closes https://github.com/paritytech/polkadot-sdk/issues/2977 The issue appears to stem from the `aquamarine` crate failing to render diagrams in re-exported crates. e.g. as raised [here](https://github.com/paritytech/polkadot-sdk/issues/2977), diagrams would render at `frame_support::traits::Hooks` but not the re-exported doc `frame::traits::Hooks`, even if I added `aquamarine` as a `frame` crate dependency. To resolve this, I followed advice in https://github.com/mersinvald/aquamarine/issues/20 to instead render mermaid diagrams directly using JS by adding an `after-content.js`. --- Also fixes compile warnings, enables `--all-features` and disallows future warnings in CI. --------- Co-authored-by:
Kian Paimani <[email protected]> Co-authored-by:
Bastian Köcher <[email protected]>
-
Lulu authored
CI will be enforcing this with next parity-publish release
-
- Apr 03, 2024
-
-
Sebastian Kunert authored
Enables pov-reclaim on the rococo/westend parachains, part of https://github.com/paritytech/polkadot-sdk/issues/3622
-
- Apr 02, 2024
-
-
Clara van Staden authored
This PR includes the following 2 improvements: ## Ethereum Client Author: @yrong ### Original Upstream PRs - https://github.com/Snowfork/polkadot-sdk/pull/123 - https://github.com/Snowfork/polkadot-sdk/pull/125 ### Description The Ethereum client syncs beacon headers as they are finalized, and imports every execution header. When a message is received, it is verified against the import execution header. This is unnecessary, since the execution header can be sent with the message as proof. The recent Deneb Ethereum upgrade made it easier to locate the relevant beacon header from an execution header, and so this improvement was made possible. This resolves a concern @svyatonik had in our initial Rococo PR: https://github.com/paritytech/polkadot-sdk/pull/2522#discussion_r1431270691 ## Inbound Queue Author: @yrong ### Original Upstream PR - https://github.com/Snowfork/polkadot-sdk/pull/118 ### Description When the AH sovereign account (who pays relayer rewards) is depleted, the inbound message will not fail. The relayer just will not receive rewards. Both these changes were done by @yrong, many thanks.
❤ ️ --------- Co-authored-by: claravanstaden <Cats 4 life!> Co-authored-by:Ron <[email protected]> Co-authored-by:
Vincent Geddes <[email protected]> Co-authored-by:
Svyatoslav Nikolsky <[email protected]>
-
Dastan authored
migrations: prevent accidentally using unversioned migrations instead of `VersionedMigration` (#3835) closes #1324 #### Problem Currently, it is possible to accidentally use inner unversioned migration instead of `VersionedMigration` since both implement `OnRuntimeUpgrade`. #### Solution With this change, we make it clear that value of `Inner` is not intended to be used directly. It is achieved by bounding `Inner` to new trait `UncheckedOnRuntimeUpgrade`, which has the same interface (except `unchecked_` prefix) as `OnRuntimeUpgrade`. #### `try-runtime` functions Since developers can implement `try-runtime` for `Inner` value in `VersionedMigration` and have custom logic for it, I added the same `try-runtime` functions to `UncheckedOnRuntimeUpgrade`. I looked for a ways to not duplicate functions, but couldn't find anything that doesn't significantly change the codebase. So I would appreciate If you have any suggestions to improve this cc @liamaharon @xlc polkadot address: 16FqwPZ8GRC5U5D4Fu7W33nA55ZXzXGWHwmbnE1eT6pxuqcT --------- Co-authored-by:
Liam Aharon <[email protected]>
-
Serban Iorga authored
Working towards migrating the `parity-bridges-common` repo inside `polkadot-sdk`. This PR upgrades some dependencies in order to align them with the versions used in `parity-bridges-common` Related to https://github.com/paritytech/parity-bridges-common/issues/2538
-
Adrian Catangiu authored
Fix "double-weights" for extrinsics, use only the ones benchmarked in the runtime. Deprecate extrinsics that don't specify WeightLimit, remove their usage across the repo. --------- Signed-off-by:
Adrian Catangiu <[email protected]> Co-authored-by: command-bot <>
-
Sam Johnson authored
derive-syn-parse v0.2.0 came out recently which (finally) adds support for syn 2x. Upgrading to this will remove many of the places where syn 1x was still compiling alongside syn 2x in the polkadot-sdk workspace. This also upgrades `docify` to 0.2.8 which is the version that upgrades derive-syn-pasre to 0.2.0. Additionally, this consolidates the `docify` versions in the repo to all use the latest, and in one case upgrades to the 0.2x syntax where 0.1.x was still being used. --------- Co-authored-by:
Liam Aharon <[email protected]>
-
- Apr 01, 2024
-
-
s0me0ne-unkn0wn authored
Rejoice! Rejoice! The story is nearly over. This PR removes stale migrations, auxiliary structures, and package dependencies, thus making Rococo and Westend totally free from any `im-online`-related stuff. `im-online` still stays a part of the Substrate node and its runtime: https://github.com/paritytech/polkadot-sdk/blob/0d9324847391e902bb42f84f0e76096b1f764efe/substrate/bin/node/runtime/src/lib.rs#L2276-L2277 I'm not sure if it makes sense to remove it from there considering that we're not removing `im-online` from FRAME. Please share your opinion.
-
Alexandru Gheorghe authored
Runtime release 1.2 includes bumping of the ParachainHost APIs up to v10, so let's move all the released APIs out of vstaging folder, this PR does not include any logic changes only renaming of the modules and some moving around. Signed-off-by:
Alexandru Gheorghe <[email protected]>
-
- Mar 28, 2024
-
-
Sebastian Kunert authored
This PR exports unified hostfunctions needed for parachains. Basicaly `SubstrateHostFunctions` + `storage_proof_size::HostFunctions`. Also removes the native executor from the parachain template. --------- Co-authored-by:
Michal Kucharczyk <[email protected]>
-
- Mar 27, 2024
-
-
Ermal Kaleci authored
This will make it possible to use remaining weight on idle for processing enqueued messages. More context here https://github.com/paritytech/polkadot-sdk/issues/3709 --------- Co-authored-by:
Adrian Catangiu <[email protected]>
-