After this RFC, we can remove from the source code of the host the allocator altogether in a future version, by removing support for all the deprecated host functions. This would remove the possibility to synchronize older blocks, which is probably controversial and requires a some preparations that are out of scope of this RFC.
+ +Table of Contents
+ +| Start Date | 2 November 2023 |
| Description | A proposal to reduce the minimum deposit required for collection creation on the Polkadot and Kusama Asset Hub, making it more accessible and affordable for artists. |
| Authors | Aurora Poppyseed, Just_Luuuu, Viki Val |
This RFC proposes changing the current deposit requirements on the Polkadot and Kusama Asset Hub for creating NFT collections. The objective is to lower the barrier to entry for artists, fostering a more inclusive and vibrant ecosystem while maintaining network integrity and preventing spam.
+The current deposit of 10 DOT for collection creation on the Polkadot Asset Hub presents a significant financial barrier for many artists. By lowering the deposit requirements, we aim to encourage more artists to participate in the Polkadot NFT ecosystem, thereby enriching the diversity and vibrancy of the community and its offerings.
+The actual implementation of the deposit is an arbitrary number coming from Uniques pallet. It is not a result of any economic analysis. This proposal aims to adjust the deposit from constant to dynamic pricing based on the deposit function with respect to stakeholders.
deposit function adjusted by correspoding pricing mechansim.Previous discussions have been held within the Polkadot Forum community and with artists expressing their concerns about the deposit amounts. Link.
+This RFC suggests modifying deposit constants defined in the nfts pallet on the Polkadot Asset Hub to require a lower deposit. The reduced deposit amount should be determined by the deposit adjusted by the pricing mechanism (arbitrary number/another pricing function).
Current deposit requirements are as follows:
++#![allow(unused)] +fn main() { +parameter_types! { + // re-use the Uniques deposits + pub const NftsCollectionDeposit: Balance = UniquesCollectionDeposit::get(); + pub const NftsItemDeposit: Balance = UniquesItemDeposit::get(); + pub const NftsMetadataDepositBase: Balance = UniquesMetadataDepositBase::get(); + pub const NftsAttributeDepositBase: Balance = UniquesAttributeDepositBase::get(); + pub const NftsDepositPerByte: Balance = UniquesDepositPerByte::get(); +} + +// +parameter_types! { + pub const UniquesCollectionDeposit: Balance = UNITS / 10; // 1 / 10 UNIT deposit to create a collection + pub const UniquesItemDeposit: Balance = UNITS / 1_000; // 1 / 1000 UNIT deposit to mint an item + pub const UniquesMetadataDepositBase: Balance = deposit(1, 129); + pub const UniquesAttributeDepositBase: Balance = deposit(1, 0); + pub const UniquesDepositPerByte: Balance = deposit(0, 1); +} +}
The proposed change would modify the deposit constants to require a lower deposit. The reduced deposit amount should be determined by deposit adjusted by an arbitrary number.
+#![allow(unused)] +fn main() { +parameter_types! { + pub const NftsCollectionDeposit: Balance = deposit(1, 130); + pub const NftsItemDeposit: Balance = deposit(1, 164) / 40; + pub const NftsMetadataDepositBase: Balance = deposit(1, 129) / 10; + pub const NftsAttributeDepositBase: Balance = deposit(1, 0) / 10; + pub const NftsDepositPerByte: Balance = deposit(0, 1); +} +}
Prices and Proposed Prices on Polkadot Asset Hub: +Scroll right
+| **Name** | **Current price implementation** | **Price if DOT = 5$** | **Price if DOT goes to 50$** | **Proposed Price in DOT** | **Proposed Price if DOT = 5$** | **Proposed Price if DOT goes to 50$**|
+|---------------------------|----------------------------------|------------------------|-------------------------------|---------------------------|----------------------------------|--------------------------------------|
+| collectionDeposit | 10 DOT | 50 $ | 500 $ | 0.20064 DOT | ~1 $ | 10.32$ |
+| itemDeposit | 0.01 DOT | 0.05 $ | 0.5 $ | 0.005 DOT | 0.025 $ | 0.251$ |
+| metadataDepositBase | 0.20129 DOT | 1.00645 $ | 10.0645 $ | 0.0020129 DOT | 0.0100645 $ | 0.100645$ |
+| attributeDepositBase | 0.2 DOT | 1 $ | 10 $ | 0.002 DOT | 0.01 $ | 0.1$ |
+Prices and Proposed Prices on Kusama Asset Hub: +Scroll right
+| **Name** | **Current price implementation** | **Price if KSM = 23$** | **Price if KSM goes to 500$** | **Proposed Price in KSM** | **Proposed Price if KSM = 23$** | **Proposed Price if KSM goes to 500$** |
+|---------------------------|----------------------------------|------------------------|-------------------------------|---------------------------|----------------------------------|----------------------------------------|
+| collectionDeposit | 0.1 KSM | 2.3 $ | 50 $ | 0.006688 KSM | 0.154 $ | 3.34 $ |
+| itemDeposit | 0.001 KSM | 0.023 $ | 0.5 $ | 0.000167 KSM | 0.00385 $ | 0.0835 $ |
+| metadataDepositBase | 0.006709666617 KSM | 0.15432183319 $ | 3.3548333085 $ | 0.0006709666617 KSM | 0.015432183319 $ | 0.33548333085 $ |
+| attributeDepositBase | 0.00666666666 KSM | 0.15333333318 $ | 3.333333333 $ | 0.000666666666 KSM | 0.015333333318 $ | 0.3333333333 $ |
+
+++Note: This is only a proposal for change and can be modified upon additional conversation.
+
Modifying deposit requirements necessitates a balanced assessment of the potential drawbacks. Highlighted below are cogent points extracted from the discourse on the Polkadot Forum conversation, which provide critical perspectives on the implications of such changes:
+++But NFT deposits were chosen somewhat arbitrarily at genesis and it’s a good exercise to re-evaluate them and adapt if they are causing pain and if lowering them has little or no negative side effect (or if the trade-off is worth it). +-> joepetrowski
+
++Underestimates mean that state grows faster, although not unbounded - effectively an economic subsidy on activity. Overestimates mean that the state grows slower - effectively an economic depressant on activity. +-> rphmeier
+
++Technical: We want to prevent state bloat, therefore using state should have a cost associated with it. +-> joepetrowski
+
The change is backwards compatible. The prevention of "spam" could be prevented by OpenGov proposal to forceDestoy list of collections that are not suitable.
This change is not expected to have a significant impact on the overall performance of the Polkadot Asset Hub. However, monitoring the network closely, especially in the initial stages after implementation, is crucial to identify and mitigate any potential issues.
+Additionally, a supplementary proposal aims to augment the network's adaptability:
+++Just from a technical perspective; I think the best we can do is to use a weak governance origin that is controlled by some consortium (ie. System Collective). +This origin could then update the NFT deposits any time the market conditions warrant it - obviously while honoring the storage deposit requirements. +To implement this, we need RFC#12 and the Parameters pallet from @xlc. +-> OliverTY
+
This dynamic governance approach would facilitate a responsive and agile economic model for deposit management, ensuring that the network remains accessible and robust in the face of market volatility.
+The proposed change aims to enhance the user experience for artists, making Polkadot more accessible and user-friendly.
+The change does not impact compatibility as redeposit function is already implemented.
If accepted, this RFC could pave the way for further discussions and proposals aimed at enhancing the inclusivity and accessibility of the Polkadot ecosystem. Future work could also explore having a weak governance origin for deposits as proposed by Oliver.
Table of Contents
This RFC proposes changes that enable the use of absolute locations in AccountId derivations, which allows protocols built using XCM to have static account derivations in any runtime, regardless of its position in the family hierarchy.
-These changes would allow protocol builders to leverage absolute locations to maintain the exact same derived account address across all networks in the ecosystem, thus enhancing user experience.
One such protocol, that is the original motivation for this proposal, is InvArch's Saturn Multisig, which gives users a unifying multisig and DAO experience across all XCM connected chains.
-This proposal aims to make it possible to derive accounts for absolute locations, enabling protocols that require the ability to maintain the same derived account in any runtime. This is done by deriving accounts from the hash of described absolute locations, which are static across different destinations.
The same location can be represented in relative form and absolute form like so:
-#![allow(unused)] @@ -3237,25 +3384,25 @@ privacy-enhancing mechanisms to address this concern.DescribeFamily
The
DescribeFamilylocation descriptor is part of theHashedDescriptionMultiLocation hashing system and exists to describe locations in an easy format for encoding and hashing, so that an AccountId can be derived from this MultiLocation.This implementation contains a match statement that does not match against absolute locations, so changes to it involve matching against absolute locations and providing appropriate descriptions for hashing.
-Drawbacks
+Drawbacks
No drawbacks have been identified with this proposal.
-Testing, Security, and Privacy
+Testing, Security, and Privacy
Tests can be done using simple unit tests, as this is not a change to XCM itself but rather to types defined in
xcm-builder.Security considerations should be taken with the implementation to make sure no unwanted behavior is introduced.
This proposal does not introduce any privacy considerations.
-Performance, Ergonomics, and Compatibility
-Performance
+Performance, Ergonomics, and Compatibility
+Performance
Depending on the final implementation, this proposal should not introduce much overhead to performance.
-Ergonomics
+Ergonomics
The ergonomics of this proposal depend on the final implementation details.
-Compatibility
+Compatibility
Backwards compatibility should remain unchanged, although that depend on the final implementation.
Prior Art and References
-
DescirbeFamilytype: https://github.com/paritytech/polkadot-sdk/blob/master/polkadot/xcm/xcm-builder/src/location_conversion.rs#L122WithComputedOrigintype: https://github.com/paritytech/polkadot-sdk/blob/master/polkadot/xcm/xcm-builder/src/barriers.rs#L153Unresolved Questions
+Unresolved Questions
Implementation details and overall code is still up to discussion.
Table of Contents
@@ -3288,13 +3435,13 @@ privacy-enhancing mechanisms to address this concern.- Authors Vedhavyas Singareddi Summary
+Summary
At the moment, we have
-system_versionfield onRuntimeVersionthat derives which state version is used for the Storage. We have a use case where we want extrinsics root is derived usingStateVersion::V1. Without defining a new field underRuntimeVersion, we would like to propose addingsystem_versionthat can be used to derive both storage and extrinsic state version.Motivation
+Motivation
Since the extrinsic state version is always
@@ -3306,11 +3453,11 @@ One of the main challenge here is some extrinsics could be big enough that this included in the Consensus block due to Block's weight restriction. If the extrinsic root is derived usingStateVersion::V0, deriving extrinsic root requires full extrinsic data. This would be problematic when we need to verify the extrinsics root if the extrinsic sizes are bigger. This problem is further explored in https://github.com/polkadot-fellows/RFCs/issues/19StateVersion::V1, then we do not need to pass the full extrinsic data but rather at maximum, 32 byte of extrinsic data. -Stakeholders
+Stakeholders
-
- Technical Fellowship, in its role of maintaining system runtimes.
Explanation
+Explanation
In order to use project specific StateVersion for extrinsic roots, we proposed an implementation that introduced parameter to
frame_system::Configbut that unfortunately did not feel correct. @@ -3336,26 +3483,26 @@ pub const VERSION: RuntimeVersion = RuntimeVersion { system_version: 1, }; }
There should be no drawbacks as it would replace state_version with same behavior but documentation should be updated
so that chains know which system_version to use.
AFAIK, should not have any impact on the security or privacy.
-These changes should be compatible for existing chains if they use state_version value for system_verision.
I do not believe there is any performance hit with this change.
-This does not break any exposed Apis.
-This change should not break any compatibility.
We proposed introducing a similar change by introducing a
parameter to frame_system::Config but did not feel that
is the correct way of introducing this change.
I do not have any specific questions about this change at the moment.
-IMO, this change is pretty self-contained and there won't be any future work necessary.
Table of Contents
@@ -3396,13 +3543,13 @@ is the correct way of introducing this change.This RFC proposes a new model for a sustainable on-demand parachain registration, involving a smaller initial deposit and periodic rent payments. The new model considers that on-demand chains may be unregistered and later re-registered. The proposed solution also ensures a quick startup for on-demand chains on Polkadot in such cases.
-With the support of on-demand parachains on Polkadot, there is a need to explore a new, more cost-effective model for registering validation code. In the current model, the parachain manager is responsible for reserving a unique ParaId and covering the cost of storing the validation code of the parachain. These costs can escalate, particularly if the validation code is large. We need a better, sustainable model for registering on-demand parachains on Polkadot to help smaller teams deploy more easily.
This RFC suggests a new payment model to create a more financially viable approach to on-demand parachain registration. In this model, a lower initial deposit is required, followed by recurring payments upon parachain registration.
This new model will coexist with the existing one-time deposit payment model, offering teams seeking to deploy on-demand parachains on Polkadot a more cost-effective alternative.
-This RFC proposes a set of changes that will enable the new rent based approach to registering and storing validation code on-chain. The new model, compared to the current one, will require periodic rent payments. The parachain won't be pruned automatically if the rent is not paid, but by permitting anyone to prune the parachain and rewarding the caller, there will be an incentive for the removal of the validation code.
On-demand parachains should still be able to utilize the current one-time payment model. However, given the size of the deposit required, it's highly likely that most on-demand parachains will opt for the new rent-based model.
@@ -3523,27 +3670,27 @@ pub(super) type CheckedCodeHash<T: Config> = StorageMap<_, Twox64Concat, ParaId, ValidationCodeHash>; }To enable parachain re-registration, we should introduce a new extrinsic in the paras-registrar pallet that allows this. The logic of this extrinsic will be same as regular registration, with the distinction that it can be called by anyone, and the required deposit will be smaller since it only has to cover for the storage of the validation code.
This RFC does not alter the process of reserving a ParaId, and therefore, it does not propose reducing it, even though such a reduction could be beneficial.
Even though this RFC doesn't delve into the specifics of the configuration values for parachain registration but rather focuses on the mechanism, configuring it carelessly could lead to potential problems.
Since the validation code hash and head data are not removed when the parachain is pruned but only when the deregister extrinsic is called, the T::DataDepositPerByte must be set to a higher value to create a strong enough incentive for removing it from the state.
The implementation of this RFC will be tested on Rococo first.
Proper research should be conducted on setting the configuration values of the new system since these values can have great impact on the network.
An audit is required to ensure the implementation's correctness.
The proposal introduces no new privacy concerns.
-This RFC should not introduce any performance impact.
-This RFC does not affect the current parachains, nor the parachains that intend to use the one-time payment model for parachain registration.
-This RFC does not break compatibility.
Prior discussion on this topic: https://github.com/paritytech/polkadot-sdk/issues/1796
-None at this time.
-As noted in this GitHub issue, we want to raise the per-byte cost of on-chain data storage. However, a substantial increase in this cost would make it highly impractical for on-demand parachains to register on Polkadot. This RFC offers an alternative solution for on-demand parachains, ensuring that the per-byte cost increase doesn't overly burden the registration process.
@@ -3600,9 +3747,9 @@ This RFC offers an alternative solution for on-demand parachains, ensuring thatAdd a metadata digest value (33-byte constant within fixed spec_version) to Signed Extensions to supplement signer party with proof of correct extrinsic interpretation. The digest value is generated once before release and is well-known and deterministic. The digest mechanism is designed to be modular and flexible. It also supports partial metadata transfer as needed by the signing party's extrinsic decoding mechanism. This considers signing devices potentially limited communication bandwidth and/or memory capacity.
While all blockchain systems support (at least in some sense) offline signing used in air-gapped wallets and lightweight embedded devices, only few allow simultaneously complex upgradeable logic and full message decoding on the cold off-line signer side; Substrate is one of these heartening few, and therefore - we should build on this feature to greatly improve transaction security, and thus in general, network resilience.
As a starting point, it is important to recognise that prudence and due care are naturally required. As we build further reliance on this feature we should be very careful to make sure it works correctly every time so as not to create false sense of security.
@@ -3632,11 +3779,11 @@ This RFC offers an alternative solution for on-demand parachains, ensuring thatAll chain teams are stakeholders, as implementing this feature would require timely effort on their side and would impact compatibility with older tools.
This feature is essential for all offline signer tools; many regular signing tools might make use of it. In general, this RFC greatly improves security of any network implementing it, as many governing keys are used with offline signers.
Implementing this RFC would remove requirement to maintain metadata portals manually, as task of metadata verification would be effectively moved to consensus mechanism of the chain.
-Detailed description of metadata shortening and digest process is provided in metadata-shortener crate (see cargo doc --open and examples). Below are presented algorithms of the process.
0x02 - 0xFFA 1-byte increase in transaction size due to signed extension value. Digest is not included in transferred transaction, only in signing process.
Some slightly out of spec systems might experience breaking changes as new content of signed extensions is added. It is important to note, that there is no real overhead in processing time nor complexity, as the metadata checking mechanism is voluntary. The only drawbacks are expected for tools that do not implement MetadataV14 self-descripting features.
-The metadata shortening protocol should be extensively tested on all available examples of metadata before releasing changes to either metadata or shortener. Careful code review should be performed on shortener implementation code to ensure security. The main metadata tree would inevitably be constructed on runtime build which would also ensure correctness.
To be able to recall shortener protocol in case of vulnerability issues, a version byte is included.
-This is negligibly short pessimization during build time on the chain side. Cold wallets performance would improve mostly as metadata validity mechanism that was taking most of effort in cold wallet support would become trivial.
-The proposal was optimized for cold storage wallets usage with minimal impact on all other parts of the ecosystem
-Proposal in this form is not compatible with older tools that do not implement proper MetadataV14 self-descriptive features; those would have to be upgraded to include a new signed extensions field.
This project was developed upon a Polkadot Treasury grant; relevant development links are located in metadata-offline-project repository.
-Changes to code of all cold signers to implement this mechanism SHOULD be done when this is enabled; non-cold signers may perform extra metadata check for better security. Ultimately, signing anything without decoding it with verifiable metadata should become discouraged in all situations where a decision-making mechanism is involved (that is, outside of fully automated blind signers like trade bots or staking rewards payout tools).
Table of Contents
@@ -3838,11 +3985,11 @@ modularized_registry.sort(|a, b| {Propose a way of permuting the availability chunk indices assigned to validators, in the context of recovering available data from systematic chunks, with the purpose of fairly distributing network bandwidth usage.
-Currently, the ValidatorIndex is always identical to the ChunkIndex. Since the validator array is only shuffled once per session, naively using the ValidatorIndex as the ChunkIndex would pose an unreasonable stress on the first N/3 validators during an entire session, when favouring availability recovery from systematic chunks.
@@ -3850,9 +3997,9 @@ validators during an entire session, when favouring availability recovery from s systematic availability chunks to different validators, based on the relay chain block and core. The main purpose is to ensure fair distribution of network bandwidth usage for availability recovery in general and in particular for systematic chunk holders. -Relay chain node core developers.
-An erasure coding algorithm is considered systematic if it preserves the original unencoded data as part of the
resulting code.
@@ -4007,7 +4154,7 @@ struct (added in https://github.com/paritytech/polkadot-sdk/pull/2177Configuration::set_node_feature extrinsic. Once the feature is enabled and new configuration is live, the
validator->chunk mapping ceases to be a 1:1 mapping and systematic recovery may begin.
core_index that used to be occupied by a candidate in some parts of the dispute protocol is
very complicated (See appendix A). This RFC assumes that availability-recovery processes initiated during
@@ -4017,28 +4164,28 @@ mitigate this problem and will likely be needed in the future for CoreJam and/or
Related discussion about updating CandidateReceiptExtensive testing will be conducted - both automated and manual. This proposal doesn't affect security or privacy.
-This is a necessary data availability optimisation, as reed-solomon erasure coding has proven to be a top consumer of CPU time in polkadot as we scale up the parachain block size and number of availability cores.
With this optimisation, preliminary performance results show that CPU time used for reed-solomon coding/decoding can be halved and total POV recovery time decrease by 80% for large POVs. See more here.
-Not applicable.
-This is a breaking change. See upgrade path section above. All validators and collators need to have upgraded their node versions before the feature will be enabled via a governance call.
See comments on the tracking issue and the in-progress PR
-Not applicable.
-This enables future optimisations for the performance of availability recovery, such as retrieving batched systematic chunks from backers/approval-checkers.
This RFC proposes to make the mechanism of RFC #8 more generic by introducing the concept of "capabilities".
Implementations can implement certain "capabilities", such as serving old block headers or being a parachain bootnode.
The discovery mechanism of RFC #8 is extended to be able to discover nodes of specific capabilities.
-The Polkadot peer-to-peer network is made of nodes. Not all these nodes are equal. Some nodes store only the headers of recently blocks, some nodes store all the block headers and bodies since the genesis, some nodes store the storage of all blocks since the genesis, and so on.
It is currently not possible to know ahead of time (without connecting to it and asking) which nodes have which data available, and it is not easily possible to build a list of nodes that have a specific piece of data available.
If you want to download for example the header of block 500, you have to connect to a randomly-chosen node, ask it for block 500, and if it says that it doesn't have the block, disconnect and try another randomly-chosen node. In certain situations such as downloading the storage of old blocks, nodes that have the information are relatively rare, and finding through trial and error a node that has the data can take a long time.
This RFC attempts to solve this problem by giving the possibility to build a list of nodes that are capable of serving specific data.
-Low-level client developers. People interested in accessing the archive of the chain.
-Reading RFC #8 first might help with comprehension, as this RFC is very similar.
Please keep in mind while reading that everything below applies for both relay chains and parachains, except mentioned otherwise.
Implementations that have the head of the chain provider capability do not register themselves as providers, but instead are the nodes that participate in the main DHT. In other words, they are the nodes that serve requests of the /<genesis_hash>/kad protocol.
Any implementation that isn't a head of the chain provider (read: light clients) must not participate in the main DHT. This is already presently the case.
Implementations must not participate in the main DHT if they don't fulfill the capability yet. For example, a node that is still in the process of warp syncing must not participate in the main DHT. However, assuming that warp syncing doesn't last more than a few seconds, it is acceptable to ignore this requirement in order to avoid complicating implementations too much.
-None that I can see.
-The content of this section is basically the same as the one in RFC 8.
This mechanism doesn't add or remove any security by itself, as it relies on existing mechanisms.
Due to the way Kademlia works, it would become the responsibility of the 20 Polkadot nodes whose sha256(peer_id) is closest to the key (described in the explanations section) to store the list of nodes that have specific capabilities.
Furthermore, when a large number of providers are registered, only the providers closest to the key are kept, up to a certain implementation-defined limit.
For this reason, an attacker can abuse this mechanism by randomly generating libp2p PeerIds until they find the 20 entries closest to the key representing the target capability. They are then in control of the list of nodes with that capability. While doing this can in no way be actually harmful, it could lead to eclipse attacks.
Because the key changes periodically and isn't predictable, and assuming that the Polkadot DHT is sufficiently large, it is not realistic for an attack like this to be maintained in the long term.
-The DHT mechanism generally has a low overhead, especially given that publishing providers is done only every 24 hours.
Doing a Kademlia iterative query then sending a provider record shouldn't take more than around 50 kiB in total of bandwidth for the parachain bootnode.
Assuming 1000 nodes with a specific capability, the 20 Polkadot full nodes corresponding to that capability will each receive a sudden spike of a few megabytes of networking traffic when the key rotates. Again, this is relatively negligible. If this becomes a problem, one can add a random delay before a node registers itself to be the provider of the key corresponding to BabeApi_next_epoch.
Maybe the biggest uncertainty is the traffic that the 20 Polkadot full nodes will receive from light clients that desire knowing the nodes with a capability. If this every becomes a problem, this value of 20 is an arbitrary constant that can be increased for more redundancy.
-Irrelevant.
-Irrelevant.
Unknown.
-While it fundamentally doesn't change much to this RFC, using BabeApi_currentEpoch and BabeApi_nextEpoch might be inappropriate. I'm not familiar enough with good practices within the runtime to have an opinion here. Should it be an entirely new pallet?
This RFC would make it possible to reliably discover archive nodes, which would make it possible to reliably send archive node requests, something that isn't currently possible. This could solve the problem of finding archive RPC node providers by migrating archive-related request to using the native peer-to-peer protocol rather than JSON-RPC.
If we ever decide to break backwards compatibility, we could divide the "history" and "archive" capabilities in two, between nodes capable of serving older blocks and nodes capable of serving newer blocks. We could even add to the peer-to-peer network nodes that are only capable of serving older blocks (by reading from a database) but do not participate in the head of the chain, and that just exist for historical purposes.
@@ -4231,19 +4378,19 @@ We could even add to the peer-to-peer network nodes that are only capable of serCurrently, substrate runtime use an simple allocator defined by host side. Every runtime MUST import these allocator functions for normal execution. This situation make runtime code not versatile enough.
So this RFC proposes to define a new spec for allocator part to make substrate runtime more generic.
-Since this RFC define a new way for allocator, we now regard the old one as legacy allocator.
As we all know, since the allocator implementation details are defined by the substrate client, parachain/parathread cannot customize memory allocator algorithm, so the new specification allows the runtime to customize memory allocation, and then export the allocator function according to the specification for the client side to use.
Another benefit is that some new host functions can be designed without allocating memory on the client, which may have potential performance improvements. Also it will help provide a unified and clean specification if substrate runtime support multi-targets(e.g. RISC-V).
There is also a potential benefit. Many programming languages that support compilation to wasm may not be friendly to supporting external allocator. This is beneficial for other programming languages to enter the substrate runtime ecosystem.
The last and most important benefit is that for offchain context execution, the runtime can fully support pure wasm. What this means here is that all imported host functions could not actually be called (as stub functions), then the various verification logic of the runtime can be converted into pure wasm, which provides the possibility for the substrate runtime to run block verification in other environments (such as in browsers and other non-substrate environments).
No attempt was made at convincing stakeholders.
-This section contains a list of functions should be exported by substrate runtime.
We define the spec as version 1, so the following dummy function v1 MUST be exported to hint
@@ -4282,20 +4429,20 @@ Check if parsed wasm module contains a exported v1 function:
Detail-heavy explanation of the RFC, suitable for explanation to an implementer of the changeset. This should address corner cases in detail and provide justification behind decisions, and provide rationale for how the design meets the solution requirements.
-The allocator inside of the runtime will make code size bigger, but it's not obvious. The allocator inside of the runtime maybe slow down(or speed up) the runtime, still not obvious.
We could ignore these drawbacks since they are not prominent. And the execution efficiency is highly decided by runtime developer. We could not prevent a poor efficiency if developer want to do it.
-Keep the legacy allocator runtime test cases, and add new feature to compile test cases for v1 allocator spec. And then update the test asserts.
Update template runtime to enable v1 spec. Once the dev network runs well, it seems that the spec is implmented correctly.
As the above says, not obvious impact about performance. And polkadot-sdk could offer the best practice allocator for all chains.
Third party also could customized by theirself. So the performance could be improved over time.
Only for runtime developer, Just need to import a new crate and enable a new feature. Maybe it's convienient for other wasm-target language to implment.
-It's 100% compatible. Only Some runtime configs and executor configs need to be depreacted.
For support new runtime spec, we MUST upgrade the client binary to support new spec of client part firstly.
We SHALL add an optional primtive crate to enable the version 1 spec and disable the legacy allocator by cargo feature. @@ -4305,9 +4452,9 @@ For the first year, we SHALL disable the v1 by default, and enable it by default
None at this time.
-The content discussed with RFC-0004 is basically orthogonal, but it could still be considered together, and it is preferred that this rfc be implmentented first.
This feature could make substrate runtime be easier supported by other languages and integreted into other ecosystem.
@@ -4340,17 +4487,17 @@ For the first year, we SHALL disable the v1 by default, and enable it by defaultThis RFC proposes lowering the existential deposit requirements on Asset Hub for Polkadot by a factor of 25, from 0.1 DOT to .004 DOT. The objective is to lower the barrier to entry for asset minters to mint a new asset to the entire DOT token holder base, and make Asset Hub on Polkadot a place where everyone can do small asset conversions.
-The current Existential deposit is 0.1 DOT on Asset Hub for Polkadot. While this is not does not appear to be a significant financial barrier for most people (only $0.80), this value makes Asset Hub impractical for Asset Hub Minters, specifically for the case where the Asset Hub Minters wishes to mint a new asset for the entire community of DOT holders (e.g. 1.25MM DOT holders would cost 125K DOT @ $8 = $1MM).
By lowering the existential deposit requirements from 0.1 DOT to 0.004 DOT, the cost of minting to the entire community of DOT holders goes from an unmanagable number [125K DOT, the value of several houses circa December 2023] down to a manageable number [5K DOT, the value of a car circa December 2023].
-asset.mint.The exact amount of the existential deposit (ED) is proposed to be 0.004 DOT based on
It is assumed that the estimated cost to store a single account is less than 0.004 DOT. If this assumption is challenged by Polkadot Fellows, we request the Fellows provided a empirical determination of what the actual cost of storing a single account is, at present day numbers of DOT Token Holders (approximately 1-2MM) and then to support a factor or 10-1000x growth over the next 5 years. This assumption has been discussed on the forum: Polkadot AssetHub - high NFT collection deposit
First, the cost has to be mapped from DOT into real world USD storage costs of running an Asset Hub on Polkadot node, and the DOT / USD ratio itself has varied widely in the past and will continue to do so in the future. Second, according to this analysis, at present the pragmatic cost of estimating storage is approximated by what it costs to store accounts for 1 or 2 years at most. Underestimates on this cost is believed to be an economic subsidy while overestimates on this cost is believe to be an economic depressant on activity.
Given the relatively underused AssetHub for Polkadot, we believe the correct thing to do is to aim to subsidize Asset Hub activity with a lower ED.
-The primary drawback for subsidize Asset Hub activity with a 25x lower ED is borne by Asset Hub users in the distant future who will pay for the subsidized activity by lowering the ED.
-Lowering the ED from 0.004 DOT to 0 DOT would clearly unnecessarily invite account spam attacks common to EVM chains, which have no ED.
Lowering ED from 0.004 DOT to 0.002 DOT or 0.001 DOT would threaten user experience wherein just 1 or 2 asset pallet operation would reap the account.
This change is not expected to have a significant impact on the overall performance of the Asset Hub for Polkadot.
-The proposed change aims to enhance the user experience for:
It is believed that Asset Hub for Kusama can undergo the same logic change without issue.
For Asset Hub for Polkadot, it is extremely desirable that this change be approved in early 2024 with some urgency.
-It is desirable to know the cost to store an account on Asset Hub for Polkadot when the number of accounts is 10MM, 100MM, 1B to better the cost of the subsidy. We do not believe a precise answer to this merits delaying a subsidy at present. However, if approved, we believe once the number of accounts reaches 10MM-25MM or exponential growth is observed, this ED be reevaluated.
-If accepted, this RFC could pave the way for other accessibility improvements:
This RFC proposes a dynamic pricing model for the sale of Bulk Coretime on the Polkadot UC. The proposed model updates the regular price of cores for each sale period, by taking into account the number of cores sold in the previous sale, as well as a limit of cores and a target number of cores sold. It ensures a minimum price and limits price growth to a maximum price increase factor, while also giving govenance control over the steepness of the price change curve. It allows governance to address challenges arising from changing market conditions and should offer predictable and controlled price adjustments.
Accompanying visualizations are provided at [1].
-RFC-1 proposes periodic Bulk Coretime Sales as a mechanism to sell continouos regions of blockspace (suggested to be 4 weeks in length). A number of Blockspace Regions (compare RFC-1 & RFC-3) are provided for sale to the Broker-Chain each period and shall be sold in a way that provides value-capture for the Polkadot network. The exact pricing mechanism is out of scope for RFC-1 and shall be provided by this RFC.
A dynamic pricing model is needed. A limited number of Regions are offered for sale each period. The model needs to find the price for a period based on supply and demand of the previous period.
The model shall give Coretime consumers predictability about upcoming price developments and confidence that Polkadot governance can adapt the pricing model to changing market conditions.
-The primary stakeholders of this RFC are:
The dynamic pricing model sets the new price based on supply and demand in the previous period. The model is a function of the number of Regions sold, piecewise-defined by two power functions.
None at present.
This pricing model is based on the requirements from the basic linear solution proposed in RFC-1, which is a simple dynamic pricing model and only used as proof. The present model adds additional considerations to make the model more adaptable under real conditions.
@@ -4605,9 +4752,9 @@ OLD_PRICE = 1000Improve the networking messages that query storage items from the remote, in order to reduce the bandwidth usage and number of round trips of light clients.
-Clients on the Polkadot peer-to-peer network can be divided into two categories: full nodes and light clients. So-called full nodes are nodes that store the content of the chain locally on their disk, while light clients are nodes that don't. In order to access for example the balance of an account, a full node can do a disk read, while a light client needs to send a network message to a full node and wait for the full node to reply with the desired value. This reply is in the form of a Merkle proof, which makes it possible for the light client to verify the exactness of the value.
Unfortunately, this network protocol is suffering from some issues:
Once Polkadot and Kusama will have transitioned to state_version = 1, which modifies the format of the trie entries, it will be possible to generate Merkle proofs that contain only the hashes of values in the storage. Thanks to this, it is already possible to prove the existence of a key without sending its entire value (only its hash), or to prove that a value has changed or not between two blocks (by sending just their hashes).
Thus, the only reason why aforementioned issues exist is because the existing networking messages don't give the possibility for the querier to query this. This is what this proposal aims at fixing.
This is the continuation of https://github.com/w3f/PPPs/pull/10, which itself is the continuation of https://github.com/w3f/PPPs/pull/5.
-The protobuf schema of the networking protocol can be found here: https://github.com/paritytech/substrate/blob/5b6519a7ff4a2d3cc424d78bc4830688f3b184c0/client/network/light/src/schema/light.v1.proto
The proposal is to modify this protocol in this way:
@@ -11,6 +11,7 @@ message Request {
@@ -4677,128 +4824,27 @@ An alternative could have been to specify the child_trie_info for e
Also note that child tries aren't considered as descendants of the main trie when it comes to the includeDescendants flag. In other words, if the request concerns the main trie, no content coming from child tries is ever sent back.
This protocol keeps the same maximum response size limit as currently exists (16 MiB). It is not possible for the querier to know in advance whether its query will lead to a reply that exceeds the maximum size. If the reply is too large, the replier should send back only a limited number (but at least one) of requested items in the proof. The querier should then send additional requests for the rest of the items. A response containing none of the requested items is invalid.
The server is allowed to silently discard some keys of the request if it judges that the number of requested keys is too high. This is in line with the fact that the server might truncate the response.
-Drawbacks
+Drawbacks
This proposal doesn't handle one specific situation: what if a proof containing a single specific item would exceed the response size limit? For example, if the response size limit was 1 MiB, querying the runtime code (which is typically 1.0 to 1.5 MiB) would be impossible as it's impossible to generate a proof less than 1 MiB. The response size limit is currently 16 MiB, meaning that no single storage item must exceed 16 MiB.
Unfortunately, because it's impossible to verify a Merkle proof before having received it entirely, parsing the proof in a streaming way is also not possible.
A way to solve this issue would be to Merkle-ize large storage items, so that a proof could include only a portion of a large storage item. Since this would require a change to the trie format, it is not realistically feasible in a short time frame.
-Testing, Security, and Privacy
+Testing, Security, and Privacy
The main security consideration concerns the size of replies and the resources necessary to generate them. It is for example easily possible to ask for all keys and values of the chain, which would take a very long time to generate. Since responses to this networking protocol have a maximum size, the replier should truncate proofs that would lead to the response being too large. Note that it is already possible to send a query that would lead to a very large reply with the existing network protocol. The only thing that this proposal changes is that it would make it less complicated to perform such an attack.
Implementers of the replier side should be careful to detect early on when a reply would exceed the maximum reply size, rather than inconditionally generate a reply, as this could take a very large amount of CPU, disk I/O, and memory. Existing implementations might currently be accidentally protected from such an attack thanks to the fact that requests have a maximum size, and thus that the list of keys in the query was bounded. After this proposal, this accidental protection would no longer exist.
Malicious server nodes might truncate Merkle proofs even when they don't strictly need to, and it is not possible for the client to (easily) detect this situation. However, malicious server nodes can already do undesirable things such as throttle down their upload bandwidth or simply not respond. There is no need to handle unnecessarily truncated Merkle proofs any differently than a server simply not answering the request.
-Performance, Ergonomics, and Compatibility
-Performance
+Performance, Ergonomics, and Compatibility
+Performance
It is unclear to the author of the RFC what the performance implications are. Servers are supposed to have limits to the amount of resources they use to respond to requests, and as such the worst that can happen is that light client requests become a bit slower than they currently are.
-Ergonomics
+Ergonomics
Irrelevant.
-Compatibility
+Compatibility
The prior networking protocol is maintained for now. The older version of this protocol could get removed in a long time.
Prior Art and References
None. This RFC is a clean-up of an existing mechanism.
-Unresolved Questions
-None
-Future Directions and Related Material
-The current networking protocol could be deprecated in a long time. Additionally, the current "state requests" protocol (used for warp syncing) could also be deprecated in favor of this one.
-
-Table of Contents
-
-RFC-0000: Lowering NFT Deposits on Polkadot and Kusama Asset Hubs
-Start Date 2 November 2023 Description A proposal to reduce the minimum deposit required for collection creation on the Polkadot and Kusama Asset Hub, making it more accessible and affordable for artists. Authors Aurora Poppyseed, Just_Luuuu, VikiiVal
-
-Summary
-This RFC proposes a change to the current deposit requirements on the Polkadot and Kusama Asset Hub for creating NFT collections. The objective is to lower the barrier to entry for artists, fostering a more inclusive and vibrant ecosystem, while maintaining network integrity and preventing spam.
-Motivation
-The current deposit of 10 DOT for collection creation on the Polkadot Asset Hub presents a significant financial barrier for many artists. By lowering the deposit requirements, we aim to encourage more artists to participate in the Polkadot NFT ecosystem, thereby enriching the diversity and vibrancy of the community and its offerings.
-Stakeholders
-
-- NFT Creators: Primary beneficiaries of the proposed change, particularly those who found the current deposit requirements prohibitive.
-- NFT Platforms: As the facilitator of artists' relations, KodaDot has a vested interest in making the platform more accessible.
-- Polkadot Community: Stands to benefit from an influx of artists, creators and diverse NFT collections, enhancing the overall ecosystem.
-
-Previous discussions have been held within the KodaDot community, as well as with artists expressing their concerns about the deposit amounts. Referencing to Polkadot Forum conversation.
-Explanation
-This RFC suggests modifying the smart contract governing collection creation on the Polkadot Asset Hub to require a lower deposit. The exact amount of the reduced deposit is yet to be determined and should be discussed and agreed upon by the stakeholders. The implementation of this change requires careful consideration of the network's integrity and the prevention of spam, possibly through alternative means such as rate limiting or account verification.
-Prices and Proposed Prices on Polkadot Asset Hub:
-Scroll right
-| **Name** | **Current price implementation** | **Price if DOT = 5$** | **Price if DOT goes to 50$** | **Proposed Price in DOT** | **Proposed Price if DOT = 5$** | **Proposed Price if DOT goes to 50$**|
-|---------------------------|----------------------------------|------------------------|-------------------------------|---------------------------|----------------------------------|--------------------------------------|
-| collectionDeposit | 10 DOT | 50 $ | 500 $ | 0.1 DOT | 0.5 $ | 5$ |
-| itemDeposit | 0.01 DOT | 0.05 $ | 0.5 $ | 0.001 DOT | 0.005 $ | 0.05$ |
-| metadataDepositBase | 0.20129 DOT | 1.00645 $ | 10.0645 $ | 0.0020129 DOT | 0.0100645 $ | 0.100645$ |
-| attributeDepositBase | 0.2 DOT | 1 $ | 10 $ | 0.002 DOT | 0.01 $ | 0.1$ |
-
-Prices and Proposed Prices on Kusama Asset Hub:
-Scroll right
-| **Name** | **Current price implementation** | **Price if KSM = 23$** | **Price if KSM goes to 500$** | **Proposed Price in KSM** | **Proposed Price if KSM = 23$** | **Proposed Price if KSM goes to 500$** |
-|---------------------------|----------------------------------|------------------------|-------------------------------|---------------------------|----------------------------------|----------------------------------------|
-| collectionDeposit | 0.1 KSM | 2.3 $ | 50 $ | 0.01 KSM | 0.23 $ | 5 $ |
-| itemDeposit | 0.001 KSM | 0.023 $ | 0.5 $ | 0.0001 KSM | 0.0023 $ | 0.05 $ |
-| metadataDepositBase | 0.006709666617 KSM | 0.15432183319 $ | 3.3548333085 $ | 0.0006709666617 KSM | 0.015432183319 $ | 0.33548333085 $ |
-| attributeDepositBase | 0.00666666666 KSM | 0.15333333318 $ | 3.333333333 $ | 0.000666666666 KSM | 0.015333333318 $ | 0.3333333333 $ |
-
-
-
-Note: This is only a proposal for change and it can be modified upon additional conversation.
-
-Drawbacks
-The contemplation of modifying deposit requirements necessitates a balanced assessment of the potential drawbacks. Highlighted below are cogent points extracted from the discourse on the Polkadot Forum conversation, which provide critical perspectives on the implications of such changes:
-
-But NFT deposits were chosen somewhat arbitrarily at genesis and it’s a good exercise to re-evaluate them and adapt if they are causing pain and if lowering them has little or no negative side effect (or if the trade-off is worth it).
--> joepetrowski
-
-
-Underestimates mean that state grows faster, although not unbounded - effectively an economic subsidy on activity. Overestimates mean that the state grows slower - effectively an economic depressant on activity.
--> rphmeier
-
-
-Technical: We want to prevent state bloat, therefore using state should have a cost associated with it.
--> joepetrowski
-
-Testing, Security, and Privacy
-Performance, Ergonomics, and Compatibility
-Performance
-This change is not expected to have a significant impact on the overall performance of the Polkadot Asset Hub. However, it is crucial to monitor the network closely, especially in the initial stages after implementation, to identify and mitigate any potential issues.
-Additionally, a supplementary proposal aims to augment the network's adaptability:
-
-Just from a technical perspective; I think the best we can do is to use a weak governance origin that is controlled by some consortium (ie. System Collective).
-This origin could then update the NFT deposits any time the market conditions warrant it - obviously while honoring the storage deposit requirements.
-To implement this, we need RFC#12 and the Parameters pallet from @xlc.
--> OliverTY
-
-This dynamic governance approach would facilitate a responsive and agile economic model for deposit management, ensuring that the network remains both accessible and robust in the face of market volatility.
-Ergonomics
-The proposed change aims to enhance the user experience for artists, making Polkadot more accessible and user-friendly.
-Compatibility
-The change doesn't impact compatibility.
Unresolved Questions
-
-- Determining the optimal new deposit amount that reduces the barrier to entry while preventing state bloat remains a subject for debate. What is the balance that allows for inclusivity without compromising the network's efficiency and security?
-
+None
Future Directions and Related Material
-If accepted, this RFC could pave the way for further discussions and proposals aimed at enhancing the inclusivity and accessibility of the Polkadot ecosystem. Future work could also explore having a weak governance origin for deposits as proposed by Oliver.
+The current networking protocol could be deprecated in a long time. Additionally, the current "state requests" protocol (used for warp syncing) could also be deprecated in favor of this one.
Table of Contents
@@ -4898,7 +4944,7 @@ This path is only available to the asset class's Admin or Fre
This RFC proposes a fourth path that does not introduce prior steps for either the sender or
receiver of the asset.
-Requirements
+Requirements
- The system MUST be secure against economic attacks that allow an attacker to create a virtually
unlimited number of accounts.
diff --git a/proposed/0004-remove-unnecessary-allocator-usage.html b/proposed/0004-remove-unnecessary-allocator-usage.html
index 19906c8..ffd244e 100644
--- a/proposed/0004-remove-unnecessary-allocator-usage.html
+++ b/proposed/0004-remove-unnecessary-allocator-usage.html
@@ -90,7 +90,7 @@
@@ -447,7 +447,7 @@ This would remove the possibility to synchronize older blocks, which is probably
-
+
@@ -461,7 +461,7 @@ This would remove the possibility to synchronize older blocks, which is probably
-
+
diff --git a/stale/000x-assethub.html b/proposed/000x-assethub.html
similarity index 67%
rename from stale/000x-assethub.html
rename to proposed/000x-assethub.html
index 5673002..cee0313 100644
--- a/stale/000x-assethub.html
+++ b/proposed/000x-assethub.html
@@ -90,7 +90,7 @@
@@ -180,7 +180,11 @@
- RFC-0000: Lowering NFT Deposits on Polkadot and Kusama Asset Hubs
- Summary
-- Motivation
+- Motivation
+
+- Requirements
+
+
- Stakeholders
- Explanation
- Drawbacks
@@ -201,28 +205,66 @@
Start Date 2 November 2023 Description A proposal to reduce the minimum deposit required for collection creation on the Polkadot and Kusama Asset Hub, making it more accessible and affordable for artists. Authors Aurora Poppyseed, Just_Luuuu, VikiiVal Authors Aurora Poppyseed, Just_Luuuu, Viki Val
Summary
-This RFC proposes a change to the current deposit requirements on the Polkadot and Kusama Asset Hub for creating NFT collections. The objective is to lower the barrier to entry for artists, fostering a more inclusive and vibrant ecosystem, while maintaining network integrity and preventing spam.
+This RFC proposes changing the current deposit requirements on the Polkadot and Kusama Asset Hub for creating NFT collections. The objective is to lower the barrier to entry for artists, fostering a more inclusive and vibrant ecosystem while maintaining network integrity and preventing spam.
Motivation
The current deposit of 10 DOT for collection creation on the Polkadot Asset Hub presents a significant financial barrier for many artists. By lowering the deposit requirements, we aim to encourage more artists to participate in the Polkadot NFT ecosystem, thereby enriching the diversity and vibrancy of the community and its offerings.
+The actual implementation of the deposit is an arbitrary number coming from Uniques pallet. It is not a result of any economic analysis. This proposal aims to adjust the deposit from constant to dynamic pricing based on the deposit function with respect to stakeholders.
+Requirements
+
+- Deposit SHOULD be derived from
deposit function adjusted by correspoding pricing mechansim.
+
Stakeholders
- NFT Creators: Primary beneficiaries of the proposed change, particularly those who found the current deposit requirements prohibitive.
-- NFT Platforms: As the facilitator of artists' relations, KodaDot has a vested interest in making the platform more accessible.
+- NFT Platforms: As the facilitator of artists' relations, NFT Marketplaces has a vested interest in onboarding new users and making the platform more accessible.
+- dApp Developers: Making the blockspace more accessible will encourage developers to create and build unique dApps in the Polkadot ecosystem.
- Polkadot Community: Stands to benefit from an influx of artists, creators and diverse NFT collections, enhancing the overall ecosystem.
-Previous discussions have been held within the KodaDot community, as well as with artists expressing their concerns about the deposit amounts. Referencing to Polkadot Forum conversation.
+Previous discussions have been held within the Polkadot Forum community and with artists expressing their concerns about the deposit amounts. Link.
Explanation
-This RFC suggests modifying the smart contract governing collection creation on the Polkadot Asset Hub to require a lower deposit. The exact amount of the reduced deposit is yet to be determined and should be discussed and agreed upon by the stakeholders. The implementation of this change requires careful consideration of the network's integrity and the prevention of spam, possibly through alternative means such as rate limiting or account verification.
+This RFC suggests modifying deposit constants defined in the nfts pallet on the Polkadot Asset Hub to require a lower deposit. The reduced deposit amount should be determined by the deposit adjusted by the pricing mechanism (arbitrary number/another pricing function).
+
+
#![allow(unused)]
+fn main() {
+parameter_types! {
+ // re-use the Uniques deposits
+ pub const NftsCollectionDeposit: Balance = UniquesCollectionDeposit::get();
+ pub const NftsItemDeposit: Balance = UniquesItemDeposit::get();
+ pub const NftsMetadataDepositBase: Balance = UniquesMetadataDepositBase::get();
+ pub const NftsAttributeDepositBase: Balance = UniquesAttributeDepositBase::get();
+ pub const NftsDepositPerByte: Balance = UniquesDepositPerByte::get();
+}
+
+//
+parameter_types! {
+ pub const UniquesCollectionDeposit: Balance = UNITS / 10; // 1 / 10 UNIT deposit to create a collection
+ pub const UniquesItemDeposit: Balance = UNITS / 1_000; // 1 / 1000 UNIT deposit to mint an item
+ pub const UniquesMetadataDepositBase: Balance = deposit(1, 129);
+ pub const UniquesAttributeDepositBase: Balance = deposit(1, 0);
+ pub const UniquesDepositPerByte: Balance = deposit(0, 1);
+}
+}
+The proposed change would modify the deposit constants to require a lower deposit. The reduced deposit amount should be determined by deposit adjusted by an arbitrary number.
+#![allow(unused)]
+fn main() {
+parameter_types! {
+ pub const NftsCollectionDeposit: Balance = deposit(1, 130);
+ pub const NftsItemDeposit: Balance = deposit(1, 164) / 40;
+ pub const NftsMetadataDepositBase: Balance = deposit(1, 129) / 10;
+ pub const NftsAttributeDepositBase: Balance = deposit(1, 0) / 10;
+ pub const NftsDepositPerByte: Balance = deposit(0, 1);
+}
+}
Prices and Proposed Prices on Polkadot Asset Hub:
Scroll right
| **Name** | **Current price implementation** | **Price if DOT = 5$** | **Price if DOT goes to 50$** | **Proposed Price in DOT** | **Proposed Price if DOT = 5$** | **Proposed Price if DOT goes to 50$**|
|---------------------------|----------------------------------|------------------------|-------------------------------|---------------------------|----------------------------------|--------------------------------------|
-| collectionDeposit | 10 DOT | 50 $ | 500 $ | 0.1 DOT | 0.5 $ | 5$ |
-| itemDeposit | 0.01 DOT | 0.05 $ | 0.5 $ | 0.001 DOT | 0.005 $ | 0.05$ |
+| collectionDeposit | 10 DOT | 50 $ | 500 $ | 0.20064 DOT | ~1 $ | 10.32$ |
+| itemDeposit | 0.01 DOT | 0.05 $ | 0.5 $ | 0.005 DOT | 0.025 $ | 0.251$ |
| metadataDepositBase | 0.20129 DOT | 1.00645 $ | 10.0645 $ | 0.0020129 DOT | 0.0100645 $ | 0.100645$ |
| attributeDepositBase | 0.2 DOT | 1 $ | 10 $ | 0.002 DOT | 0.01 $ | 0.1$ |
@@ -230,17 +272,17 @@
Scroll right
| **Name** | **Current price implementation** | **Price if KSM = 23$** | **Price if KSM goes to 500$** | **Proposed Price in KSM** | **Proposed Price if KSM = 23$** | **Proposed Price if KSM goes to 500$** |
|---------------------------|----------------------------------|------------------------|-------------------------------|---------------------------|----------------------------------|----------------------------------------|
-| collectionDeposit | 0.1 KSM | 2.3 $ | 50 $ | 0.01 KSM | 0.23 $ | 5 $ |
-| itemDeposit | 0.001 KSM | 0.023 $ | 0.5 $ | 0.0001 KSM | 0.0023 $ | 0.05 $ |
+| collectionDeposit | 0.1 KSM | 2.3 $ | 50 $ | 0.006688 KSM | 0.154 $ | 3.34 $ |
+| itemDeposit | 0.001 KSM | 0.023 $ | 0.5 $ | 0.000167 KSM | 0.00385 $ | 0.0835 $ |
| metadataDepositBase | 0.006709666617 KSM | 0.15432183319 $ | 3.3548333085 $ | 0.0006709666617 KSM | 0.015432183319 $ | 0.33548333085 $ |
| attributeDepositBase | 0.00666666666 KSM | 0.15333333318 $ | 3.333333333 $ | 0.000666666666 KSM | 0.015333333318 $ | 0.3333333333 $ |
-Note: This is only a proposal for change and it can be modified upon additional conversation.
+Note: This is only a proposal for change and can be modified upon additional conversation.
Drawbacks
-The contemplation of modifying deposit requirements necessitates a balanced assessment of the potential drawbacks. Highlighted below are cogent points extracted from the discourse on the Polkadot Forum conversation, which provide critical perspectives on the implications of such changes:
+Modifying deposit requirements necessitates a balanced assessment of the potential drawbacks. Highlighted below are cogent points extracted from the discourse on the Polkadot Forum conversation, which provide critical perspectives on the implications of such changes:
But NFT deposits were chosen somewhat arbitrarily at genesis and it’s a good exercise to re-evaluate them and adapt if they are causing pain and if lowering them has little or no negative side effect (or if the trade-off is worth it).
-> joepetrowski
@@ -254,9 +296,10 @@
-> joepetrowski
Testing, Security, and Privacy
+The change is backwards compatible. The prevention of "spam" could be prevented by OpenGov proposal to forceDestoy list of collections that are not suitable.
Performance, Ergonomics, and Compatibility
Performance
-This change is not expected to have a significant impact on the overall performance of the Polkadot Asset Hub. However, it is crucial to monitor the network closely, especially in the initial stages after implementation, to identify and mitigate any potential issues.
+This change is not expected to have a significant impact on the overall performance of the Polkadot Asset Hub. However, monitoring the network closely, especially in the initial stages after implementation, is crucial to identify and mitigate any potential issues.
Additionally, a supplementary proposal aims to augment the network's adaptability:
Just from a technical perspective; I think the best we can do is to use a weak governance origin that is controlled by some consortium (ie. System Collective).
@@ -264,27 +307,30 @@ This origin could then update the NFT deposits any time the market conditions wa
To implement this, we need RFC#12 and the Parameters pallet from @xlc.
-> OliverTY
-This dynamic governance approach would facilitate a responsive and agile economic model for deposit management, ensuring that the network remains both accessible and robust in the face of market volatility.
+This dynamic governance approach would facilitate a responsive and agile economic model for deposit management, ensuring that the network remains accessible and robust in the face of market volatility.
Ergonomics
The proposed change aims to enhance the user experience for artists, making Polkadot more accessible and user-friendly.
Compatibility
-The change doesn't impact compatibility.
+The change does not impact compatibility as redeposit function is already implemented.
Unresolved Questions
-- Determining the optimal new deposit amount that reduces the barrier to entry while preventing state bloat remains a subject for debate. What is the balance that allows for inclusivity without compromising the network's efficiency and security?
+
Future Directions and Related Material
+
+
+
If accepted, this RFC could pave the way for further discussions and proposals aimed at enhancing the inclusivity and accessibility of the Polkadot ecosystem. Future work could also explore having a weak governance origin for deposits as proposed by Oliver.