This book contains the Polkadot Fellowship Requests for Comments (RFCs) detailing proposed changes to the technical implementation of the Polkadot network.
polkadot-fellows/RFCs
(source)
Table of Contents
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:
Smart Contract Support:
Storage and Execution:
Integration with Existing Pallets:
Security and Auditing:
There are several drawbacks to consider:
By enabling smart contracts on the Coretime chain, we can significantly expand its capabilities and attract a wider range of developers and users, fostering innovation and growth in the ecosystem.
CoreIndex
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 backward compatible way. Additionally, it proposes the addition of a SessionIndex field in +the CandidateDescriptor to make dispute resolution more secure and robust.
CandidateDescriptor
This RFC proposes a way to solve two different problems:
Sessionindex
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 +unused fields to introduce core index and a session index information in the CandidateDescriptor +and extend the UMP to transport non-XCM messages.
The CandidateDescriptor 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 the version, +the core, 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.
CandidateCommitments +remains unchanged as we will store scale encoded UMPSignal messages directly in the parachain +UMP queue by outputting them in upward_messages.
UMPSignal
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 of 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::SelectCore ] +}
#![allow(unused)] +fn main() { +/// An `u8` wrap-around sequence number. Typically this would be the least significant byte of the +/// parachain block number. +pub struct CoreSelector(pub u8); + +/// An offset in the relay chain claim queue. +pub struct ClaimQueueOffset(pub u8); + +/// Signals sent by a parachain to the relay chain. +pub enum UMPSignal { + /// A message sent by a parachain to select the core the candidate is committed to. + /// Relay chain validators, in particular backers, use the `CoreSelector` and `ClaimQueueOffset` + /// to compute the index of the core the candidate has committed to. + /// + SelectCore(CoreSelector, ClaimQueueOffset), +} +}
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 fulfills the requirement.
CoreSelector
ClaimQueueOffset
cq_offset = 1 and core_selector = 3
cq_offset = 1
core_selector = 3
The table below represents a snapshot of the claim queue:
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 committed core index is Core 3 like this:
[ Para A, Para B, Para A]
[ Core 1, Core 3]
para_assigned_cores
core_selector
Core 3
#![allow(unused)] +fn main() { +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.
collator: CollatorId
signature: CollatorSignature
reserved1
reserved2
version: u8
core_index: u16
session_index: u32
The new primitive will look like this:
#![allow(unused)] +fn main() { +pub struct CandidateDescriptorV2<H = Hash> { + /// The ID of the para this is a candidate for. + para_id: ParaId, + /// The hash of the relay-chain block this is executed in the context of. + relay_parent: H, + /// Version field. The raw value here is not exposed, instead, it is used + /// to determine the `CandidateDescriptorVersion` + version: InternalVersion, + /// The core index where the candidate is backed. + core_index: u16, + /// The session in which the candidate is backed. + session_index: SessionIndex, + /// Reserved bytes. + reserved1: [u8; 25], + /// The blake2-256 hash of the persisted validation data. This is extra data derived from + /// relay-chain state which may vary based on bitfields included before the candidate. + /// Thus it cannot be derived entirely from the relay parent. + persisted_validation_data_hash: Hash, + /// The blake2-256 hash of the PoV. + pov_hash: Hash, + /// The root of a block's erasure encoding Merkle tree. + erasure_root: Hash, + /// Reserved bytes. + reserved2: [u8; 64], + /// Hash of the para header that is being generated by this candidate. + para_head: Hash, + /// The blake2-256 hash of the validation code bytes. + validation_code_hash: ValidationCodeHash, +} +}
In future format versions, parts of the reserved1 and reserved2 bytes can be used to include +additional information in the descriptor.
If the candidate descriptor is version 1, there are no changes.
Backers 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
For version 2 descriptors the runtime will determine the core_index using the same inputs +as backers did off-chain. It currently stores the claim queue at the newest allowed +relay parent corresponding to the claim queue offset 0. The runtime needs to be changed to store +a claim queue snapshot at all allowed relay parents.
0
Two flavors of candidate receipts are used in network protocols, runtime and node +implementation:
CommittedCandidateReceipt
CandidateCommitments
CandidateReceipt
We want to support both the old and new versions in the runtime and node, so the implementation must +be able to detect the version of a given candidate receipt.
The version of the descriptor is detected by checking the reserved fields. +If they are not zeroed, it means it is a version 1 descriptor. Otherwise the version field +is used further to determine the version. It should be 0 for version 2 descriptors. If it is not +the descriptor has an unknown version and should be considered invalid.
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.
Backward compatibility of the implementation will be tested on testnets (Versi and Westend).
There is no impact on privacy.
Overall performance will be improved by not checking the collator signatures in runtime and nodes. +The impact on the UMP queue and candidate receipt processing is negligible.
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 the newest relay parent +provides the best latency while picking older relay parents avoids re-orgs.
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 backward 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 these +candidates.
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 support the new primitives before any collator or node is 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 + 1 of the validators are upgraded. Node implementations +need to decode the new candidate descriptor once the feature is enabled otherwise they might +raise disputes and get slashed.
Once the feature is 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 is required.
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 descriptor 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. +This RFC proposes making the fee handling system simpler and more general, by doing two things:
BuyExecution
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. +The standard should have a way to correctly deal with these implementation specific fees, that might not exist in every system that uses XCM. +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, and any other type of fee +necessary for the program to execute successfully.
Asset
#![allow(unused)] +fn main() { +PayFees { asset: 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.
asset
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)] +fn main() { +// Instruction that loads the holding register +BuyExecution { asset, weight_limit } +// ...rest +}
With this RFC, the structure would be the same, but using the new instruction, that has different semantics:
#![allow(unused)] +fn main() { +// Instruction that loads the holding register +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.
Removal of JIT fees is also related, they are useless with this proposal.
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 authorizes another chain to replicate its pure proxies, accepting the inherent risk of that chain potentially being compromised. This authorization allows a malicious actor from the compromised chain to take control of any pure proxy account on the chain that granted the authorization. However, this is limited to pure proxies that originated from the compromised chain if they have a chain-specific seed within the preimage.
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.
secp256r1_ecdsa_verify_prehashed
NIST-P256
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.
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)] +fn main() { +fn ext_secp256r1_ecdsa_verify_prehashed_version_1( + sig: &[u8; 64], + msg: &[u8; 32], + pub_key: &[u8; 64], +) -> 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.
A followup of the RFC-0014. This RFC proposes adding a new collective to the Polkadot Collectives +
A followup of the RFC-0014. This RFC proposes adding a new collective to the Polkadot Collectives Chain: The Unbrick Collective, as well as improvements in the mechanisms that will allow teams operating paras that had stopped producing blocks to be assisted, in order to restore the production of blocks of these paras.
Since the initial launch of Polkadot parachains, there has been many incidients causing parachains to stop producing new blocks (therefore, being bricked) and many occurrences that requires Polkadot governance to update the parachain head state/wasm. This can be due to many reasons range @@ -235,14 +1038,14 @@ damage to the parachain and users.
In consequence, the idea of a Unbrick Collective that can provide assistance to para teams when they brick and further protection against future halts is reasonable enough.
The Unbrick Collective is defined as an unranked collective of members, not paid by the Polkadot Treasury. Its main goal is to serve as a point of contact and assistance for enacting the actions @@ -304,31 +1107,31 @@ of the new PVF being set). Therefore, they must have the technical capacity to p
The ability to modify the Head State and/or the PVF of a para means a possibility to perform arbitrary modifications of it (i.e. take control the native parachain token or any bridged assets in the para).
This could introduce a new attack vectorm, and therefore, such great power needs to be handled carefully.
The implementation of this RFC will be tested on testnets (Rococo and Westend) first.
An audit will be required to ensure the implementation doesn't introduce unwanted side effects.
There are no privacy related concerns.
This RFC should not introduce any performance impact.
This RFC should improve the experience for new and existing parachain teams, lowering the barrier to unbrick a stalled para.
This RFC is fully compatible with existing interfaces.
WhitelistedUnbrickCaller
Unbrick
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.
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 -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.
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.
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.
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.
#![allow(unused)] -fn main() { -[ XCM message1, XCM message2, ..., EMPTY message, UMPSignal::SelectCore ] -}
#![allow(unused)] -fn main() { -/// An `u8` wrap around sequence number. Typically this would be the least significant byte of the -/// parachain block number. -pub struct CoreSelector(pub u8); - -/// An offset in the relay chain claim queue. -pub struct ClaimQueueOffset(pub u8); - -/// Signals sent by a parachain to the relay chain. -pub enum UMPSignal { - /// A message sent by a parachain to select the core the candidate is committed to. - /// Relay chain validators, in particular backers, use the `CoreSelector` and `ClaimQueueOffset` - /// to compute the index of the core the candidate has committed to. - /// - SelectCore(CoreSelector, ClaimQueueOffset), -} -}
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 fulfill the requirement.
| | 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 committed core index is Core 3 like this:
#![allow(unused)] -fn main() { -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.
Thew new primitive will look like this:
#![allow(unused)] -fn main() { -pub struct CandidateDescriptorV2<H = Hash> { - /// The ID of the para this is a candidate for. - para_id: ParaId, - /// The hash of the relay-chain block this is executed in the context of. - relay_parent: H, - /// Version field. The raw value here is not exposed, instead it is used - /// to determine the `CandidateDescriptorVersion` - version: InternalVersion, - /// The core index where the candidate is backed. - core_index: u16, - /// The session in which the candidate is backed. - session_index: SessionIndex, - /// Reserved bytes. - reserved1: [u8; 25], - /// The blake2-256 hash of the persisted validation data. This is extra data derived from - /// relay-chain state which may vary based on bitfields included before the candidate. - /// Thus it cannot be derived entirely from the relay-parent. - persisted_validation_data_hash: Hash, - /// The blake2-256 hash of the PoV. - pov_hash: Hash, - /// The root of a block's erasure encoding Merkle tree. - erasure_root: Hash, - /// Reserved bytes. - reserved2: [u8; 64], - /// Hash of the para header that is being generated by this candidate. - para_head: Hash, - /// The blake2-256 hash of the validation code bytes. - validation_code_hash: ValidationCodeHash, -} -}
In future format versions, parts of the reserved1 and reserved2 bytes can be used to include -additional information in the descriptor.
Backers must check the validity of core_index and session_index fields. -A candidate must not be backed if any of the following are true:
relay_parent
For version 2 descriptors the runtime will determine the core_index similarly to backers but -will always ignore the committed claim queue offset and use 0, as it only cares -about what candidates can be backed at current block.
As the chain advances the claims also advance to the top of the queue. The runtime will only back -a candidate if the claimed core selected by it's claim queue offset has reached the top of the queue -at the current relay chain block: current_block_num - relay_parent_num - 1 == claim_queue_offset.
current_block_num - relay_parent_num - 1 == claim_queue_offset
The impact of this change is that candidates built into the future (claim queue offset > 0) -can no longer be backed earlier even if the core is free and the core is assigned to the -parachain.
claim queue offset > 0
Introducing this additional check is required to ensure the runtime computes the core index -determinstically. For example, some collator has missed his slot and the core is now used -to back a candidate with a higher claim queue offset. The number of assigned cores can -be different at these two queue offsets and the committed core indices would be different.
There are two flavors of candidate receipts that are used in network protocols, runtime and node -implementation:
CanidateDescriptor
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.
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.
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).
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.
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.
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 is 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 + 1 of the validators are upgraded. Node implementions need to decode the new candidate descriptor once the feature is enabled otherwise they might raise disputes and get slashed.
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.
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
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. -This RFC proposes making the fee handling system simpler and more general, by doing two things:
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. -The standard should have a way to correctly deal with these implementation specific fees, that might not exist in every system that uses XCM. -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, and any other type of fee -necessary for the program to execute successfully.
#![allow(unused)] -fn main() { -PayFees { asset: 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. -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.
#![allow(unused)] -fn main() { -// Instruction that loads the holding register -BuyExecution { asset, weight_limit } -// ...rest -}
#![allow(unused)] -fn main() { -// Instruction that loads the holding register -PayFees { asset } -// ...rest -}
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.
#![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); - } -} - -}
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.
“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:
#![allow(unused)] -fn main() { -fn ext_secp256r1_ecdsa_verify_prehashed_version_1( - sig: &[u8; 64], - msg: &[u8; 32], - pub_key: &[u8; 64], -) -> bool; -}
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 +
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.
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 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 of XCM messages and the start of UMPSignal messages.
#![allow(unused)] fn main() { [ XCM message1, XCM message2, ..., EMPTY message, UMPSignal::SelectCore ] @@ -278,7 +278,7 @@ minimize breaking changes of XCM message decoding in tools like Subscan for exam UMPSignal messages #![allow(unused)] fn main() { -/// An `u8` wrap around sequence number. Typically this would be the least significant byte of the +/// An `u8` wrap-around sequence number. Typically this would be the least significant byte of the /// parachain block number. pub struct CoreSelector(pub u8); @@ -287,172 +287,165 @@ pub struct ClaimQueueOffset(pub u8); /// Signals sent by a parachain to the relay chain. pub enum UMPSignal { - /// A message sent by a parachain to select the core the candidate is committed to. - /// Relay chain validators, in particular backers, use the `CoreSelector` and `ClaimQueueOffset` - /// to compute the index of the core the candidate has committed to. - /// - SelectCore(CoreSelector, ClaimQueueOffset), + /// A message sent by a parachain to select the core the candidate is committed to. + /// Relay chain validators, in particular backers, use the `CoreSelector` and `ClaimQueueOffset` + /// to compute the index of the core the candidate has committed to. + /// + SelectCore(CoreSelector, ClaimQueueOffset), } } -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 fulfill the requirement. +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 fulfills the requirement. Example: cq_offset = 1 and 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 +offset = 0offset = 1offset = 2 +Core 1Para APara APara A +Core 2Para APara BPara A +Core 3Para BPara APara 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 committed core index is Core 3 like this: #![allow(unused)] fn main() { 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. +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. Polkadot Primitive changes New CandidateDescriptor -reclaim 32 bytes from collator: CollatorId and 64 bytes from signature: CollatorSignature -and rename to reserved1 and reserved2 fields. +reclaim 32 bytes from collator: CollatorId and 64 bytes from signature: CollatorSignature +and rename to reserved1 and reserved2 fields. take 1 bytes from reserved1 for a new version: u8 field. take 2 bytes from reserved1 for a new core_index: u16 field. take 4 bytes from reserved1 for a new session_index: u32 field. the remaining reserved1 and reserved2 fields are zeroed -Thew new primitive will look like this: +The new primitive will look like this: #![allow(unused)] fn main() { pub struct CandidateDescriptorV2<H = Hash> { - /// The ID of the para this is a candidate for. - para_id: ParaId, - /// The hash of the relay-chain block this is executed in the context of. - relay_parent: H, - /// Version field. The raw value here is not exposed, instead it is used - /// to determine the `CandidateDescriptorVersion` - version: InternalVersion, - /// The core index where the candidate is backed. - core_index: u16, - /// The session in which the candidate is backed. - session_index: SessionIndex, - /// Reserved bytes. - reserved1: [u8; 25], - /// The blake2-256 hash of the persisted validation data. This is extra data derived from - /// relay-chain state which may vary based on bitfields included before the candidate. - /// Thus it cannot be derived entirely from the relay-parent. - persisted_validation_data_hash: Hash, - /// The blake2-256 hash of the PoV. - pov_hash: Hash, - /// The root of a block's erasure encoding Merkle tree. - erasure_root: Hash, - /// Reserved bytes. - reserved2: [u8; 64], - /// Hash of the para header that is being generated by this candidate. - para_head: Hash, - /// The blake2-256 hash of the validation code bytes. - validation_code_hash: ValidationCodeHash, + /// The ID of the para this is a candidate for. + para_id: ParaId, + /// The hash of the relay-chain block this is executed in the context of. + relay_parent: H, + /// Version field. The raw value here is not exposed, instead, it is used + /// to determine the `CandidateDescriptorVersion` + version: InternalVersion, + /// The core index where the candidate is backed. + core_index: u16, + /// The session in which the candidate is backed. + session_index: SessionIndex, + /// Reserved bytes. + reserved1: [u8; 25], + /// The blake2-256 hash of the persisted validation data. This is extra data derived from + /// relay-chain state which may vary based on bitfields included before the candidate. + /// Thus it cannot be derived entirely from the relay parent. + persisted_validation_data_hash: Hash, + /// The blake2-256 hash of the PoV. + pov_hash: Hash, + /// The root of a block's erasure encoding Merkle tree. + erasure_root: Hash, + /// Reserved bytes. + reserved2: [u8; 64], + /// Hash of the para header that is being generated by this candidate. + para_head: Hash, + /// The blake2-256 hash of the validation code bytes. + validation_code_hash: ValidationCodeHash, } } -In future format versions, parts of the reserved1 and reserved2 bytes can be used to include +In future format versions, parts of the reserved1 and reserved2 bytes can be used to include additional information in the descriptor. Parachain block validation If the candidate descriptor is version 1, there are no changes. -Backers must check the validity of core_index and session_index fields. +Backers must check the validity of core_index and session_index fields. A candidate must not be backed if any of the following are true: the core_index in the descriptor does not match the core the backer is assigned to -the session_index is not equal to the session of the relay_parent in the descriptor -the core_index in the descriptor does not match the one determined by the +the session_index is not equal to the session index the candidate is backed in +the core_index in the descriptor does not match the one determined by the UMPSignal::SelectCore message On-chain backing If the candidate descriptor is version 1, there are no changes. -For version 2 descriptors the runtime will determine the core_index similarly to backers but -will always ignore the committed claim queue offset and use 0, as it only cares -about what candidates can be backed at current block. -As the chain advances the claims also advance to the top of the queue. The runtime will only back -a candidate if the claimed core selected by it's claim queue offset has reached the top of the queue -at the current relay chain block: current_block_num - relay_parent_num - 1 == claim_queue_offset. -The impact of this change is that candidates built into the future (claim queue offset > 0) -can no longer be backed earlier even if the core is free and the core is assigned to the -parachain. -Introducing this additional check is required to ensure the runtime computes the core index -determinstically. For example, some collator has missed his slot and the core is now used -to back a candidate with a higher claim queue offset. The number of assigned cores can -be different at these two queue offsets and the committed core indices would be different. +For version 2 descriptors the runtime will determine the core_index using the same inputs +as backers did off-chain. It currently stores the claim queue at the newest allowed +relay parent corresponding to the claim queue offset 0. The runtime needs to be changed to store +a claim queue snapshot at all allowed relay parents. Backwards compatibility -There are two flavors of candidate receipts that are used in network protocols, runtime and node +Two flavors of candidate receipts are used in network protocols, runtime and node implementation: -CommittedCandidateReceipt which includes the CanidateDescriptor and the CandidateCommitments -CandidateReceipt which includes the CanidateDescriptor and just a hash of the commitments +CommittedCandidateReceipt which includes the CandidateDescriptor and the CandidateCommitments +CandidateReceipt which includes the CandidateDescriptor and just a hash of the commitments -We want to support both the old and new versions in the runtime and node. The implementation must +We want to support both the old and new versions in the runtime and node, so the implementation must 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. +The version of the descriptor is detected by checking the reserved fields. +If they are not zeroed, it means it is a version 1 descriptor. Otherwise the version field +is used further to determine the version. It should be 0 for version 2 descriptors. If it is not +the descriptor has an unknown version and should be considered invalid. Drawbacks -The only drawback is that further additions to the descriptor are limited to the amount of +The only drawback is that further additions to the descriptor are limited to the amount of remaining unused space. Testing, Security, and Privacy -Standard testing (unit tests, CI zombienet tests) for functionality and mandatory security audit +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). +Backward compatibility of the implementation will be tested on testnets (Versi and Westend). There is no impact on privacy. Performance -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. +Overall performance will be improved by not checking the collator signatures in runtime and nodes. +The impact on the UMP queue and candidate receipt processing is negligible. +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 the newest relay parent +provides the best latency while picking older relay parents avoids re-orgs. Ergonomics -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 +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 +The implementation of this RFC itself must not introduce any breaking changes for the parachain runtime or collator nodes. Compatibility -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. +The proposed changes are backward 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 these +candidates. Relay chain runtime -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 is allowed to use -the new candidate receipts format. +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 support the new primitives before any collator or node is allowed +to use the new candidate receipts format. Validators 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 + 1 of the validators are upgraded. Node implementions need to decode the new candidate descriptor once the feature is enabled otherwise they might raise disputes and get slashed. -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. +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 + 1 of the validators are upgraded. Node implementations +need to decode the new candidate descriptor once the feature is enabled otherwise they might +raise disputes and get slashed. +Once the feature is 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 is required. Tooling -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 +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 Forum discussion about a new CandidateReceipt format: -https://forum.polkadot.network/t/pre-rfc-discussion-candidate-receipt-format-v2/3738 +https://forum.polkadot.network/t/pre-rfc-discussion-candidate-receipt-format-v2/3738 Unresolved Questions N/A 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 +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. +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 descriptor introduced in this RFC. diff --git a/proposed/0105-xcm-improved-fee-mechanism.html b/proposed/0105-xcm-improved-fee-mechanism.html index d13e687..8caafae 100644 --- a/proposed/0105-xcm-improved-fee-mechanism.html +++ b/proposed/0105-xcm-improved-fee-mechanism.html @@ -90,7 +90,7 @@ - IntroductionNewly ProposedRFC-0117: The Unbrick CollectiveProposedRFC-0002: Smart Contracts on the Coretime ChainRFC-0103: Introduce a CoreIndex commitment and a SessionIndex field in candidate receiptsRFC-0105: XCM improved fee mechanismRFC-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 signaturesRFC-114: Adjust Tipper Track Confirmation PeriodsApprovedRFC-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-0100: New XCM instruction: InitiateAssetsTransferRFC-0101: XCM Transact remove require_weight_at_most parameterRFC-0107: XCM Execution hintsRFC-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-0106: Remove XCM fees modeRFC-0109: Descend XCM origin instead of clearing it where possibleRFC-TODO: Stale Nomination Reward Curve + IntroductionNewly ProposedProposedRFC-0002: Smart Contracts on the Coretime ChainRFC-0103: Introduce a CoreIndex commitment and a SessionIndex field in candidate receiptsRFC-0105: XCM improved fee mechanismRFC-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 signaturesRFC-0117: The Unbrick CollectiveRFC-114: Adjust Tipper Track Confirmation PeriodsApprovedRFC-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-0100: New XCM instruction: InitiateAssetsTransferRFC-0101: XCM Transact remove require_weight_at_most parameterRFC-0107: XCM Execution hintsRFC-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-0106: Remove XCM fees modeRFC-0109: Descend XCM origin instead of clearing it where possibleRFC-TODO: Stale Nomination Reward Curve diff --git a/proposed/0111-pure-proxy-replication.html b/proposed/0111-pure-proxy-replication.html index d4b0794..9e7f4f8 100644 --- a/proposed/0111-pure-proxy-replication.html +++ b/proposed/0111-pure-proxy-replication.html @@ -90,7 +90,7 @@ - IntroductionNewly ProposedRFC-0117: The Unbrick CollectiveProposedRFC-0002: Smart Contracts on the Coretime ChainRFC-0103: Introduce a CoreIndex commitment and a SessionIndex field in candidate receiptsRFC-0105: XCM improved fee mechanismRFC-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 signaturesRFC-114: Adjust Tipper Track Confirmation PeriodsApprovedRFC-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-0100: New XCM instruction: InitiateAssetsTransferRFC-0101: XCM Transact remove require_weight_at_most parameterRFC-0107: XCM Execution hintsRFC-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-0106: Remove XCM fees modeRFC-0109: Descend XCM origin instead of clearing it where possibleRFC-TODO: Stale Nomination Reward Curve + IntroductionNewly ProposedProposedRFC-0002: Smart Contracts on the Coretime ChainRFC-0103: Introduce a CoreIndex commitment and a SessionIndex field in candidate receiptsRFC-0105: XCM improved fee mechanismRFC-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 signaturesRFC-0117: The Unbrick CollectiveRFC-114: Adjust Tipper Track Confirmation PeriodsApprovedRFC-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-0100: New XCM instruction: InitiateAssetsTransferRFC-0101: XCM Transact remove require_weight_at_most parameterRFC-0107: XCM Execution hintsRFC-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-0106: Remove XCM fees modeRFC-0109: Descend XCM origin instead of clearing it where possibleRFC-TODO: Stale Nomination Reward Curve diff --git a/proposed/0112-compress-state-response-message-in-state-sync.html b/proposed/0112-compress-state-response-message-in-state-sync.html index a25afaf..f9c8ccd 100644 --- a/proposed/0112-compress-state-response-message-in-state-sync.html +++ b/proposed/0112-compress-state-response-message-in-state-sync.html @@ -90,7 +90,7 @@ - IntroductionNewly ProposedRFC-0117: The Unbrick CollectiveProposedRFC-0002: Smart Contracts on the Coretime ChainRFC-0103: Introduce a CoreIndex commitment and a SessionIndex field in candidate receiptsRFC-0105: XCM improved fee mechanismRFC-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 signaturesRFC-114: Adjust Tipper Track Confirmation PeriodsApprovedRFC-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-0100: New XCM instruction: InitiateAssetsTransferRFC-0101: XCM Transact remove require_weight_at_most parameterRFC-0107: XCM Execution hintsRFC-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-0106: Remove XCM fees modeRFC-0109: Descend XCM origin instead of clearing it where possibleRFC-TODO: Stale Nomination Reward Curve + IntroductionNewly ProposedProposedRFC-0002: Smart Contracts on the Coretime ChainRFC-0103: Introduce a CoreIndex commitment and a SessionIndex field in candidate receiptsRFC-0105: XCM improved fee mechanismRFC-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 signaturesRFC-0117: The Unbrick CollectiveRFC-114: Adjust Tipper Track Confirmation PeriodsApprovedRFC-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-0100: New XCM instruction: InitiateAssetsTransferRFC-0101: XCM Transact remove require_weight_at_most parameterRFC-0107: XCM Execution hintsRFC-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-0106: Remove XCM fees modeRFC-0109: Descend XCM origin instead of clearing it where possibleRFC-TODO: Stale Nomination Reward Curve diff --git a/proposed/0114-secp256r1-hostfunction.html b/proposed/0114-secp256r1-hostfunction.html index bd379bf..9dfeb6c 100644 --- a/proposed/0114-secp256r1-hostfunction.html +++ b/proposed/0114-secp256r1-hostfunction.html @@ -90,7 +90,7 @@ - IntroductionNewly ProposedRFC-0117: The Unbrick CollectiveProposedRFC-0002: Smart Contracts on the Coretime ChainRFC-0103: Introduce a CoreIndex commitment and a SessionIndex field in candidate receiptsRFC-0105: XCM improved fee mechanismRFC-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 signaturesRFC-114: Adjust Tipper Track Confirmation PeriodsApprovedRFC-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-0100: New XCM instruction: InitiateAssetsTransferRFC-0101: XCM Transact remove require_weight_at_most parameterRFC-0107: XCM Execution hintsRFC-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-0106: Remove XCM fees modeRFC-0109: Descend XCM origin instead of clearing it where possibleRFC-TODO: Stale Nomination Reward Curve + IntroductionNewly ProposedProposedRFC-0002: Smart Contracts on the Coretime ChainRFC-0103: Introduce a CoreIndex commitment and a SessionIndex field in candidate receiptsRFC-0105: XCM improved fee mechanismRFC-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 signaturesRFC-0117: The Unbrick CollectiveRFC-114: Adjust Tipper Track Confirmation PeriodsApprovedRFC-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-0100: New XCM instruction: InitiateAssetsTransferRFC-0101: XCM Transact remove require_weight_at_most parameterRFC-0107: XCM Execution hintsRFC-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-0106: Remove XCM fees modeRFC-0109: Descend XCM origin instead of clearing it where possibleRFC-TODO: Stale Nomination Reward Curve @@ -260,7 +260,7 @@ Most of the modern devices and applications rely on the “secp256r1” elliptic - + @@ -274,7 +274,7 @@ Most of the modern devices and applications rely on the “secp256r1” elliptic - +
#![allow(unused)] fn main() { -/// An `u8` wrap around sequence number. Typically this would be the least significant byte of the +/// An `u8` wrap-around sequence number. Typically this would be the least significant byte of the /// parachain block number. pub struct CoreSelector(pub u8); @@ -287,172 +287,165 @@ pub struct ClaimQueueOffset(pub u8); /// Signals sent by a parachain to the relay chain. pub enum UMPSignal { - /// A message sent by a parachain to select the core the candidate is committed to. - /// Relay chain validators, in particular backers, use the `CoreSelector` and `ClaimQueueOffset` - /// to compute the index of the core the candidate has committed to. - /// - SelectCore(CoreSelector, ClaimQueueOffset), + /// A message sent by a parachain to select the core the candidate is committed to. + /// Relay chain validators, in particular backers, use the `CoreSelector` and `ClaimQueueOffset` + /// to compute the index of the core the candidate has committed to. + /// + SelectCore(CoreSelector, ClaimQueueOffset), } }
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 +
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 committed core index is Core 3 like this:
#![allow(unused)] fn main() { let committed_core_index = para_assigned_cores[core_selector % para_assigned_cores.len()]; }
#![allow(unused)] fn main() { pub struct CandidateDescriptorV2<H = Hash> { - /// The ID of the para this is a candidate for. - para_id: ParaId, - /// The hash of the relay-chain block this is executed in the context of. - relay_parent: H, - /// Version field. The raw value here is not exposed, instead it is used - /// to determine the `CandidateDescriptorVersion` - version: InternalVersion, - /// The core index where the candidate is backed. - core_index: u16, - /// The session in which the candidate is backed. - session_index: SessionIndex, - /// Reserved bytes. - reserved1: [u8; 25], - /// The blake2-256 hash of the persisted validation data. This is extra data derived from - /// relay-chain state which may vary based on bitfields included before the candidate. - /// Thus it cannot be derived entirely from the relay-parent. - persisted_validation_data_hash: Hash, - /// The blake2-256 hash of the PoV. - pov_hash: Hash, - /// The root of a block's erasure encoding Merkle tree. - erasure_root: Hash, - /// Reserved bytes. - reserved2: [u8; 64], - /// Hash of the para header that is being generated by this candidate. - para_head: Hash, - /// The blake2-256 hash of the validation code bytes. - validation_code_hash: ValidationCodeHash, + /// The ID of the para this is a candidate for. + para_id: ParaId, + /// The hash of the relay-chain block this is executed in the context of. + relay_parent: H, + /// Version field. The raw value here is not exposed, instead, it is used + /// to determine the `CandidateDescriptorVersion` + version: InternalVersion, + /// The core index where the candidate is backed. + core_index: u16, + /// The session in which the candidate is backed. + session_index: SessionIndex, + /// Reserved bytes. + reserved1: [u8; 25], + /// The blake2-256 hash of the persisted validation data. This is extra data derived from + /// relay-chain state which may vary based on bitfields included before the candidate. + /// Thus it cannot be derived entirely from the relay parent. + persisted_validation_data_hash: Hash, + /// The blake2-256 hash of the PoV. + pov_hash: Hash, + /// The root of a block's erasure encoding Merkle tree. + erasure_root: Hash, + /// Reserved bytes. + reserved2: [u8; 64], + /// Hash of the para header that is being generated by this candidate. + para_head: Hash, + /// The blake2-256 hash of the validation code bytes. + validation_code_hash: ValidationCodeHash, } }
In future format versions, parts of the reserved1 and reserved2 bytes can be used to include +
In future format versions, parts of the reserved1 and reserved2 bytes can be used to include additional information in the descriptor.
Backers must check the validity of core_index and session_index fields. +
Backers must check the validity of core_index and session_index fields. A candidate must not be backed if any of the following are true:
There are two flavors of candidate receipts that are used in network protocols, runtime and node +
Two flavors of candidate receipts are used in network protocols, runtime and node implementation:
We want to support both the old and new versions in the runtime and node. The implementation must +
We want to support both the old and new versions in the runtime and node, so the implementation must be able to detect the version of a given candidate receipt.
The only drawback is that further additions to the descriptor are limited to the amount of +
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 +
Standard testing (unit tests, CI zombienet tests) for functionality and mandatory security audit to ensure the implementation does not introduce any new security issues.
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 +
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 +
The implementation of this RFC itself must not introduce any breaking changes for the parachain runtime or collator nodes.
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 +
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.
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 +
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