[pull] master from paritytech:master #11
Closed
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
![pull[bot]](https://avatars.githubusercontent.com/in/12910?s=60&v=4){kind=small}
Same issue but about av-cores was fixed in #1403 Signed-off-by: Andrei Sandu <andrei-mihail@parity.io>
Closes #4041 Changes: - Increase cache size and reduce retries. - Ignore Substrate SE links :( - Fix broken link. --------- Signed-off-by: Oliver Tale-Yazdi <oliver.tale-yazdi@parity.io>
#3630) 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.
Currently `subsystem-regression-tests` job fails if the first benchmarks fail and there is no result for the second benchmark. Also dividing the job makes the pipeline faster (currently it's a longest job) cc paritytech/ci_cd#969 cc @AndreiEres --------- Co-authored-by: Andrei Eres <eresav@me.com>
Implements the idea from #3899 - Removed latencies - Number of runs reduced from 50 to 5, according to local runs it's quite enough - Network message is always sent in a spawned task, even if latency is zero. Without it, CPU time sometimes spikes. - Removed the `testnet` profile because we probably don't need that debug additions. After the local tests I can't say that it brings a significant improvement in the stability of the results. However, I belive it is worth trying and looking at the results over time.
Completes the removal of `try-runtime-cli` logic from `polkadot-sdk`.
One more try to make this test robust from a resource perspective. --------- Signed-off-by: Andrei Sandu <andrei-mihail@parity.io> Co-authored-by: Javier Viola <javier@parity.io>
Implements polkadot-fellows/RFCs#82 Allow any parachain to have bidirectional channel with any system parachains Looking for initial feedbacks before continue finish it TODOs: - [x] docs - [x] benchmarks - [x] tests --------- Co-authored-by: joe petrowski <25483142+joepetrowski@users.noreply.github.com> Co-authored-by: Adrian Catangiu <adrian@parity.io>
Small adjustments which should make understanding what is going on much easier for future readers. Initialization is a bit messy, the very least we should do is adding documentation to make it harder to use wrongly. I was thinking about calling `request_core_count` right from `start_sales`, but as explained in the docs, this is not necessarily what you want. --------- Co-authored-by: eskimor <eskimor@no-such-url.com> Co-authored-by: Bastian Köcher <git@kchr.de> Co-authored-by: Dónal Murray <donal.murray@parity.io>
Fixes #3576 Required by elastic scaling collators. Deprecates old API: `candidate_pending_availability`. TODO: - [x] PRDoc --------- Signed-off-by: Andrei Sandu <andrei-mihail@parity.io>
…transfer types (#3695) # 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 <bkontur@gmail.com> Co-authored-by: command-bot <>
- Progresses #3155 ### What's inside A job, that will take each of the three [templates](https://github.com/paritytech/polkadot-sdk/tree/master/templates), yank them out of the monorepo workspace, and push to individual repositories ([1](https://github.com/paritytech/polkadot-sdk-minimal-template), [2](https://github.com/paritytech/polkadot-sdk-parachain-template), [3](https://github.com/paritytech/polkadot-sdk-solochain-template)). In case the build/test does not succeed, a PR such as [this one](paritytech-stg/polkadot-sdk-solochain-template#2) gets created instead. I'm proposing a manual dispatch trigger for now - so we can test and iterate faster - and change it to fully automatic triggered by releases later. The manual trigger looks like this: <img width="340px" src="https://github.com/paritytech/polkadot-sdk/assets/12039224/e87e0fda-23a3-4735-9035-af801e8417fc"/> ### How it works The job replaces dependencies [referenced by git](https://github.com/paritytech/polkadot-sdk/blob/d733c77ee2d2e8e2d5205c552a5efb2e5b5242c8/templates/minimal/pallets/template/Cargo.toml#L25) with a reference to released crates using [psvm](https://github.com/paritytech/psvm). It creates a new workspace for the template, and adapts what's needed from the `polkadot-sdk` workspace. ### See the results The action has been tried out in staging, and the results can be observed here: - [minimal stg](https://github.com/paritytech-stg/polkadot-sdk-minimal-template/) - [parachain stg](https://github.com/paritytech-stg/polkadot-sdk-parachain-template/) - [solochain stg](https://github.com/paritytech-stg/polkadot-sdk-solochain-template/) These are based on the `1.9.0` release (using `release-crates-io-v1.9.0` branch).
1. The `CustomFmtContext::ContextWithFormatFields` enum arm isn't actually used and thus we don't need the enum anymore. 2. We don't do anything with most of the normalized metadata that's created by calling `event.normalized_metadata();` - the `target` we can get from `event.metadata.target()` and level we can get from `event.metadata.level()` - let's just call them direct to simplify things. (`event.metadata()` is just a field call under the hood) Changelog: No functional changes, might run a tad faster with lots of logging turned on. --------- Co-authored-by: Bastian Köcher <git@kchr.de>
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`)
This PR introduces `BlockHashProvider` into `pallet_mmr::Config` This type is used to get `block_hash` for a given `block_number` rather than directly using `frame_system::Pallet::block_hash` The `DefaultBlockHashProvider` uses `frame_system::Pallet::block_hash` to get the `block_hash` Closes: #4062
Fixes #3999 --------- Co-authored-by: Branislav Kontur <bkontur@gmail.com>
This workflow will automatically add issues related to async backing to the Parachain team board, updating a custom "meta" field. Requested by @the-right-joyce
…nd (#4006) Changes: - Add pallet-parameters to Rococo to configure the NIS and preimage pallet. - Fix names of expanded dynamic params. Apparently, `to_class_case` removes suffix `s`, and `Nis` becomes `Ni` 😑. Now using `to_pascal_case`. --------- Signed-off-by: Oliver Tale-Yazdi <oliver.tale-yazdi@parity.io> Co-authored-by: Alessandro Siniscalchi <asiniscalchi@gmail.com> Co-authored-by: Kian Paimani <5588131+kianenigma@users.noreply.github.com> Co-authored-by: command-bot <>
…eo (#4066) Verified by running a node using `--reserved-only` and `--reserved-nodes`.
Co-authored-by: Liam Aharon <liam.aharon@hotmail.com>
As discovered during investigation of #3314 and #3673 there are active validators which accidentally might change their network key during restart, that's not a safe operation when you are in the active set because of distributed nature of DHT, so the old records would still exist in the network until they expire 36h, so unless they have a good reason validators should avoid changing their key when they restart their nodes. There is an effort in parallel to improve this situation #3786, but those changes are way more intrusive and will need more rigorous testing, additionally they will reduce the time to less than 36h, but the propagation won't be instant anyway, so not changing your network during restart should be the safest way to run your node, unless you have a really good reason to change it. ## Proposal 1. Do not auto-generate the network if the network file does not exist in the provided path. Nodes where the key file does not exist will get the following error: ``` Error: 0: Starting an authorithy without network key in /home/alexggh/.local/share/polkadot/chains/ksmcc3/network/secret_ed25519. This is not a safe operation because the old identity still lives in the dht for 36 hours. Because of it your node might suffer from not being properly connected to other nodes for validation purposes. If it is the first time running your node you could use one of the following methods. 1. Pass --unsafe-force-node-key-generation and make sure you remove it for subsequent node restarts 2. Separetly generate the key with: polkadot key generate-node-key --file <YOUR_PATH_TO_NODE_KEY> ``` 2. Add an explicit parameters for nodes that do want to change their network despite the warnings or if they run the node for the first time. `--unsafe-force-node-key-generation` 3. For `polkadot key generate-node-key` add two new mutually exclusive parameters `base_path` and `default_base_path` to help with the key generation in the same path the polkadot main command would expect it. 4. Modify the installation scripts to auto-generate a key in default path if one was not present already there, this should help with making the executable work out of the box after an instalation. ## Notes Nodes that do not have already the key persisted will fail to start after this change, however I do consider that better than the current situation where they start but they silently hide that they might not be properly connected to their peers. ## TODO - [x] Make sure only nodes that are authorities on producation chains will be affected by this restrictions. - [x] Proper PRDOC, to make sure node operators are aware this is coming. --------- Signed-off-by: Alexandru Gheorghe <alexandru.gheorghe@parity.io> Co-authored-by: Dmitry Markin <dmitry@markin.tech> Co-authored-by: s0me0ne-unkn0wn <48632512+s0me0ne-unkn0wn@users.noreply.github.com> Co-authored-by: Bastian Köcher <git@kchr.de>
Extracted to a separate PR as requested here: paritytech/parity-bridges-common#2873 (comment)
While `sp-api-proc-macro` isn't used directly and thus, it should have the same features enabled as `sp-api`. However, I have seen issues around `frame-metadata` not being enabled for `sp-api`, but for `sp-api-proc-macro`. This can be prevented by using the `frame_metadata_enabled` macro from `sp-api` that ensures we have the same feature set between both crates.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
See Commits and Changes for more details.
Created by
pull[bot]
Can you help keep this open source service alive? 💖 Please sponsor : )