Closed
Conversation
…ing the view (paritytech#7777) #### Description Avoid banning future/stale transactions reported as invalid by the authorship module. #### Note for reviewers When re-org is handled by transaction pool, the view for new fork (`Bn'`) is cloned from the tip of the other existing fork (`Bn`). The new view is not entirely re-validated during the maintain process (it will be revalidated in the background), so it may happen that it contains transactions that are ready on (`Bn`) but actually are not ready on (`Bn'`). All required (which are expected to be in retracted set) transactions are submitted to the new view, but order of txs in ready iterator is not updated. The proper fix would require to re-build the the iterator - which is not trivial as we do not have tags for transactions for block `Bn'` yet. We could force retracted txs to be before ready transactions but it also does not feel to be a good solution - it still would be best effort trial. For now allowing future transactions to re-enter the view immediately is in my opinion a good compromise. This PR is a quick fix and actually brings back behavior of txpool from before merging paritytech#6008. The bad thing is that incorrect transactions are detected during block authorship, but this situation to happen requires some specific pre-conditions which should be rare. If this PR is not merged, some transaction will get included into blocks, only after [`DEFAULT_BAN_TIME_SECS`](https://github.com/paritytech/polkadot-sdk/blob/4b39ff00b887039bc3e02a763a29deb09df56833/substrate/client/transaction-pool/src/graph/rotator.rs#L37), which is pretty bad. --------- Co-authored-by: cmd[bot] <41898282+github-actions[bot]@users.noreply.github.com>
…7959) Closes paritytech#7958 Resets the `payout.expire_at` field with the `PayoutPeriod` every time that there is a valid Payout attempt. --------- Co-authored-by: Victor Oliva <olivarra1@gmail.com>
…y where to do a backport based on labels (paritytech#7976) This PR changes the command-backport.yml flow so that the branch names are not hardcoded in the pipeline file but will be parsed from the labels. The idea is that there are going to be a label representing each stable branch: - A4-backport-stable2407 - A4-backport-stable2409 - A4-backport-stable2412 - A4-backport-stable2503 If the backport is needed to any of those branches or to all of them, the corresponding label can be set on the PR and the branch name will be parsed from it. The labels need to be created in the repo and adjusted as soon as there is a new release appears or an old one disappears.
…ritytech#7978) make macro in bp-runtime no longer require `sp-std` in scope. --------- Co-authored-by: cmd[bot] <41898282+github-actions[bot]@users.noreply.github.com>
We need to bump 2 runtime APIs to 13, because we are [backporting](paritytech#7824) validation code bomb API to 2412-4 patch which is supposed to be included in next fellowship release. Details here: paritytech#7824 (comment) Should only be merged if paritytech#7824 is merged in 2412-4 patch. Important note: on Westend, runtime needs to be upgraded first, then validators. --------- Signed-off-by: Andrei Sandu <andrei-mihail@parity.io> Co-authored-by: cmd[bot] <41898282+github-actions[bot]@users.noreply.github.com>
…h#7885) This PR modifies the archive_call method result to align with the rpc-v2 spec: - https://github.com/paritytech/json-rpc-interface-spec/blob/main/src/api/archive_unstable_call.md Previously, the method result was encoded to a json containing a "result" field, however the spec specifies a "value" field. This aims to rectify that. cc @paritytech/subxt-team --------- Signed-off-by: Alexandru Vasile <alexandru.vasile@parity.io> Co-authored-by: Niklas Adolfsson <niklasadolfsson1@gmail.com>
Bump zombienet-sdk version, including fixes for issues with init containers. Thx!
This PR Improves the weight metering for the `enqueue_xcmp_message()` method, by accounting for cached reads/writes and for the size of the enqueued messages --------- Co-authored-by: cmd[bot] <41898282+github-actions[bot]@users.noreply.github.com>
…ng PJS apps (paritytech#7671) This Pull Request fixes the following issues present with PJS derived from paritytech#2072 - Represents `Tracks` constant as a `Vec<(TrackId, TrackInfo)>` instead of `Vec<Track>`, so tracks iteration in PJS apps _Governance_ hook remains as how it was before, and  - Encapsulates `[u8; N]` from `name` field in a `StringLike` structure that represents its `TypeInfo` as a `&str` and encodes as such. This fixes errors present in PJS apps that treat `name` as a javascript `string`.  --------- Co-authored-by: Guillaume Thiolliere <gui.thiolliere@gmail.com> Co-authored-by: Oliver Tale-Yazdi <oliver.tale-yazdi@parity.io>
Currently parachains are injecting through the xcm-emulator the default digests in each block, something that can prevent testing certain consensus aspects. We propose to add the type `DigestProvider`, which needs to implement the trait `Convert<blockNumber, Digest>`. The idea is that we can call the implementation of this trait before initializing every block, and thus, allowing us to inject custom digests provided by this trait. Obviously the default behavior persists if you set this type to `().` The utilization of the `Convert` trait was arbitrary, as it was the easiest to accomplish the solution. I am not against using a custom trait defined for this purpose if that is preferred. --------- Co-authored-by: cmd[bot] <41898282+github-actions[bot]@users.noreply.github.com>
# Description Part of paritytech#3326 As per title, the `pallet:getter` usage has been removed from: - `pallet-xcm` - `xcm-simulator-fuzzer` Getters have been implemented manually for all storage items where an auto-generated one has been removed. polkadot address: 12poSUQPtcF1HUPQGY3zZu2P8emuW9YnsPduA4XG3oCEfJVp --------- Co-authored-by: Branislav Kontur <bkontur@gmail.com>
Upgrading these crates would help to remove tons of outdated (and obsoleted) dependencies. In addition, a small group of crates do not use workspace deps, I correct these. --------- Co-authored-by: Branislav Kontur <bkontur@gmail.com>
PR updates the contributor docs and adds commands to execute CI locally. cc paritytech/ci_cd#965
paritytech#7939) Revert the following PRs which we are pulling from release stable2503: - paritytech#7582 - paritytech#7424 - paritytech#7282 and leave pallet-staking in its pre-AHM state. ## Context We are forking pallet-staking into `pallet-staking` (also referred as staking-classic, this is the version that will stay on RC) and `pallet-staking-next` which will live on AH post AHM. Additional context: paritytech#7858 (comment) These changes in crate `pallet-staking` will become the staking classic. The staking next version is worked in the PR paritytech#7601. ## For AHM migration The `UnappliedSlashes` storage will need to be translated from `rc::staking-classic` to `ah::staking-next`. [Bookmarking](https://github.com/paritytech/polkadot-sdk/blob/master/substrate/frame/staking/src/migrations.rs#L91) the code that can be referred for this. ## Follow ups (cc: @tdimitrov and @seadanda ) 1) Revert pallet-staking v17 migration in westend. - Update `in code storage version` of pallet-staking storage from 17 to 16 (separate PR). - Update `on chain storage version` of pallet-staking storage from 17 to 16. The storage key for pallet-staking on chain version is `0x5f3e4907f716ac89b6347d15ececedca4e7b9012096b41c4eb3aaf947f6ea429` which should be set currently to `0x1100`, and needs to be updated to `0x1000`. - After the runtime upgrade with the code from this PR is deployed on Westend, kill the following storage prefixes under the Pallet prefix `Staking`: - OffenceQueue - OffenceQueueEras - ProcessingOffence - UnappliedSlashes: This also exists in staking-classic as a storage map (one key) and in pre-revert code as double storage map (two keys). Killing with prefix `UnappliedSlashes` may kill the ones created post upgrade (but that's okay for westend). - VoterSnapshotStatus - NextElectionPage - ElectableStashes 2) Remove exposure dependency Worked in the PR: paritytech#7936. --------- Co-authored-by: Tsvetomir Dimitrov <tsvetomir@parity.io> Co-authored-by: Maciej <maciej.zyszkiewicz@parity.io>
Implementation of the Snowbridge V2 [specification](https://github.com/paritytech/polkadot-sdk/blob/master/bridges/snowbridge/docs/v2.md). Companion PR for changes on the Ethereum side: Snowfork/snowbridge#1371 # High-level overview The implementation of V2 is additive and does not affect the V1 protocol in any manner. ## BridgeHub * Adds pallet `snowbridge-pallet-inbound-queue-v2` which is responsible for: * Receiving and verifying messages from Ethereum * Converting those messages to XCM * Forwarding the XCMs to AssetHub * Adds pallet `snowbridge-pallet-outbound-queue-v2` which is responsible for: * Receiving XCMs from AH or governance messages from `snowbridge-pallet-system-v2` * Converting those XCMs to messages that can be interpreted on Ethereum (our Gateway contract specifically) * Adds pallet `snowbridge-pallet-system-v2` which is the governance controlplane for V2 * The primitives crates for V1 and V2 have been refactored and consolidated: * Added pallet `snowbridge-inbound-queue-primitives` with all primitives for the inbound path for V1 and V2. * Added pallet `snowbridge-outbound-queue-primitives` with all primitives for the outbound path for V1 and V2. Note that much of the code for the inbound-queue and outbound-queue pallets is derived from the original V1 pallets. ## AssetHub * Adds pallet `snowbridge-pallet-system-frontend`. This pallet acts as a proxy for `snowbridge-pallet-system-v2` on BH, and allows any AH account to interface with the V2 controlplane without having to interact with BH in any manner. ## Supported messaging functionality ### Ethereum->Polkadot * Users can transfer up to 8 ERC20 tokens, as well as native ether * Users can provide an arbitrary xcm message The assets will placed into holding on AH, and the user-supplied XCM is responsible for handling those assets in holding. For reference, see the inbound message [format]( https://github.com/vgeddes/polkadot-sdk/blob/387c72546be38763a2d3c9b52c0f6cc1d8ac707e/bridges/snowbridge/primitives/inbound-queue/src/v2/message.rs#L101). ### Polkadot->Ethereum Users can provide an XCM that includes: * Transfers for up to 7 Polkadot-native or Ethereum-native assets registered on AH. * A single `Transact` instruction to call an Ethereum mainnet contract These XCM instructions are converted to a batch of commands that are executed on the Ethereum side. For reference, see the outbound message [format](https://github.com/vgeddes/polkadot-sdk/blob/387c72546be38763a2d3c9b52c0f6cc1d8ac707e/bridges/snowbridge/primitives/outbound-queue/src/v2/message.rs#L122) ## Relayer Incentivization BH holds wrapped ether that will be used to reward relayers for both the inbound and outbound directions. When a reward is marked as claimable, it can be minted on AH when the beneficiary desires to do so. ### Ethereum->Polkadot Users supply an an arbitrary reward in ether on Ethereum. This is included in the message sent to BH, where it added as a reward for the relayer. The relayer can claim these rewards on AH at a later point using the `pallet-bridge-relayers` API. ### Polkadot->Ethereum Users supply an an arbitrary reward in wrapped ether using their funds on AH. When the message is committed for delivery on BH, this reward is tracked in `outbound_queue_v2::PendingOrders[MessageNonce]` After a relayer has delivered the message to Ethereum and forwarded the delivery receipt back to `outbound-queue-v2`, the reward will be rendered claimable, and the relayer can claim these rewards on AH at a later point using the `pallet-bridge-relayers` API. --------- Signed-off-by: Adrian Catangiu <adrian@parity.io> Co-authored-by: claravanstaden <claravanstaden64@gmail.com> Co-authored-by: ron <yrong1997@gmail.com> Co-authored-by: Adrian Catangiu <adrian@parity.io>
…tytech#7993) paritytech#7988. The coretime-revenue test is the one remaining which uses static data types from the metadata for rococo and coretime-rococo. That test does some quite intricate event decoding which actually benefits from having static data types. Rewriting it using only dynamic types would actually be counterproductive and would complicate it
This PR updates outdated RELEASE.md file Addresses: paritytech#7188 --------- Co-authored-by: Michal Kucharczyk <1728078+michalkucharczyk@users.noreply.github.com> Co-authored-by: Iulian Barbu <14218860+iulianbarbu@users.noreply.github.com> Co-authored-by: Oliver Tale-Yazdi <oliver.tale-yazdi@parity.io>
…age item (paritytech#8024) Signed-off-by: Adrian Catangiu <adrian@parity.io> Co-authored-by: claravanstaden <claravanstaden64@gmail.com> Co-authored-by: Vincent Geddes <117534+vgeddes@users.noreply.github.com> Co-authored-by: Adrian Catangiu <adrian@parity.io>
Collaborator
Author
|
Closed in favor of paritytech#8038 |
This file contains hidden or 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
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
17 participants
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.
This update primarily focuses on testing PNA from third-party parachains, specifically the transfer of PAL, the native token of Penpal(i.e.
Here).The tests in this PR demonstrate that a one-click tranfer from Penpal to Ethereum is possible with a minor tweak to Penpal's runtime configuration. The first hop, from Penpal to AH is teleport-based, while the next hop, from AH to Ethereum is reserved-based.
The main challenge is that most of the Parachains don't allow teleporting native assets to AH-- e.g., Moonbeam, Bifrost, and Acala. Mythos is the only exception.
We need to finalize the approch to determine how to build the XCM to support one-click transfers for PNA, which could be possible in V2. However, if we do want to support it in V1, a potential upgrade path is: