(source)
Table of Contents
This RFC proposes to change the duration of the Confirmation Period for the Big Tipper and Small Tipper tracks in Polkadot OpenGov:
Small Tipper: 10 Minutes -> 12 Hours
Big Tipper: 1 Hour -> 1 Day
Currently, these are the durations of treasury tracks in Polkadot OpenGov. Confirmation periods for the Spender tracks were adjusted based on RFC20 and its related conversation.
You can see that there is a general trend on the Spender track that when the privilege level (the amount the track can spend) the confirmation period approximately doubles.
I believe that the Big Tipper and Small Tipper track's confirmation periods should be adjusted to match this trend.
In the current state it is possible to somewhat positively snipe these tracks, and whilst the power/privilege level of these tracks is very low (they cannot spend a large amount of funds), I believe we should increase the confirmation periods to something higher. This is backed up by the recent sentiment in the greater community regarding referendums submitted on these tracks. The parameters of Polkadot OpenGov can be adjusted based on the general sentiment of token holders when necessary.
The primary stakeholders of this RFC are: +– DOT token holders – as this affects the protocol's treasury +– Entities wishing to submit a referendum on these tracks – as this affects the referendum's timeline +– Projects with governance app integrations – see Performance, Ergonomics and Compatibility section below
This RFC proposes to change the duration of the confirmation period for both the Big Tipper and Small Tipper tracks. To achieve this the confirm_period parameter for those tracks should be changed.
confirm_period
You can see the lines of code that need to be adjusted here:
Big Tipper: https://github.com/polkadot-fellows/runtimes/blob/f4c5d272d4672387771fb038ef52ca36f3429096/relay/polkadot/src/governance/tracks.rs#L245
Small Tipper: https://github.com/polkadot-fellows/runtimes/blob/f4c5d272d4672387771fb038ef52ca36f3429096/relay/polkadot/src/governance/tracks.rs#L231
This RFC proposes to change the confirm_period for the Big Tipper track to DAYS (i.e. 1 Day) and the confirm_period for the Small Tipper track to 12 * HOURS (i.e. 12 Hours).
DAYS
12 * HOURS
The drawback of changing these confirmation periods is that the lifecycle of referenda submitted on those tracks would be ultimately longer, and it would add a greater potential to negatively "snipe" referenda on those tracks by knocking the referendum out of its confirmation period once the decision period has ended. This can be a good or a bad thing depending on your outlook of positive vs negative sniping.
This referendum will enhance the security of the protocol as it relates to its treasury. The confirmation period is one of the last lines of defense for the Polkadot token holder DAO to react to a potentially bad referendum and vote NAY in order for its confirmation period to be aborted.
This is a simple change (code wise) that should not affect the performance of the Polkadot protocol, outside of increasing the duration of the confirmation periods for these 2 tracks.
As per the implementation of changes described in RFC-20, it was identified that governance UIs automatically update to meet the new parameters:
N/A
Some token holders may want these confirmation periods to remain as they are currently and for them not to increase. If this is something that the Polkadot Technical Fellowship considers to be an issue to implement into a runtime upgrade then I can create a Wish For Change to obtain token holder approval.
The parameters of Polkadot OpenGov will likely continue to change over time, there are additional discussions in the community regarding adjusting the min_support for some tracks so that it does not trend towards 0%, similar to the current state of the Whitelisted Caller track. This is outside of the scope of this RFC and requires a lot more discussion.
min_support
This book contains the Polkadot Fellowship Requests for Comments (RFCs) detailing proposed changes to the technical implementation of the Polkadot network.
polkadot-fellows/RFCs
This RFC proposes a solution to replicate an existing pure proxy from one chain to others. The aim is to address the current limitations where pure proxy accounts, which are keyless, cannot have their proxy relationships recreated on different chains. This leads to issues where funds or permissions transferred to the same keyless account address on chains other than its origin chain become inaccessible.
A pure proxy is a new account created by a primary account. The primary account is set as a proxy for the pure proxy account, managing it. Pure proxies are keyless and non-reproducible, meaning they lack a private key and have an address derived from a preimage determined by on-chain logic. More on pure proxies can be found here.
For the purpose of this document, we define a keyless account as a "pure account", the controlling account as a "proxy account", and the entire relationship as a "pure proxy".
The relationship between a pure account (e.g., account ID: pure1) and its proxy (e.g., account ID: alice) is stored on-chain (e.g., parachain A) and currently cannot be replicated to another chain (e.g., parachain B). Because the account pure1 is keyless and its proxy relationship with alice is not replicable from the parachain A to the parachain B, alice does not control the pure1 account on the parachain B.
pure1
alice
A
B
Although this behaviour is not promised, users and clients often mistakenly expect alice to control the same pure1 account on the parachain B. As a result, assets transferred to the account or permissions granted for it are inaccessible. Several factors contribute to this misuse:
Given that these mistakes are likely, it is necessary to provide a solution to either prevent them or enable access to a pure account on a target chain.
Runtime Users, Runtime Devs, wallets, cross-chain dApps.
One possible solution is to allow a proxy to create or replicate a pure proxy relationship for the same pure account on a target chain. For example, Alice, as the proxy of the pure1 pure account on parachain A, should be able to set a proxy for the same pure1 account on parachain B.
To minimise security risks, the parachain B should grant the parachain A the least amount of permission necessary for the replication. First, Parachain A claims to Parachain B that the operation is commanded by the pure account, and thus by its proxy, and second, provides proof that the account is keyless.
The replication process will be facilitated by XCM, with the first claim made using the DescendOrigin instruction. The replication call on parachain A would require a signed origin by the pure account and construct an XCM program for parachain B, where it first descends the origin, resulting in the ParachainA/AccountId32(pure1) origin location on the receiving side.
DescendOrigin
ParachainA/AccountId32(pure1)
To prove that the pure account is keyless, the client must provide the initial preimage used by the chain to derive the pure account. Parachain A verifies it and sends it to parachain B with the replication request.
We can draft a pallet extension for the proxy pallet, which needs to be initialised on both sides to enable replication:
#![allow(unused)] -fn main() { -// Simplified version to illustrate the concept. -mod pallet_proxy_replica { - /// The part of the pure account preimage that has to be provided by a client. - struct Witness { - /// Pure proxy swapner - spawner: AccountId, - /// Disambiguation index - index: u16, - /// The block height and extrinsic index of when the pure account was created. - block_number: BlockNumber, - /// The extrinsic index. - ext_index: u32, - // Part of the preimage, but constant. - // proxy_type: ProxyType::Any, - } - // ... - - /// The replication call to be initiated on the source chain. - // Simplified version, the XCM part will be abstracted by the `Config` trait. - fn replicate(origin: SignedOrigin, witness: Witness, proxy: xcm::Location) -> ... { - let pure = ensure_signed(origin); - ensure!(pure == proxy_pallet::derive_pure_account(witness), Error::NotPureAccount); - let xcm = vec![ - DescendOrigin(who), - Transact( - // … - origin_kind: OriginKind::Xcm, - call: pallet_proxy_replica::create(witness, proxy).encode(), - ) - ]; - xcmTransport::send(xcm)?; - } - // … - - /// The call initiated by the source chain on the receiving chain. - // `Config::CreateOrigin` - generally open for whitelisted parachain IDs and - // converts `Origin::Xcm(ParachainA/AccountId32(pure1))` to `AccountID(pure1)`. - fn create(origin: Config::CreateOrigin, witness: Witness, proxy: xcm::Location) -> ... { - let pure = T::CreateOrigin::ensure_origin(origin); - ensure!(pure == proxy_pallet::derive_pure_account(witness), Error::NotPureAccount); - proxy_pallet::create_pure_proxy(pure, proxy); - } -} - -}
There are two disadvantages to this approach:
We could eliminate the first disadvantage by allowing only the spawner of the pure proxy to recreate the pure proxies, if they sign the transaction on a remote chain and supply the witness/preimage. Since the preimage of a pure account includes the account ID of the spawner, we can verify that the account signing the transaction is indeed the spawner of the given pure account. However, this approach would grant exclusive rights to the spawner over the pure account, which is not a property of pure proxies at present. This is why it's not an option for us.
As an alternative to requiring clients to provide a witness data, we could label pure accounts on the source chain and trust it on the receiving chain. However, this would require the receiving chain to place greater trust in the source chain. If the source chain is compromised, any type of account on the trusting chain could also be compromised.
A conceptually different solution would be to not implement replication of pure proxies and instead inform users that ownership of a pure proxy on one chain does not imply ownership of the same account on another chain. This solution seems complex, as it would require UIs and clients to adapt to this understanding. Moreover, mistakes would likely remain unavoidable.
Each chain expressly authorize another chain to replicate its pure proxies, accepting the inherent risk of that chain potentially being compromised.
There is a security issue, not introduced by the proposed solution but worth mentioning. The same spawner can create the pure accounts on different chains controlled by the different accounts. This is possible because the current preimage version of the proxy pallet does not include any non-reproducible, chain-specific data, and elements like block numbers and extrinsic indexes can be reproduced with some effort. This issue could be addressed by adding a chain-specific seed into the preimages of pure accounts.
The replication is facilitated by XCM, which adds some additional load to the communication channel. However, since the number of replications is not expected to be large, the impact is minimal.
The proposed solution does not alter any existing interfaces. It does require clients to obtain the witness data which should not be an issue with support of an indexer.
None.
This RFC proposes compressing the state response message during the state syncing process to reduce the amount of data transferred.
State syncing can require downloading several gigabytes of data, particularly for blockchains with large state sizes, such as Astar, which has a state size exceeding 5 GiB (https://github.com/AstarNetwork/Astar/issues/1110). This presents a significant challenge for nodes with slower network connections. Additionally, the current state sync implementation lacks a persistence feature (https://github.com/paritytech/polkadot-sdk/issues/4), meaning any network disruption forces the node to re-download the entire state, making the process even more difficult.
This RFC benefits all projects utilizing the Substrate framework, specifically in improving the efficiency of state syncing.
The largest portion of the state response message consists of either CompactProof or Vec<KeyValueStateEntry>, depending on whether a proof is requested (source):
CompactProof
Vec<KeyValueStateEntry>
None identified.
The code changes required for this RFC are straightforward: compress the state response on the sender side and decompress it on the receiver side. Existing sync tests should ensure functionality remains intact.
This RFC optimizes network bandwidth usage during state syncing, particularly for blockchains with gigabyte-sized states, while introducing negligible CPU overhead for compression and decompression. For example, compressing the state response during a recent Polkadot warp sync (around height #22076653) reduces the data transferred from 530,310,121 bytes to 352,583,455 bytes — a 33% reduction, saving approximately 169 MiB of data.
Performance data is based on this patch, with logs available here.
No compatibility issues identified.
This RFC proposes a new host function, secp256r1_ecdsa_verify_prehashed, for verifying NIST-P256 signatures. The function takes as input the message hash, r and s components of the signature, and the x and y coordinates of the public key. By providing this function, runtime authors can leverage a more efficient verification mechanism for "secp256r1" elliptic curve signatures, reducing computational costs and improving overall performance.
secp256r1_ecdsa_verify_prehashed
NIST-P256
r
s
x
y
“secp256r1” elliptic curve is a standardized curve by NIST which has the same calculations by different input parameters with “secp256k1” elliptic curve. The cost of combined attacks and the security conditions are almost the same for both curves. Adding a host function can provide signature verifications using the “secp256r1” elliptic curve in the runtime and multi-faceted benefits can occur. One important factor is that this curve is widely used and supported in many modern devices such as Apple’s Secure Enclave, Webauthn, Android Keychain which proves the user adoption. Additionally, the introduction of this host function could enable valuable features in the account abstraction which allows more efficient and flexible management of accounts by transaction signs in mobile devices. Most of the modern devices and applications rely on the “secp256r1” elliptic curve. The addition of this host function enables a more efficient verification of device native transaction signing mechanisms. For example:
This RFC proposes a new host function for runtime authors to leverage a more efficient verification mechanism for "secp256r1" elliptic curve signatures.
Proposed host function signature:
#![allow(unused)] @@ -437,23 +310,114 @@ Most of the modern devices and applications rely on the “secp256r1” elliptic ) -> bool; }
The host function MUST return true if the signature is valid or false otherwise.
true
false
The changes are not directly affecting the protocol security, parachains are not enforced to use the host function.
The host function proposed in this RFC allows parachain runtime developers to use a more efficient verification mechanism for "secp256r1" elliptic curve signatures.
Parachain teams will need to include this host function to upgrade.
BuyExecution
No performance changes/implications.
The proposal enhances developers' and users' cross-chain asset transfer capabilities. This enhancement is optimized for XCM programs transferring multiple assets, needing to run their logic across multiple chains.
Does this proposal break compatibility with existing interfaces, older versions of implementations? Summarize necessary migrations or upgrade strategies, if any.
This enhancement is compatible with all existing XCM programs and versions.
RequestCodeUpgrade
Change the upgrade process of a parachain runtime upgrade to become an off-chain -process with regards to the relay chain. Upgrades are still contained in -parachain blocks, but will no longer need to end up in relay chain blocks nor in -relay chain state.
Having parachain runtime upgrades go through the relay chain has always been -seen as a scalability concern. Due to optimizations in statement -distribution and asynchronous backing it became less crucial and got -de-prioritized, the original issue can be found -here.
With the introduction of Agile Coretime and in general our efforts to reduce -barrier to entry more for Polkadot more, the issue becomes more relevant again: -We would like to reduce the required storage deposit for PVF registration, with -the aim to not only make it cheaper to run a parachain (bulk + on-demand -coretime), but also reduce the amount of capital required for the deposit. With -this we would hope for far more parachains to get registered, thousands -potentially even ten thousands. With so many PVFs registered, updates are -expected to become more frequent and even attacks on service quality for other -parachains would become a higher risk.
The issues with on-chain runtime upgrades are:
We discussed introducing a separate signalling before submitting the actual -runtime, but I think we should just go one step further and make upgrades fully -off-chain. Which also helps bringing down deposit costs in a secure way, as we -are also actually reducing costs for the network.
As part of elastic scaling we are already planning to increase flexibility of UMP -messages, we can now use this to our advantage and introduce another UMP message:
#![allow(unused)] -fn main() { -enum UMPSignal { - // For elastic scaling - OnCore(CoreIndex), - // For off-chain upgrades - RequestCodeUpgrade(Hash), -} -}
We could also make that new message a regular XCM, calling an extrinsic on the -relay chain, but we will want to look into that message right after validation -on the backers on the node side, making a straight forward semantic message more -apt for the purpose.
We will introduce a new request/response protocol for both collators and -validators, with the following request/response:
#![allow(unused)] -fn main() { -struct RequestBlob { - blob_hash: Hash, -} - -struct BlobResponse { - blob: Vec<u8> -} -}
This protocol will be used by backers to request the PVF from collators in the -following conditions:
In case they received the collation via PoV distribution instead of from the -collator itself, they will use the exact same message to fetch from the valiator -they got the PoV from.
Once the candidate issuing RequestCodeUpgrade got backed on chain, validators -will start fetching the code from the backers as part of availability -distribution.
To mitigate attack vectors we should make sure that serving requests for code -can be treated as low priority requests. Thus I am suggesting the following -scheme:
Validators will notice via a runtime API (TODO: Define) that a new code has been requested, the -API will return the Hash and a counter, which starts at some configurable -value e.g. 10. The validators are now aware of the new hash and start fetching, -but they don't have to wait for the fetch to succeed to sign their bitfield.
Hash
Then on each further candidate from that chain that counter gets decremented. -Validators which have not yet succeeded fetching will now try again. This game -continues until the counter reached 0. Now it is mandatory to have to code in -order to sign a 1 in the bitfield.
0
1
PVF pre-checking will happen after the candidate which brought the counter to -0 has been successfully included and thus is also able to assume that 2/3 of -the validators have the code.
This scheme serves two purposes:
First when a candidate is backed we need to make the new hash available -(together with a counter) via a -runtime API so validators in availability distribution can check for it and -fetch it if changed (see previous section). For performance reasons, I think we -should not do an additional call, but replace the existing one with one containing the new additional information (Option<(Hash, Counter)>).
Once the candidate gets included (counter 0), the hash is given to pre-checking -and only after pre-checking succeeded (and a full session passed) it is finally -enacted and the parachain can switch to the new code. (Same process as it used -to be.)
If a backer receives a collation for a parachain it does not yet have the code -as enacted on chain (see "On-chain code upgrade process"), it will use above -request/response protocol to fetch it from whom it received the collation.
Validators in availability distribution will be changed to only sign a 1 in -the bitfield of a candidate if they not only have the chunk, but also the -currently active PVF. They will fetch it from backers in case they don't have it -yet.
Two ways:
We covered how validators get hold of new code, but when can they prune old ones? -In principle it is not an issue, if some validors prune code, because:
But the majority of validators should always keep the latest code of any -parachain and only prune the previous one, once the first candidate using the -new code got finalized. This ensures that disputes will always be able to -resolve.
The major drawback of this solution is the same as any solution the moves work -off-chain, it adds complexity to the node. E.g. nodes needing the PVF, need to -store them separately, together with their own pruning strategy as well.
Implementations adhering to this RFC, will respond to PVF requests with the -actual PVF, if they have it. Requesters will persist received PVFs on disk for -as long as they are replaced by a new one. Implementations must not be lazy -here, if validators only fetched the PVF when needed, they can be prevented from -participating in disputes.
Validators should treat incoming requests for PVFs in general with rather low -priority, but should prefer fetches from other validators over requests from -random peers.
Given that we are altering what set bits in the availability bitfields mean (not -only chunk, but also PVF available), it is important to have enough validators -upgraded, before we allow collators to make use of the new runtime upgrade -mechanism. Otherwise we would risk disputes to not being able to succeed.
This RFC has no impact on privacy.
This proposal lightens the load on the relay chain and is thus in general -beneficial for the performance of the network, this is achieved by the -following:
End users are only affected by better performance and more stable block times. -Parachains will need to implement the introduced request/response protocol and -adapt to the new signalling mechanism via an UMP message, instead of sending -the code upgrade directly.
UMP
For parachain operators we should emit events on initiated runtime upgrade and -each block reporting the current counter and how many blocks to go until the -upgrade gets passed to pre-checking. This is especially important for on-demand -chains or bulk users not occupying a full core. Further more that behaviour of -requiring multiple blocks to fully initiate a runtime upgrade needs to be well -documented.
We will continue to support the old mechanism for code upgrades for a while, but -will start to impose stricter limits over time, with the number of registered -parachains going up. With those limits in place parachains not migrating to the -new scheme might be having a harder time upgrading and will miss more blocks. I -guess we can be lenient for a while still, so the upgrade path for -parachains should be rather smooth.
In total the protocol changes we need are:
For validators and collators:
Only for validators:
Off-chain runtime upgrades have been discussed before, the architecture -described here is simpler though as it piggybacks on already existing features, -namely:
I have code
https://github.com/paritytech/polkadot-sdk/issues/971
TODO: Fully resolve these questions and incorporate in RFC text.
By no longer having code upgrade go through the relay chain, occupying a full relay -chain block, the impact on other parachains is already greatly reduced, if we -make distribution and PVF pre-checking low-priority processes on validators. The -only thing attackers might be able to do is delay upgrades of other parachains.
Which seems like a problem to be solved once we actually see it as a problem in -the wild (and can already be mitigated by adjusting the counter). The good thing -is that we have all the ingredients to go further if need be. Signalling no -longer actually includes the code, hence there is no need to reject the -candidate: The parachain can make progress even if we choose not to immediately -act on the request and no relay chain resources are wasted either.
We could for example introduce another UMP Signalling message -RequestCodeUpgradeWithPriority which not just requests a code upgrade, but -also offers some DOT to get ranked up in a queue.
RequestCodeUpgradeWithPriority
Making this storage mechanism more general purpose is worth thinking about. E.g. -by resolving above "fee" question, we might also be able to resolve the pruning -question in a more generic way and thus could indeed open this storage facility -for other purposes as well. E.g. smart contracts, so the PoV would only need to -reference contracts by hash and the actual PoV is stored on validators and -collators and thus no longer needs to be part of the PoV.
A possible avenue would be to change the response to:
#![allow(unused)] -fn main() { -enum BlobResponse { - Blob(Vec<u8>), - Blobs(MerkleTree), -} -}
With this the hash specified in the request can also be a merkle root and the -responder will respond with the entire merkle tree (only hashes, no payload). -Then the requester can traverse the leaf hashes and use the same request -response protocol to request any locally missing blobs in that tree.
One leaf would for example be the PVF others could be smart contracts. With a -properly specified format (e.g. which leaf is the PVF?), what we got here is -that a parachain can not only update its PVF, but additional data, -incrementally. E.g. adding another smart contract, does not require resubmitting -the entire PVF to validators, only the root hash on the relay chain gets -updated, then validators fetch the merkle tree and only fetch any missing -leaves. That additional data could be made available to the PVF via a to be -added host function. The nice thing about this approach is, that while we can -upgrade incrementally, lifetime is still tied to the PVF and we get all the same -guarantees. Assuming the validators store blobs by hash, we even get disk -sharing if multiple parachains use the same data (e.g. same smart contracts).
Elastic scaling is not resilient against griefing attacks without a way for a PoV (Proof of Validity) to commit to the particular core index it was intended for. This RFC proposes a way to include core index information in the candidate commitments and the CandidateDescriptor data structure in a backwards compatible way. Additionally it proposes the addition of a SessionIndex field in the CandidateDescriptor to make dispute resolution more secure and robust.
CandidateDescriptor
SessionIndex
This RFC proposes a way to solve two different problems:
This approach and alternatives have been considered and discussed in this issue.
The approach proposed below was chosen primarily because it minimizes the number of breaking changes, the complexity and takes less implementation and testing time. The proposal is to change the existing primitives while keeping binary compatibility with the older versions. We repurpose @@ -1438,27 +1063,27 @@ be able to detect the version of a given candidate receipt.
The version of the descriptor is detected by checking if the version field is 0 and the reserved fields are zeroed. If this is true it means the descriptor is version 2, otherwise we consider it is version 1.
version
The only drawback is that further additions to the descriptor are limited to the amount of remaining unused space.
Standard testing (unit tests, CI zombienet tests) for functionality and mandatory security audit to ensure the implementation does not introduce any new security issues.
Backwards compatibility of the implementation will be tested on testnets (Versi and Westend).
There is no impact on privacy.
The expected performance impact is negligible for sending and processing the new UMP message in the runtime as well as on the node side.
The ClaimQueueOffset along with the relay parent choice allows parachains to optimize their block production for either throughput or latency. A value of 0 with newest relay parent provides best latency while picking older relay parents avoids re-orgs.
ClaimQueueOffset
It is mandatory for elastic parachains to switch to the new receipt format. It is optional but desired that all parachains switch to the new receipts for providing the session index for disputes.
The implementation of this RFC itself must not introduce any breaking changes for the parachain runtime or collator nodes.
The proposed changes are backwards compatible in general, but additional care must be taken by waiting for at least 2/3 + 1 validators to upgrade. Validators that have not upgraded will not back candidates using the new descriptor format and will also initiate disputes against.
2/3 + 1
CoreIndex
SessionIndex< Any tooling that decodes UMP XCM messages needs an update to support or ignore the new UMP messages, but they should be fine to decode the regular XCM messages that come before the separator. -Prior Art and References +Prior Art and References Forum discussion about a new CandidateReceipt format: https://forum.polkadot.network/t/pre-rfc-discussion-candidate-receipt-format-v2/3738 -Unresolved Questions +Unresolved Questions N/A -Future Directions and Related Material +Future Directions and Related Material The implementation is extensible and future proof to some extent. With minimal or no breaking changes, additional fields can be added in the candidate descriptor until the reserved space is exhausted @@ -1526,7 +1151,7 @@ by using the version field of the descirptor introduced in this RFC AuthorsFrancisco Aguirre -Summary +Summary XCM already handles execution fees in an effective and efficient manner using the BuyExecution instruction. However, other types of fees are not handled as effectively -- for example, delivery fees. Fees exist that can't be measured using Weight -- as execution fees can -- so a new method should be thought up for those cases. @@ -1535,7 +1160,7 @@ This RFC proposes making the fee handling system simpler and more general, by do Adding a fees register Deprecating BuyExecution and adding a new instruction PayFees with new semantics to ultimately replace it.
Any tooling that decodes UMP XCM messages needs an update to support or ignore the new UMP messages, but they should be fine to decode the regular XCM messages that come before the separator.
Forum discussion about a new CandidateReceipt format: https://forum.polkadot.network/t/pre-rfc-discussion-candidate-receipt-format-v2/3738
CandidateReceipt
The implementation is extensible and future proof to some extent. With minimal or no breaking changes, additional fields can be added in the candidate descriptor until the reserved space is exhausted
XCM already handles execution fees in an effective and efficient manner using the BuyExecution instruction. However, other types of fees are not handled as effectively -- for example, delivery fees. Fees exist that can't be measured using Weight -- as execution fees can -- so a new method should be thought up for those cases. @@ -1535,7 +1160,7 @@ This RFC proposes making the fee handling system simpler and more general, by do
Weight
fees
PayFees
Execution fees are handled correctly by XCM right now. However, the addition of extra fees, like for message delivery, result in awkward ways of integrating them into the XCVM implementation. This is because these types of fees are not included in the language. @@ -1543,25 +1168,29 @@ The standard should have a way to correctly deal with these implementation speci The new instruction moves the specified amount of fees from the holding register to a dedicated fees register that the XCVM can use in flexible ways depending on its implementation. The XCVM implementation is free to use these fees to pay for execution fees, transport fees, or any other type of fee that might be necessary. This moves the specifics of fees further away from the XCM standard, and more into the actual underlying XCVM implementation, which is a good thing.
The new instruction that will replace BuyExecution is a much simpler and general version: PayFees. This instruction takes one Asset, takes it from the holding register, and puts it into a new fees register. -The XCVM implementation can now use this Asset to make sure every necessary fee is paid for, this includes execution fees, delivery fees, or any other fee.
Asset
#![allow(unused)] fn main() { PayFees { asset: Asset } }
This new instruction will reserve the entirety of asset for fee payment. -The asset can't be used for anything else during the entirety of the program. +
asset
This new instruction will reserve the entirety of the asset operand for fee payment. +There is not concept of returning the leftover fees to the holding register, to allow for the implementation to charge fees at different points during execution. +Because of this, the asset passed in can't be used for anything else during the entirety of the program. This is different from the current semantics of BuyExecution.
If not all Asset in the fees register is used when the execution ends, then we trap them alongside any possible leftover assets from the holding register.
If not all Asset in the fees register is used when the execution ends, then we trap them alongside any possible leftover assets from the holding register. +RefundSurplus can be used to move all leftover fees from the fees register to the holding register. +Care must be taken that this is used only after all possible instructions which might charge fees, else execution will fail.
RefundSurplus
holding
Most XCM programs that pay for execution are written like so:
#![allow(unused)] @@ -1577,27 +1206,27 @@ BuyExecution { asset, weight_limit } PayFees { asset } // ...rest }
There needs to be an explicit change from BuyExecution to PayFees, most often accompanied by a reduction in the assets passed in.
It might become a security concern if leftover fees are trapped, since a lot of them are expected.
There should be no performance downsides to this approach. The fees register is a simplification that may actually result in better performance, in the case an implementation is doing a workaround to achieve what this RFC proposes.
The interface is going to be very similar to the already existing one. Even simpler since PayFees will only receive one asset. That asset will allow users to limit the amount of fees they are willing to pay.
This RFC can't just change the semantics of the BuyExecution instruction since that instruction accepts any funds, uses what it needs and returns the rest immediately. The new proposed instruction, PayFees, doesn't return the leftover immediately, it keeps it in the fees register. In practice, the deprecated BuyExecution needs to be slowly rolled out in favour of PayFees.
The closed RFC PR on the xcm-format repository, before XCM RFCs got moved to fellowship RFCs: https://github.com/polkadot-fellows/xcm-format/pull/53.
None
This proposal would greatly benefit from an improved asset trapping system.
CustomAssetClaimer is also related, as it directly improves the ergonomics of this proposal.
LeftoverAssetsDestination execution hint would also similarly improve the ergonomics.
The SetFeesMode instruction and the fees_mode register allow for the existence of JIT withdrawal. JIT withdrawal complicates the fee mechanism and leads to bugs and unexpected behaviour. The proposal is to remove said functionality. Another effort to simplify fee handling in XCM.
SetFeesMode
fees_mode
The JIT withdrawal mechanism creates bugs such as not being able to get fees when all assets are put into holding and none left in the origin location. This is a confusing behavior, since there are funds for fees, just not where the XCVM wants them. The XCVM should have only one entrypoint to fee payment, the holding register. That way there is also less surface for bugs.
The SetFeesMode instruction will be removed. The Fees Mode register will be removed.
Fees Mode
Users will have to make sure to put enough assets in WithdrawAsset when previously some things might have been charged directly from their accounts. This leads to a more predictable behaviour though so it will only be a drawback for the minority of users.
WithdrawAsset
Implementations and benchmarking must change for most existing pallet calls that send XCMs to other locations.
Performance will be improved since unnecessary checks will be avoided.
JIT withdrawal was a way of side-stepping the regular flow of XCM programs. By removing it, the spec is simplified but now old use-cases have to work with the original intended behaviour, which may result in more implementation work.
Ergonomics for users will undoubtedly improve since the system is more predictable.
Existing programs in the ecosystem will break. The instruction should be deprecated as soon as this RFC is approved (but still fully supported), then removed in a subsequent XCM version (probably deprecate in v5, remove in v6).
The previous RFC PR on the xcm-format repo, before XCM RFCs were moved to fellowship RFCs: https://github.com/polkadot-fellows/xcm-format/pull/57.
The new generic fees mechanism is related to this proposal and further stimulates it as the JIT withdraw fees mechanism will become useless anyway.
A previous XCM RFC (https://github.com/polkadot-fellows/xcm-format/pull/37) introduced a SetAssetClaimer instruction. This idea of instructing the XCVM to change some implementation-specific behavior is useful. In order to generalize this mechanism, this RFC introduces a new instruction SetHints and makes the SetAssetClaimer be just one of many possible execution hints.
SetAssetClaimer
SetHints
There is a need for specifying how certain implementation-specific things should behave. Things like who can claim the assets or what can be done instead of trapping assets. Another idea for a hint:
AssetForFees
LeftoverAssetsDestination
A new instruction, SetHints, will be added. This instruction will take a single parameter of type Hint, an enumeration. The first variant for this enum is AssetClaimer, which allows to specify a location that should be able to claim trapped assets. @@ -1751,27 +1380,27 @@ enum Hint { type NumVariants = /* Number of variants of the `Hint` enum */; } -
Hint
AssetClaimer
The SetHints instruction might be hard to benchmark, since we should look into the actual hints being set to know how much weight to attribute to it.
Hints are specified on a per-message basis, so they have to be specified at the beginning of a message. If they were to be specified at the end, hints like AssetClaimer would be useless if an error occurs beforehand and assets get trapped before ever reaching the hint.
The instruction takes a bounded vector of hints so as to not force barriers to allow an arbitrary number of SetHint instructions.
SetHint
The SetHints instruction provides a better integration with barriers. If we had to add one barrier for SetAssetClaimer and another for each new hint that's added, barriers would need to be changed all the time. Also, this instruction would make it simpler to write XCM programs. You only need to specify the hints you want in one single instruction at the top of your program.
The previous RFC PR in the xcm-format repository before XCM RFCs moved to fellowship RFCs: https://github.com/polkadot-fellows/xcm-format/pull/59.
XCM programs that want to ensure that the following XCM instructions cannot command the authority of the Original Origin (such as asset transfer programs) should consider, where possible, using DescendOrigin into a demoted, safer origin rather than ClearOrigin which clears the origin completely.
ClearOrigin
Currently, all XCM asset transfer instructions ultimately clear the origin in the remote XCM message by use of the ClearOrigin instruction. This is done for security considerations to ensure that later instructions cannot command the authority of the Original Origin (the sending chain).
The problem with this approach is that it limits what can be achieved on remote chains through XCM. Most XCM operations require having an origin, and following any asset transfer the origin is lost, meaning not much can be done other than depositing the transferred assets to some local account or transferring them onward to another chain.
For example, we cannot transfer some funds for buying execution, then do a Transact (all in the same XCM message).
Transact
The above example is a basic, core building block for cross-chain interactions and we should support it.
In the case of XCM programs going from origin-chain directly to dest-chain without an intermediary hop, we can enable scenarios such as above by using the DescendOrigin instruction instead of the ClearOrigin instruction.
origin-chain
dest-chain
Instead of clearing the origin-chain origin, we can "descend" into a child location of origin-chain, specifically we could "descend" into the actual origin of the initiator. Most common such descension would be X2(Parachain(origin-chain), AccountId32(origin-account)), when the initiator is a (signed/pure/proxy) account origin-account.
X2(Parachain(origin-chain), AccountId32(origin-account))
origin-account
This allows an actor on chain A to Transact on chain B without having to prefund its SA account on chain B, instead they can simply transfer the required fees in the same XCM program as the Transact.
Unfortunately, this approach only works when the asset transfer has the same XCM route/hops as the rest of the program. Meaning it only works if the assets can be directly transferred from chain A to chain B without going through intermediary hops or reserve chains. When going through a reserve-chain, the original origin-chain/origin-account origin is lost and cannot be recreated using just the DescendOrigin instruction Even so, this proposal is still useful for the majority of usecases (where the asset transfer happens directly between A and B).
origin-chain/origin-account
The TransferReserveAsset, DepositReserveAsset, InitiateReserveWithdraw and InitiateTeleport instructions should use a DescendOrigin instruction on the onward XCM program instead of the currently used ClearOrigin instruction. The DescendOrigin instruction should effectively mutate the origin on the remote chain to the SA of the origin on the local chain.
TransferReserveAsset
DepositReserveAsset
InitiateReserveWithdraw
InitiateTeleport
No performance, ergonomics, user experience, security, or privacy drawbacks.
In terms of ergonomics and user experience, the support for combining an asset transfer with a subsequent action (like Transact) is assymetrical:
But it is still a net positive for ergonomics and user experience, while being neutral for the rest.
Barriers should also allow DescendOrigin, not just ClearOrigin. XCM program builders should audit their programs and eliminate assumptions of "no origin" on remote side. Instead, the working assumption is that the origin on the remote side is the local origin reanchored location. This new assumption is 100% in line with the behavior of remote XCM programs sent over using pallet_xcm::send.
pallet_xcm::send
No impact.
Improves ergonomics by allowing the local origin to operate on the remote chain even when the XCM program includes an asset transfer.
At the executor-level this change is backwards and forwards compatible. Both types of programs can be executed on new and old versions of XCM with no changes in behavior.
Programs switching to the new approach is however a breaking change from the existing XCM barriers point of view. For example, the AllowTopLevelPaidExecutionFrom barrier permits programs containing ClearOrigin before BuyExecution, but will reject programs with DescendOrigin before BuyExecution.
How to achieve this for all workflows, not just point-to-point XCM programs with no intermediary hops?
As long as the intermediary hop(s) is/are not trusted to "impersonate" a location from the original origin chain, there is no way AFAICT to hold on to the original origin.
Similar (maybe even better) results can be achieved using XCMv5ExecuteWithOrigin instruction, instead of DescendOrigin. But that introduces version downgrade compatibility challenges.
#![allow(unused)] +fn main() { +// Simplified version to illustrate the concept. +mod pallet_proxy_replica { + /// The part of the pure account preimage that has to be provided by a client. + struct Witness { + /// Pure proxy swapner + spawner: AccountId, + /// Disambiguation index + index: u16, + /// The block height and extrinsic index of when the pure account was created. + block_number: BlockNumber, + /// The extrinsic index. + ext_index: u32, + // Part of the preimage, but constant. + // proxy_type: ProxyType::Any, + } + // ... + + /// The replication call to be initiated on the source chain. + // Simplified version, the XCM part will be abstracted by the `Config` trait. + fn replicate(origin: SignedOrigin, witness: Witness, proxy: xcm::Location) -> ... { + let pure = ensure_signed(origin); + ensure!(pure == proxy_pallet::derive_pure_account(witness), Error::NotPureAccount); + let xcm = vec![ + DescendOrigin(who), + Transact( + // … + origin_kind: OriginKind::Xcm, + call: pallet_proxy_replica::create(witness, proxy).encode(), + ) + ]; + xcmTransport::send(xcm)?; + } + // … + + /// The call initiated by the source chain on the receiving chain. + // `Config::CreateOrigin` - generally open for whitelisted parachain IDs and + // converts `Origin::Xcm(ParachainA/AccountId32(pure1))` to `AccountID(pure1)`. + fn create(origin: Config::CreateOrigin, witness: Witness, proxy: xcm::Location) -> ... { + let pure = T::CreateOrigin::ensure_origin(origin); + ensure!(pure == proxy_pallet::derive_pure_account(witness), Error::NotPureAccount); + proxy_pallet::create_pure_proxy(pure, proxy); + } +} + +}
As chains have strict PoV size limits, care must be taken in the PoV impact of the session manager. Appropriate benchmarking and tests should ensure that conservative limits are placed on the number of Invulnerables and Candidates.
The primary group affected is Candidate collators, who, after implementation of this RFC, will need to compete in a bond-based election rather than a race to claim a Candidate spot.
This RFC is compatible with the existing implementation and can be handled via upgrades and migration.
Assuming 1000 parachain full nodes, the 20 Polkadot full nodes corresponding to a specific parachain will each receive a sudden spike of a few megabytes of networking traffic when the key rotates. Again, this is relatively negligible. If this becomes a problem, one can add a random delay before a parachain full node registers itself to be the provider of the key corresponding to BabeApi_next_epoch.
key
BabeApi_next_epoch
Maybe the biggest uncertainty is the traffic that the 20 Polkadot full nodes will receive from light clients that desire knowing the bootnodes of a parachain. Light clients are generally encouraged to cache the peers that they use between restarts, so they should only query these 20 Polkadot full nodes at their first initialization. If this every becomes a problem, this value of 20 is an arbitrary constant that can be increased for more redundancy.
Irrelevant.
The performance overhead is minimal in the sense that no clutter was added after fulfilling the requirements. The only performance difference is that initialize_block also returns an enum that needs to be passed through the WASM boundary. This should be negligible.
initialize_block
The new interface allows for more extensible runtime logic. In the future, this will be utilized for multi-block-migrations which should be a huge ergonomic advantage for parachain developers.
The advice here is OPTIONAL and outside of the RFC. To not degrade user experience, it is recommended to ensure that an updated node can still import historic blocks.
There is no privacy related concerns.
This RFC should not introduce any performance impact.
This RFC should improve the developer experiences for new and existing parachain teams
This RFC is fully compatibility with existing interfaces.
This is an optimization. The removal of public/user transactions on the Relay Chain ensures that its primary resources are allocated to system performance.
This proposal alters very little for coretime users (e.g. parachain developers). Application developers will need to interact with multiple chains, making ergonomic light client tools particularly important for application development.
For existing parachains that interact with these subsystems, they will need to configure their runtimes to recognize the new locations in the network.
Implementing this proposal will require some changes to pallet APIs and/or a pub-sub protocol. Application developers will need to interact with multiple chains in the network.
system_version
These changes should be compatible for existing chains if they use state_version value for system_verision.
state_version
system_verision
I do not believe there is any performance hit with this change.
This does not break any exposed Apis.
This change should not break any compatibility.
We proposed introducing a similar change by introducing a @@ -4529,9 +4285,9 @@ is the correct way of introducing this change.
Parachain nodes need to enable proof recording during block import to correctly implement the proposed host function. Benchmarking conducted with balance transfers has shown a performance reduction of around 0.6% when proof recording is enabled.
The host function proposed in this RFC allows parachain runtime developers to keep track of the proof size. Typical usage patterns would be to keep track of the overall proof size or the difference between subsequent calls to the host function.
forceDestroy
The proposed change aims to enhance the user experience for artists, traders, and utilizers of Kusama and Polkadot Asset Hubs, making Polkadot and Kusama more accessible and user-friendly.
The change does not impact compatibility as a redeposit function is already implemented.
redeposit
If this RFC is accepted, there should not be any unresolved questions regarding how to adapt the @@ -5014,9 +4770,9 @@ CPU time in polkadot as we scale up the parachain block size and number of avail
With this optimisation, preliminary performance results show that CPU time used for reed-solomon coding/decoding can be halved and total POV recovery time decrease by 80% for large POVs. See more here.
Not applicable.
This is a breaking change. See upgrade path section above. All validators and collators need to have upgraded their node versions before the feature will be enabled via a governance call.
The interfaces have been optimized to make it as easy as possible to generate the ownership proof.
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. The RPC that exists around this runtime api needs to be updated to support passing the account id @@ -5304,9 +5060,9 @@ to acquire them. However, the asset of choice can be changed in the future.
SessionKeys
Vec<Transaction>
The change is backwards compatible if done in two steps: modify the sender to always send one transaction per notification, then, after a while, modify the receiver to enforce the new format.
Doing a Kademlia iterative query then sending a provider record shouldn't take more than around 50 kiB in total of bandwidth for the parachain bootnode.
Assuming 1000 nodes with a specific capability, the 20 Polkadot full nodes corresponding to that capability will each receive a sudden spike of a few megabytes of networking traffic when the key rotates. Again, this is relatively negligible. If this becomes a problem, one can add a random delay before a node registers itself to be the provider of the key corresponding to BabeApi_next_epoch.
Maybe the biggest uncertainty is the traffic that the 20 Polkadot full nodes will receive from light clients that desire knowing the nodes with a capability. If this every becomes a problem, this value of 20 is an arbitrary constant that can be increased for more redundancy.
Unknown.
There should be no measurable impact on performance to Polkadot or any other chain using this feature. The metadata root hash is calculated at compile time and at runtime it is optionally used when checking the signature of a transaction. This means that at runtime no performance heavy operations are done.
The proposal alters the way a transaction is built, signed, and verified. So, this imposes some required changes to any kind of developer who wants to construct transactions for Polkadot or any chain using this feature. As the developer can pass 0 for disabling the verification of the metadata root hash, it can be easily ignored.
RFC 46 produced by the Alzymologist team is a previous work reference that goes in this direction as well.
This change would allow Polkadot to support new types of transactions, with the specific "general" transaction type in mind at the time of writing this proposal.
There is no performance impact.
The impact to developers and end-users is minimal as it would just be a bitmask update on their part for parsing the extrinsic type along with the version.
This change breaks backwards compatiblity because any transaction that is neither signed nor unsigned, but a new transaction type, would be interpreted as having a future extrinsic format version.
The original design was originally proposed in the TransactionExtension PR, which is also the motivation behind this effort.
TransactionExtension
The changes are backwards compatible with the existing protocol, so nodes with both the old protocol and newer protocol can exist in the network, this is achieved by the fact that we use protobuf for serializing and deserializing the records, so new fields will be ignore when deserializing with the older protocol and vice-versa when deserializing an old record with the new protocol the new field will be None and the new code accepts this record as being valid.
The enhancements have been inspired by the algorithm specified in here
The authors cannot see any potential impact on performance.
The authors cannot see any potential impact on ergonomics for developers. We discussed potential impact on UX/UI for users above.
The authors cannot see any potential impact on compatibility. This should be assessed by the technical fellows.
6
5
This will ensure that changes to the transactions extensions can be done in a backwards compatible way.
Runtime developers need to take care of the versioning and ensure to bump as required, so that there are no compatibility breaking changes without a bump of the version. It will also add a little bit more code in the runtime to decode these old versions, but this should be neglectable.
When introduced together with extrinsic format version 5 from RFC84, it can be implemented in a backwards compatible way. So, transactions can still be send using the old extrinsic format and decoded by the runtime.
No performance change.
Ergonomics are slightly improved by simplifying Transact API.
Compatible with previous XCM programs.
NetworkId::ByGenesis
It will very slightly reduce the ergonomics of testnet developers but improve the stability of the language.
NetworkId::Rococo and NetworkId::Westend can just use NetworkId::ByGenesis, as can other testnets.
NetworkId::Rococo
NetworkId::Westend
A previous attempt to add NetworkId::Paseo: https://github.com/polkadot-fellows/xcm-format/pull/58.
NetworkId::Paseo
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.
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.
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.
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:
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:
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.
runtime/polkadot/src/governance/tracks.rs
Currently it is set to confirm_period: 3 * HOURS
confirm_period: 3 * HOURS
It should be changed to confirm_period: 48 * HOURS as a minimum.
confirm_period: 48 * HOURS
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?
I have confirmed with the following projects that this is not a breaking change for their governance apps:
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.
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)] @@ -7275,25 +6947,25 @@ Also note that child tries aren't considered as descendants of the main trie whe 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#L122 WithComputedOrigin type: https://github.com/paritytech/polkadot-sdk/blob/master/polkadot/xcm/xcm-builder/src/barriers.rs#L153 -Unresolved Questions +Unresolved Questions Implementation details and overall code is still up to discussion. (source) Table of Contents @@ -7325,7 +6997,7 @@ Also note that child tries aren't considered as descendants of the main trie whe ChaosDAO -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. @@ -7333,7 +7005,7 @@ Also note that child tries aren't considered as descendants of the main trie whe 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. @@ -7341,13 +7013,13 @@ Also note that child tries aren't considered as descendants of the main trie whe 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. -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. @@ -7363,21 +7035,21 @@ Also note that child tries aren't considered as descendants of the main trie whe 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 +Unresolved Questions N/A -Future Directions and Related Material +Future Directions and Related Material 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) @@ -7419,9 +7091,9 @@ Also note that child tries aren't considered as descendants of the main trie whe AuthorsSergej Sakac -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. @@ -7435,11 +7107,11 @@ Also note that child tries aren't considered as descendants of the main trie whe 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. -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. @@ -7546,27 +7218,27 @@ pub(super) type CheckedCodeHash<T: Config> = StorageMap<_, Twox64Concat, ParaId, ValidationCodeHash>; }
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.
DescribeFamily
HashedDescription
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.
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
WithComputedOrigin
Implementation details and overall code is still up to discussion.
This RFC proposes to make modifications to voting power delegations as part of the Conviction Voting pallet. The changes being proposed include:
It has become clear since the launch of OpenGov that there are a few common tropes which pop up time and time again:
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.
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.
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.
delegate_all
undelegate_all
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.
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.
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.
ParaId
This RFC suggests a new payment model to create a more financially viable approach to on-demand parachain registration. In this model, a lower initial deposit is required, followed by recurring payments upon parachain registration.
This new model will coexist with the existing one-time deposit payment model, offering teams seeking to deploy on-demand parachains on Polkadot a more cost-effective alternative.
This RFC proposes a set of changes that will enable the new rent based approach to registering and storing validation code on-chain. The new model, compared to the current one, will require periodic rent payments. The parachain won't be pruned automatically if the rent is not paid, but by permitting anyone to prune the parachain and rewarding the caller, there will be an incentive for the removal of the validation code.
On-demand parachains should still be able to utilize the current one-time payment model. However, given the size of the deposit required, it's highly likely that most on-demand parachains will opt for the new rent-based model.
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.
paras-registrar
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.
deregister
T::DataDepositPerByte
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 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.
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.
:heappages
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:
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.
ext_storage_get
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.
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.
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:
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) @@ -7711,11 +7383,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 @@ -7768,7 +7440,7 @@ to implement them. Here's what would be needed:
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.
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.
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:
placeDecisionDesposit
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.
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:
Stateful Multisig
Stateless Multisig
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.
and much more...
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.
Standard audit/review requirements apply.
Doing back of the envelop calculation to proof that the stateful multisig is more efficient than the stateless multisig given it's smaller footprint size on blocks.
Quick review over the extrinsics for both as it affects the block size:
Stateless Multisig: @@ -8468,17 +8140,17 @@ We have the following extrinsics:
So even though the stateful multisig has a larger state size, it's still more efficient in terms of block size and total footprint on the blockchain.
The Stateful Multisig will have better ergonomics for managing multisig accounts for both developers and end-users.
This RFC is compatible with the existing implementation and can be handled via upgrades and migration. It's not intended to replace the existing multisig pallet.
multisig pallet in polkadot-sdk
This proposes to increase the maximum length of PGP Fingerprint values from a 20 bytes/chars limit to a 40 bytes/chars limit.
Pretty Good Privacy (PGP) Fingerprints are shorter versions of their corresponding Public Key that may be printed on a business card.
They may be used by someone to validate the correct corresponding Public Key.
The maximum length of identity PGP Fingerprint values should be increased from the current 20 bytes/chars limit at least a 40 bytes/chars limit to support PGP Fingerprints and GPG Fingerprints.
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 their 40 character long PGP Fingerprint or GPG Fingerprint, which is longer than the maximum length of 20 bytes/chars [u8;20], then they will encounter this error:
identity
setIdentity(info)
[u8;20]
createType(Call):: Call: failed decoding identity.setIdentity:: Struct: failed on args: {...}:: Struct: failed on pgpFingerprint: Option<[u8;20]>:: Expected input with 20 bytes (160 bits), found 40 bytes
Increasing maximum length of identity PGP Fingerprint values from the current 20 bytes/chars limit to at least a 40 bytes/chars limit would overcome these errors and support PGP Fingerprints and GPG Fingerprints, satisfying the solution requirements.
No drawbacks have been identified.
Implementations would be tested for adherance by checking that 40 bytes/chars PGP Fingerprints 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 a 40 bytes/chars limit since that would at least provide support for PGP Fingerprints, satisfying the solution requirements.
No potential ergonomic optimizations have been identified.
Updates to Polkadot.js Apps, API and its documentation and those referring to it may be required.
No prior articles or references.
No further questions at this stage.
Relates to RFC entitled "Increase maximum length of identity raw data values from 32 bytes".
This proposes to require a slashable deposit in the broker pallet when initially purchasing or renewing Bulk Coretime or Instantaneous Coretime cores.
Additionally, it proposes to record a reputational status based on the behavior of the purchaser, as it relates to their use of Kusama Coretime cores that they purchase, and to possibly reserve a proportion of the cores for prospective purchasers that have an on-chain identity.
There are sales of Kusama Coretime cores that are scheduled to occur later this month by Coretime Marketplace Lastic.xyz initially in limited quantities, and potentially also by RegionX in future that is subject to their Polkadot referendum #582. This poses a risk in that some Kusama Coretime core purchasers may buy Kusama Coretime cores when they have no intention of actually placing a workload on them or leasing them out, which would prevent those that wish to purchase and actually use Kusama Coretime cores from being able to use any at cores at all.
Reputation. To disincentivise certain behaviours, a reputational status indicator could be used to record the historic behavior of the purchaser and whether on-chain judgement has determined they have adequately rectified that behaviour, as it relates to their usage of Kusama Coretime cores that they purchase.
The slashable deposit if set too high, may result in an economic impact, where less Kusama Coretime core sales are purchased.
Lack of a slashable deposit in the Broker pallet is a security concern, since it exposes Kusama Coretime sales to potential abuse.
Reserving a proportion of Kusama Coretime sales cores for those with on-chain identities should not be to the exclusion of accounts that wish to remain anonymous or cause cores to be wasted unnecessarily. As such, if cores that are reserved for on-chain identities remain unsold then they should be released to anonymous accounts that are on a waiting list.
It should improve performance as it reduces the potential for state bloat since there is less risk of undesirable Kusama Coretime sales activity that would be apparent with no requirement for a slashable deposit or there being no reputational risk to purchasers that waste or misuse Kusama Coretime cores.
The solution proposes to minimize the risk of some Kusama Coretime cores not even being used or leased to perform any tasks at all.
It will be important to monitor and manage the slashable deposits, purchaser reputations, and utilization of the proportion of cores that are reserved for accounts with an on-chain identity.
The mechanism for setting a slashable deposit amount, should avoid undue complexity for users.
No prior articles.
This RFC proposes a new pallet_inflation to be added to the Polkadot runtime, which improves inflation machinery of the Polkadot relay chain in a number of ways:
pallet_inflation
The existing inflation logic in the relay chain suffers from a number of drawbacks:
This RFC is relevant to the following stakeholders, listed from high to low impact:
First, let's further elaborate on the existing order. The current inflation logic is deeply nested in pallet_staking, and pallet_staking::Config::EraPayout interface. Through this trait, the @@ -8893,7 +8565,7 @@ prefixed by dynamic_params.
pallet_staking
pallet_staking::Config::EraPayout
dynamic_params
Whereby FixedAnnualInflationAmount is the fixed absolute value (as opposed to ratio) by which the chain inflates annually, for example 100m DOTs.
FixedAnnualInflationAmount
The following drawbacks are noted:
The new pallet_inflation, among its integration into pallet_staking must be thoroughly audited and reviewed by fellows. We also emphasize on simulating the actual inflation logic using the real polkadot state with Chopsticks and try-runtime.
The proposed system in this RFC implies a handful of extra storage reads and writes "per inflation cycle", but given that a reasonable instance of this pallet would probably decide to inflation eg. once per day, the performance impact is negligible.
The drawback section above noted some ergonomic concerns.
The "New Order" section above notes the compatibility notes with the existing staking and inflation system.
pallet_parameters
This RFC proposes the addition of a secondary market feature to either the broker pallet or as a separate pallet maintained by Lastic, enabling users to list and purchase regions. This includes creating, purchasing, and removing listings, as well as emitting relevant events and handling associated errors.
Currently, the broker pallet lacks functionality for a secondary market, which limits users' ability to freely trade regions. This RFC aims to introduce a secure and straightforward mechanism for users to list regions they own for sale and allow other users to purchase these regions.
While integrating this functionality directly into the broker pallet is one option, another viable approach is to implement it as a separate pallet maintained by Lastic. This separate pallet would have access to the broker pallet and add minimal functionality necessary to support the secondary market.
Adding smart contracts to the Coretime chain could also address this need; however, this process is expected to be lengthy and complex. We cannot afford to wait for this extended timeline to enable basic secondary market functionality. By proposing either integration into the broker pallet or the creation of a dedicated pallet, we can quickly enhance the flexibility and utility of the broker pallet, making it more user-friendly and valuable.
Primary stakeholders include:
This RFC introduces the following key features:
The main drawback of adding the additional complexity directly to the broker pallet is the potential increase in maintenance overhead. Therefore, we propose adding additional functionality as a separate pallet on the Coretime chain. To take the pressure off from implementing these features, implementation along with unit tests would be taken care of by Lastic (Aurora Makovac, Philip Lucsok).
There are potential risks of security vulnerabilities in the new market functionalities, such as unauthorized region transfers or incorrect balance adjustments. Therefore, extensive security measures would have to be implemented.
Change the upgrade process of a parachain runtime upgrade to become an off-chain +process with regards to the relay chain. Upgrades are still contained in +parachain blocks, but will no longer need to end up in relay chain blocks nor in +relay chain state.
Having parachain runtime upgrades go through the relay chain has always been +seen as a scalability concern. Due to optimizations in statement +distribution and asynchronous backing it became less crucial and got +de-prioritized, the original issue can be found +here.
With the introduction of Agile Coretime and in general our efforts to reduce +barrier to entry more for Polkadot more, the issue becomes more relevant again: +We would like to reduce the required storage deposit for PVF registration, with +the aim to not only make it cheaper to run a parachain (bulk + on-demand +coretime), but also reduce the amount of capital required for the deposit. With +this we would hope for far more parachains to get registered, thousands +potentially even ten thousands. With so many PVFs registered, updates are +expected to become more frequent and even attacks on service quality for other +parachains would become a higher risk.
We discussed introducing a separate signalling before submitting the actual +runtime, but I think we should just go one step further and make upgrades fully +off-chain. Which also helps bringing down deposit costs in a secure way, as we +are also actually reducing costs for the network.
As part of elastic scaling we are already planning to increase flexibility of UMP +messages, we can now use this to our advantage and introduce another UMP message:
#![allow(unused)] +fn main() { +enum UMPSignal { + // For elastic scaling + OnCore(CoreIndex), + // For off-chain upgrades + RequestCodeUpgrade(Hash), +} +}
We could also make that new message a regular XCM, calling an extrinsic on the +relay chain, but we will want to look into that message right after validation +on the backers on the node side, making a straight forward semantic message more +apt for the purpose.
We will introduce a new request/response protocol for both collators and +validators, with the following request/response:
#![allow(unused)] +fn main() { +struct RequestBlob { + blob_hash: Hash, +} + +struct BlobResponse { + blob: Vec<u8> +} +}
This protocol will be used by backers to request the PVF from collators in the +following conditions:
In case they received the collation via PoV distribution instead of from the +collator itself, they will use the exact same message to fetch from the valiator +they got the PoV from.
Once the candidate issuing RequestCodeUpgrade got backed on chain, validators +will start fetching the code from the backers as part of availability +distribution.
To mitigate attack vectors we should make sure that serving requests for code +can be treated as low priority requests. Thus I am suggesting the following +scheme:
Validators will notice via a runtime API (TODO: Define) that a new code has been requested, the +API will return the Hash and a counter, which starts at some configurable +value e.g. 10. The validators are now aware of the new hash and start fetching, +but they don't have to wait for the fetch to succeed to sign their bitfield.
Then on each further candidate from that chain that counter gets decremented. +Validators which have not yet succeeded fetching will now try again. This game +continues until the counter reached 0. Now it is mandatory to have to code in +order to sign a 1 in the bitfield.
PVF pre-checking will happen after the candidate which brought the counter to +0 has been successfully included and thus is also able to assume that 2/3 of +the validators have the code.
First when a candidate is backed we need to make the new hash available +(together with a counter) via a +runtime API so validators in availability distribution can check for it and +fetch it if changed (see previous section). For performance reasons, I think we +should not do an additional call, but replace the existing one with one containing the new additional information (Option<(Hash, Counter)>).
Once the candidate gets included (counter 0), the hash is given to pre-checking +and only after pre-checking succeeded (and a full session passed) it is finally +enacted and the parachain can switch to the new code. (Same process as it used +to be.)
If a backer receives a collation for a parachain it does not yet have the code +as enacted on chain (see "On-chain code upgrade process"), it will use above +request/response protocol to fetch it from whom it received the collation.
Validators in availability distribution will be changed to only sign a 1 in +the bitfield of a candidate if they not only have the chunk, but also the +currently active PVF. They will fetch it from backers in case they don't have it +yet.
We covered how validators get hold of new code, but when can they prune old ones? +In principle it is not an issue, if some validors prune code, because:
But the majority of validators should always keep the latest code of any +parachain and only prune the previous one, once the first candidate using the +new code got finalized. This ensures that disputes will always be able to +resolve.
The major drawback of this solution is the same as any solution the moves work +off-chain, it adds complexity to the node. E.g. nodes needing the PVF, need to +store them separately, together with their own pruning strategy as well.
Implementations adhering to this RFC, will respond to PVF requests with the +actual PVF, if they have it. Requesters will persist received PVFs on disk for +as long as they are replaced by a new one. Implementations must not be lazy +here, if validators only fetched the PVF when needed, they can be prevented from +participating in disputes.
Validators should treat incoming requests for PVFs in general with rather low +priority, but should prefer fetches from other validators over requests from +random peers.
Given that we are altering what set bits in the availability bitfields mean (not +only chunk, but also PVF available), it is important to have enough validators +upgraded, before we allow collators to make use of the new runtime upgrade +mechanism. Otherwise we would risk disputes to not being able to succeed.
This proposal lightens the load on the relay chain and is thus in general +beneficial for the performance of the network, this is achieved by the +following:
End users are only affected by better performance and more stable block times. +Parachains will need to implement the introduced request/response protocol and +adapt to the new signalling mechanism via an UMP message, instead of sending +the code upgrade directly.
For parachain operators we should emit events on initiated runtime upgrade and +each block reporting the current counter and how many blocks to go until the +upgrade gets passed to pre-checking. This is especially important for on-demand +chains or bulk users not occupying a full core. Further more that behaviour of +requiring multiple blocks to fully initiate a runtime upgrade needs to be well +documented.
We will continue to support the old mechanism for code upgrades for a while, but +will start to impose stricter limits over time, with the number of registered +parachains going up. With those limits in place parachains not migrating to the +new scheme might be having a harder time upgrading and will miss more blocks. I +guess we can be lenient for a while still, so the upgrade path for +parachains should be rather smooth.
Off-chain runtime upgrades have been discussed before, the architecture +described here is simpler though as it piggybacks on already existing features, +namely:
By no longer having code upgrade go through the relay chain, occupying a full relay +chain block, the impact on other parachains is already greatly reduced, if we +make distribution and PVF pre-checking low-priority processes on validators. The +only thing attackers might be able to do is delay upgrades of other parachains.
Which seems like a problem to be solved once we actually see it as a problem in +the wild (and can already be mitigated by adjusting the counter). The good thing +is that we have all the ingredients to go further if need be. Signalling no +longer actually includes the code, hence there is no need to reject the +candidate: The parachain can make progress even if we choose not to immediately +act on the request and no relay chain resources are wasted either.
We could for example introduce another UMP Signalling message +RequestCodeUpgradeWithPriority which not just requests a code upgrade, but +also offers some DOT to get ranked up in a queue.
Making this storage mechanism more general purpose is worth thinking about. E.g. +by resolving above "fee" question, we might also be able to resolve the pruning +question in a more generic way and thus could indeed open this storage facility +for other purposes as well. E.g. smart contracts, so the PoV would only need to +reference contracts by hash and the actual PoV is stored on validators and +collators and thus no longer needs to be part of the PoV.
#![allow(unused)] +fn main() { +enum BlobResponse { + Blob(Vec<u8>), + Blobs(MerkleTree), +} +}
With this the hash specified in the request can also be a merkle root and the +responder will respond with the entire merkle tree (only hashes, no payload). +Then the requester can traverse the leaf hashes and use the same request +response protocol to request any locally missing blobs in that tree.
One leaf would for example be the PVF others could be smart contracts. With a +properly specified format (e.g. which leaf is the PVF?), what we got here is +that a parachain can not only update its PVF, but additional data, +incrementally. E.g. adding another smart contract, does not require resubmitting +the entire PVF to validators, only the root hash on the relay chain gets +updated, then validators fetch the merkle tree and only fetch any missing +leaves. That additional data could be made available to the PVF via a to be +added host function. The nice thing about this approach is, that while we can +upgrade incrementally, lifetime is still tied to the PVF and we get all the same +guarantees. Assuming the validators store blobs by hash, we even get disk +sharing if multiple parachains use the same data (e.g. same smart contracts).
#![allow(unused)] diff --git a/proposed/0106-xcm-remove-fees-mode.html b/proposed/0106-xcm-remove-fees-mode.html index f4f7c79..4ae31d4 100644 --- a/proposed/0106-xcm-remove-fees-mode.html +++ b/proposed/0106-xcm-remove-fees-mode.html @@ -90,7 +90,7 @@ - IntroductionNewly ProposedRFC-0111: Pure Proxy ReplicationRFC-0112: Compress the State Response Message in State SyncRFC-0114: Introduce secp256r1_ecdsa_verify_prehashed Host Function to verify NIST-P256 elliptic curve signaturesProposedRFC-0002: Smart Contracts on the Coretime ChainRFC-0100: New XCM instruction: InitiateAssetsTransferRFC-0000: Feature Name HereRFC-0103: Introduce a CoreIndex commitment and a SessionIndex field in candidate receiptsRFC-0105: XCM improved fee mechanismRFC-0106: Remove XCM fees modeRFC-0107: XCM Execution hintsRFC-0109: Descend XCM origin instead of clearing it where possibleApprovedRFC-1: Agile CoretimeRFC-5: Coretime InterfaceRFC-0007: System Collator SelectionRFC-0008: Store parachain bootnodes in relay chain DHTRFC-0010: Burn Coretime RevenueRFC-0012: Process for Adding New System CollectivesRFC-0013: Prepare Core runtime API for MBMsRFC-0014: Improve locking mechanism for parachainsRFC-0022: Adopt Encointer RuntimeRFC-0026: Sassafras Consensus ProtocolRFC-0032: Minimal RelayRFC-0042: Add System version that replaces StateVersion on RuntimeVersionRFC-0043: Introduce storage_proof_size Host Function for Improved Parachain Block UtilizationRFC-0045: Lowering NFT Deposits on Asset HubRFC-0047: Assignment of availability chunks to validatorsRFC-0048: Generate ownership proof for SessionKeysRFC-0050: Fellowship SalariesRFC-0056: Enforce only one transaction per notificationRFC-0059: Add a discovery mechanism for nodes based on their capabilitiesRFC-0078: Merkleized MetadataRFC-0084: General transactions in extrinsic formatRFC-0091: DHT Authority discovery record creation timeRFC-0097: Unbonding QueueRFC-0099: Introduce a transaction extension versionRFC-0101: XCM Transact remove require_weight_at_most parameterRFC-0108: Remove XCM testnet NetworkIdsStaleRFC-0004: Remove the host-side runtime memory allocatorRFC-0006: Dynamic Pricing for Bulk Coretime SalesRFC-0009: Improved light client requests networking protocolRFC-0015: Market Design RevisitRFC-0020: Treasurer Track Confirmation Period Duration ModificationRFC-34: XCM Absolute Location Account Derivation RFC-0035: Conviction Voting Delegation ModificationsRFC-0044: Rent based registration modelRFC-0054: Remove the concept of "heap pages" from the clientRFC-0070: X Track for @kusamanetworkRFC-0073: Decision Deposit Referendum TrackRFC-0074: Stateful Multisig PalletRFC-0077: Increase maximum length of identity PGP fingerprint values from 20 bytesRFC-0088: Add slashable locked deposit, purchaser reputation, and reserved cores for on-chain identities to broker palletRFC-0089: Flexible InflationRFC-0001: Secondary Market for RegionsRFC-TODO: Stale Nomination Reward Curve + IntroductionNewly ProposedRFC-0112: Compress the State Response Message in State SyncRFC-0114: Introduce secp256r1_ecdsa_verify_prehashed Host Function to verify NIST-P256 elliptic curve signaturesRFC-114: Adjust Tipper Track Confirmation PeriodsProposedRFC-0002: Smart Contracts on the Coretime ChainRFC-0100: New XCM instruction: InitiateAssetsTransferRFC-0103: Introduce a CoreIndex commitment and a SessionIndex field in candidate receiptsRFC-0105: XCM improved fee mechanismRFC-0106: Remove XCM fees modeRFC-0107: XCM Execution hintsRFC-0109: Descend XCM origin instead of clearing it where possibleRFC-0111: Pure Proxy ReplicationApprovedRFC-1: Agile CoretimeRFC-5: Coretime InterfaceRFC-0007: System Collator SelectionRFC-0008: Store parachain bootnodes in relay chain DHTRFC-0010: Burn Coretime RevenueRFC-0012: Process for Adding New System CollectivesRFC-0013: Prepare Core runtime API for MBMsRFC-0014: Improve locking mechanism for parachainsRFC-0022: Adopt Encointer RuntimeRFC-0026: Sassafras Consensus ProtocolRFC-0032: Minimal RelayRFC-0042: Add System version that replaces StateVersion on RuntimeVersionRFC-0043: Introduce storage_proof_size Host Function for Improved Parachain Block UtilizationRFC-0045: Lowering NFT Deposits on Asset HubRFC-0047: Assignment of availability chunks to validatorsRFC-0048: Generate ownership proof for SessionKeysRFC-0050: Fellowship SalariesRFC-0056: Enforce only one transaction per notificationRFC-0059: Add a discovery mechanism for nodes based on their capabilitiesRFC-0078: Merkleized MetadataRFC-0084: General transactions in extrinsic formatRFC-0091: DHT Authority discovery record creation timeRFC-0097: Unbonding QueueRFC-0099: Introduce a transaction extension versionRFC-0101: XCM Transact remove require_weight_at_most parameterRFC-0108: Remove XCM testnet NetworkIdsStaleRFC-0004: Remove the host-side runtime memory allocatorRFC-0006: Dynamic Pricing for Bulk Coretime SalesRFC-0009: Improved light client requests networking protocolRFC-0015: Market Design RevisitRFC-34: XCM Absolute Location Account Derivation RFC-0035: Conviction Voting Delegation ModificationsRFC-0044: Rent based registration modelRFC-0054: Remove the concept of "heap pages" from the clientRFC-0070: X Track for @kusamanetworkRFC-0073: Decision Deposit Referendum TrackRFC-0074: Stateful Multisig PalletRFC-0077: Increase maximum length of identity PGP fingerprint values from 20 bytesRFC-0088: Add slashable locked deposit, purchaser reputation, and reserved cores for on-chain identities to broker palletRFC-0089: Flexible InflationRFC-0001: Secondary Market for RegionsRFC-0000: Feature Name HereRFC-TODO: Stale Nomination Reward Curve diff --git a/proposed/0107-xcm-execution-hints.html b/proposed/0107-xcm-execution-hints.html index 1235d14..795f618 100644 --- a/proposed/0107-xcm-execution-hints.html +++ b/proposed/0107-xcm-execution-hints.html @@ -90,7 +90,7 @@ - IntroductionNewly ProposedRFC-0111: Pure Proxy ReplicationRFC-0112: Compress the State Response Message in State SyncRFC-0114: Introduce secp256r1_ecdsa_verify_prehashed Host Function to verify NIST-P256 elliptic curve signaturesProposedRFC-0002: Smart Contracts on the Coretime ChainRFC-0100: New XCM instruction: InitiateAssetsTransferRFC-0000: Feature Name HereRFC-0103: Introduce a CoreIndex commitment and a SessionIndex field in candidate receiptsRFC-0105: XCM improved fee mechanismRFC-0106: Remove XCM fees modeRFC-0107: XCM Execution hintsRFC-0109: Descend XCM origin instead of clearing it where possibleApprovedRFC-1: Agile CoretimeRFC-5: Coretime InterfaceRFC-0007: System Collator SelectionRFC-0008: Store parachain bootnodes in relay chain DHTRFC-0010: Burn Coretime RevenueRFC-0012: Process for Adding New System CollectivesRFC-0013: Prepare Core runtime API for MBMsRFC-0014: Improve locking mechanism for parachainsRFC-0022: Adopt Encointer RuntimeRFC-0026: Sassafras Consensus ProtocolRFC-0032: Minimal RelayRFC-0042: Add System version that replaces StateVersion on RuntimeVersionRFC-0043: Introduce storage_proof_size Host Function for Improved Parachain Block UtilizationRFC-0045: Lowering NFT Deposits on Asset HubRFC-0047: Assignment of availability chunks to validatorsRFC-0048: Generate ownership proof for SessionKeysRFC-0050: Fellowship SalariesRFC-0056: Enforce only one transaction per notificationRFC-0059: Add a discovery mechanism for nodes based on their capabilitiesRFC-0078: Merkleized MetadataRFC-0084: General transactions in extrinsic formatRFC-0091: DHT Authority discovery record creation timeRFC-0097: Unbonding QueueRFC-0099: Introduce a transaction extension versionRFC-0101: XCM Transact remove require_weight_at_most parameterRFC-0108: Remove XCM testnet NetworkIdsStaleRFC-0004: Remove the host-side runtime memory allocatorRFC-0006: Dynamic Pricing for Bulk Coretime SalesRFC-0009: Improved light client requests networking protocolRFC-0015: Market Design RevisitRFC-0020: Treasurer Track Confirmation Period Duration ModificationRFC-34: XCM Absolute Location Account Derivation RFC-0035: Conviction Voting Delegation ModificationsRFC-0044: Rent based registration modelRFC-0054: Remove the concept of "heap pages" from the clientRFC-0070: X Track for @kusamanetworkRFC-0073: Decision Deposit Referendum TrackRFC-0074: Stateful Multisig PalletRFC-0077: Increase maximum length of identity PGP fingerprint values from 20 bytesRFC-0088: Add slashable locked deposit, purchaser reputation, and reserved cores for on-chain identities to broker palletRFC-0089: Flexible InflationRFC-0001: Secondary Market for RegionsRFC-TODO: Stale Nomination Reward Curve + IntroductionNewly ProposedRFC-0112: Compress the State Response Message in State SyncRFC-0114: Introduce secp256r1_ecdsa_verify_prehashed Host Function to verify NIST-P256 elliptic curve signaturesRFC-114: Adjust Tipper Track Confirmation PeriodsProposedRFC-0002: Smart Contracts on the Coretime ChainRFC-0100: New XCM instruction: InitiateAssetsTransferRFC-0103: Introduce a CoreIndex commitment and a SessionIndex field in candidate receiptsRFC-0105: XCM improved fee mechanismRFC-0106: Remove XCM fees modeRFC-0107: XCM Execution hintsRFC-0109: Descend XCM origin instead of clearing it where possibleRFC-0111: Pure Proxy ReplicationApprovedRFC-1: Agile CoretimeRFC-5: Coretime InterfaceRFC-0007: System Collator SelectionRFC-0008: Store parachain bootnodes in relay chain DHTRFC-0010: Burn Coretime RevenueRFC-0012: Process for Adding New System CollectivesRFC-0013: Prepare Core runtime API for MBMsRFC-0014: Improve locking mechanism for parachainsRFC-0022: Adopt Encointer RuntimeRFC-0026: Sassafras Consensus ProtocolRFC-0032: Minimal RelayRFC-0042: Add System version that replaces StateVersion on RuntimeVersionRFC-0043: Introduce storage_proof_size Host Function for Improved Parachain Block UtilizationRFC-0045: Lowering NFT Deposits on Asset HubRFC-0047: Assignment of availability chunks to validatorsRFC-0048: Generate ownership proof for SessionKeysRFC-0050: Fellowship SalariesRFC-0056: Enforce only one transaction per notificationRFC-0059: Add a discovery mechanism for nodes based on their capabilitiesRFC-0078: Merkleized MetadataRFC-0084: General transactions in extrinsic formatRFC-0091: DHT Authority discovery record creation timeRFC-0097: Unbonding QueueRFC-0099: Introduce a transaction extension versionRFC-0101: XCM Transact remove require_weight_at_most parameterRFC-0108: Remove XCM testnet NetworkIdsStaleRFC-0004: Remove the host-side runtime memory allocatorRFC-0006: Dynamic Pricing for Bulk Coretime SalesRFC-0009: Improved light client requests networking protocolRFC-0015: Market Design RevisitRFC-34: XCM Absolute Location Account Derivation RFC-0035: Conviction Voting Delegation ModificationsRFC-0044: Rent based registration modelRFC-0054: Remove the concept of "heap pages" from the clientRFC-0070: X Track for @kusamanetworkRFC-0073: Decision Deposit Referendum TrackRFC-0074: Stateful Multisig PalletRFC-0077: Increase maximum length of identity PGP fingerprint values from 20 bytesRFC-0088: Add slashable locked deposit, purchaser reputation, and reserved cores for on-chain identities to broker palletRFC-0089: Flexible InflationRFC-0001: Secondary Market for RegionsRFC-0000: Feature Name HereRFC-TODO: Stale Nomination Reward Curve diff --git a/proposed/0109-xcm-descend-instead-of-clear-origin.html b/proposed/0109-xcm-descend-instead-of-clear-origin.html index 12feeaa..e95d3f7 100644 --- a/proposed/0109-xcm-descend-instead-of-clear-origin.html +++ b/proposed/0109-xcm-descend-instead-of-clear-origin.html @@ -90,7 +90,7 @@ - IntroductionNewly ProposedRFC-0111: Pure Proxy ReplicationRFC-0112: Compress the State Response Message in State SyncRFC-0114: Introduce secp256r1_ecdsa_verify_prehashed Host Function to verify NIST-P256 elliptic curve signaturesProposedRFC-0002: Smart Contracts on the Coretime ChainRFC-0100: New XCM instruction: InitiateAssetsTransferRFC-0000: Feature Name HereRFC-0103: Introduce a CoreIndex commitment and a SessionIndex field in candidate receiptsRFC-0105: XCM improved fee mechanismRFC-0106: Remove XCM fees modeRFC-0107: XCM Execution hintsRFC-0109: Descend XCM origin instead of clearing it where possibleApprovedRFC-1: Agile CoretimeRFC-5: Coretime InterfaceRFC-0007: System Collator SelectionRFC-0008: Store parachain bootnodes in relay chain DHTRFC-0010: Burn Coretime RevenueRFC-0012: Process for Adding New System CollectivesRFC-0013: Prepare Core runtime API for MBMsRFC-0014: Improve locking mechanism for parachainsRFC-0022: Adopt Encointer RuntimeRFC-0026: Sassafras Consensus ProtocolRFC-0032: Minimal RelayRFC-0042: Add System version that replaces StateVersion on RuntimeVersionRFC-0043: Introduce storage_proof_size Host Function for Improved Parachain Block UtilizationRFC-0045: Lowering NFT Deposits on Asset HubRFC-0047: Assignment of availability chunks to validatorsRFC-0048: Generate ownership proof for SessionKeysRFC-0050: Fellowship SalariesRFC-0056: Enforce only one transaction per notificationRFC-0059: Add a discovery mechanism for nodes based on their capabilitiesRFC-0078: Merkleized MetadataRFC-0084: General transactions in extrinsic formatRFC-0091: DHT Authority discovery record creation timeRFC-0097: Unbonding QueueRFC-0099: Introduce a transaction extension versionRFC-0101: XCM Transact remove require_weight_at_most parameterRFC-0108: Remove XCM testnet NetworkIdsStaleRFC-0004: Remove the host-side runtime memory allocatorRFC-0006: Dynamic Pricing for Bulk Coretime SalesRFC-0009: Improved light client requests networking protocolRFC-0015: Market Design RevisitRFC-0020: Treasurer Track Confirmation Period Duration ModificationRFC-34: XCM Absolute Location Account Derivation RFC-0035: Conviction Voting Delegation ModificationsRFC-0044: Rent based registration modelRFC-0054: Remove the concept of "heap pages" from the clientRFC-0070: X Track for @kusamanetworkRFC-0073: Decision Deposit Referendum TrackRFC-0074: Stateful Multisig PalletRFC-0077: Increase maximum length of identity PGP fingerprint values from 20 bytesRFC-0088: Add slashable locked deposit, purchaser reputation, and reserved cores for on-chain identities to broker palletRFC-0089: Flexible InflationRFC-0001: Secondary Market for RegionsRFC-TODO: Stale Nomination Reward Curve + IntroductionNewly ProposedRFC-0112: Compress the State Response Message in State SyncRFC-0114: Introduce secp256r1_ecdsa_verify_prehashed Host Function to verify NIST-P256 elliptic curve signaturesRFC-114: Adjust Tipper Track Confirmation PeriodsProposedRFC-0002: Smart Contracts on the Coretime ChainRFC-0100: New XCM instruction: InitiateAssetsTransferRFC-0103: Introduce a CoreIndex commitment and a SessionIndex field in candidate receiptsRFC-0105: XCM improved fee mechanismRFC-0106: Remove XCM fees modeRFC-0107: XCM Execution hintsRFC-0109: Descend XCM origin instead of clearing it where possibleRFC-0111: Pure Proxy ReplicationApprovedRFC-1: Agile CoretimeRFC-5: Coretime InterfaceRFC-0007: System Collator SelectionRFC-0008: Store parachain bootnodes in relay chain DHTRFC-0010: Burn Coretime RevenueRFC-0012: Process for Adding New System CollectivesRFC-0013: Prepare Core runtime API for MBMsRFC-0014: Improve locking mechanism for parachainsRFC-0022: Adopt Encointer RuntimeRFC-0026: Sassafras Consensus ProtocolRFC-0032: Minimal RelayRFC-0042: Add System version that replaces StateVersion on RuntimeVersionRFC-0043: Introduce storage_proof_size Host Function for Improved Parachain Block UtilizationRFC-0045: Lowering NFT Deposits on Asset HubRFC-0047: Assignment of availability chunks to validatorsRFC-0048: Generate ownership proof for SessionKeysRFC-0050: Fellowship SalariesRFC-0056: Enforce only one transaction per notificationRFC-0059: Add a discovery mechanism for nodes based on their capabilitiesRFC-0078: Merkleized MetadataRFC-0084: General transactions in extrinsic formatRFC-0091: DHT Authority discovery record creation timeRFC-0097: Unbonding QueueRFC-0099: Introduce a transaction extension versionRFC-0101: XCM Transact remove require_weight_at_most parameterRFC-0108: Remove XCM testnet NetworkIdsStaleRFC-0004: Remove the host-side runtime memory allocatorRFC-0006: Dynamic Pricing for Bulk Coretime SalesRFC-0009: Improved light client requests networking protocolRFC-0015: Market Design RevisitRFC-34: XCM Absolute Location Account Derivation RFC-0035: Conviction Voting Delegation ModificationsRFC-0044: Rent based registration modelRFC-0054: Remove the concept of "heap pages" from the clientRFC-0070: X Track for @kusamanetworkRFC-0073: Decision Deposit Referendum TrackRFC-0074: Stateful Multisig PalletRFC-0077: Increase maximum length of identity PGP fingerprint values from 20 bytesRFC-0088: Add slashable locked deposit, purchaser reputation, and reserved cores for on-chain identities to broker palletRFC-0089: Flexible InflationRFC-0001: Secondary Market for RegionsRFC-0000: Feature Name HereRFC-TODO: Stale Nomination Reward Curve @@ -263,7 +263,7 @@ For example, the - + @@ -277,7 +277,7 @@ For example, the - +