Sergej Sakac
e6f3106d89
This PR introduces changes enabling the transfer of coretime regions via XCM. TL;DR: There are two primary issues that are resolved in this PR: 1. The `mint` and `burn` functions were not implemented for coretime regions. These operations are essential for moving assets to and from the XCM holding register. 2. The transfer of non-fungible assets through XCM was previously disallowed. This was due to incorrectly benchmarking non-fungible asset transfers via XCM, which led to assigning it a weight of `Weight::Max`, effectively preventing its execution. ### `mint_into` and `burn` implementation This PR addresses the issue with cross-chain transferring regions back to the Coretime chain. Remote reserve transfers are performed by withdrawing and depositing the asset to and from the holding registry. This requires the asset to support burning and minting functionality. This PR adds burning and minting; however, they work a bit differently than usual so that the associated region record is not lost when burning. Instead of removing all the data, burning will set the owner of the region to `None`, and when minting it back, it will set it to an actual value. So, when cross-chain transferring, withdrawing into the registry will remove the region from its original owner, and when depositing it from the registry, it will set its owner to another account This was originally implemented in this PR: #3455, however we decided to move all of it to this single PR (https://github.com/paritytech/polkadot-sdk/pull/3455#discussion_r1547324892) ### Fixes made in this PR - Update the `XcmReserveTransferFilter` on coretime chain since it is meant as a reserve chain for coretime regions. - Update the XCM benchmark to use `AssetTransactor` instead of assuming `pallet-balances` for fungible transfers. - Update the XCM benchmark to properly measure weight consumption for nonfungible reserve asset transfers. ATM reserve transfers via the extrinsic do not work since the weight for it is set to `Weight::max()`. Closes: https://github.com/paritytech/polkadot-sdk/issues/865 --------- Co-authored-by: Branislav Kontur <bkontur@gmail.com> Co-authored-by: Francisco Aguirre <franciscoaguirreperez@gmail.com> Co-authored-by: Dónal Murray <donalm@seadanda.dev>
Substrate
Substrate is a next-generation framework for blockchain innovation 🚀.
Getting Started
Head to docs.substrate.io and follow the installation
instructions. Then try out one of the tutorials. Refer to the Docker
instructions to quickly run Substrate, Substrate Node Template, Subkey, or to build a chain spec.
Community & Support
Join the highly active and supportive community on the Substrate Stack Exchange to ask questions about use and problems you run into using this software. Please do report bugs and issues here for anything you suspect requires action in the source.
Contributions & Code of Conduct
Please follow the contributions guidelines as outlined in docs/contributor/CONTRIBUTING.md.
In all communications and contributions, this project follows the Contributor Covenant Code of Conduct.
Security
The security policy and procedures can be found in
docs/contributor/SECURITY.md.
License
- Substrate Primitives (
sp-*), Frame (frame-*) and the pallets (pallets-*), binaries (/bin) and all other utilities are licensed under Apache 2.0. - Substrate Client (/client/*/sc-*) is licensed under GPL v3.0 with a classpath linking exception.
The reason for the split-licensing is to ensure that for the vast majority of teams using Substrate to create feature-chains, then all changes can be made entirely in Apache2-licensed code, allowing teams full freedom over what and how they release and giving licensing clarity to commercial teams.
In the interests of the community, we require any deeper improvements made to Substrate's core logic (e.g. Substrate's internal consensus, crypto or database code) to be contributed back so everyone can benefit.