Linear pricing<
SCALE_UP = 1
OLD_PRICE = 1000
-Drawbacks
+Drawbacks
None at present.
-Prior Art and References
+Prior Art and References
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.
Future Possibilities
This RFC, if accepted, shall be implemented in conjunction with RFC-1.
@@ -7135,9 +7058,9 @@ Summary
+Summary
Improve 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.
-Motivation
+Motivation
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:
@@ -7147,9 +7070,9 @@ Motivation
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.
-Stakeholders
+Stakeholders
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.
-Explanation
+Explanation
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 {
@@ -7207,22 +7130,22 @@ Explanation
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
+Prior Art and References
None. This RFC is a clean-up of an existing mechanism.
Unresolved Questions
None
@@ -7256,9 +7179,9 @@ Summary
+Summary
This document is a proposal for restructuring the bulk markets in the Polkadot UC's coretime allocation system to improve efficiency and fairness. The proposal suggests separating the BULK_PERIOD into MARKET_PERIOD and RENEWAL_PERIOD, allowing for a market-driven price discovery through a clearing price Dutch auction during the MARKET_PERIOD followed by renewal offers at the MARKET_PRICE during the RENEWAL_PERIOD. The new system ensures synchronicity between renewal and market prices, fairness among all current tenants, and efficient price discovery, while preserving price caps to provide security for current tenants. It seeks to start a discussion about the possibility of long-term leases.
-Motivation
+Motivation
While the initial RFC-1 has provided a robust framework for Coretime allocation within the Polkadot UC, this proposal builds upon its strengths and uses many provided building blocks to address some areas that could be further improved.
In particular, this proposal introduces the following changes:
@@ -7278,14 +7201,14 @@ Motivation
The premise of this proposal is to reduce complexity by introducing a common price (that develops releative to capacity consumption of Polkadot UC), while still allowing for market forces to add efficiency. Longterm lease owners still receive priority IF they can pay (close to) the market price. This prevents a situation where the renewal price significantly diverges from renewal prices which allows for core captures. While maximum price increase certainty might seem contradictory to efficient price discovery, the proposed model aims to balance these elements, utilizing market forces to determine the price and allocate cores effectively within certain bounds. It must be stated, that potential price increases remain predictable (in the worst-case) but could be higher than in the originally proposed design. The argument remains, however, that we need to allow market forces to affect all prices for an efficient Coretime pricing and allocation.
Ultimately, this the framework proposed here adheres to all requirements stated in RFC-1.
-Stakeholders
+Stakeholders
Primary stakeholder sets are:
- Protocol researchers and developers, largely represented by the Polkadot Fellowship and Parity Technologies' Engineering division.
- Polkadot Parachain teams both present and future, and their users.
- Polkadot DOT token holders.
-Explanation
+Explanation
Bulk Markets
The BULK_PERIOD has been restructured into two primary segments: the MARKET_PERIOD and RENEWAL_PERIOD, along with an auxiliary SETTLEMENT_PERIOD. This latter period doesn't necessitate any actions from the coretime system chain, but it facilitates a more efficient allocation of coretime in secondary markets. A significant departure from the original proposal lies in the timing of renewals, which now occur post-market phase. This adjustment aims to harmonize renewal prices with their market counterparts, ensuring a more consistent and equitable pricing model.
Market Period (14 days)
@@ -7332,9 +7255,9 @@ Drawbacks
+Drawbacks
There are trade-offs that arise from this proposal, compared to the initial model. The most notable one is that here, I prioritize requirement 6 over requirement 2. The price, in the very "worst-case" (meaning a huge explosion in demand for coretime) could lead to a much larger increase of prices in Coretime. From an economic perspective, this (rare edgecase) would also mean that we'd vastly underprice Coretime in the original model, leading to highly inefficient allocations.
-Prior Art and References
+Prior Art and References
This RFC builds extensively on the available ideas put forward in RFC-1.
Additionally, I want to express a special thanks to Samuel Haefner and Shahar Dobzinski for fruitful discussions and helping me structure my thoughts.
Unresolved Questions
@@ -7369,16 +7292,16 @@ Authors Gabriel Facco de Arruda
-Summary
+Summary
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.
-Motivation
+Motivation
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.
-Stakeholders
+Stakeholders
- Ecosystem developers
-Explanation
+Explanation
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)]
@@ -7435,20 +7358,20 @@ WithCom
DescribeFamily
The DescribeFamily location descriptor is part of the HashedDescription MultiLocation 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
+Prior Art and References
DescirbeFamily type: https://github.com/paritytech/polkadot-sdk/blob/master/polkadot/xcm/xcm-builder/src/location_conversion.rs#L122WithComputedOrigin type: https://github.com/paritytech/polkadot-sdk/blob/master/polkadot/xcm/xcm-builder/src/barriers.rs#L153ChaosDAO Summary
+Summary
This RFC proposes to make modifications to voting power delegations as part of the Conviction Voting pallet. The changes being proposed include:
- Allow a Delegator to vote independently of their Delegate if they so desire.
@@ -7493,7 +7416,7 @@ Summary
- Make a change so that when a delegate votes abstain their delegated votes also vote abstain.
- Allow a Delegator to delegate/ undelegate their votes for all tracks with a single call.
-Motivation
+Motivation
It has become clear since the launch of OpenGov that there are a few common tropes which pop up time and time again:
- The frequency of referenda is often too high for network participants to have sufficient time to review, comprehend, and ultimately vote on each individual referendum. This means that these network participants end up being inactive in on-chain governance.
@@ -7501,13 +7424,13 @@ MotivationDelegating votes for all tracks currently requires long batched calls which result in high fees for the Delegator - resulting in a reluctance from many to delegate their votes.
We believe (based on feedback from token holders with a larger stake in the network) that if there were some changes made to delegation mechanics, these larger stake holders would be more likely to delegate their voting power to active network participants – thus greatly increasing the support turnout.
-Stakeholders
+Stakeholders
The primary stakeholders of this RFC are:
- The Polkadot Technical Fellowship who will have to research and implement the technical aspects of this RFC
- DOT token holders in general
-Explanation
+Explanation
This RFC proposes to make 4 changes to the convictionVoting pallet logic in order to improve the user experience of those delegating their voting power to another account.
-
@@ -7523,17 +7446,17 @@
Explanation
Allow a Delegator to delegate/ undelegate their votes for all tracks with a single call - in order to delegate votes across all tracks, a user must batch 15 calls - resulting in high costs for delegation. A single call for delegate_all/ undelegate_all would reduce the complexity and therefore costs of delegations considerably for prospective Delegators.
-Drawbacks
+Drawbacks
We do not foresee any drawbacks by implementing these changes. If anything we believe that this should help to increase overall voter turnout (via the means of delegation) which we see as a net positive.
-Testing, Security, and Privacy
+Testing, Security, and Privacy
We feel that the Polkadot Technical Fellowship would be the most competent collective to identify the testing requirements for the ideas presented in this RFC.
-Performance, Ergonomics, and Compatibility
-Performance
+Performance, Ergonomics, and Compatibility
+Performance
This change may add extra chain storage requirements on Polkadot, especially with respect to nested delegations.
Ergonomics & Compatibility
The change to add nested delegations may affect governance interfaces such as Nova Wallet who will have to apply changes to their indexers to support nested delegations. It may also affect the Polkadot Delegation Dashboard as well as Polkassembly & SubSquare.
We want to highlight the importance for ecosystem builders to create a mechanism for indexers and wallets to be able to understand that changes have occurred such as increasing the pallet version, etc.
-Prior Art and References
+Prior Art and References
N/A
Unresolved Questions
N/A
@@ -7579,9 +7502,9 @@ Summary
+Summary
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.
-Motivation
+Motivation
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.
@@ -7595,11 +7518,11 @@ RequirementsThe solution MUST allow anyone to pay the rent.
- The solution MUST prevent the removal of validation code if it could still be required for disputes or approval checking.
-Stakeholders
+Stakeholders
- Future Polkadot on-demand Parachains
-Explanation
+Explanation
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.
@@ -7706,23 +7629,23 @@ }
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.
-Drawbacks
+Drawbacks
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.
-Testing, Security, and Privacy
+Testing, Security, and Privacy
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.
-Performance, Ergonomics, and Compatibility
-Performance
+Performance, Ergonomics, and Compatibility
+Performance
This RFC should not introduce any performance impact.
-Ergonomics
+Ergonomics
This RFC does not affect the current parachains, nor the parachains that intend to use the one-time payment model for parachain registration.
-Compatibility
+Compatibility
This RFC does not break compatibility.
-Prior Art and References
+Prior Art and References
Prior discussion on this topic: https://github.com/paritytech/polkadot-sdk/issues/1796
Unresolved Questions
None at this time.
@@ -7760,16 +7683,16 @@ Summary
+Summary
Rather than enforce a limit to the total memory consumption on the client side by loading the value at :heappages, enforce that limit on the runtime side.
-Motivation
+Motivation
From the early days of Substrate up until recently, the runtime was present in two forms: the wasm runtime (wasm bytecode passed through an interpreter) and the native runtime (native code directly run by the client).
Since the wasm runtime has a lower amount of available memory (4 GiB maximum) compared to the native runtime, and in order to ensure sure that the wasm and native runtimes always produce the same outcome, it was necessary to clamp the amount of memory available to both runtimes to the same value.
In order to achieve this, a special storage key (a "well-known" key) :heappages was introduced and represents the number of "wasm pages" (one page equals 64kiB) of memory that are available to the memory allocator of the runtimes. If this storage key is absent, it defaults to 2048, which is 128 MiB.
The native runtime has since then been disappeared, but the concept of "heap pages" still exists. This RFC proposes a simplification to the design of Polkadot by removing the concept of "heap pages" as is currently known, and proposes alternative ways to achieve the goal of limiting the amount of memory available.
-Stakeholders
+Stakeholders
Client implementers and low-level runtime developers.
-Explanation
+Explanation
This RFC proposes the following changes to the client:
- The client no longer considers
:heappages as special.
@@ -7795,23 +7718,23 @@ Explanation
Each parachain can choose the option that they prefer, but the author of this RFC strongly suggests either option C or B.
-Drawbacks
+Drawbacks
In case of path A, there is one situation where the behaviour pre-RFC is not equivalent to the one post-RFC: when a host function that performs an allocation (for example ext_storage_get) is called, without this RFC this allocation might fail due to reaching the maximum heap pages, while after this RFC this will always succeed.
This is most likely not a problem, as storage values aren't supposed to be larger than a few megabytes at the very maximum.
In the unfortunate event where the runtime runs out of memory, path B would make it more difficult to relax the memory limit, as we would need to re-upload the entire Wasm, compared to updating only :heappages in path A or before this RFC.
In the case where the runtime runs out of memory only in the specific event where the Wasm runtime is modified, this could brick the chain. However, this situation is no different than the thousands of other ways that a bug in the runtime can brick a chain, and there's no reason to be particularily worried about this situation in particular.
-Testing, Security, and Privacy
+Testing, Security, and Privacy
This RFC would reduce the chance of a consensus issue between clients.
The :heappages are a rather obscure feature, and it is not clear what happens in some corner cases such as the value being too large (error? clamp?) or malformed. This RFC would completely erase these questions.
-Performance, Ergonomics, and Compatibility
-Performance
+Performance, Ergonomics, and Compatibility
+Performance
In case of path A, it is unclear how performances would be affected. Path A consists in moving client-side operations to the runtime without changing these operations, and as such performance differences are expected to be minimal. Overall, we're talking about one addition/subtraction per malloc and per free, so this is more than likely completely negligible.
In case of path B and C, the performance gain would be a net positive, as this RFC strictly removes things.
-Ergonomics
+Ergonomics
This RFC would isolate the client and runtime more from each other, making it a bit easier to reason about the client or the runtime in isolation.
-Compatibility
+Compatibility
Not a breaking change. The runtime-side changes can be applied immediately (without even having to wait for changes in the client), then as soon as the runtime is updated, the client can be updated without any transition period. One can even consider updating the client before the runtime, as it corresponds to path C.
-Prior Art and References
+Prior Art and References
None.
Unresolved Questions
None.
@@ -7853,7 +7776,7 @@ Summary
+Summary
This RFC proposes adding a trivial governance track on Kusama to facilitate X (formerly known as Twitter) posts on the @kusamanetwork account. The technical aspect
of implementing this in the runtime is very inconsequential and straight-forward, though it might get more technical if the Fellowship wants to regulate this track
with a non-existent permission set. If this is implemented it would need to be followed up with:
@@ -7861,7 +7784,7 @@ Summary
- the establishment of specifications for proposing X posts via this track, and
- the development of tools/processes to ensure that the content contained in referenda enacted in this track would be automatically posted on X.
-Motivation
+Motivation
The overall motivation for this RFC is to decentralize the management of the Kusama brand/communication channel to KSM holders. This is necessary in my opinion primarily
because of the inactivity of the account in recent history, with posts spanning weeks or months apart. I am currently unaware of who/what entity manages the Kusama
X account, but if they are affiliated with Parity or W3F this proposed solution could also offload some of the legal ramifications of making (or not making)
@@ -7871,11 +7794,11 @@
Motivation
Finally, this RFC is the epitome of experimentation that Kusama is ideal for. This proposal may spark newfound excitement for Kusama and help us realize Kusama's potential
for pushing boundaries and trying new unconventional ideas.
-Stakeholders
+Stakeholders
This idea has not been formalized by any individual (or group of) KSM holder(s). To my knowledge the socialization of this idea is contained
entirely in my recent X post here, but it is possible that an idea like this one has been discussed in
other places. It appears to me that the ecosystem would welcome a change like this which is why I am taking action to formalize the discussion.
-Explanation
+Explanation
The implementation of this idea can be broken down into 3 primary phases:
Phase 1 - Track configurations
First, we begin with this RFC to ensure all feedback can be discussed and implemented in the proposal. After the Fellowship and the community come to a reasonable
@@ -7928,7 +7851,7 @@
Drawbacks
+Drawbacks
The main drawback to this change is that it requires a lot of off-chain coordination. It's easy enough to include the track on Kusama but it's a totally different
challenge to make it function as intended. The tools need to be built and the auth tokens need to be managed. It would certainly add an administrative burden to whoever
manages the X account since they would either need to run the tools themselves or manage auth tokens.
@@ -7940,22 +7863,22 @@ Drawbacks
agency to manage posts. It wouldn't be decentralized but it would probably be more effective in terms of creating good content.
Finally, this solution is merely pseudo-decentralization since the X account manager would still have ultimate control of the account. It's decentralized insofar as
the auth tokens are given to people actually running the tools; a house of cards is required to facilitate X posts via this track. Not ideal.
-Testing, Security, and Privacy
+Testing, Security, and Privacy
There's major precedent for configuring tracks on openGov given the amount of power tracks have, so it shouldn't be hard to come up with a sound configuration.
That's why I recommend restricting permissions of this track to remarks and batches of remarks, or something equally inconsequential.
Building the tools for this implementation is really straight-forward and could be audited by Fellowship members, and the community at large, on Github.
The largest security concern would be the management of Kusama's X account's auth tokens. We would need to ensure that they aren't compromised.
-Performance, Ergonomics, and Compatibility
-Performance
+Performance, Ergonomics, and Compatibility
+Performance
If a track on Kusama promises users that compliant referenda enacted therein would be posted on Kusama's X account, users would expect that track to perform as promised.
If the house of cards tumbles down and a compliant referendum doesn't actually get anything posted, users might think that Kusama is broken or unreliable. This
could be damaging to Kusama's image and cause people to question the soundness of other features on Kusama.
As mentioned in the drawbacks, the performance of this feature would depend on off-chain coordinations. We can reduce the administrative burden of these coordinations
by funding third parties with the Treasury to deal with it, but then we're relying on trusting these parties.
-Ergonomics
+Ergonomics
By adding a new track to Kusama, governance platforms like Polkassembly or Nova Wallet would need to include it on their applications. This shouldn't be too
much of a burden or overhead since they've already built the infrastructure for other openGov tracks.
-Compatibility
+Compatibility
This change wouldn't break any compatibility as far as I know.
References
One reference to a similar feature requiring on-chain/off-chain coordination would be the Kappa-Sigma-Mu Society. Nothing on-chain necessarily enforces the rules
@@ -8000,11 +7923,11 @@
Summary
+Summary
The current size of the decision deposit on some tracks is too high for many proposers. As a result, those needing to use it have to find someone else willing to put up the deposit for them - and a number of legitimate attempts to use the root track have timed out. This track would provide a more affordable (though slower) route for these holders to use the root track.
-Motivation
+Motivation
There have been recent attempts to use the Kusama root track which have timed out with no decision deposit placed. Usually, these referenda have been related to parachain registration related issues.
-Explanation
+Explanation
Propose to address this by adding a new referendum track [22] Referendum Deposit which can place the decision deposit on another referendum. This would require the following changes:
- [Referenda Pallet] Modify the
placeDecisionDesposit function to additionally allow it to be called by root, with root call bypassing the requirements for a deposit payment.
@@ -8028,19 +7951,19 @@ Drawbacks
+Drawbacks
This track would provide a route to starting a root referendum with a much-reduced slashable deposit. This might be undesirable but, assuming the decision deposit cost for this track is still high enough, slashing would still act as a disincentive.
An alternative to this might be to reduce the decision deposit size some of the more expensive tracks. However, part of the purpose of the high deposit - at least on the root track - is to prevent spamming the limited queue with junk referenda.
-Testing, Security, and Privacy
+Testing, Security, and Privacy
Will need additional tests case for the modified pallet and runtime. No security or privacy issues.
-Performance, Ergonomics, and Compatibility
-Performance
+Performance, Ergonomics, and Compatibility
+Performance
No significant performance impact.
-Ergonomics
+Ergonomics
Only changes related to adding the track. Existing functionality is unchanged.
-Compatibility
+Compatibility
No compatibility issues.
-Prior Art and References
+Prior Art and References
- Recent discussion / referendum for an alternative way to address this issue: Kusama Referendum 340 - Funding a Decision Deposit Sponsor
@@ -8089,7 +8012,7 @@ Summary
+Summary
A pallet to facilitate enhanced multisig accounts. The main enhancement is that we store a multisig account in the state with related info (signers, threshold,..etc). The module affords enhanced control over administrative operations such as adding/removing signers, changing the threshold, account deletion, canceling an existing proposal. Each signer can approve/reject a proposal while still exists. The proposal is not intended for migrating or getting rid of existing multisig. It's to allow both options to coexist.
For the rest of the RFC We use the following terms:
@@ -8097,7 +8020,7 @@ Summary
Stateful Multisig to refer to the proposed pallet.Stateless Multisig to refer to the current multisig pallet in polkadot-sdk.
-Motivation
+Motivation
Problem
Entities in the Polkadot ecosystem need to have a way to manage their funds and other operations in a secure and efficient way. Multisig accounts are a common way to achieve this. Entities by definition change over time, members of the entity may change, threshold requirements may change, and the multisig account may need to be deleted. For even more enhanced hierarchical control, the multisig account may need to be controlled by other multisig accounts.
Current native solutions for multisig operations are less optimal, performance-wise (as we'll explain later in the RFC), and lack fine-grained control over the multisig account.
@@ -8139,12 +8062,12 @@ Use Cases
and much more...
-Stakeholders
+Stakeholders
- Polkadot holders
- Polkadot developers
-Explanation
+Explanation
I've created the stateful multisig pallet during my studies in Polkadot Blockchain Academy under supervision from @shawntabrizi and @ank4n. After that, I've enhanced it to be fully functional and this is a draft PR#3300 in polkadot-sdk. I'll list all the details and design decisions in the following sections. Note that the PR is not 1-1 exactly to the current RFC as the RFC is a more polished version of the PR after updating based on the feedback and discussions.
Let's start with a sequence diagram to illustrate the main operations of the Stateful Multisig.
@@ -8557,14 +8480,14 @@ In case threshold is lower than the number of approvers then the proposal is still valid.
- In case threshold is higher than the number of approvers then we catch it during execute proposal and error.
Summary
Motivation
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.
Stakeholders
+Stakeholders
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.
-Explanation
+Explanation
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 {
@@ -7207,22 +7130,22 @@ Explanation
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
+Prior Art and References
None. This RFC is a clean-up of an existing mechanism.
Unresolved Questions
None
@@ -7256,9 +7179,9 @@ Summary
+Summary
This document is a proposal for restructuring the bulk markets in the Polkadot UC's coretime allocation system to improve efficiency and fairness. The proposal suggests separating the BULK_PERIOD into MARKET_PERIOD and RENEWAL_PERIOD, allowing for a market-driven price discovery through a clearing price Dutch auction during the MARKET_PERIOD followed by renewal offers at the MARKET_PRICE during the RENEWAL_PERIOD. The new system ensures synchronicity between renewal and market prices, fairness among all current tenants, and efficient price discovery, while preserving price caps to provide security for current tenants. It seeks to start a discussion about the possibility of long-term leases.
-Motivation
+Motivation
While the initial RFC-1 has provided a robust framework for Coretime allocation within the Polkadot UC, this proposal builds upon its strengths and uses many provided building blocks to address some areas that could be further improved.
In particular, this proposal introduces the following changes:
@@ -7278,14 +7201,14 @@ Motivation
The premise of this proposal is to reduce complexity by introducing a common price (that develops releative to capacity consumption of Polkadot UC), while still allowing for market forces to add efficiency. Longterm lease owners still receive priority IF they can pay (close to) the market price. This prevents a situation where the renewal price significantly diverges from renewal prices which allows for core captures. While maximum price increase certainty might seem contradictory to efficient price discovery, the proposed model aims to balance these elements, utilizing market forces to determine the price and allocate cores effectively within certain bounds. It must be stated, that potential price increases remain predictable (in the worst-case) but could be higher than in the originally proposed design. The argument remains, however, that we need to allow market forces to affect all prices for an efficient Coretime pricing and allocation.
Ultimately, this the framework proposed here adheres to all requirements stated in RFC-1.
-Stakeholders
+Stakeholders
Primary stakeholder sets are:
- Protocol researchers and developers, largely represented by the Polkadot Fellowship and Parity Technologies' Engineering division.
- Polkadot Parachain teams both present and future, and their users.
- Polkadot DOT token holders.
-Explanation
+Explanation
Bulk Markets
The BULK_PERIOD has been restructured into two primary segments: the MARKET_PERIOD and RENEWAL_PERIOD, along with an auxiliary SETTLEMENT_PERIOD. This latter period doesn't necessitate any actions from the coretime system chain, but it facilitates a more efficient allocation of coretime in secondary markets. A significant departure from the original proposal lies in the timing of renewals, which now occur post-market phase. This adjustment aims to harmonize renewal prices with their market counterparts, ensuring a more consistent and equitable pricing model.
Market Period (14 days)
@@ -7332,9 +7255,9 @@ Drawbacks
+Drawbacks
There are trade-offs that arise from this proposal, compared to the initial model. The most notable one is that here, I prioritize requirement 6 over requirement 2. The price, in the very "worst-case" (meaning a huge explosion in demand for coretime) could lead to a much larger increase of prices in Coretime. From an economic perspective, this (rare edgecase) would also mean that we'd vastly underprice Coretime in the original model, leading to highly inefficient allocations.
-Prior Art and References
+Prior Art and References
This RFC builds extensively on the available ideas put forward in RFC-1.
Additionally, I want to express a special thanks to Samuel Haefner and Shahar Dobzinski for fruitful discussions and helping me structure my thoughts.
Unresolved Questions
@@ -7369,16 +7292,16 @@ Authors Gabriel Facco de Arruda
-Summary
+Summary
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.
-Motivation
+Motivation
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.
-Stakeholders
+Stakeholders
- Ecosystem developers
-Explanation
+Explanation
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)]
@@ -7435,20 +7358,20 @@ WithCom
DescribeFamily
The DescribeFamily location descriptor is part of the HashedDescription MultiLocation 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
+Prior Art and References
DescirbeFamily type: https://github.com/paritytech/polkadot-sdk/blob/master/polkadot/xcm/xcm-builder/src/location_conversion.rs#L122WithComputedOrigin type: https://github.com/paritytech/polkadot-sdk/blob/master/polkadot/xcm/xcm-builder/src/barriers.rs#L153ChaosDAO Summary
+Summary
This RFC proposes to make modifications to voting power delegations as part of the Conviction Voting pallet. The changes being proposed include:
- Allow a Delegator to vote independently of their Delegate if they so desire.
@@ -7493,7 +7416,7 @@ Summary
- Make a change so that when a delegate votes abstain their delegated votes also vote abstain.
- Allow a Delegator to delegate/ undelegate their votes for all tracks with a single call.
-Motivation
+Motivation
It has become clear since the launch of OpenGov that there are a few common tropes which pop up time and time again:
- The frequency of referenda is often too high for network participants to have sufficient time to review, comprehend, and ultimately vote on each individual referendum. This means that these network participants end up being inactive in on-chain governance.
@@ -7501,13 +7424,13 @@ MotivationDelegating votes for all tracks currently requires long batched calls which result in high fees for the Delegator - resulting in a reluctance from many to delegate their votes.
We believe (based on feedback from token holders with a larger stake in the network) that if there were some changes made to delegation mechanics, these larger stake holders would be more likely to delegate their voting power to active network participants – thus greatly increasing the support turnout.
-Stakeholders
+Stakeholders
The primary stakeholders of this RFC are:
- The Polkadot Technical Fellowship who will have to research and implement the technical aspects of this RFC
- DOT token holders in general
-Explanation
+Explanation
This RFC proposes to make 4 changes to the convictionVoting pallet logic in order to improve the user experience of those delegating their voting power to another account.
-
@@ -7523,17 +7446,17 @@
Explanation
Allow a Delegator to delegate/ undelegate their votes for all tracks with a single call - in order to delegate votes across all tracks, a user must batch 15 calls - resulting in high costs for delegation. A single call for delegate_all/ undelegate_all would reduce the complexity and therefore costs of delegations considerably for prospective Delegators.
-Drawbacks
+Drawbacks
We do not foresee any drawbacks by implementing these changes. If anything we believe that this should help to increase overall voter turnout (via the means of delegation) which we see as a net positive.
-Testing, Security, and Privacy
+Testing, Security, and Privacy
We feel that the Polkadot Technical Fellowship would be the most competent collective to identify the testing requirements for the ideas presented in this RFC.
-Performance, Ergonomics, and Compatibility
-Performance
+Performance, Ergonomics, and Compatibility
+Performance
This change may add extra chain storage requirements on Polkadot, especially with respect to nested delegations.
Ergonomics & Compatibility
The change to add nested delegations may affect governance interfaces such as Nova Wallet who will have to apply changes to their indexers to support nested delegations. It may also affect the Polkadot Delegation Dashboard as well as Polkassembly & SubSquare.
We want to highlight the importance for ecosystem builders to create a mechanism for indexers and wallets to be able to understand that changes have occurred such as increasing the pallet version, etc.
-Prior Art and References
+Prior Art and References
N/A
Unresolved Questions
N/A
@@ -7579,9 +7502,9 @@ Summary
+Summary
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.
-Motivation
+Motivation
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.
@@ -7595,11 +7518,11 @@ RequirementsThe solution MUST allow anyone to pay the rent.
- The solution MUST prevent the removal of validation code if it could still be required for disputes or approval checking.
-Stakeholders
+Stakeholders
- Future Polkadot on-demand Parachains
-Explanation
+Explanation
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.
@@ -7706,23 +7629,23 @@ }
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.
-Drawbacks
+Drawbacks
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.
-Testing, Security, and Privacy
+Testing, Security, and Privacy
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.
-Performance, Ergonomics, and Compatibility
-Performance
+Performance, Ergonomics, and Compatibility
+Performance
This RFC should not introduce any performance impact.
-Ergonomics
+Ergonomics
This RFC does not affect the current parachains, nor the parachains that intend to use the one-time payment model for parachain registration.
-Compatibility
+Compatibility
This RFC does not break compatibility.
-Prior Art and References
+Prior Art and References
Prior discussion on this topic: https://github.com/paritytech/polkadot-sdk/issues/1796
Unresolved Questions
None at this time.
@@ -7760,16 +7683,16 @@ Summary
+Summary
Rather than enforce a limit to the total memory consumption on the client side by loading the value at :heappages, enforce that limit on the runtime side.
-Motivation
+Motivation
From the early days of Substrate up until recently, the runtime was present in two forms: the wasm runtime (wasm bytecode passed through an interpreter) and the native runtime (native code directly run by the client).
Since the wasm runtime has a lower amount of available memory (4 GiB maximum) compared to the native runtime, and in order to ensure sure that the wasm and native runtimes always produce the same outcome, it was necessary to clamp the amount of memory available to both runtimes to the same value.
In order to achieve this, a special storage key (a "well-known" key) :heappages was introduced and represents the number of "wasm pages" (one page equals 64kiB) of memory that are available to the memory allocator of the runtimes. If this storage key is absent, it defaults to 2048, which is 128 MiB.
The native runtime has since then been disappeared, but the concept of "heap pages" still exists. This RFC proposes a simplification to the design of Polkadot by removing the concept of "heap pages" as is currently known, and proposes alternative ways to achieve the goal of limiting the amount of memory available.
-Stakeholders
+Stakeholders
Client implementers and low-level runtime developers.
-Explanation
+Explanation
This RFC proposes the following changes to the client:
- The client no longer considers
:heappages as special.
@@ -7795,23 +7718,23 @@ Explanation
Each parachain can choose the option that they prefer, but the author of this RFC strongly suggests either option C or B.
-Drawbacks
+Drawbacks
In case of path A, there is one situation where the behaviour pre-RFC is not equivalent to the one post-RFC: when a host function that performs an allocation (for example ext_storage_get) is called, without this RFC this allocation might fail due to reaching the maximum heap pages, while after this RFC this will always succeed.
This is most likely not a problem, as storage values aren't supposed to be larger than a few megabytes at the very maximum.
In the unfortunate event where the runtime runs out of memory, path B would make it more difficult to relax the memory limit, as we would need to re-upload the entire Wasm, compared to updating only :heappages in path A or before this RFC.
In the case where the runtime runs out of memory only in the specific event where the Wasm runtime is modified, this could brick the chain. However, this situation is no different than the thousands of other ways that a bug in the runtime can brick a chain, and there's no reason to be particularily worried about this situation in particular.
-Testing, Security, and Privacy
+Testing, Security, and Privacy
This RFC would reduce the chance of a consensus issue between clients.
The :heappages are a rather obscure feature, and it is not clear what happens in some corner cases such as the value being too large (error? clamp?) or malformed. This RFC would completely erase these questions.
-Performance, Ergonomics, and Compatibility
-Performance
+Performance, Ergonomics, and Compatibility
+Performance
In case of path A, it is unclear how performances would be affected. Path A consists in moving client-side operations to the runtime without changing these operations, and as such performance differences are expected to be minimal. Overall, we're talking about one addition/subtraction per malloc and per free, so this is more than likely completely negligible.
In case of path B and C, the performance gain would be a net positive, as this RFC strictly removes things.
-Ergonomics
+Ergonomics
This RFC would isolate the client and runtime more from each other, making it a bit easier to reason about the client or the runtime in isolation.
-Compatibility
+Compatibility
Not a breaking change. The runtime-side changes can be applied immediately (without even having to wait for changes in the client), then as soon as the runtime is updated, the client can be updated without any transition period. One can even consider updating the client before the runtime, as it corresponds to path C.
-Prior Art and References
+Prior Art and References
None.
Unresolved Questions
None.
@@ -7853,7 +7776,7 @@ Summary
+Summary
This RFC proposes adding a trivial governance track on Kusama to facilitate X (formerly known as Twitter) posts on the @kusamanetwork account. The technical aspect
of implementing this in the runtime is very inconsequential and straight-forward, though it might get more technical if the Fellowship wants to regulate this track
with a non-existent permission set. If this is implemented it would need to be followed up with:
@@ -7861,7 +7784,7 @@ Summary
- the establishment of specifications for proposing X posts via this track, and
- the development of tools/processes to ensure that the content contained in referenda enacted in this track would be automatically posted on X.
-Motivation
+Motivation
The overall motivation for this RFC is to decentralize the management of the Kusama brand/communication channel to KSM holders. This is necessary in my opinion primarily
because of the inactivity of the account in recent history, with posts spanning weeks or months apart. I am currently unaware of who/what entity manages the Kusama
X account, but if they are affiliated with Parity or W3F this proposed solution could also offload some of the legal ramifications of making (or not making)
@@ -7871,11 +7794,11 @@
Motivation
Finally, this RFC is the epitome of experimentation that Kusama is ideal for. This proposal may spark newfound excitement for Kusama and help us realize Kusama's potential
for pushing boundaries and trying new unconventional ideas.
-Stakeholders
+Stakeholders
This idea has not been formalized by any individual (or group of) KSM holder(s). To my knowledge the socialization of this idea is contained
entirely in my recent X post here, but it is possible that an idea like this one has been discussed in
other places. It appears to me that the ecosystem would welcome a change like this which is why I am taking action to formalize the discussion.
-Explanation
+Explanation
The implementation of this idea can be broken down into 3 primary phases:
Phase 1 - Track configurations
First, we begin with this RFC to ensure all feedback can be discussed and implemented in the proposal. After the Fellowship and the community come to a reasonable
@@ -7928,7 +7851,7 @@
Drawbacks
+Drawbacks
The main drawback to this change is that it requires a lot of off-chain coordination. It's easy enough to include the track on Kusama but it's a totally different
challenge to make it function as intended. The tools need to be built and the auth tokens need to be managed. It would certainly add an administrative burden to whoever
manages the X account since they would either need to run the tools themselves or manage auth tokens.
@@ -7940,22 +7863,22 @@ Drawbacks
agency to manage posts. It wouldn't be decentralized but it would probably be more effective in terms of creating good content.
Finally, this solution is merely pseudo-decentralization since the X account manager would still have ultimate control of the account. It's decentralized insofar as
the auth tokens are given to people actually running the tools; a house of cards is required to facilitate X posts via this track. Not ideal.
-Testing, Security, and Privacy
+Testing, Security, and Privacy
There's major precedent for configuring tracks on openGov given the amount of power tracks have, so it shouldn't be hard to come up with a sound configuration.
That's why I recommend restricting permissions of this track to remarks and batches of remarks, or something equally inconsequential.
Building the tools for this implementation is really straight-forward and could be audited by Fellowship members, and the community at large, on Github.
The largest security concern would be the management of Kusama's X account's auth tokens. We would need to ensure that they aren't compromised.
-Performance, Ergonomics, and Compatibility
-Performance
+Performance, Ergonomics, and Compatibility
+Performance
If a track on Kusama promises users that compliant referenda enacted therein would be posted on Kusama's X account, users would expect that track to perform as promised.
If the house of cards tumbles down and a compliant referendum doesn't actually get anything posted, users might think that Kusama is broken or unreliable. This
could be damaging to Kusama's image and cause people to question the soundness of other features on Kusama.
As mentioned in the drawbacks, the performance of this feature would depend on off-chain coordinations. We can reduce the administrative burden of these coordinations
by funding third parties with the Treasury to deal with it, but then we're relying on trusting these parties.
-Ergonomics
+Ergonomics
By adding a new track to Kusama, governance platforms like Polkassembly or Nova Wallet would need to include it on their applications. This shouldn't be too
much of a burden or overhead since they've already built the infrastructure for other openGov tracks.
-Compatibility
+Compatibility
This change wouldn't break any compatibility as far as I know.
References
One reference to a similar feature requiring on-chain/off-chain coordination would be the Kappa-Sigma-Mu Society. Nothing on-chain necessarily enforces the rules
@@ -8000,11 +7923,11 @@
Summary
+Summary
The current size of the decision deposit on some tracks is too high for many proposers. As a result, those needing to use it have to find someone else willing to put up the deposit for them - and a number of legitimate attempts to use the root track have timed out. This track would provide a more affordable (though slower) route for these holders to use the root track.
-Motivation
+Motivation
There have been recent attempts to use the Kusama root track which have timed out with no decision deposit placed. Usually, these referenda have been related to parachain registration related issues.
-Explanation
+Explanation
Propose to address this by adding a new referendum track [22] Referendum Deposit which can place the decision deposit on another referendum. This would require the following changes:
- [Referenda Pallet] Modify the
placeDecisionDesposit function to additionally allow it to be called by root, with root call bypassing the requirements for a deposit payment.
@@ -8028,19 +7951,19 @@ Drawbacks
+Drawbacks
This track would provide a route to starting a root referendum with a much-reduced slashable deposit. This might be undesirable but, assuming the decision deposit cost for this track is still high enough, slashing would still act as a disincentive.
An alternative to this might be to reduce the decision deposit size some of the more expensive tracks. However, part of the purpose of the high deposit - at least on the root track - is to prevent spamming the limited queue with junk referenda.
-Testing, Security, and Privacy
+Testing, Security, and Privacy
Will need additional tests case for the modified pallet and runtime. No security or privacy issues.
-Performance, Ergonomics, and Compatibility
-Performance
+Performance, Ergonomics, and Compatibility
+Performance
No significant performance impact.
-Ergonomics
+Ergonomics
Only changes related to adding the track. Existing functionality is unchanged.
-Compatibility
+Compatibility
No compatibility issues.
-Prior Art and References
+Prior Art and References
- Recent discussion / referendum for an alternative way to address this issue: Kusama Referendum 340 - Funding a Decision Deposit Sponsor
@@ -8089,7 +8012,7 @@ Summary
+Summary
A pallet to facilitate enhanced multisig accounts. The main enhancement is that we store a multisig account in the state with related info (signers, threshold,..etc). The module affords enhanced control over administrative operations such as adding/removing signers, changing the threshold, account deletion, canceling an existing proposal. Each signer can approve/reject a proposal while still exists. The proposal is not intended for migrating or getting rid of existing multisig. It's to allow both options to coexist.
For the rest of the RFC We use the following terms:
@@ -8097,7 +8020,7 @@ Summary
Stateful Multisig to refer to the proposed pallet.Stateless Multisig to refer to the current multisig pallet in polkadot-sdk.
-Motivation
+Motivation
Problem
Entities in the Polkadot ecosystem need to have a way to manage their funds and other operations in a secure and efficient way. Multisig accounts are a common way to achieve this. Entities by definition change over time, members of the entity may change, threshold requirements may change, and the multisig account may need to be deleted. For even more enhanced hierarchical control, the multisig account may need to be controlled by other multisig accounts.
Current native solutions for multisig operations are less optimal, performance-wise (as we'll explain later in the RFC), and lack fine-grained control over the multisig account.
@@ -8139,12 +8062,12 @@ Use Cases
and much more...
-Stakeholders
+Stakeholders
- Polkadot holders
- Polkadot developers
-Explanation
+Explanation
I've created the stateful multisig pallet during my studies in Polkadot Blockchain Academy under supervision from @shawntabrizi and @ank4n. After that, I've enhanced it to be fully functional and this is a draft PR#3300 in polkadot-sdk. I'll list all the details and design decisions in the following sections. Note that the PR is not 1-1 exactly to the current RFC as the RFC is a more polished version of the PR after updating based on the feedback and discussions.
Let's start with a sequence diagram to illustrate the main operations of the Stateful Multisig.
@@ -8557,14 +8480,14 @@ In case threshold is lower than the number of approvers then the proposal is still valid.
- In case threshold is higher than the number of approvers then we catch it during execute proposal and error.