mirror of
https://github.com/pezkuwichain/pezkuwi-subxt.git
synced 2026-06-17 02:01:02 +00:00
Branislav Kontur
bb8ddc46c1
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 <git@kchr.de> Co-authored-by: Dónal Murray <donal.murray@parity.io> Co-authored-by: gupnik <nikhilgupta.iitk@gmail.com>
NFTs pallet
A pallet for dealing with non-fungible assets.
Overview
The NFTs pallet provides functionality for non-fungible tokens' management, including:
- Collection Creation
- NFT Minting
- NFT Transfers and Atomic Swaps
- NFT Trading methods
- Attributes Management
- NFT Burning
To use it in your runtime, you need to implement
nfts::Config.
The supported dispatchable functions are documented in the
nfts::Call enum.
Terminology
- Collection creation: The creation of a new collection.
- NFT minting: The action of creating a new item within a collection.
- NFT transfer: The action of sending an item from one account to another.
- Atomic swap: The action of exchanging items between accounts without needing a 3rd party service.
- NFT burning: The destruction of an item.
- Non-fungible token (NFT): An item for which each unit has unique characteristics. There is exactly one instance of such an item in existence and there is exactly one owning account (though that owning account could be a proxy account or multi-sig account).
- Soul Bound NFT: An item that is non-transferable from the account which it is minted into.
Goals
The NFTs pallet in Substrate is designed to make the following possible:
- Allow accounts to permissionlessly create nft collections.
- Allow a named (permissioned) account to mint and burn unique items within a collection.
- Move items between accounts permissionlessly.
- Allow a named (permissioned) account to freeze and unfreeze items within a collection or the entire collection.
- Allow the owner of an item to delegate the ability to transfer the item to some named third-party.
- Allow third-parties to store information in an NFT without owning it (Eg. save game state).
Interface
Permissionless dispatchables
create: Create a new collection by placing a deposit.mint: Mint a new item within a collection (when the minting is public).transfer: Send an item to a new owner.redeposit: Update the deposit amount of an item, potentially freeing funds.approve_transfer: Name a delegate who may authorize a transfer.cancel_approval: Revert the effects of a previousapprove_transfer.approve_item_attributes: Name a delegate who may change item's attributes within a namespace.cancel_item_attributes_approval: Revert the effects of a previousapprove_item_attributes.set_price: Set the price for an item.buy_item: Buy an item.pay_tips: Pay tips, could be used for paying the creator royalties.create_swap: Create an offer to swap an NFT for another NFT and optionally some fungibles.cancel_swap: Cancel previously created swap offer.claim_swap: Swap items in an atomic way.
Permissioned dispatchables
destroy: Destroy a collection. This destroys all the items inside the collection and refunds the deposit.force_mint: Mint a new item within a collection.burn: Destroy an item within a collection.lock_item_transfer: Prevent an individual item from being transferred.unlock_item_transfer: Revert the effects of a previouslock_item_transfer.clear_all_transfer_approvals: Clears all transfer approvals set by calling theapprove_transfer.lock_collection: Prevent all items within a collection from being transferred (making them allsoul bound).lock_item_properties: Lock item's metadata or attributes.transfer_ownership: Alter the owner of a collection, moving all associated deposits. (Ownership of individual items will not be affected.)set_team: Alter the permissioned accounts of a collection.set_collection_max_supply: Change the max supply of a collection.update_mint_settings: Update the minting settings for collection.
Metadata (permissioned) dispatchables
set_attribute: Set a metadata attribute of an item or collection.clear_attribute: Remove a metadata attribute of an item or collection.set_metadata: Set general metadata of an item (E.g. an IPFS address of an image url).clear_metadata: Remove general metadata of an item.set_collection_metadata: Set general metadata of a collection.clear_collection_metadata: Remove general metadata of a collection.
Force (i.e. governance) dispatchables
force_create: Create a new collection (the collection id can not be chosen).force_collection_owner: Change collection's owner.force_collection_config: Change collection's config.force_set_attribute: Set an attribute.
Please refer to the Call enum and
its associated variants for documentation on each function.
Related Modules
License: Apache-2.0