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.
(source)
Table of Contents
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.
None.
No compatibility issues identified.
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 @@ -513,7 +584,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 integration of smart contracts on the Coretime chain to enhance flexibility and enable complex decentralized applications, including secondary market functionalities.
Currently, the Coretime chain lacks the capability to support smart contracts, which limits the range of decentralized applications that can be developed and deployed. By enabling smart contracts, the Coretime chain can facilitate more sophisticated functionalities such as automated region trading, dynamic pricing mechanisms, and other decentralized applications that require programmable logic. This will enhance the utility of the Coretime chain, attract more developers, and create more opportunities for innovation.
Additionally, while there is a proposal (#885) to allow EVM-compatible contracts on Polkadot’s Asset Hub, the implementation of smart contracts directly on the Coretime chain will provide synchronous interactions and avoid the complexities of asynchronous operations via XCM.
Primary stakeholders include:
This RFC introduces the following key components:
There are several drawbacks to consider:
This RFC proposes a new instruction that provides a way to initiate on remote chains, asset transfers which transfer multiple types (teleports, local-reserve, destination-reserve) of assets, using XCM alone.
The currently existing instructions are too opinionated and force each XCM asset transfer to a single transfer type (teleport, local-reserve, destination-reserve). This results in inability to combine different types of transfers in single transfer which results in overall poor UX when trying to move assets across chains.
XCM is the de-facto cross-chain messaging protocol within the Polkadot ecosystem, and cross-chain assets transfers is one of its main use-cases. Unfortunately, in its current spec, it does not support initiating on a remote chain, one or more transfers that combine assets with different transfer types. @@ -768,14 +839,14 @@ For example, allows single XCM program execution to transfer multiple assets fro Kusama Asset Hub, over the bridge through Polkadot Asset Hub with final destination ParaP on Polkadot.
ParaP
With current XCM, we are limited to doing multiple independent transfers for each individual hop in order to move both "interesting" assets, but also "supporting" assets (used to pay fees).
A new instruction InitiateAssetsTransfer is introduced that initiates an assets transfer from the chain it is executed on, to another chain. The executed transfer is point-to-point (chain-to-chain) with all of the transfer properties specified in the instruction parameters. The instruction also @@ -963,9 +1034,9 @@ by executing a single XCM message, even though we'll be mixing multiple ).unwrap(); }) } -
InitiateAssetsTransfer
No drawbacks identified.
There should be no security risks related to the new instruction from the XCVM perspective. It follows the same pattern as with single-type asset transfers, only now it allows combining multiple types at once.
Improves security by enabling @@ -974,16 +1045,16 @@ which minimizes the potential free/unpaid work that a receiving chain has to do. required execution fee payment, part of the instruction logic through the remote_fees: Option<AssetTransferFilter> parameter, which will make sure the remote XCM starts with a single-asset-holding-loading-instruction, immediately followed by a BuyExecution using said asset.
remote_fees: Option<AssetTransferFilter>
BuyExecution
This brings no impact to the rest of the XCM spec. It is a new, independent instruction, no changes to existing instructions.
Enhances the exposed functionality of Polkadot. Will allow multi-chain transfers that are currently forced to happen in multiple programs per asset per "hop", to be possible in a single XCM program.
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.
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 @@ -1064,13 +1135,13 @@ 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:
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 @@ -1218,8 +1289,8 @@ 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 @@ -1245,7 +1316,7 @@ 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.
UMP
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 @@ -1266,7 +1337,7 @@ validators. "hot" PVF).
Off-chain runtime upgrades have been discussed before, the architecture described here is simpler though as it piggybacks on already existing features, namely:
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 @@ -1340,7 +1411,7 @@ sharing if multiple parachains use the same data (e.g. same smart contracts).
CoreIndex
SessionIndex
Elastic scaling is not resiliet against griefing attacks without a way for a PoV (Proof of Validity) to commit to the particular core index it was intedened for. This RFC proposes a way to include core index information in the candidate commitments and the CandidateDescriptor data strcuture 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
At present time misbehaving collator nodes, or anyone who has acquired a valid collation can prevent a parachain from effecitvely using elastic scaling by providing the same collation to all backing groups assigned to the parachain. This happens before the next parachain block is authored and will prevent the chain of candidates to be formed, reducing the throughput of the parachain to a single core.
The session index of candidates is important for the disputes protocol as it is used to lookup validator keys and check dispute vote signatures. By adding a SessionIndex in the CandidateDescriptor, validators no longer have to trust the Sessionindex provided by the validator raising a dispute. It can happen that the dispute concerns a relay chain block not yet imported by a validator. In this case validators can safely assume the session index refers to the session the candidate has appeared in, otherwise the chain would have rejected candidate.
Sessionindex
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.
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 primarly 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 unused fields to introduce core index and a session index information in the CandidateDescriptor and extend the UMP usage to output core index information.
The approach proposed below was chosen primarly 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 unused fields to introduce core index and a session index information in the CandidateDescriptor and extend the UMP for transporting non-XCM messages.
The CandidateDescriptor currently includes collator and signature fields. The collator includes a signature on the following descriptor fields: parachain id, relay parent, validation data hash, validation code hash and the PoV hash.
collator
signature
However, in practice, having a collator signature in the receipt on the relay chain does not provide any benefits as there is no mechanism to punish or reward collators that have provided bad parachain blocks.
This proposal aims to remove the collator signature and all the logic that checks the collator signatures of candidate receipts. We use the first 7 reclaimed bytes to represent version, the core and session index, and fill the rest with zeroes. So, there is no change in the layout and length of the receipt. The new primitive is binary compatible with the old one.
There are two flavors of candidate receipts which are used in network protocols, runtime and node implementation:
CommittedCandidateReceipt
CanidateDescriptor
CandidateCommitments
CandidateReceipt
We want to support both the old and new versions in the runtime and node. The implementation must be able to detect the version of a given candidate receipt.
CandidateDescriptor is a valid version 2 descriptor, if:
CandidateCommitments remains unchanged as we will store scale encoded UMPSignal messages directly in the parachain UMP queue by outputing them in the upward_messages.
UMPSignal
CandidateCommitments remains unchanged as we will store scale encoded UMPSignal messages directly in the parachain UMP queue by outputing them in upward_messages.
The UMP queue layout is changed to allow the relay chain to receive both the XCM messages and UMPSignal messages. An empty message (empty Vec<u8>) is used to mark the end XCM messages and the start of UMPSignal messages.
Vec<u8>
This way of representing the new messages has been chosen over introducing an enum wrapper to minimize breaking changes of XCM message decoding in tools like Subscan for example.
Example:
#![allow(unused)] fn main() { -[ XCM message1, XCM message2, ..., EMPTY message, UMPSignal::CoreSelector ] +[ XCM message1, XCM message2, ..., EMPTY message, UMPSignal::SelectCore ] }
#![allow(unused)] @@ -1440,17 +1500,32 @@ pub enum UMPSignal { SelectCore(CoreSelector, ClaimQueueOffset), } }
As we dont want to have a claim queue snapshot in the parachain runtime, we need to set ClaimQueueOffset -statically to some sane value. Parachains should prefer to have a static value that makes sense for their usecase which can be changed by governance at some future point. Changing the value dynamically can be a friction point. It will work out fine to decrease the value to build more into the present. But if the value is increased to build more into the future, a relay chain block will be skipped.
ClaimQueueOffset
Considering para_assigned_cores is a sorted vec of core indices assigned to a parachain at the -specified claim queue offset, validators will determine the committed core index like this:
para_assigned_cores
The parachain runtime is not concerned with the actual CoreIndex the candidate is intended for, +but must provide enough information for the validators and collators to compute it. CoreSelector +and ClaimQueueOffset use only 2 bytes and fullfil the requirement.
CoreSelector
cq_offset = 1 and core_selector = 3
cq_offset = 1
core_selector = 3
The table below represents a snapshot of the claim queue:
| | offset = 0 | offset = 1 | offset = 2 | +| :--: | :--: | :--: | :--: | +| Core 1 | Para A | Para A | Para A | +| Core 2 | Para A | Para B | Para A | +| Core 3 | Para B | Para A | Para A |
The purpose of ClaimQueueOffset is to select the column from the above table. +For cq_offset = 1 we get [ Para A, Para B, Para A] and use as input to create +a sorted vec with the cores A is assigned to: [ Core 1, Core 3] and call it para_assigned_cores. +We use core_selector and determine the commited core index is Core 3 like this:
[ Para A, Para B, Para A]
[ Core 1, Core 3]
core_selector
Core 3
#![allow(unused)] fn main() { -let assigned_core_index = core_selector % para_assigned_cores.len(); -let committed_core_index = para_assigned_cores[assigned_core_index]; +let committed_core_index = para_assigned_cores[core_selector % para_assigned_cores.len()]; }
Parachains should prefer to have a static ClaimQueueOffset value that makes sense for their +usecase which can be changed by governance at some future point. Changing the value dynamically +can be a friction point. It will work out fine to decrease the value to build more into the +present. But if the value is increased to build more into the future, a relay chain block will +be skipped.
collator: CollatorId
signature: CollatorSignature
reserved1
reserved2
version: u8
In future format versions, parts of the reserved1 and reserved2 bytes can be used to include additional information in the descriptor.
We want to decouple the actual representation of the CandidateDescriptor from the higher level code. This should make it easier to implement future format versions of this primitive. To hide the logic of versioning the descriptor fields will be private and getter methods are provided for all the fields.
#![allow(unused)] -fn main() { -impl<H> CandidateDescriptorV2<H> { - - /// Returns the collator id in the descriptor. Returns `None` if descriptor is at verision 2. - pub fn collator(&self) -> Option<CollatorId>; - - /// Returns the collator signature in the descriptor. Returns `None` if descriptor is at verision 2. - pub fn signature(&self) -> Option<CollatorSignature>; - - /// Returns the core index of the descriptor. Returns `None` if the descriptor is at version 1. - pub fn core_index(&self) -> Option<CoreIndex>; - - /// Returns the session index of the descriptor. Returns `None` if the descriptor is at version 1. - pub fn session_index(&self) -> Option<SessionIndex>; - - /// ... -} - -}
A manual decode Decode implementation is required to account for version detection and constructing the appropriate variant.
Decode
Backers will make use of the core index information to validate the blocks during backing and reject blocks if:
If the candidate descriptor is version 1, there are no changes.
For version 2, backers and the runtime must check the validity of core_index and session_index fields. +A candidate must not be backed if any of the following are true:
core_index
session_index
UMPSignal::SelectCore
relay_parent
If core index (and session index) information is not available (backers got an old candidate receipt), there will be no changes compared to current behaviour.
The runtime will also perform the above checks and reject invalid candidates.
The version of the descriptor is detected by checking if the version field is 0 and the +reserved fields are zerored. If this is true it means the descriptor is version 2, +otherwise we consider it is version 1.
version
0
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 secuirty 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 expectation is that performance impact is negligible for sending and processing the UMP message has negligible performance impact in the runtime as well as on the node side.
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.
Once this RFC is implemented the parachain runtime and node must not require any manual changes to use it, except if the parachain wants to change the ClaimQueueOffset that is used to determine the core index.
The proposed changes are backwards compatible in general, but additional care must be taken by waiting for enough validators to upgrade before the validators and runtime start accepting the new candidate receipts.
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
The first step is to remove collator signature checking logic in the runtime, but keep the node side collator signature checks.
The runtime must be upgraded to the new primitives before any collator or node are allowed to use the new candidate receipts format.
To ensure a smooth launch, a new node feature is required. -The feature acts as a signal for supporting the new candidate receipts on the node side and can only be safely enabled if at least 2/3 of the validators are upgraded.
Once enabled, the validators will skip checking the collator signature when processing the candidate receipts and verify the CoreIndex and SessionIndex fields if present in the receipt.
No new implementation of networking protocol versions for collation and validation are required.
The implementation of this RFC will supersede the Elastic MVP feature that relies on injecting a core index in the validator_indices fields of the BackedCandidate primitive. Elastic parachains must upgrade to use the new receipt format.
validator_indices
BackedCandidate
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
N/A
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
At this point there is a simple way to determine the version of the receipt, by testing for zeroed reserved bytes in the descriptor. Future versions of the receipt can be implemented and identified by using the version field of the descirptor introduced in this RFC.
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. @@ -1605,7 +1665,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. @@ -1613,14 +1673,14 @@ 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
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 SetExecutionHints and makes the SetAssetClaimer be just one of many possible execution hints.
SetAssetClaimer
SetExecutionHints
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:
LeftoverAssetsDestination
A new instruction, SetExecutionHints, will be added. This instruction will take a single parameter of type ExecutionHint, an enumeration. The first variant for this enum is AssetClaimer, which allows to specify a location that should be able to claim trapped assets. @@ -1820,29 +1880,29 @@ enum ExecutionHint { type NumVariants = /* Number of variants of the `ExecutionHint` enum */; } -
ExecutionHint
AssetClaimer
The SetExecutionHints 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.
ExecutionHints 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 SetExecutionHint instructions.
SetExecutionHint
The SetExecutionHints 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 easy 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.
SetLeftoverAssetsDestination is an idea of a hint that could be added. What more are there? This RFC creates a convenience for a pattern that was identified. Should we try to hinder that pattern instead?
SetLeftoverAssetsDestination
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.
DescendOrigin
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.
Runtime Users, Runtime Devs, wallets, cross-chain dApps.
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.
This is a proposal to reduce the impact of stale nominations in the Polkadot staking system. With this proposal, nominators are incentivized to update or renew their selected validators once per time period. Nominators that do not update or renew their selected validators would be considered stale, and a decaying multiplier would be applied to their nominations, reducing the weight of their nomination and rewards.
Longer motivation behind the content of the RFC, presented as a combination of both problems and requirements for the solution.
One of Polkadot's primary utilities is providing a high quality security layer for applications built on top of it. To achieve this, Polkadot runs a Nominated Proof-of-Stake system, allowing nominators to vote on who they think are the best validators for Polkadot.
This system functions best when nominators and validators are active participants in the network. Nominators should consistently evaluate the quality and preferences of validators, and adjust their nominations accordingly.
Unfortunately, many Polkadot nominators do not play an active role in the NPoS system. For many, they set their nominations, and then seldomly look back at the.
This can lead to many negative behaviors:
Primary stakeholders are:
Detail-heavy explanation of the RFC, suitable for explanation to an implementer of the changeset. This should address corner cases in detail and provide justification behind decisions, and provide rationale for how the design meets the solution requirements.
Description of recognized drawbacks to the approach given in the RFC. Non-exhaustively, drawbacks relating to performance, ergonomics, user experience, security, or privacy.
Describe the the impact of the proposal on these three high-importance areas - how implementations can be tested for adherence, effects that the proposal has on security and privacy per-se, as well as any possible implementation pitfalls which should be clearly avoided.
Describe the impact of the proposal on the exposed functionality of Polkadot.
Is this an optimization or a necessary pessimization? What steps have been taken to minimize additional overhead?
If the proposal alters exposed interfaces to developers or end-users, which types of usage patterns have been optimized for?
Provide references to either prior art or other relevant research for the submitted design.
Provide specific questions to discuss and address before the RFC is voted on by the Fellowship. This should include, for example, alternatives to aspects of the proposed design where the appropriate trade-off to make is unclear.
Describe future work which could be enabled by this RFC, if it were accepted, as well as related RFCs. This is a place to brain-dump and explore possibilities, which themselves may become their own RFCs.
#![allow(unused)] @@ -277,17 +266,32 @@ pub enum UMPSignal { SelectCore(CoreSelector, ClaimQueueOffset), } }