- Mar 22, 2024
-
-
girazoki authored
Currently `transfer_assets` from pallet-xcm covers 4 main different transfer types: - `localReserve` - `DestinationReserve` - `Teleport` - `RemoteReserve` For the first three, the local execution and the remote message sending are separated, and fees are deducted in pallet-xcm itself: https://github.com/paritytech/polkadot-sdk/blob/3410dfb3929462da88be2da813f121d8b1cf46b3/polkadot/xcm/pallet-xcm/src/lib.rs#L1758 . For the 4th case `RemoteReserve`, pallet-xcm is still relying on the xcm-executor itself to send the message (through the `initiateReserveWithdraw` instruction). In this case, if delivery fees need to be charged, it is not possible to do so because the `jit_withdraw` mode has not being set. This PR proposes to still use the `initiateReserveWithdraw` but prepending a `setFeesMode { jit_withdraw: true }` to make sure delivery fees can be paid. A test-case is also added to present the aforementioned case --------- Co-authored-by:
Adrian Catangiu <[email protected]>
-
- Mar 21, 2024
-
-
Egor_P authored
This PR backports: - node version bump - `spec_vesion` bump - reordering of the `prdocs` to the appropriate folder from the `1.9.0` release branch
-
- Mar 20, 2024
-
-
s0me0ne-unkn0wn authored
This PR proposes enabling PoV reclaim on the `rococo-parachain` testchain to streamline testing and development of high-TPS stuff.
-
- Mar 19, 2024
-
-
Juan Ignacio Rios authored
Currently the xcm-executor returns an `Unimplemented` error if it receives any HRMP-related instruction. What I propose here, which is what we are currently doing in our forked executor at polimec, is to introduce a trait implemented by the executor which will handle those instructions. This way, if parachains want to keep the default behavior, they just use `()` and it will return unimplemented, but they can also implement their own logic to establish HRMP channels with other chains in an automated fashion, without requiring to go through governance. Our implementation is mentioned in the [polkadot HRMP docs](https://arc.net/l/quote/hduiivbu ), and it was suggested to us to submit a PR to add these changes to polkadot-sdk. --------- Co-authored-by:
Branislav Kontur <[email protected]> Co-authored-by: command-bot <>
-
- Mar 18, 2024
-
-
K Gunjan authored
Removed the `pallet::getter` macro call from storage type definitions and added the corresponding implementations directly. fixes #3330 polkadot address: 14JzTPPUd8x8phKi8qLxHgNTnTMg6DUukCLXoWprejkaHXPz --------- Co-authored-by:
Bastian Köcher <[email protected]>
-
- Mar 17, 2024
-
-
s0me0ne-unkn0wn authored
Totally removes the `experimental` feature. Closes #3648. --------- Co-authored-by:
Bastian Köcher <[email protected]>
-
- Mar 15, 2024
-
-
gupnik authored
Step in https://github.com/paritytech/polkadot-sdk/issues/171 This PR removes `as [disambiguation_path]` syntax from `derive_impl` usage across the polkadot-sdk as introduced in https://github.com/paritytech/polkadot-sdk/pull/3505
-
- Mar 14, 2024
-
-
Ignacio Palacios authored
Issues addressed in this PR: - Improve *Penpal* runtime: - Properly handled received assets. Previously, it treated `(1, Here)` as the local native currency, whereas it should be treated as a `ForeignAsset`. This wasn't a great example of standard Parachain behaviour, as no Parachain treats the system asset as the local currency. - Remove `AllowExplicitUnpaidExecutionFrom` the system. Again, this wasn't a great example of standard Parachain behaviour. - Move duplicated `ForeignAssetFeeAsExistentialDepositMultiplierFeeCharger` to `assets_common` crate. - Improve emulated tests: - Update *Penpal* tests to new runtime. - To simplify tests, register the reserve transferred, teleported, and system assets in *Penpal* and *AssetHub* genesis. This saves us from having to create the assets repeatedly for each test - Add missing test case: `reserve_transfer_assets_from_para_to_system_para`. - Cleanup. - Prevent integration tests crates imports from being re-exported, as they were polluting the `polkadot-sdk` docs. There is still a test case missing for reserve transfers: - Reserve transfer of system asset from *Parachain* to *Parachain* trough *AssetHub*. - This is not yet possible with `pallet-xcm` due to the reasons explained in https://github.com/paritytech/polkadot-sdk/pull/3339 --------- Co-authored-by: command-bot <>
-
- Mar 13, 2024
-
-
georgepisaltu authored
Revert "FRAME: Create `TransactionExtension` as a replacement for `SignedExtension` (#2280)" (#3665) This PR reverts #2280 which introduced `TransactionExtension` to replace `SignedExtension`. As a result of the discussion [here](https://github.com/paritytech/polkadot-sdk/pull/3623#issuecomment-1986789700 ), the changes will be reverted for now with plans to reintroduce the concept in the future. --------- Signed-off-by:
georgepisaltu <[email protected]>
-
- Mar 06, 2024
-
-
Branislav Kontur authored
The current `penpal` runtime utilizes the `EthereumLocation` parameter, which is employed for XCM emulated integration tests concerning the Rococo <> ETH bridge. It includes a hard-coded chainId for the Ethereum testnet utilized in Rococo. The `EthereumLocation` serves the purpose of aligning with the `TrustedReserves`. However, due to this hard-coded configuration, reusing `penpal` for testing various environments such as Kusama/Polkadot versus Ethereum bridge becomes unfeasible. This PR introduces the capability to easily customize the asset location for `TrustedReserves` without needing to know anything about Ethereum. ## TODO - [x] fix integration tests with `System::set_storage(CustomizableAssetFromSystemAssetHub::key(), <whatever-location-is-needed>)` @claravanstaden - [ ] ~~maybe add some helper function/macro to support `set_storage` for other runtimes (that we could reuse)~~ - [ ] Release patch for: `penpal-runtime` + emulated crate with `set_storage` support (if needed) - [ ] backport to 1.7.0 - [ ] backport to 1.8.0 --------- Co-authored-by:
Clara van Staden <[email protected]>
-
- Mar 04, 2024
-
-
Gavin Wood authored
Closes #2160 First part of [Extrinsic Horizon](https://github.com/paritytech/polkadot-sdk/issues/2415 ) Introduces a new trait `TransactionExtension` to replace `SignedExtension`. Introduce the idea of transactions which obey the runtime's extensions and have according Extension data (né Extra data) yet do not have hard-coded signatures. Deprecate the terminology of "Unsigned" when used for transactions/extrinsics owing to there now being "proper" unsigned transactions which obey the extension framework and "old-style" unsigned which do not. Instead we have __*General*__ for the former and __*Bare*__ for the latter. (Ultimately, the latter will be phased out as a type of transaction, and Bare will only be used for Inherents.) Types of extrinsic are now therefore: - Bare (no hardcoded signature, no Extra data; used to be known as "Unsigned") - Bare transactions (deprecated): Gossiped, validated with `ValidateUnsigned` (deprecated) and the `_bare_compat` bits of `TransactionExtension` (deprecated). - Inherents: Not gossiped, validated with `ProvideInherent`. - Extended (Extra data): Gossiped, validated via `TransactionExtension`. - Signed transactions (with a hardcoded signature). - General transactions (without a hardcoded signature). `TransactionExtension` differs from `SignedExtension` because: - A signature on the underlying transaction may validly not be present. - It may alter the origin during validation. - `pre_dispatch` is renamed to `prepare` and need not contain the checks present in `validate`. - `validate` and `prepare` is passed an `Origin` rather than a `AccountId`. - `validate` may pass arbitrary information into `prepare` via a new user-specifiable type `Val`. - `AdditionalSigned`/`additional_signed` is renamed to `Implicit`/`implicit`. It is encoded *for the entire transaction* and passed in to each extension as a new argument to `validate`. This facilitates the ability of extensions to acts as underlying crypto. There is a new `DispatchTransaction` trait which contains only default function impls and is impl'ed for any `TransactionExtension` impler. It provides several utility functions which reduce some of the tedium from using `TransactionExtension` (indeed, none of its regular functions should now need to be called directly). Three transaction version discriminator ("versions") are now permissible: - 0b000000100: Bare (used to be called "Unsigned"): contains Signature or Extra (extension data). After bare transactions are no longer supported, this will strictly identify an Inherents only. - 0b100000100: Old-school "Signed" Transaction: contains Signature and Extra (extension data). - 0b010000100: New-school "General" Transaction: contains Extra (extension data), but no Signature. For the New-school General Transaction, it becomes trivial for authors to publish extensions to the mechanism for authorizing an Origin, e.g. through new kinds of key-signing schemes, ZK proofs, pallet state, mutations over pre-authenticated origins or any combination of the above. ## Code Migration ### NOW: Getting it to build Wrap your `SignedExtension`s in `AsTransactionExtension`. This should be accompanied by renaming your aggregate type in line with the new terminology. E.g. Before: ```rust /// The SignedExtension to the basic transaction logic. pub type SignedExtra = ( /* snip */ MySpecialSignedExtension, ); /// Unchecked extrinsic type as expected by this runtime. pub type UncheckedExtrinsic = generic::UncheckedExtrinsic<Address, RuntimeCall, Signature, SignedExtra>; ``` After: ```rust /// The extension to the basic transaction logic. pub type TxExtension = ( /* snip */ AsTransactionExtension<MySpecialSignedExtension>, ); /// Unchecked extrinsic type as expected by this runtime. pub type UncheckedExtrinsic = generic::UncheckedExtrinsic<Address, RuntimeCall, Signature, TxExtension>; ``` You'll also need to alter any transaction building logic to add a `.into()` to make the conversion happen. E.g. Before: ```rust fn construct_extrinsic( /* snip */ ) -> UncheckedExtrinsic { let extra: SignedExtra = ( /* snip */ MySpecialSignedExtension::new(/* snip */), ); let payload = SignedPayload::new(call.clone(), extra.clone()).unwrap(); let signature = payload.using_encoded(|e| sender.sign(e)); UncheckedExtrinsic::new_signed( /* snip */ Signature::Sr25519(signature), extra, ) } ``` After: ```rust fn construct_extrinsic( /* snip */ ) -> UncheckedExtrinsic { let tx_ext: TxExtension = ( /* snip */ MySpecialSignedExtension::new(/* snip */).into(), ); let payload = SignedPayload::new(call.clone(), tx_ext.clone()).unwrap(); let signature = payload.using_encoded(|e| sender.sign(e)); UncheckedExtrinsic::new_signed( /* snip */ Signature::Sr25519(signature), tx_ext, ) } ``` ### SOON: Migrating to `TransactionExtension` Most `SignedExtension`s can be trivially converted to become a `TransactionExtension`. There are a few things to know. - Instead of a single trait like `SignedExtension`, you should now implement two traits individually: `TransactionExtensionBase` and `TransactionExtension`. - Weights are now a thing and must be provided via the new function `fn weight`. #### `TransactionExtensionBase` This trait takes care of anything which is not dependent on types specific to your runtime, most notably `Call`. - `AdditionalSigned`/`additional_signed` is renamed to `Implicit`/`implicit`. - Weight must be returned by implementing the `weight` function. If your extension is associated with a pallet, you'll probably want to do this via the pallet's existing benchmarking infrastructure. #### `TransactionExtension` Generally: - `pre_dispatch` is now `prepare` and you *should not reexecute the `validate` functionality in there*! - You don't get an account ID any more; you get an origin instead. If you need to presume an account ID, then you can use the trait function `AsSystemOriginSigner::as_system_origin_signer`. - You get an additional ticket, similar to `Pre`, called `Val`. This defines data which is passed from `validate` into `prepare`. This is important since you should not be duplicating logic from `validate` to `prepare`, you need a way of passing your working from the former into the latter. This is it. - This trait takes two type parameters: `Call` and `Context`. `Call` is the runtime call type which used to be an associated type; you can just move it to become a type parameter for your trait impl. `Context` is not currently used and you can safely implement over it as an unbounded type. - There's no `AccountId` associated type any more. Just remove it. Regarding `validate`: - You get three new parameters in `validate`; all can be ignored when migrating from `SignedExtension`. - `validate` returns a tuple on success; the second item in the tuple is the new ticket type `Self::Val` which gets passed in to `prepare`. If you use any information extracted during `validate` (off-chain and on-chain, non-mutating) in `prepare` (on-chain, mutating) then you can pass it through with this. For the tuple's last item, just return the `origin` argument. Regarding `prepare`: - This is renamed from `pre_dispatch`, but there is one change: - FUNCTIONALITY TO VALIDATE THE TRANSACTION NEED NOT BE DUPLICATED FROM `validate`!! - (This is different to `SignedExtension` which was required to run the same checks in `pre_dispatch` as in `validate`.) Regarding `post_dispatch`: - Since there are no unsigned transactions handled by `TransactionExtension`, `Pre` is always defined, so the first parameter is `Self::Pre` rather than `Option<Self::Pre>`. If you make use of `SignedExtension::validate_unsigned` or `SignedExtension::pre_dispatch_unsigned`, then: - Just use the regular versions of these functions instead. - Have your logic execute in the case that the `origin` is `None`. - Ensure your transaction creation logic creates a General Transaction rather than a Bare Transaction; this means having to include all `TransactionExtension`s' data. - `ValidateUnsigned` can still be used (for now) if you need to be able to construct transactions which contain none of the extension data, however these will be phased out in stage 2 of the Transactions Horizon, so you should consider moving to an extension-centric design. ## TODO - [x] Introduce `CheckSignature` impl of `TransactionExtension` to ensure it's possible to have crypto be done wholly in a `TransactionExtension`. - [x] Deprecate `SignedExtension` and move all uses in codebase to `TransactionExtension`. - [x] `ChargeTransactionPayment` - [x] `DummyExtension` - [x] `ChargeAssetTxPayment` (asset-tx-payment) - [x] `ChargeAssetTxPayment` (asset-conversion-tx-payment) - [x] `CheckWeight` - [x] `CheckTxVersion` - [x] `CheckSpecVersion` - [x] `CheckNonce` - [x] `CheckNonZeroSender` - [x] `CheckMortality` - [x] `CheckGenesis` - [x] `CheckOnlySudoAccount` - [x] `WatchDummy` - [x] `PrevalidateAttests` - [x] `GenericSignedExtension` - [x] `SignedExtension` (chain-polkadot-bulletin) - [x] `RefundSignedExtensionAdapter` - [x] Implement `fn weight` across the board. - [ ] Go through all pre-existing extensions which assume an account signer and explicitly handle the possibility of another kind of origin. - [x] `CheckNonce` should probably succeed in the case of a non-account origin. - [x] `CheckNonZeroSender` should succeed in the case of a non-account origin. - [x] `ChargeTransactionPayment` and family should fail in the case of a non-account origin. - [ ] - [x] Fix any broken tests. --------- Signed-off-by:
georgepisaltu <[email protected]> Signed-off-by:
Alexandru Vasile <[email protected]> Signed-off-by:
dependabot[bot] <[email protected]> Signed-off-by:
Oliver Tale-Yazdi <[email protected]> Signed-off-by:
Alexandru Gheorghe <[email protected]> Signed-off-by:
Andrei Sandu <[email protected]> Co-authored-by:
Nikhil Gupta <[email protected]> Co-authored-by:
georgepisaltu <[email protected]> Co-authored-by:
Chevdor <[email protected]> Co-authored-by:
Bastian Köcher <[email protected]> Co-authored-by:
Maciej <[email protected]> Co-authored-by:
Javier Viola <[email protected]> Co-authored-by:
Marcin S. <[email protected]> Co-authored-by:
Tsvetomir Dimitrov <[email protected]> Co-authored-by:
Javier Bullrich <[email protected]> Co-authored-by:
Koute <[email protected]> Co-authored-by:
Adrian Catangiu <[email protected]> Co-authored-by:
Vladimir Istyufeev <[email protected]> Co-authored-by:
Ross Bulat <[email protected]> Co-authored-by:
Gonçalo Pestana <[email protected]> Co-authored-by:
Liam Aharon <[email protected]> Co-authored-by:
Svyatoslav Nikolsky <[email protected]> Co-authored-by:
André Silva <[email protected]> Co-authored-by:
Oliver Tale-Yazdi <[email protected]> Co-authored-by:
s0me0ne-unkn0wn <[email protected]> Co-authored-by:
ordian <[email protected]> Co-authored-by:
Sebastian Kunert <[email protected]> Co-authored-by:
Aaro Altonen <[email protected]> Co-authored-by:
Dmitry Markin <[email protected]> Co-authored-by:
Alexandru Vasile <[email protected]> Co-authored-by:
Alexander Samusev <[email protected]> Co-authored-by:
Julian Eager <[email protected]> Co-authored-by:
Michal Kucharczyk <[email protected]> Co-authored-by:
Davide Galassi <[email protected]> Co-authored-by:
Dónal Murray <[email protected]> Co-authored-by:
yjh <[email protected]> Co-authored-by:
Tom Mi <[email protected]> Co-authored-by:
dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com> Co-authored-by:
Will | Paradox | ParaNodes.io <[email protected]> Co-authored-by:
Bastian Köcher <[email protected]> Co-authored-by:
Joshy Orndorff <[email protected]> Co-authored-by:
Joshy Orndorff <[email protected]> Co-authored-by:
PG Herveou <[email protected]> Co-authored-by:
Alexander Theißen <[email protected]> Co-authored-by:
Kian Paimani <[email protected]> Co-authored-by:
Juan Girini <[email protected]> Co-authored-by:
bader y <[email protected]> Co-authored-by:
James Wilson <[email protected]> Co-authored-by:
joe petrowski <[email protected]> Co-authored-by:
asynchronous rob <[email protected]> Co-authored-by:
Parth <[email protected]> Co-authored-by:
Andrew Jones <[email protected]> Co-authored-by:
Jonathan Udd <[email protected]> Co-authored-by:
Serban Iorga <[email protected]> Co-authored-by:
Egor_P <[email protected]> Co-authored-by:
Branislav Kontur <[email protected]> Co-authored-by:
Evgeny Snitko <[email protected]> Co-authored-by:
Just van Stam <[email protected]> Co-authored-by:
Francisco Aguirre <[email protected]> Co-authored-by:
gupnik <[email protected]> Co-authored-by:
dzmitry-lahoda <[email protected]> Co-authored-by:
zhiqiangxu <[email protected]> Co-authored-by:
Nazar Mokrynskyi <[email protected]> Co-authored-by:
Anwesh <[email protected]> Co-authored-by:
cheme <[email protected]> Co-authored-by:
Sam Johnson <[email protected]> Co-authored-by:
kianenigma <[email protected]> Co-authored-by:
Jegor Sidorenko <[email protected]> Co-authored-by:
Muharem <[email protected]> Co-authored-by:
joepetrowski <[email protected]> Co-authored-by:
Alexandru Gheorghe <[email protected]> Co-authored-by:
Gabriel Facco de Arruda <[email protected]> Co-authored-by:
Squirrel <[email protected]> Co-authored-by:
Andrei Sandu <[email protected]> Co-authored-by:
georgepisaltu <[email protected]> Co-authored-by: command-bot <>
-
- Mar 01, 2024
-
-
Egor_P authored
This PR backports Node version and `spec_version` bumps to `1.8.0` from the latest release and orders prdoc files related to it.
-
- Feb 28, 2024
-
-
Oliver Tale-Yazdi authored
This MR is the merge of https://github.com/paritytech/substrate/pull/14414 and https://github.com/paritytech/substrate/pull/14275. It implements [RFC#13](https://github.com/polkadot-fellows/RFCs/pull/13), closes https://github.com/paritytech/polkadot-sdk/issues/198. ----- This Merge request introduces three major topicals: 1. Multi-Block-Migrations 1. New pallet `poll` hook for periodic service work 1. Replacement hooks for `on_initialize` and `on_finalize` in cases where `poll` cannot be used and some more general changes to FRAME. The changes for each topical span over multiple crates. They are listed in topical order below. # 1.) Multi-Block-Migrations Multi-Block-Migrations are facilitated by creating `pallet_migrations` and configuring `System::Config::MultiBlockMigrator` to point to it. Executive picks this up and triggers one step of the migrations pallet per block. The chain is in lockdown mode for as long as an MBM is ongoing. Executive does this by polling `MultiBlockMigrator::ongoing` and not allowing any transaction in a block, if true. A MBM is defined through trait `SteppedMigration`. A condensed version looks like this: ```rust /// A migration that can proceed in multiple steps. pub trait SteppedMigration { type Cursor: FullCodec + MaxEncodedLen; type Identifier: FullCodec + MaxEncodedLen; fn id() -> Self::Identifier; fn max_steps() -> Option<u32>; fn step( cursor: Option<Self::Cursor>, meter: &mut WeightMeter, ) -> Result<Option<Self::Cursor>, SteppedMigrationError>; } ``` `pallet_migrations` can be configured with an aggregated tuple of these migrations. It then starts to migrate them one-by-one on the next runtime upgrade. Two things are important here: - 1. Doing another runtime upgrade while MBMs are ongoing is not a good idea and can lead to messed up state. - 2. **Pallet Migrations MUST BE CONFIGURED IN `System::Config`, otherwise it is not used.** The pallet supports an `UpgradeStatusHandler` that can be used to notify external logic of upgrade start/finish (for example to pause XCM dispatch). Error recovery is very limited in the case that a migration errors or times out (exceeds its `max_steps`). Currently the runtime dev can decide in `FailedMigrationHandler::failed` how to handle this. One follow-up would be to pair this with the `SafeMode` pallet and enact safe mode when an upgrade fails, to allow governance to rescue the chain. This is currently not possible, since governance is not `Mandatory`. ## Runtime API - `Core`: `initialize_block` now returns `ExtrinsicInclusionMode` to inform the Block Author whether they can push transactions. ### Integration Add it to your runtime implementation of `Core` and `BlockBuilder`: ```patch diff --git a/runtime/src/lib.rs b/runtime/src/lib.rs @@ impl_runtime_apis! { impl sp_block_builder::Core<Block> for Runtime { - fn initialize_block(header: &<Block as BlockT>::Header) { + fn initialize_block(header: &<Block as BlockT>::Header) -> RuntimeExecutiveMode { Executive::initialize_block(header) } ... } ``` # 2.) `poll` hook A new pallet hook is introduced: `poll`. `Poll` is intended to replace mostly all usage of `on_initialize`. The reason for this is that any code that can be called from `on_initialize` cannot be migrated through an MBM. Currently there is no way to statically check this; the implication is to use `on_initialize` as rarely as possible. Failing to do so can result in broken storage invariants. The implementation of the poll hook depends on the `Runtime API` changes that are explained above. # 3.) Hard-Deadline callbacks Three new callbacks are introduced and configured on `System::Config`: `PreInherents`, `PostInherents` and `PostTransactions`. These hooks are meant as replacement for `on_initialize` and `on_finalize` in cases where the code that runs cannot be moved to `poll`. The reason for this is to make the usage of HD-code (hard deadline) more explicit - again to prevent broken invariants by MBMs. # 4.) FRAME (general changes) ## `frame_system` pallet A new memorize storage item `InherentsApplied` is added. It is used by executive to track whether inherents have already been applied. Executive and can then execute the MBMs directly between inherents and transactions. The `Config` gets five new items: - `SingleBlockMigrations` this is the new way of configuring migrations that run in a single block. Previously they were defined as last generic argument of `Executive`. This shift is brings all central configuration about migrations closer into view of the developer (migrations that are configured in `Executive` will still work for now but is deprecated). - `MultiBlockMigrator` this can be configured to an engine that drives MBMs. One example would be the `pallet_migrations`. Note that this is only the engine; the exact MBMs are injected into the engine. - `PreInherents` a callback that executes after `on_initialize` but before inherents. - `PostInherents` a callback that executes after all inherents ran (including MBMs and `poll`). - `PostTransactions` in symmetry to `PreInherents`, this one is called before `on_finalize` but after all transactions. A sane default is to set all of these to `()`. Example diff suitable for any chain: ```patch @@ impl frame_system::Config for Test { type MaxConsumers = ConstU32<16>; + type SingleBlockMigrations = (); + type MultiBlockMigrator = (); + type PreInherents = (); + type PostInherents = (); + type PostTransactions = (); } ``` An overview of how the block execution now looks like is here. The same graph is also in the rust doc. <details><summary>Block Execution Flow</summary> <p> ![Screenshot 2023-12-04 at 19 11 29](https://github.com/paritytech/polkadot-sdk/assets/10380170/e88a80c4-ef11-4faa-8df5-8b33a724c054) </p> </details> ## Inherent Order Moved to https://github.com/paritytech/polkadot-sdk/pull/2154 --------------- ## TODO - [ ] Check that `try-runtime` still works - [ ] Ensure backwards compatibility with old Runtime APIs - [x] Consume weight correctly - [x] Cleanup --------- Signed-off-by:
Oliver Tale-Yazdi <[email protected]> Co-authored-by:
Liam Aharon <[email protected]> Co-authored-by:
Juan Girini <[email protected]> Co-authored-by: command-bot <> Co-authored-by:
Francisco Aguirre <[email protected]> Co-authored-by:
Gavin Wood <[email protected]> Co-authored-by:
Bastian Köcher <[email protected]>
-
- Feb 20, 2024
-
-
Branislav Kontur authored
-
- Feb 13, 2024
-
-
Branislav Kontur authored
I found out during the cleanup of this deprecation message in the `polkadot-fellows` repository that we deprecated `CurrencyAdapter` without making the recommended changes. ## TODO - [ ] fix `polkadot-fellows` bump to 1.6.0 https://github.com/polkadot-fellows/runtimes/pull/159 --------- Co-authored-by:
Francisco Aguirre <[email protected]>
-
- Feb 12, 2024
-
-
Oliver Tale-Yazdi authored
Changes (partial https://github.com/paritytech/polkadot-sdk/issues/994): - Set log to `0.4.20` everywhere - Lift `log` to the workspace Starting with a simpler one after seeing https://github.com/paritytech/polkadot-sdk/pull/2065 from @jsdw . This sets the `default-features` to `false` in the root and then overwrites that in each create to its original value. This is necessary since otherwise the `default` features are additive and its impossible to disable them in the crate again once they are enabled in the workspace. I am using a tool to do this, so its mostly a test to see that it works as expected. --------- Signed-off-by:
Oliver Tale-Yazdi <[email protected]>
-
- Feb 09, 2024
-
-
Egor_P authored
This PR backports version bumps from `1.7.0` release branch and moves related prdoc files to the appropriate folder.
-
- Jan 31, 2024
-
-
Adrian Catangiu authored
This fix aims to solve an issue in Kusama that resulted in failed reserve asset transfers. During multi-hop XCMs, like reserve asset transfers where the reserve is not the sender nor the destination, but a third remote chain, the origin is not available to pay for delivery fees out of their account directly, so delivery fees should be paid out of transferred assets. This commit also adds an xcm-emulator regression test that validates this scenario is now working. Signed-off-by:
Adrian Catangiu <[email protected]> Co-authored-by:
Francisco Aguirre <[email protected]>
-
Branislav Kontur authored
[frame] `#[pallet::composite_enum]` improved variant count handling + removed `pallet_balances`'s `MaxHolds` config (#2657) I started this investigation/issue based on @liamaharon question [here](https://github.com/paritytech/polkadot-sdk/pull/1801#discussion_r1410452499). ## Problem The `pallet_balances` integrity test should correctly detect that the runtime has correct distinct `HoldReasons` variant count. I assume the same situation exists for RuntimeFreezeReason. It is not a critical problem, if we set `MaxHolds` with a sufficiently large value, everything should be ok. However, in this case, the integrity_test check becomes less useful. **Situation for "any" runtime:** - `HoldReason` enums from different pallets: ```rust /// from pallet_nis #[pallet::composite_enum] pub enum HoldReason { NftReceipt, } /// from pallet_preimage #[pallet::composite_enum] pub enum HoldReason { Preimage, } // from pallet_state-trie-migration #[pallet::composite_enum] pub enum HoldReason { SlashForContinueMigrate, SlashForMigrateCustomTop, SlashForMigrateCustomChild, } ``` - generated `RuntimeHoldReason` enum looks like: ```rust pub enum RuntimeHoldReason { #[codec(index = 32u8)] Preimage(pallet_preimage::HoldReason), #[codec(index = 38u8)] Nis(pallet_nis::HoldReason), #[codec(index = 42u8)] StateTrieMigration(pallet_state_trie_migration::HoldReason), } ``` - composite enum `RuntimeHoldReason` variant count is detected as `3` - we set `type MaxHolds = ConstU32<3>` - `pallet_balances::integrity_test` is ok with `3`(at least 3) However, the real problem can occur in a live runtime where some functionality might stop working. This is due to a total of 5 distinct hold reasons (for pallets with multi-instance support, it is even more), and not all of them can be used because of an incorrect `MaxHolds`, which is deemed acceptable according to the `integrity_test`: ``` // pseudo-code - if we try to call all of these: T::Currency::hold(&pallet_nis::HoldReason::NftReceipt.into(), &nft_owner, deposit)?; T::Currency::hold(&pallet_preimage::HoldReason::Preimage.into(), &nft_owner, deposit)?; T::Currency::hold(&pallet_state_trie_migration::HoldReason::SlashForContinueMigrate.into(), &nft_owner, deposit)?; // With `type MaxHolds = ConstU32<3>` these two will fail T::Currency::hold(&pallet_state_trie_migration::HoldReason::SlashForMigrateCustomTop.into(), &nft_owner, deposit)?; T::Currency::hold(&pallet_state_trie_migration::HoldReason::SlashForMigrateCustomChild.into(), &nft_owner, deposit)?; ``` ## Solutions A macro `#[pallet::*]` expansion is extended of `VariantCount` implementation for the `#[pallet::composite_enum]` enum type. This expansion generates the `VariantCount` implementation for pallets' `HoldReason`, `FreezeReason`, `LockId`, and `SlashReason`. Enum variants must be plain enum values without fields to ensure a deterministic count. The composite runtime enum, `RuntimeHoldReason` and `RuntimeFreezeReason`, now sets `VariantCount::VARIANT_COUNT` as the sum of pallets' enum `VariantCount::VARIANT_COUNT`: ```rust #[frame_support::pallet(dev_mode)] mod module_single_instance { #[pallet::composite_enum] pub enum HoldReason { ModuleSingleInstanceReason1, ModuleSingleInstanceReason2, } ... } #[frame_support::pallet(dev_mode)] mod module_multi_instance { #[pallet::composite_enum] pub enum HoldReason<I: 'static = ()> { ModuleMultiInstanceReason1, ModuleMultiInstanceReason2, ModuleMultiInstanceReason3, } ... } impl self::sp_api_hidden_includes_construct_runtime::hidden_include::traits::VariantCount for RuntimeHoldReason { const VARIANT_COUNT: u32 = 0 + module_single_instance::HoldReason::VARIANT_COUNT + module_multi_instance::HoldReason::<module_multi_instance::Instance1>::VARIANT_COUNT + module_multi_instance::HoldReason::<module_multi_instance::Instance2>::VARIANT_COUNT + module_multi_instance::HoldReason::<module_multi_instance::Instance3>::VARIANT_COUNT; } ``` In addition, `MaxHolds` is removed (as suggested [here](https://github.com/paritytech/polkadot-sdk/pull/2657#discussion_r1443324573)) from `pallet_balances`, and its `Holds` are now bounded to `RuntimeHoldReason::VARIANT_COUNT`. Therefore, there is no need to let the runtime specify `MaxHolds`. ## For reviewers Relevant changes can be found here: - `substrate/frame/support/procedural/src/lib.rs` - `substrate/frame/support/procedural/src/pallet/parse/composite.rs` - `substrate/frame/support/procedural/src/pallet/expand/composite.rs` - `substrate/frame/support/procedural/src/construct_runtime/expand/composite_helper.rs` - `substrate/frame/support/procedural/src/construct_runtime/expand/hold_reason.rs` - `substrate/frame/support/procedural/src/construct_runtime/expand/freeze_reason.rs` - `substrate/frame/support/src/traits/misc.rs` And the rest of the files is just about removed `MaxHolds` from `pallet_balances` ## Next steps Do the same for `MaxFreezes` https://github.com/paritytech/polkadot-sdk/issues/2997 . --------- Co-authored-by: command-bot <> Co-authored-by:
Bastian Köcher <[email protected]> Co-authored-by:
Dónal Murray <[email protected]> Co-authored-by:
gupnik <[email protected]>
-
Branislav Kontur authored
The `parachains-common` contains a lots of constants and type definitions which are used for `polkadot-sdk`'s testnet runtimes and also for `polkadot-fellows`'s production [SP runtimes](https://github.com/polkadot-fellows/runtimes/tree/main/system-parachains/constants). This PR cleans `parachains-common` module to contain only common and generic functionality. Testnet-specific constants have been moved to the separate module dedicated just for testnets: `polkadot-sdk/cumulus/parachains/runtimes/constants/` Part of: https://github.com/paritytech/polkadot-sdk/issues/3054 --------- Co-authored-by:
georgepisaltu <[email protected]>
-
- Jan 30, 2024
-
-
Oliver Tale-Yazdi authored
Reverts paritytech/polkadot-sdk#2302.
🤦 ♂️ should have checked the migration CI first. We either need to reduce the `max_message_size` for the open HRMP channels on the failing chains or increase the `PageSize` of the XCMP queue. Both would be fine on a test-net, but i assume this will also fail before the next SP runtime upgrade so first need to think what best to do. AFAIK its not possible currently to change the `max_message_size` of an open HRMP channel.
-
- Jan 29, 2024
-
-
Oliver Tale-Yazdi authored
Remove `without_storage_info` from the XCMP queue pallet. Part of https://github.com/paritytech/polkadot-sdk/issues/323 Changes: - Limit the number of channels that can be suspended at the same time. - Limit the number of channels that can have messages or signals pending at the same time. A No-OP migration is put in place to ensure that all `BoundedVec`s still decode and not truncate after upgrade. The storage version is thereby bumped to 4 to have our tooling remind us to deploy that migration. --------- Signed-off-by:
Oliver Tale-Yazdi <[email protected]> Co-authored-by:
Francisco Aguirre <[email protected]>
-
- Jan 26, 2024
-
-
Liam Aharon authored
Related https://github.com/paritytech/polkadot-sdk/issues/3032 --- Using https://github.com/liamaharon/cargo-workspace-version-tools/ `cargo run -- sync --path ../polkadot-sdk` --------- Signed-off-by:
Oliver Tale-Yazdi <[email protected]> Co-authored-by:
Oliver Tale-Yazdi <[email protected]>
-
- Jan 24, 2024
-
-
Just van Stam authored
Moved from: https://github.com/paritytech/polkadot/pull/6951 closes https://github.com/paritytech/polkadot-sdk/issues/490 - [x] update cumulus --- This PR introduces transactional processing of certain xcm instructions. For the list of instructions checkout https://github.com/paritytech/polkadot-sdk/issues/490. The transactional processing is implemented as an xcm-executor config item. The two implementations in this PR are `FrameTransactionalProcessor` and `()`. The `()` implementation does no transactional processing. Each implementation of the `ProcessTransaction` trait has an `IS_TRANSACTIONAL` const that tells the XCVM if transactional processing is actually implemented. If Transactional processing is implemented, changes to touched registers should also be rolled back to prevent inconsistencies. Note for reviewers: Check out the following safety assumption: https://github.com/paritytech/polkadot-sdk/pull/1222/files#diff-4effad7d8c1c9de19fd27e18661cbf2128c8718f3b2420a27d2f816e0749ea53R30 --------- Co-authored-by:
Keith Yeung <[email protected]> Co-authored-by:
Francisco Aguirre <[email protected]> Co-authored-by: command-bot <>
-
Branislav Kontur authored
This PR avoids automatically pulling rococo/westend runtime constants into the runtime by default. Usually, we have testnet runtimes dedicated to rococo or westend, and therefore, we don't need both dependencies. Additionally, it prevents pulling rococo/westend-related items into the `polkadot-fellows` repo, as seen in the Cargo.lock [here](https://github.com/polkadot-fellows/runtimes/blob/main/Cargo.lock#L14137-L14151) and [here](https://github.com/polkadot-fellows/runtimes/blob/main/Cargo.lock#L9756-L9770 ). --------- Co-authored-by:
Adrian Catangiu <[email protected]>
-
- Jan 23, 2024
-
-
Branislav Kontur authored
There were several improvements and PRs that didn't apply to all runtimes, so this PR attempts to align those small differences. In addition, the PR eliminates unused dependencies across multiple modules. Relates to PR for `polkadot-fellows`: https://github.com/polkadot-fellows/runtimes/pull/154
-
- Jan 22, 2024
-
-
joe petrowski authored
Clean up all the old syntax. --------- Co-authored-by: command-bot <> Co-authored-by:
gupnik <[email protected]> Co-authored-by:
Nikhil Gupta <[email protected]> Co-authored-by:
Maksym H <[email protected]>
-
- Jan 17, 2024
-
-
Egor_P authored
This PR backports version bumps from release branch `release-polkadot-v1.6.0` back to `master` and also moved `prdoc` files related to the release to the appropriate folder
-
- Jan 16, 2024
-
-
Francisco Aguirre authored
# Note for reviewer Most changes are just syntax changes necessary for the new version. Most important files should be the ones under the `xcm` folder. # Description Added XCMv4. ## Removed `Multi` prefix The following types have been renamed: - MultiLocation -> Location - MultiAsset -> Asset - MultiAssets -> Assets - InteriorMultiLocation -> InteriorLocation - MultiAssetFilter -> AssetFilter - VersionedMultiAsset -> VersionedAsset - WildMultiAsset -> WildAsset - VersionedMultiLocation -> VersionedLocation In order to fix a name conflict, the `Assets` in `xcm-executor` were renamed to `HoldingAssets`, as they represent assets in holding. ## Removed `Abstract` asset id It was not being used anywhere and this simplifies the code. Now assets are just constructed as follows: ```rust let asset: Asset = (AssetId(Location::new(1, Here)), 100u128).into(); ``` No need for specifying `Concrete` anymore. ## Outcome is now a named fields struct Instead of ```rust pub enum Outcome { Complete(Weight), Incomplete(Weight, Error), Error(Error), } ``` we now have ```rust pub enum Outcome { Complete { used: Weight }, Incomplete { used: Weight, error: Error }, Error { error: Error }, } ``` ## Added Reanchorable trait Now both locations and assets implement this trait, making it easier to reanchor both. ## New syntax for building locations and junctions Now junctions are built using the following methods: ```rust let location = Location { parents: 1, interior: [Parachain(1000), PalletInstance(50), GeneralIndex(1984)].into() }; ``` or ```rust let location = Location::new(1, [Parachain(1000), PalletInstance(50), GeneralIndex(1984)]); ``` And they are matched like so: ```rust match location.unpack() { (1, [Parachain(id)]) => ... (0, Here) => ..., (1, [_]) => ..., } ``` This syntax is mandatory in v4, and has been also implemented for v2 and v3 for easier migration. This was needed to make all sizes smaller. # TODO - [x] Scaffold v4 - [x] Port github.com/paritytech/polkadot/pull/7236 - [x] Remove `Multi` prefix - [x] Remove `Abstract` asset id --------- Co-authored-by: command-bot <> Co-authored-by:
Keith Yeung <[email protected]>
-
- Jan 10, 2024
-
-
Clara van Staden authored
- updates snowbridge crates to `0.9.0` - updates Cargo.toml files in preparation for publishing to crates.io - adds Kusama and Polkadot Snowbridge runtime config crates - moves runtime tests from the Snowbridge subtree into the bridge hub tests dir --------- Co-authored-by: claravanstaden <Cats 4 life!> Co-authored-by:
Ron <[email protected]>
-
- Dec 28, 2023
-
-
Sophia Gold authored
Adds the fix in https://github.com/paritytech/polkadot-sdk/pull/2039 to the rococo-parachain runtime.
-
- Dec 21, 2023
-
-
Clara van Staden authored
# Description Adds Snowbridge to the Rococo bridge hub runtime. Includes config changes required in Rococo asset hub. --------- Co-authored-by:
Alistair Singh <[email protected]> Co-authored-by:
ron <[email protected]> Co-authored-by:
Vincent Geddes <[email protected]> Co-authored-by: claravanstaden <Cats 4 life!>
-
- Dec 18, 2023
-
-
Branislav Kontur authored
This PR contains just a few clippy fixes and nits, which are, however, relaxed by workspace clippy settings here: https://github.com/paritytech/polkadot-sdk/blob/master/Cargo.toml#L483-L506 --------- Co-authored-by:
Dmitry Sinyavin <[email protected]> Co-authored-by:
ordian <[email protected]> Co-authored-by: command-bot <> Co-authored-by:
Bastian Köcher <[email protected]>
-
- Dec 14, 2023
-
-
Francisco Aguirre authored
In the move from the old `Currency` traits to the new `fungible/s` family of traits, we already had the `FungiblesAdapter` and `NonFungiblesAdapter` for multiple fungible and non fungible assets respectively. However, for handling only one fungible asset, we were missing a `FungibleAdapter`, and so used the old `CurrencyAdapter` instead. This PR aims to fill in that gap, and provide the new adapter for more updated examples. I marked the old `CurrencyAdapter` as deprecated as part of this PR, and I'll change it to the new `FungibleAdapter` in a following PR. The two stages are separated so as to not bloat this PR with some name fixes in tests. --------- Co-authored-by: command-bot <>
-
- Dec 13, 2023
-
-
Squirrel authored
We currently use a bit of a hack in `.cargo/config` to make sure that clippy isn't too annoying by specifying the list of lints. There is now a stable way to define lints for a workspace. The only down side is that every crate seems to have to opt into this so there's a *few* files modified in this PR. Dependencies: - [x] PR that upgrades CI to use rust 1.74 is merged. --------- Co-authored-by:
joe petrowski <[email protected]> Co-authored-by:
Branislav Kontur <[email protected]> Co-authored-by:
Liam Aharon <[email protected]>
-
- Dec 12, 2023
-
-
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]>
-
- Dec 06, 2023
-
-
Adrian Catangiu authored
# Motivation (+testing) ### Enable easy `ForeignAssets` transfers using `pallet-xcm` We had just previously added capabilities to teleport fees during reserve-based transfers, but what about reserve-transferring fees when needing to teleport some non-fee asset? This PR aligns everything under either explicit reserve-transfer, explicit teleport, or this new flexible `transfer_assets()` which can mix and match as needed with fewer artificial constraints imposed to the user. This will enable, for example, a (non-system) parachain to teleport their `ForeignAssets` assets to AssetHub while using DOT to pay fees. (the assets are teleported - as foreign assets should from their owner chain - while DOT used for fees can only be reserve-based transferred between said parachain and AssetHub). Added `xcm-emulator` tests for this scenario ^. # Description Reverts `(limited_)reserve_transfer_assets` to only allow reserve-based transfers for all `assets` including fees. Similarly `(limited_)teleport_assets` only allows teleports for all `assets` including fees. For complex combinations of asset transfers where assets and fees may have different reserves or different reserve/teleport trust configurations, users can use the newly added `transfer_assets()` extrinsic which is more flexible in allowing more complex scenarios. `assets` (excluding `fees`) must have same reserve location or otherwise be teleportable to `dest`. No limitations imposed on `fees`. - for local reserve: transfer assets to sovereign account of destination chain and forward a notification XCM to `dest` to mint and deposit reserve-based assets to `beneficiary`. - for destination reserve: 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`. - for remote 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`. - for teleports: burn local assets and forward XCM to `dest` chain to mint/teleport assets and deposit them to `beneficiary`. ## Review notes Only around 500 lines are prod code (see `pallet_xcm/src/lib.rs`), the rest of the PR is new tests and improving existing tests. --------- Co-authored-by: command-bot <>
-
- Dec 01, 2023
-
-
Liam Aharon authored
Using taplo, fixes all our broken and inconsistent toml formatting and adds CI to keep them tidy. If people want we can customise the format rules as described here https://taplo.tamasfe.dev/configuration/formatter-options.html @ggwpez , I suggest zepter is used only for checking features are propagated, and leave formatting for taplo to avoid duplicate work and conflicts. TODO - [x] Use `exclude = [...]` syntax in taplo file to ignore zombienet tests instead of deleting the dir --------- Signed-off-by:
Oliver Tale-Yazdi <[email protected]> Co-authored-by:
Oliver Tale-Yazdi <[email protected]> Co-authored-by:
Bastian Köcher <[email protected]>
-
- Nov 28, 2023
-
-
gupnik authored
Step in https://github.com/paritytech/polkadot-sdk/issues/171 This PR adds `derive_impl` on all `frame_system` config impls for mock runtimes. The overridden configs are maintained as of now to ensure minimal changes. --------- Co-authored-by:
Oliver Tale-Yazdi <[email protected]>
-
- Nov 27, 2023
-
-
Chevdor authored
## Overview This PR aligns the `spec_version` formatting to the [recent changes](https://github.com/polkadot-fellows/runtimes/pull/26/files#diff-efa4caeb17487ecb13d8f5eb7863c3241d84afa2e73fbf25909a2ca89df0f362R142 ) made for the Polkadot/Kusama runtimes. It also backports the latest version `v1.4.0` bumps as `1_004_000`. ## Details During the switch from `v0.9` to `v1.x`, the format of the `spec_version` was modified from: `(M)m_ppp` for a runtime considered on version `M.m.pp`. For instance `0.9.42` had a `spec_version` of `9420`. With the transition to `v1.x`, the format was changed to a bigger number (still `u32`) formatted as `MM_mm_ppp` where `1.2.3` would be stored as `01_02_003`. This PR aligns the format with that has been introduced in the fellowship repo: `MMM_mmm_ppp`. --------- Co-authored-by:
Bastian Köcher <[email protected]>
-