forked from paritytech/polkadot-sdk
-
Notifications
You must be signed in to change notification settings - Fork 0
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Inbound queue v2 #5
Draft
claravanstaden
wants to merge
201
commits into
yrong:v2
Choose a base branch
from
claravanstaden:inbound-queue-v2
base: v2
Could not load branches
Branch not found: {{ refName }}
Loading
Could not load tags
Nothing to show
Loading
Are you sure you want to change the base?
Some commits from the old base branch may be removed from the timeline,
and old review comments may become outdated.
Draft
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
…itytech#5892) Resolves polkadot-fellows/runtimes#459 Tested with rococo/westend/kusama/polkadot runtimes --------- Co-authored-by: DavidK <[email protected]> Co-authored-by: Muharem <[email protected]> Co-authored-by: Shawn Tabrizi <[email protected]> Co-authored-by: Dónal Murray <[email protected]>
`AccountData` should be set to `()` and not to `AccountInfo`. Closes: paritytech#5922 --------- Co-authored-by: Shawn Tabrizi <[email protected]>
Related to paritytech#5924 (comment) improve prdoc arguments validation & help: - convert audiences options to snake_case. Fixes paritytech#5927 - support more than one audiences - define allowed bump options - infer --pr from the actual PR (now it's optional, can still be overwritten) ![image](https://github.com/user-attachments/assets/24e18fe2-2f67-4ce0-90e4-34f6c2f860c9) Test evidence: paritytech-stg@6dd274e
- moved the omni-node lib from `cumulus/polkadot-parachain/polkadot-parachain-lib` to `cumulus/polkadot-omni-node/lib` - renamed `polkadot-parachain-lib` to `polkadot-omni-node-lib` - added `polkadot-omni-node` binary Related to paritytech#5566
Changes: - Add `--exclude-pallets` to exclude some pallets from runtimes where we dont have genesis presets yet - Make `--genesis-builder-policy=none` work with `--runtime` - CI: Run the frame-omni-bencher for all runtimes --------- Signed-off-by: Oliver Tale-Yazdi <[email protected]> Co-authored-by: ggwpez <[email protected]> Co-authored-by: Bastian Köcher <[email protected]> Co-authored-by: Branislav Kontur <[email protected]> Co-authored-by: alvicsam <[email protected]> Co-authored-by: Maksym H <[email protected]> Co-authored-by: Alexander Samusev <[email protected]> Co-authored-by: Maksym H <[email protected]>
Bump zombienet version, including fixes for `ci` and set _resources requests_ for the runner. Thx! Co-authored-by: Bastian Köcher <[email protected]>
Implement a syscall to retreive the transaction origin. --------- Signed-off-by: Cyrill Leutwiler <[email protected]> Signed-off-by: xermicus <[email protected]> Co-authored-by: GitHub Action <[email protected]> Co-authored-by: command-bot <> Co-authored-by: Alexander Theißen <[email protected]>
Addresses paritytech#4284 For V5, removed `required_weight_at_most` from `Transact`. The weigher now has to decode the call inside of a transaction in order to know it's dispatch weight. It's harder to make mistakes now, since the user no longer specifies a weight value which might be wrong.
…itytech#5995) A step towards paritytech#4782 In order to nail down the right preludes in `polkadot-sdk-frame`, we need to migrate a number of pallets to be written with it. Moreover, migrating our pallets to this simpler patter will encourage the ecosystem to also follow along. If this PR is approved and has no unwanted negative consequences, I will make a tracking issue to migrate all pallets to this umbrella crate. TODO: - [x] fix frame benchmarking template. Can we detect the umbrella crate in there and have an `if else`? cc @ggwpez - [x] Migrate benchmarking to v2 @re-gius a good candidate for you, you can open a PR against my branch. - [x] tracking issue with follow-ups --------- Co-authored-by: Guillaume Thiolliere <[email protected]> Co-authored-by: Giuseppe Re <[email protected]> Co-authored-by: Dónal Murray <[email protected]> Co-authored-by: Shawn Tabrizi <[email protected]> Co-authored-by: Oliver Tale-Yazdi <[email protected]>
…rigin on destination (paritytech#5971) Built on top of paritytech#5876 # Description Currently, all XCM asset transfer instructions ultimately clear the origin in the remote XCM message by use of the `ClearOrigin` instruction. This is done for security considerations to ensure that subsequent (user-controlled) instructions cannot command the authority of the sending chain. The problem with this approach is that it limits what can be achieved on remote chains through XCM. Most XCM operations require having an origin, and following any asset transfer the origin is lost, meaning not much can be done other than depositing the transferred assets to some local account or transferring them onward to another chain. For example, we cannot transfer some funds for buying execution, then do a `Transact` (all in the same XCM message). In the case of XCM programs going from source-chain directly to dest-chain without an intermediary hop, we can enable scenarios such as above by using the AliasOrigin instruction instead of the ClearOrigin instruction. Instead of clearing the source-chain origin, the destination chain shall attempt to alias source-chain to "original origin" on the source chain. Most common such origin aliasing would be X1(Parachain(source-chain)) -> X2(Parachain(source-chain), AccountId32(origin-account)) for the case of a single hop transfer where the initiator is a (signed/pure/proxy) account origin-account on source-chain. This is equivalent to using the DescendOrigin instruction in this case, but also usable in the multi hop case. This allows an actor on chain A to Transact on chain B without having to prefund its SA account on chain B, instead they can simply transfer the required fees in the same XCM program as the Transact. As long as the asset transfer has the same XCM route/hops as the rest of the program, this pattern of usage can be composed across multiple hops, to ultimately Transact on the final hop using the original origin on the source chain, effectively abstracting away any intermediary hops. ### XCM `InitiateAssetsTransfer` instruction changes A new parameter `preserve_origin` to be added to the `InitiateAssetsTransfer` XCM instruction that specifies if the original origin should be preserved or cleared. ```diff InitiateAssetsTransfer { destination: Location, assets: Vec<AssetTransferFilter>, remote_fees: Option<AssetTransferFilter>, + preserve_origin: bool, remote_xcm: Xcm<()>, } ``` This parameter is explicitly necessary because the instruction should be usable between any two chains regardless of their origin-aliasing trust relationship. Preserving the origin requires some level of trust, while clearing it works regardless of that relationship. Specifying `preserve_origin: false` will always work regardless of the configured alias filters of the involved chains. # Testing - [x] e2e test: User on PenpalA registers foreign token (transacts) on PenpalB through XCM, while paying all fees using USDT (meaning XCM has to go through AssetHub) - AH carries over the original origin, effectively being a transparent proxy, - [x] e2e test: User/contract on Ethereum registers foreign token (transacts) on Polkadot-PenpalA through XCM (over bridge), while paying all fees using DOT (has to go through AssetHub) - AH carries over the original origin, effectively being a transparent proxy for Ethereum, --------- Signed-off-by: Adrian Catangiu <[email protected]> Co-authored-by: Francisco Aguirre <[email protected]> Co-authored-by: Branislav Kontur <[email protected]>
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.
No description provided.