@@ -11,6 +11,7 @@ message Request {
@@ -4525,26 +4637,26 @@ 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.
-
+
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.
-
+
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.
-
-
+
+
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.
-
+
Irrelevant.
-
+
The prior networking protocol is maintained for now. The older version of this protocol could get removed in a long time.
-
+
None. This RFC is a clean-up of an existing mechanism.
-
+
None
-
+
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.
(source)
Table of Contents
@@ -4574,9 +4686,9 @@ Also note that child tries aren't considered as descendants of the main trie whe
| Authors | Jonas Gehrlein |
-
+
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.
-
+
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:
@@ -4596,14 +4708,14 @@ Also note that child tries aren't considered as descendants of the main trie whe
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.
-
+
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.
-
+
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.
@@ -4650,12 +4762,12 @@ Also note that child tries aren't considered as descendants of the main trie whe
- Long-term Coretime: The Polkadot UC is undergoing a transition from two-year leases without an instantaneous market to a model encompassing instantaneous and one-month leases. This shift seems to pivot from one extreme to another. While the introduction of short-term leases, both instantaneous and for one month, is a constructive move to lower barriers to entry and promote experimentation, it seems to be the case that established projects might benefit from more extended lease options. We could consider offering another product, such as a six-month Coretime lease, using the same mechanism described herein. Although the majority of leases would still be sold on a one-month basis, the addition of this option would enhance market efficiency as it would strengthen the impact of a secondary market.
-
+
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.
-
+
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.
-
+
The technical feasability needs to be assessed.
(source)
Table of Contents
@@ -4687,9 +4799,9 @@ Also note that child tries aren't considered as descendants of the main trie whe
| Authors | ChaosDAO |
-
+
This RFC proposes a change to the duration of the confirmation period for the treasurer track from 3 hours to at least 48 hours.
-
+
Track parameters for Polkadot OpenGov should be configured in a way that their "difficulty" increases relative to the power associated with their respective origin. When we look at the confirmation periods for treasury based tracks, we can see that this is clearly the case - with the one notable exception to the trend being the treasurer track:
| Track Description | Confirmation Period Duration |
|---|
| Small Tipper | 10 Min |
@@ -4702,7 +4814,7 @@ Also note that child tries aren't considered as descendants of the main trie whe
The confirmation period is one of the last lines of defence for the collective Polkadot stakeholders to react to a potentially bad referendum and vote NAY in order for its confirmation period to be aborted.
Since the power / privilege level of the treasurer track is greater than that of the the big spender track – their confirmation period should be either equal, or the treasurer track's should be higher (note: currently the big spender track has a longer confirmation period than even the root track).
-
+
The primary stakeholders of this RFC are:
- DOT token holders – as this affects the protocol's treasury
@@ -4712,17 +4824,17 @@ Also note that child tries aren't considered as descendants of the main trie whe
- Leemo - expressed interest to change this parameter
- Paradox - expressed interest to change this parameter
-
+
This RFC proposes to change the duration of the confirmation period for the treasurer track. In order to achieve that, the confirm_period parameter for the treasurer track in runtime/polkadot/src/governance/tracks.rs must be changed.
Currently it is set to confirm_period: 3 * HOURS
It should be changed to confirm_period: 48 * HOURS as a minimum.
It may make sense for it to be changed to a value greater than 48 hours since the treasurer track has more power than the big spender track (48 hour confirmation period); however, the root track's confirmation period is 24 hours. 48 hours may be on the upper bounds of a trade-off between security and flexibility.
-
+
The drawback of changing the treasurer track's confirmation period would be that the lifecycle of a referendum submitted on the treasurer track would ultimately be longer. However, the security of the protocol and its treasury should take priority here.
-
+
This change will enhance / improve the security of the protocol as it relates to its treasury. The confirmation period is one of the last lines of defence for the collective Polkadot stakeholders to react to a potentially bad referendum and vote NAY in order for its confirmation period to be aborted. It makes sense for the treasurer track's confirmation period duration to be either equal to, or higher than, the big spender track confirmation period.
-
-
+
+
This is a simple change (code wise) which should not affect the performance of the Polkadot protocol, outside of increasing the duration of the confirmation period on the treasurer track.
If the proposal alters exposed interfaces to developers or end-users, which types of usage patterns have been optimized for?
@@ -4732,14 +4844,14 @@ Also note that child tries aren't considered as descendants of the main trie whe
Polkassembly - directly uses on-chain data via rpc to fetch trackInfo so the change will be automatically reflected.
SubSquare - scan script will update their app to the latest parameters and it will be automatically reflected in their app.
-
+
N/A
-
+
The proposed change to the confirmation period duration for the treasurer track is to set it to 48 hours. This is equal to the current confirmation period for the big spender track.
Typically it seems that track parameters increase in difficulty (duration, etc.) based on the power level of their associated origin.
The longest confirmation period is that of the big spender, at 48 hours. There may be value in discussing whether or not the treasurer track confirmation period should be longer than 48 hours – a discussion of the trade-offs between security vs flexibility/agility.
As a side note, the root track confirmation period is 24 hours.
-
+
This RFC hopefully reminds the greater Polkadot community that it is possible to submit changes to the parameters of Polkadot OpenGov, and the greater protocol as a whole through the RFC process.
(source)
Table of Contents
@@ -5746,16 +5858,16 @@ privacy-enhancing mechanisms to address this concern.
| Authors | Gabriel Facco de Arruda |
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)]
@@ -5812,25 +5924,25 @@ privacy-enhancing mechanisms to address this concern.
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.
-
+
No drawbacks have been identified with this proposal.
-
+
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.
-
-
+
+
Depending on the final implementation, this proposal should not introduce much overhead to performance.
-
+
The ergonomics of this proposal depend on the final implementation details.
-
+
Backwards compatibility should remain unchanged, although that depend on the final implementation.
-
+
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#L153
-
+
Implementation details and overall code is still up to discussion.
(source)
Table of Contents
@@ -5862,7 +5974,7 @@ privacy-enhancing mechanisms to address this concern.
| ChaosDAO | |
-
+
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.
@@ -5870,7 +5982,7 @@ privacy-enhancing mechanisms to address this concern.
- 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.
-
+
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.
@@ -5878,13 +5990,13 @@ privacy-enhancing mechanisms to address this concern.
- Delegating 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.
-
+
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
-
+
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.
-
@@ -5900,21 +6012,21 @@ privacy-enhancing mechanisms to address this concern.
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.
-
+
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.
-
+
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.
-
-
+
+
This change may add extra chain storage requirements on Polkadot, especially with respect to nested delegations.
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.
-
+
N/A
-
+
N/A
-
+
Additionally we would like to re-open the conversation about the potential for there to be free delegations. This was discussed by Dr Gavin Wood at Sub0 2022 and we feel like this would go a great way towards increasing the amount of network participants that are delegating: https://youtu.be/hSoSA6laK3Q?t=526
Overall, we strongly feel that delegations are a great way to increase voter turnout, and the ideas presented in this RFC would hopefully help in that aspect.
(source)
@@ -5956,9 +6068,9 @@ privacy-enhancing mechanisms to address this concern.
| Authors | Sergej Sakac |
-
+
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.
@@ -5972,11 +6084,11 @@ privacy-enhancing mechanisms to address this concern.
The 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.
-
+
- Future Polkadot on-demand Parachains
-
+
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.
@@ -6083,27 +6195,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.
(source)
@@ -6137,24 +6249,24 @@ This RFC offers an alternative solution for on-demand parachains, ensuring that
| Authors | Bastian Köcher |
-
+
When rotating/generating the SessionKeys of a node, the node calls into the runtime using the
SessionKeys::generate_session_keys runtime api. This runtime api function needs to be changed
to add an extra parameter owner and to change the return value to also include the proof of
ownership. The owner should be the account id of the account setting the SessionKeys on chain
to allow the on chain logic the verification of the proof. The on chain logic is then able to proof
the possession of the private keys of the SessionKeys using the proof.
-
+
When a user sets new SessionKeys on chain the chain can currently not ensure that the user
actually has control over the private keys of the SessionKeys. With the RFC applied the chain is able
to ensure that the user actually is in possession of the private keys.
-
+
- Polkadot runtime implementors
- Polkadot node implementors
- Validator operators
-
+
We are first going to explain the proof format being used:
#![allow(unused)]
fn main() {
@@ -6187,26 +6299,26 @@ actual exported function signature looks like:
already gets the proof passed as Vec<u8>. This proof needs to be decoded to
the actual Proof type as explained above. The proof and the SCALE encoded
account_id of the sender are used to verify the ownership of the SessionKeys.
-
+
Validator operators need to pass the their account id when rotating their session keys in a node.
This will require updating some high level docs and making users familiar with the slightly changed ergonomics.
-
+
Testing of the new changes is quite easy as it only requires passing an appropriate owner
for the current testing context. The changes to the proof generation and verification got
audited to ensure they are correct.
-
-
+
+
Does not have any impact on the overall performance, only setting SessionKeys will require more weight.
-
+
If the proposal alters exposed interfaces to developers or end-users, which types of usage patterns have been optimized for?
-
+
Introduces a new version of the SessionKeys runtime api. Thus, nodes should be updated before
a runtime is enacted that contains these changes otherwise they will fail to generate session keys.
-
+
None.
-
+
None.
-
+
Substrate implementation of the RFC.
(source)
Table of Contents
@@ -6239,16 +6351,16 @@ a runtime is enacted that contains these changes otherwise they will fail to gen
| Authors | Pierre Krieger |
-
+
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.
-
+
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.
-
+
Client implementers and low-level runtime developers.
-
+
This RFC proposes the following changes to the client:
- The client no longer considers
:heappages as special.
@@ -6274,27 +6386,27 @@ a runtime is enacted that contains these changes otherwise they will fail to gen
Each parachain can choose the option that they prefer, but the author of this RFC strongly suggests either option C or B.
-
+
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.
-
+
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.
-
-
+
+
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.
-
+
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.
-
+
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.
-
+
None.
-
+
None.
-
+
This RFC follows the same path as https://github.com/polkadot-fellows/RFCs/pull/4 by scoping everything related to memory allocations to the runtime.
(source)
Table of Contents
@@ -6332,7 +6444,7 @@ The :heappages are a rather obscure feature, and it is not clear wh
| Author | Adam Clay Steeber |
-
+
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:
@@ -6340,7 +6452,7 @@ with a non-existent permission set. If this is implemented it would need to be f
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.
-
+
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)
@@ -6350,11 +6462,11 @@ and the community becomes totally autonomous in the management of Kusama's X pos
that could be offloaded to openGov, provided this proof-of-concept is successful.
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.
-
+
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.
-
+
The implementation of this idea can be broken down into 3 primary phases:
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
@@ -6407,7 +6519,7 @@ to implement them. Here's what would be needed:
a UI to allow layman users to propose referenda on this track
After everything is complete, we can update the Kusama wiki to include documentation on the X post specifications and include links to the tools/UI.
-
+
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.
@@ -6419,28 +6531,28 @@ If that happens, we risk getting Kusama banned on X!
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.
-
+
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.
-
-
+
+
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.
-
+
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.
-
+
This change wouldn't break any compatibility as far as I know.
-
+
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
or facilitates bids, challenges, defenses, etc. However, the Society has managed to maintain itself with integrity to its rules. So I don't think this is totally
out of Kusama's scope. But it will require some off-chain effort to maintain.
-
+
- Who will develop the tools necessary to implement this feature? How do we select them?
- How can this idea be better implemented with on-chain/substrate features?
@@ -6479,11 +6591,11 @@ out of Kusama's scope. But it will require some off-chain effort to maintain.Authors | JelliedOwl |
-
+
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.
-
+
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.
-
+
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.
@@ -6507,136 +6619,24 @@ out of Kusama's scope. But it will require some off-chain effort to maintain.Approval & Support curves: As per the root track, timed to match the decision period
- Maximum deciding: 10
-
+
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.
-
+
Will need additional tests case for the modified pallet and runtime. No security or privacy issues.
-
-
+
+
No significant performance impact.
-
+
Only changes related to adding the track. Existing functionality is unchanged.
-
+
No compatibility issues.
-
+
-
-Feedback on whether my proposed implementation of this is the best way to address the issue - including which calls the track should be allowed to make. Are the track parameters correct or should be use something different? Alternative would be welcome.
-(source)
-Table of Contents
-
-
- | |
|---|
-| Start Date | 20 Feb 2024 |
-| Description | Increase the maximum length of identity raw data values from 32 bytes |
-| Authors | Luke Schoen |
-
-
This proposes to increase the maximum length of identity raw data values from a 32 bytes/chars limit to either a 64 bytes/chars limit or a 128 bytes/chars limit.
-
-
-At the moment if you upload a file and pin it to IPFS storage you get an IPFS Content Identifier (CID), which is the unique ID of the file in the IPFS Network. That CID may be used to retrieve the file again via a standard IPFS interface and gateway from anywhere.
-CIDs are reasonably short regardless of the size the underlying content and are based on the cryptographic hash of the content.
-IPFS providers may default to using and recommending using CIDv1 [0] when using SHA256 generates a CID 46 bytes long, rather than CIDv0 [0] that generates a CID 59 bytes long, however CIDv0 may be be the preferred choice for minting and storing NFTs on-chain since it is cheaper.
-Further, the URI protocol + CID for CIDv0 (ipfs://Qm...) will be 7+46=53 chars while for CIDv1 (ipfs://baf...) it will be 7+59=66 chars [1], so neither CIDv0 nor CIDv1 have a CID that supports a maximum length of 32 bytes, which exceeds the maximum 32 bytes/chars limit for bytes/string fields of their Polkadot on-chain identity.
-
-If you want to set a Polkadot on-chain identity, users may provide raw data values of their email address "email" field, which may be longer than 32 bytes/chars (e.g. abcdefghijklmnopqrstuvwxyz@me.com or longer), and either just a CID or the URI protocol + CID associated with a legal document, as the value of the "legal" field, and the URI protocol + CID associated with the profile image to associated with their on-chain identity, as the value of the "image" field, however each field can only store a maximum length of 32 bytes/chars of information [3]. They may also want to set a custom value in the "additional" field, which currently only stores a maximum length of 32 bytes, since it currently has a FieldLimit.
-Possible disadvantages of the current 32 bytes/chars limitation:
-
-- Discourages users from using on-chain Web3 storage providers instead of Web2 storage providers to link to their on-chain identity. For example, in my Decentralized Voices application [4], since it is not possible to proactively provide a link in my on-chain identity to the IPFS CID associated with Conflict of Interest document that has been signed for integration with dApps or immediate verification by interested parties, it would instead be necessary to reactively share that IPFS CID upon each individual request from interested parties.
-- Encourages users to use Web2 storage providers and URL shorteners that may result in a plethora of on-chain profiles that have dead links.
-- Encourages dApps to use Web2 storage providers for their users, for example Polkassembly requesting users to upload a profile image that is stored in a Web2 storage provider rather than first defaulting to use the "image" field from their on-chain identity, since it may be the case that the "image" field of most on-chain identities is not widely used due to the maximum length of 32 bytes/chars restriction.
-- Discourages users from setting an on-chain identity by creating an extrinsic using Polkadot.js with
identity > setIdentity(info), since if they try to provide their email address or website domain name that is longer than 32 characters, or try to use a IPFS CID, they will encounter an error.
-- Discourages users from using on-chain Web3 registrars to judge on-chain identity fields, where the shortest value they are able to generate is not less than or equal to the maximum length of 32 bytes.
-
-
-The maximum length of identity raw data values should be increased from the current 32 bytes/chars limit at least a 59 bytes/chars limit (or a 66 bytes/chars limit) to support IPFS CIDs that are either CIDv0 or CIDv1.
-They maximum length of "additional" field values should be increased by the same amount.
-
-
-- Any Polkadot account holder wishing to use a Polkadot on-chain identity for their:
-
-- Email addresses that are longer than 32 characters
-- Website domain names that are longer than 32 characters
-- Files that are stored on the IPFS Network since associated CIDs are longer than 32 characters
-
-
-
-
-If a user tries to setting an on-chain identity by creating an extrinsic using Polkadot.js with identity > setIdentity(info), then if they try to provide an email address or a website domain name that is longer than 32 characters, or try to use the IPFS CID (which may be associated with a file such as a document or image), then they will encounter this error:
-
createType(Call):: Call: failed decoding identity.setIdentity:: Struct: failed on args: {...}:: Data.Raw values are limited to a maximum length of 32 bytes
-
-Increasing maximum length of identity raw data values from the current 32 bytes/chars limit to at least a 59 bytes/chars limit (or a 66 bytes/chars limit) would overcome these errors and support IPFS CIDs that are either CIDv0 or CIDv1, satisfying the solution requirements.
-Increasing the maximum length of "additional" field values would also overcome these errors and should be increased from the current 32 bytes/chars limitFieldLimit by the same amount.
-
-
-If Polkadot on-chain identities are able to store raw data values greater than the current maximum length of 32 bytes, then each identity may want to use the maximum (or more) amount of "additional" custom fields or more, which would impact storage and performance on the network.
-
-Implementations would need to be tested for adherance by checking that IPFS CIDs that are either CIDv0 or CIDv1 are supported.
-No effect on security or privacy has been identified than already exists.
-No implementation pitfalls have been identified.
-
-
-It would be an optimization, since the associated exposed interfaces to developers and end-users could start being used.
-To minimize additional overhead the proposal suggests at least a 59 bytes/chars limit (or a 66 bytes/chars limit) since that would at least provide support for IPFS CIDs that are either CIDv0 or CIDv1, satisfying the solution requirements.
-
-It alters exposed interfaces to developers and end-users since they will now be able to provide IPFS CIDs that are either CIDv0 or CIDv1 as the values of Polkadot on-chain identity raw data input fields. Optionally 66 bytes/chars limit could be established to optimise for the usage pattern end-users, since that may be more intuitive to them, as it would allow users to provide a link (e.g. URI protocol + CID) rather than just the CID.
-
-Updates to Polkadot.js Apps, API and its documentation and those referring to it may be required.
-
-
-No prior articles.
-
-
-Why can't we increase the maximum length of Polkadot on-chain identity raw data values and the "additional" field limit from 32 bytes/chars to an even longer maximum length than proposed of 128 bytes/chars?
-
-Relates to RFC entitled "Increase maximum length of identity PGP fingerprint values from 20 bytes".
+Feedback on whether my proposed implementation of this is the best way to address the issue - including which calls the track should be allowed to make. Are the track parameters correct or should be use something different? Alternative would be welcome.
diff --git a/proposed/0074-stateful-multisig-pallet.html b/proposed/0074-stateful-multisig-pallet.html
index da3a9c0..0973c48 100644
--- a/proposed/0074-stateful-multisig-pallet.html
+++ b/proposed/0074-stateful-multisig-pallet.html
@@ -90,7 +90,7 @@
@@ -780,11 +780,11 @@ Implement call filters. This will allow multisig accounts to only accept certain