- Dec 13, 2023
-
-
eskimor authored
-
eskimor authored
-
eskimor authored
-
eskimor authored
Co-authored-by:
Bastian Köcher <[email protected]>
-
eskimor authored
-
eskimor authored
-
Marcin S. authored
-
gupnik authored
-
Svyatoslav Nikolsky authored
So far the `bridge-hub-test-utils` contained a tests set for testing BridgeHub runtime that is bridging with the remote **parachain**. But we have https://github.com/paritytech/polkadot-sdk/pull/2540 coming, which would add Rococo <> Bulletin chain bridge (where Bulletin = standalone chain that is using GRANDPA finality). Then it'll be expanded to Polkadot BH as well. So this PR adds the same set of tests to the `bridge-hub-test-utils`, but for the case when remote chain is the chain with GRANDPA finality. There's a lot of changes in this PR - I'll describe some: - I've added `BasicParachainRuntime` trait to decrease number of lines we need to add to `where` clause. Could revert, but imo it is useful; - `cumulus/parachains/runtimes/bridge-hubs/test-utils/src/test_data` is a submodule for generating test data for the test sets. `from_parachain.rs` is used in tests for the case when remote chain is a parachain, `from_grandpa_chain.rs` - for the bridges with remote GRANDPA chains. `mod.rs` has some code, shared by both types of tests; - `cumulus/parachains/runtimes/bridge-hubs/test-utils/src/test_data` is a submodule with all test cases. The `mod.rs` has tests, suitable for all cases. There's also `wth_parachain.rs` and `with_grandpa_chain.rs` with the same meaning as above; - I've merged the "core" code of two previous tests - `relayed_incoming_message_works` and `complex_relay_extrinsic_works` into one single `relayed_incoming_message_works` test. So now we are always constructing extrinsics and are dispatching them using executive module (meaning all signed extensions are also tested). New test set is used here: https://github.com/paritytech/polkadot-sdk/pull/2540. Once this PR is merged, I'll merge that other PR with master to remove duplicate changes. I'm also planning to cleanup generic constraints + remove some unnecessary assumptions about used chains in a follow-up PRs. But for now I think this PR has enough changes, so don't want to complicate it even more. --- Breaking changes for the code that have used those tests before: - the `construct_and_apply_extrinsic` callback now accepts the `RuntimeCall` instead of the `pallet_utility::Call`; - the `construct_and_apply_extrinsic` now may be called multiple times for the single test, so make sure the `frame_system::CheckNonce` is correctly constructed; - all previous tests have been moved from `bridge_hub_test_utils::test_cases` to `bridge_hub_test_utils::test_cases::from_parachain` module; - there are several changes in test arguments - please refer to https://github.com/paritytech/polkadot-sdk/compare/sv-tests-for-bridge-with-remote-grandpa-chain?expand=1#diff-79a28d4d3e1749050341c2424f00c4c139825b1a20937767f83e58b95166735c for details.
-
Chevdor authored
This PR introduces: - a new script - a new GH Workflow - runtime reference spec files for `rococo` and `westend` It brings a mechanism to check that part(s) of the runtimes' metadata that should not change over time, actually did not change over time. Ideally, the GHW should trigger when a release is edited but GH seem to [have an issue](https://github.com/orgs/community/discussions/47794) that prevents the trigger from working. This is why the check has been implemented as `workflow_dispatch` for a start. The `workflow_dispatch` requires a `release_id` that can be found using: ``` curl -s -H "Authorization: Bearer ${GITHUB_TOKEN}" \ https://api.github.com/repos/paritytech/polkadot-sdk/releases | \ jq '.[] | { name: .name, id: .id }' ``` as documented in the workflow. A sample run can be seen [here](https://github.com/chevdor/polkadot-sdk/actions/runs/6811176342).
-
Joshy Orndorff authored
Rename `ExportGenesisStateCommand` to `ExportGenesisHeadCommand` and make it respect custom genesis block builders (#2331) Closes #2326. This PR both fixes a logic bug and replaces an incorrect name. ## Bug Fix: Respecting custom genesis builder Prior to this PR the standard logic for creating a genesis block was repeated inside of cumulus. This PR removes that duplicated logic, and calls into the proper `BuildGenesisBlock` implementation. One consequence is that if the genesis block has already been initialized, it will not be re-created, but rather read from the database like it is for other node invocations. So you need to watch out for old unpurged data during the development process. Offchain tools may need to be updated accordingly. I've already filed https://github.com/paritytech/zombienet/issues/1519 ## Rename: It doesn't export state. It exports head data. The name export-genesis-state was always wrong, nad it's never too late to right a wrong. I've changed the name of the struct to `ExportGenesisHeadCommand`. There is still the question of what to do with individual nodes' public CLIs. I have updated the parachain template to a reasonable default that preserves compatibility with tools that will expect `export-genesis-state` to still work. And I've chosen not to modify the public CLIs of any other nodes in the repo. I'll leave it up to their individual owners/maintains to decide whether that is appropriate. --------- Co-authored-by:
Joshy Orndorff <[email protected]> Co-authored-by:
Bastian Köcher <[email protected]> Co-authored-by:
Bastian Köcher <[email protected]>
-
Alexandru Gheorghe authored
Initial implementation for the plan discussed here: https://github.com/paritytech/polkadot-sdk/issues/701 Built on top of https://github.com/paritytech/polkadot-sdk/pull/1178 v0: https://github.com/paritytech/polkadot/pull/7554, ## Overall idea When approval-voting checks a candidate and is ready to advertise the approval, defer it in a per-relay chain block until we either have MAX_APPROVAL_COALESCE_COUNT candidates to sign or a candidate has stayed MAX_APPROVALS_COALESCE_TICKS in the queue, in both cases we sign what candidates we have available. This should allow us to reduce the number of approvals messages we have to create/send/verify. The parameters are configurable, so we should find some values that balance: - Security of the network: Delaying broadcasting of an approval shouldn't but the finality at risk and to make sure that never happens we won't delay sending a vote if we are past 2/3 from the no-show time. - Scalability of the network: MAX_APPROVAL_COALESCE_COUNT = 1 & MAX_APPROVALS_COALESCE_TICKS =0, is what we have now and we know from the measurements we did on versi, it bottlenecks approval-distribution/approval-voting when increase significantly the number of validators and parachains - Block storage: In case of disputes we have to import this votes on chain and that increase the necessary storage with MAX_APPROVAL_COALESCE_COUNT * CandidateHash per vote. Given that disputes are not the normal way of the network functioning and we will limit MAX_APPROVAL_COALESCE_COUNT in the single digits numbers, this should be good enough. Alternatively, we could try to create a better way to store this on-chain through indirection, if that's needed. ## Other fixes: - Fixed the fact that we were sending random assignments to non-validators, that was wrong because those won't do anything with it and they won't gossip it either because they do not have a grid topology set, so we would waste the random assignments. - Added metrics to be able to debug potential no-shows and mis-processing of approvals/assignments. ## TODO: - [x] Get feedback, that this is moving in the right direction. @ordian @sandreim @eskimor @burdges, let me know what you think. - [x] More and more testing. - [x] Test in versi. - [x] Make MAX_APPROVAL_COALESCE_COUNT & MAX_APPROVAL_COALESCE_WAIT_MILLIS a parachain host configuration. - [x] Make sure the backwards compatibility works correctly - [x] Make sure this direction is compatible with other streams of work: https://github.com/paritytech/polkadot-sdk/issues/635 & https://github.com/paritytech/polkadot-sdk/issues/742 - [x] Final versi burn-in before merging --------- Signed-off-by:
Alexandru Gheorghe <[email protected]>
-
- Dec 12, 2023
-
-
eskimor authored
-
Branislav Kontur authored
## Summary This PR turns on `-D warnings` for `cargo-check-each-crate job` job to fail on warnings e.g. like this: https://gitlab.parity.io/parity/mirrors/polkadot-sdk/-/jobs/4673130 Before this PR, there was a warning and `cargo-check-each-crate` job did not fail: https://gitlab.parity.io/parity/mirrors/polkadot-sdk/-/jobs/4641444 ``` warning: unused import: `ToTokens` --> substrate/primitives/api/proc-macro/src/utils.rs:22:34 | 22 | use quote::{format_ident, quote, ToTokens}; | ^^^^^^^^ | = note: `#[warn(unused_imports)]` on by default warning: `sp-api-proc-macro` (lib) generated 1 warning (run `cargo fix --lib -p sp-api-proc-macro` to apply 1 suggestion) ``` Fixes on the way: https://gitlab.parity.io/parity/mirrors/polkadot-sdk/-/jobs/4641444 https://gitlab.parity.io/parity/mirrors/polkadot-sdk/-/jobs/4673265 https://gitlab.parity.io/parity/mirrors/polkadot-sdk/-/jobs/4673410 https://gitlab.parity.io/parity/mirrors/polkadot-sdk/-/jobs/4673681 https://gitlab.parity.io/parity/mirrors/polkadot-sdk/-/jobs/4673836 https://gitlab.parity.io/parity/mirrors/polkadot-sdk/-/jobs/4673941 https://gitlab.parity.io/parity/mirrors/polkadot-sdk/-/jobs/4674256 https://gitlab.parity.io/parity/mirrors/polkadot-sdk/-/jobs/4679328 ## Questions - [ ] why does this check triggers only `cargo check --locked`? `--all-features` or `--all-targets` are not needed? Or aren't they avoided intentionally? --------- Co-authored-by: command-bot <>
-
eskimor authored
-
Parth authored
# Description - What does this PR do? This PR make some methods of `OverlayedChanges` public which were previously only visible in same crate. - Why are these changes needed? Since, some methods of the `OverlayedChanges` only have crate level visibility, which makes `OverlayedChanges` somewhat unusable outside the crate to create custom implementation of `Externalities`. We make those method public to enable `OverlayedChanges` to remedy this. - How were these changes implemented and what do they affect? Changes are implemented by replacing crate visibility to public visibility of 4 functions. # Checklist - [x] My PR includes a detailed description as outlined in the "Description" section above - [ ] My PR follows the [labeling requirements](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) --------- Co-authored-by:
Bastian Köcher <[email protected]>
-
eskimor authored
-
eskimor authored
-
Egor_P authored
Small update of the title in one of the prdoc files
-
Francisco Aguirre authored
We were not filtering for sibling parachains, but for sibling anything --------- Co-authored-by:
Branislav Kontur <[email protected]> Co-authored-by: command-bot <>
-
Marcin S. authored
-
Marcin S. authored
-
eskimor authored
-
eskimor authored
-
eskimor authored
-
Branislav Kontur authored
## Summary This pull request proposes a solution for improved control of the versioned XCM flow over the bridge (across different consensus chains) and resolves the situation where the sending chain/consensus has already migrated to a higher XCM version than the receiving chain/consensus. ## Problem/Motivation The current flow over the bridge involves a transfer from AssetHubRococo (AHR) to BridgeHubRococo (BHR) to BridgeHubWestend (BHW) and finally to AssetHubWestend (AHW), beginning with a reserve-backed transfer on AHR. In this process: 1. AHR sends XCM `ExportMessage` through `XcmpQueue`, incorporating XCM version checks using the `WrapVersion` feature, influenced by `pallet_xcm::SupportedVersion` (managed by `pallet_xcm::force_xcm_version` or version discovery). 2. BHR handles the `ExportMessage` instruction, utilizing the latest XCM version. The `HaulBlobExporter` converts the inner XCM to [`VersionedXcm::from`](https://github.com/paritytech/polkadot-sdk/blob/63ac2471aa0210f0ac9903bdd7d8f9351f9a635f/polkadot/xcm/xcm-builder/src/universal_exports.rs#L465-L467), also using the latest XCM version. However, challenges arise: - Incompatibility when BHW uses a different version than BHR. For instance, if BHR migrates to **XCMv4** while BHW remains on **XCMv3**, BHR's `VersionedXcm::from` uses `VersionedXcm::V4` variant, causing encoding issues for BHW. ``` /// Just a simulation of possible error, which could happen on BHW /// (this code is based on actual master without XCMv4) let encoded = hex_literal::hex!("0400"); println!("{:?}", VersionedXcm::<()>::decode(&mut &encoded[..])); Err(Error { cause: None, desc: "Could not decode `VersionedXcm`, variant doesn't exist" }) ``` - Similar compatibility issues exist between AHR and AHW. ## Solution This pull request introduces the following solutions: 1. **New trait `CheckVersion`** - added to the `xcm` module and exposing `pallet_xcm::SupportedVersion`. This enhancement allows checking the actual XCM version for desired destinations outside of the `pallet_xcm` module. 2. **Version Check in `HaulBlobExporter`** uses `CheckVersion` to check known/configured destination versions, ensuring compatibility. For example, in the scenario mentioned, BHR can store the version `3` for BHW. If BHR is on XCMv4, it will attempt to downgrade the message to version `3` instead of using the latest version `4`. 3. **Version Check in `pallet-xcm-bridge-hub-router`** - this check ensures compatibility with the real destination's XCM version, preventing the unnecessary sending of messages to the local bridge hub if versions are incompatible. These additions aim to improve the control and compatibility of XCM flows over the bridge and addressing issues related to version mismatches. ## Possible alternative solution _(More investigation is needed, and at the very least, it should extend to XCMv4/5. If this proves to be a viable option, I can open an RFC for XCM.)._ Add the `XcmVersion` attribute to the `ExportMessage` so that the sending chain can determine, based on what is stored in `pallet_xcm::SupportedVersion`, the version the destination is using. This way, we may not need to handle the version in `HaulBlobExporter`. ``` ExportMessage { network: NetworkId, destination: InteriorMultiLocation, xcm: Xcm<()> destination_xcm_version: Version, // <- new attritbute }, ``` ``` pub trait ExportXcm { fn validate( network: NetworkId, channel: u32, universal_source: &mut Option<InteriorMultiLocation>, destination: &mut Option<InteriorMultiLocation>, message: &mut Option<Xcm<()>>, destination_xcm_version: Version, , // <- new attritbute ) -> SendResult<Self::Ticket>; ``` ## Future Directions This PR does not fix version discovery over bridge, further investigation will be conducted here: https://github.com/paritytech/polkadot-sdk/issues/2417. ## TODO - [x] `pallet_xcm` mock for tests uses hard-coded XCM version `2` - change to 3 or lastest? - [x] fix `pallet-xcm-bridge-hub-router` - [x] fix HaulBlobExporter with version determination [here](https://github.com/paritytech/polkadot-sdk/blob/2183669d05f9b510f979a0cc3c7847707bacba2e/polkadot/xcm/xcm-builder/src/universal_exports.rs#L465) - [x] add unit-tests to the runtimes - [x] run benchmarks for `ExportMessage` - [x] extend local run scripts about `force_xcm_version(dest, version)` - [ ] when merged, prepare governance calls for Rococo/Westend - [ ] add PRDoc Part of: https://github.com/paritytech/parity-bridges-common/issues/2719 --------- Co-authored-by: command-bot <>
-
eskimor authored
-
eskimor authored
-
Chevdor authored
This PR introduces a script and some templates to use the prdoc involved in a release and build: - the changelog - a simple draft of audience documentation Since the prdoc presence was enforced in the middle of the version 1.5.0, not all PRs did come with a `prdoc` file. This PR creates all the missing `prdoc` files with some minimum content allowing to properly generate the changelog. The generated content is **not** suitable for the audience documentation. The audience documentation will be possible with the next version, when all PR come with a proper `prdoc`. ## Assumptions - the prdoc files for release `vX.Y.Z` have been moved under `prdoc/X.Y.Z` - the changelog requires for now for the prdoc files to contain author + topic. Thos fields are optional. The build script can be called as: ``` VERSION=X.Y.Z ./scripts/release/build-changelogs.sh ``` Related: - #1408 --------- Co-authored-by:
EgorPopelyaev <[email protected]>
-
eskimor authored
-
eskimor authored
I don't really get what the common crate is actually meant to be for. Coretime is parachains functionality in any case and moving it to the parachains crate makes things a bit more straight forward/inline with other code.
-
juangirini authored
A brief explanation of the Deprecation Checklist is added to the Contributing notes with a link to it
-
Marcin S. authored
-
Marcin S. authored
-
Bastian Köcher authored
-
Marcin S. authored
-
eskimor authored
-
dependabot[bot] authored
Bumps [names](https://github.com/fnichol/names) from 0.13.0 to 0.14.0. <details> <summary>Release notes</summary> <p><em>Sourced from <a href="https://github.com/fnichol/names/releases">names's releases</a>.</em></p> <blockquote> <h2>Release 0.14.0</h2> <h2><a href="https://github.com/fnichol/names/compare/v0.13.0...v0.14.0">0.14.0</a> - 2022-06-28</h2> <h3>Changed</h3> <ul> <li>upgrade to <code>regex</code> 1.5.6</li> </ul> <!-- raw HTML omitted --> </blockquote> </details> <details> <summary>Changelog</summary> <p><em>Sourced from <a href="https://github.com/fnichol/names/blob/main/CHANGELOG.md">names's changelog</a>.</em></p> <blockquote> <h2>[0.14.0] - 2022-06-28</h2> <h3>Changed</h3> <ul> <li>upgrade to <code>regex</code> 1.5.6</li> </ul> </blockquote> </details> <details> <summary>Commits</summary> <ul> <li><a href="https://github.com/fnichol/names/commit/8f09d5bf9860582c485b5856cbb325642d3e82c2"><code>8f09d5b</code></a> release: names 0.14.0</li> <li><a href="https://github.com/fnichol/names/commit/b589b911b489812aa4a279efa1b91e6fe7ff7dfa"><code>b589b91</code></a> release: update CHANGELOG.md</li> <li><a href="https://github.com/fnichol/names/commit/e1bed3056d38a98a22f28f39db42211404a00953"><code>e1bed30</code></a> merge: <a href="https://redirect.github.com/fnichol/names/issues/20">#20</a></li> <li><a href="https://github.com/fnichol/names/commit/12eb753220007a2aafe741031af83562c1e617f6"><code>12eb753</code></a> Bump regex from 1.5.4 to 1.5.6</li> <li><a href="https://github.com/fnichol/names/commit/ed520b76b8542fdca09d9d80658f4ea0b8914464"><code>ed520b7</code></a> merge: <a href="https://redirect.github.com/fnichol/names/issues/19">#19</a></li> <li><a href="https://github.com/fnichol/names/commit/852eaee067bcadfb2a59e78b432919a87983fe6d"><code>852eaee</code></a> chore: start next iteration 0.13.1-dev</li> <li>See full diff in <a href="https://github.com/fnichol/names/compare/v0.13.0...v0.14.0">compare view</a></li> </ul> </details> <br /> [![Dependabot compatibility score](https://dependabot-badges.githubapp.com/badges/compatibility_score?dependency-name=names&package-manager=cargo&previous-version=0.13.0&new-version=0.14.0)](https://docs.github.com/en/github/managing-security-vulnerabilities/about-dependabot-security-updates#about-compatibility-scores ) Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting `@dependabot rebase`. [//]: # (dependabot-automerge-start) [//]: # (dependabot-automerge-end) --- <details> <summary>Dependabot commands and options</summary> <br /> You can trigger Dependabot actions by commenting on this PR: - `@dependabot rebase` will rebase this PR - `@dependabot recreate` will recreate this PR, overwriting any edits that have been made to it - `@dependabot merge` will merge this PR after your CI passes on it - `@dependabot squash and merge` will squash and merge this PR after your CI passes on it - `@dependabot cancel merge` will cancel a previously requested merge and block automerging - `@dependabot reopen` will reopen this PR if it is closed - `@dependabot close` will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually - `@dependabot show <dependency name> ignore conditions` will show all of the ignore conditions of the specified dependency - `@dependabot ignore <dependency name> major version` will close this group update PR and stop Dependabot creating any more for the specific dependency's major version (unless you unignore this specific dependency's major version or upgrade to it yourself) - `@dependabot ignore <dependency name> minor version` will close this group update PR and stop Dependabot creating any more for the specific dependency's minor version (unless you unignore this specific dependency's minor version or upgrade to it yourself) - `@dependabot ignore <dependency name>` will close this group update PR and stop Dependabot creating any more for the specific dependency (unless you unignore this specific dependency or upgrade to it yourself) - `@dependabot unignore <dependency name>` will remove all of the ignore conditions of the specified dependency - `@dependabot unignore <dependency name> <ignore condition>` will remove the ignore condition of the specified dependency and ignore conditions </details> Signed-off-by:
dependabot[bot] <[email protected]> Co-authored-by:
dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>
-