diff --git a/404.html b/404.html index cf34656..8092c0f 100644 --- a/404.html +++ b/404.html @@ -91,7 +91,7 @@ diff --git a/approved/0001-agile-coretime.html b/approved/0001-agile-coretime.html index e90c1d0..7dceb96 100644 --- a/approved/0001-agile-coretime.html +++ b/approved/0001-agile-coretime.html @@ -90,7 +90,7 @@ diff --git a/approved/0005-coretime-interface.html b/approved/0005-coretime-interface.html index 6354289..a194d96 100644 --- a/approved/0005-coretime-interface.html +++ b/approved/0005-coretime-interface.html @@ -90,7 +90,7 @@ diff --git a/approved/0007-system-collator-selection.html b/approved/0007-system-collator-selection.html index ef1a1a7..64b37be 100644 --- a/approved/0007-system-collator-selection.html +++ b/approved/0007-system-collator-selection.html @@ -90,7 +90,7 @@ diff --git a/approved/0008-parachain-bootnodes-dht.html b/approved/0008-parachain-bootnodes-dht.html index fec9a55..082ffb2 100644 --- a/approved/0008-parachain-bootnodes-dht.html +++ b/approved/0008-parachain-bootnodes-dht.html @@ -90,7 +90,7 @@ diff --git a/approved/0010-burn-coretime-revenue.html b/approved/0010-burn-coretime-revenue.html index 1366ce3..0460df9 100644 --- a/approved/0010-burn-coretime-revenue.html +++ b/approved/0010-burn-coretime-revenue.html @@ -90,7 +90,7 @@ diff --git a/approved/0012-process-for-adding-new-collectives.html b/approved/0012-process-for-adding-new-collectives.html index b5602eb..b742234 100644 --- a/approved/0012-process-for-adding-new-collectives.html +++ b/approved/0012-process-for-adding-new-collectives.html @@ -90,7 +90,7 @@ diff --git a/approved/0013-prepare-blockbuilder-and-core-runtime-apis-for-mbms.html b/approved/0013-prepare-blockbuilder-and-core-runtime-apis-for-mbms.html index 071bce4..6cc13b4 100644 --- a/approved/0013-prepare-blockbuilder-and-core-runtime-apis-for-mbms.html +++ b/approved/0013-prepare-blockbuilder-and-core-runtime-apis-for-mbms.html @@ -90,7 +90,7 @@ diff --git a/approved/0014-improve-locking-mechanism-for-parachains.html b/approved/0014-improve-locking-mechanism-for-parachains.html index f26b2a1..233d10c 100644 --- a/approved/0014-improve-locking-mechanism-for-parachains.html +++ b/approved/0014-improve-locking-mechanism-for-parachains.html @@ -90,7 +90,7 @@ diff --git a/approved/0022-adopt-encointer-runtime.html b/approved/0022-adopt-encointer-runtime.html index 37f5165..3e79580 100644 --- a/approved/0022-adopt-encointer-runtime.html +++ b/approved/0022-adopt-encointer-runtime.html @@ -90,7 +90,7 @@ diff --git a/approved/0026-sassafras-consensus.html b/approved/0026-sassafras-consensus.html index 6d89397..baf730e 100644 --- a/approved/0026-sassafras-consensus.html +++ b/approved/0026-sassafras-consensus.html @@ -90,7 +90,7 @@ diff --git a/approved/0032-minimal-relay.html b/approved/0032-minimal-relay.html index 5073737..78b3fe4 100644 --- a/approved/0032-minimal-relay.html +++ b/approved/0032-minimal-relay.html @@ -90,7 +90,7 @@ diff --git a/approved/0042-extrinsics-state-version.html b/approved/0042-extrinsics-state-version.html index 8fa8088..7d332a4 100644 --- a/approved/0042-extrinsics-state-version.html +++ b/approved/0042-extrinsics-state-version.html @@ -90,7 +90,7 @@ diff --git a/approved/0043-storage-proof-size-hostfunction.html b/approved/0043-storage-proof-size-hostfunction.html index 3125454..20bf778 100644 --- a/approved/0043-storage-proof-size-hostfunction.html +++ b/approved/0043-storage-proof-size-hostfunction.html @@ -90,7 +90,7 @@ diff --git a/approved/0045-nft-deposits-asset-hub.html b/approved/0045-nft-deposits-asset-hub.html index 85c4691..a8cbc83 100644 --- a/approved/0045-nft-deposits-asset-hub.html +++ b/approved/0045-nft-deposits-asset-hub.html @@ -90,7 +90,7 @@ diff --git a/approved/0047-assignment-of-availability-chunks.html b/approved/0047-assignment-of-availability-chunks.html index d3d7b0f..946b458 100644 --- a/approved/0047-assignment-of-availability-chunks.html +++ b/approved/0047-assignment-of-availability-chunks.html @@ -90,7 +90,7 @@ diff --git a/approved/0048-session-keys-runtime-api.html b/approved/0048-session-keys-runtime-api.html index 770f3f1..e2f85ad 100644 --- a/approved/0048-session-keys-runtime-api.html +++ b/approved/0048-session-keys-runtime-api.html @@ -90,7 +90,7 @@ diff --git a/approved/0050-fellowship-salaries.html b/approved/0050-fellowship-salaries.html index 1cdbd62..7bb88bb 100644 --- a/approved/0050-fellowship-salaries.html +++ b/approved/0050-fellowship-salaries.html @@ -90,7 +90,7 @@ diff --git a/approved/0056-one-transaction-per-notification.html b/approved/0056-one-transaction-per-notification.html index fe59a5f..2d17adb 100644 --- a/approved/0056-one-transaction-per-notification.html +++ b/approved/0056-one-transaction-per-notification.html @@ -90,7 +90,7 @@ diff --git a/approved/0059-nodes-capabilities-discovery.html b/approved/0059-nodes-capabilities-discovery.html index 6799a51..2be0d15 100644 --- a/approved/0059-nodes-capabilities-discovery.html +++ b/approved/0059-nodes-capabilities-discovery.html @@ -90,7 +90,7 @@ diff --git a/approved/0078-merkleized-metadata.html b/approved/0078-merkleized-metadata.html index 17fd869..3805e1c 100644 --- a/approved/0078-merkleized-metadata.html +++ b/approved/0078-merkleized-metadata.html @@ -90,7 +90,7 @@ diff --git a/approved/0084-general-transaction-extrinsic-format.html b/approved/0084-general-transaction-extrinsic-format.html index 6f936c6..075ac7c 100644 --- a/approved/0084-general-transaction-extrinsic-format.html +++ b/approved/0084-general-transaction-extrinsic-format.html @@ -90,7 +90,7 @@ diff --git a/approved/0091-dht-record-creation-time.html b/approved/0091-dht-record-creation-time.html index 421430d..1d84a69 100644 --- a/approved/0091-dht-record-creation-time.html +++ b/approved/0091-dht-record-creation-time.html @@ -90,7 +90,7 @@ diff --git a/approved/0097-unbonding_queue.html b/approved/0097-unbonding_queue.html index 209266d..51d3ffb 100644 --- a/approved/0097-unbonding_queue.html +++ b/approved/0097-unbonding_queue.html @@ -90,7 +90,7 @@ diff --git a/approved/0099-transaction-extension-version.html b/approved/0099-transaction-extension-version.html index 691cb7b..04b6165 100644 --- a/approved/0099-transaction-extension-version.html +++ b/approved/0099-transaction-extension-version.html @@ -90,7 +90,7 @@ diff --git a/approved/0100-xcm-multi-type-asset-transfer.html b/approved/0100-xcm-multi-type-asset-transfer.html index 4364d34..cbd0da2 100644 --- a/approved/0100-xcm-multi-type-asset-transfer.html +++ b/approved/0100-xcm-multi-type-asset-transfer.html @@ -90,7 +90,7 @@ diff --git a/approved/0101-xcm-transact-remove-max-weight-param.html b/approved/0101-xcm-transact-remove-max-weight-param.html index 80bfa46..a16cb12 100644 --- a/approved/0101-xcm-transact-remove-max-weight-param.html +++ b/approved/0101-xcm-transact-remove-max-weight-param.html @@ -90,7 +90,7 @@ diff --git a/approved/0103-introduce-core-index-commitment.html b/approved/0103-introduce-core-index-commitment.html index fdd7b5f..727acf2 100644 --- a/approved/0103-introduce-core-index-commitment.html +++ b/approved/0103-introduce-core-index-commitment.html @@ -90,7 +90,7 @@ diff --git a/approved/0105-xcm-improved-fee-mechanism.html b/approved/0105-xcm-improved-fee-mechanism.html index 7e08b66..cc0497b 100644 --- a/approved/0105-xcm-improved-fee-mechanism.html +++ b/approved/0105-xcm-improved-fee-mechanism.html @@ -90,7 +90,7 @@ diff --git a/approved/0107-xcm-execution-hints.html b/approved/0107-xcm-execution-hints.html index 5f603e3..5bcd785 100644 --- a/approved/0107-xcm-execution-hints.html +++ b/approved/0107-xcm-execution-hints.html @@ -90,7 +90,7 @@ diff --git a/approved/0108-xcm-remove-testnet-ids.html b/approved/0108-xcm-remove-testnet-ids.html index dcf57e2..34e9c62 100644 --- a/approved/0108-xcm-remove-testnet-ids.html +++ b/approved/0108-xcm-remove-testnet-ids.html @@ -90,7 +90,7 @@ diff --git a/index.html b/index.html index 54bdeea..fdd2517 100644 --- a/index.html +++ b/index.html @@ -90,7 +90,7 @@ diff --git a/introduction.html b/introduction.html index 54bdeea..fdd2517 100644 --- a/introduction.html +++ b/introduction.html @@ -90,7 +90,7 @@ diff --git a/new/0000-rewards.html b/new/0000-rewards.html index 98c07d5..0232fd3 100644 --- a/new/0000-rewards.html +++ b/new/0000-rewards.html @@ -90,7 +90,7 @@ @@ -288,7 +288,29 @@ pub struct ApprovalsTallyMessage(Vec<ApprovalTallyMessageLine>);

Rewards compoutation

We compute the approvals rewards by taking the median of the approval_usages fields for each validator across all validators ApprovalsTallyMessages.

-

TODO: used_downloads from $\beta'$ below.

+
let mut approval_usages_medians = Vec::new(); 
+for i in 0..num_validators {
+    let mut v: Vec<u32> = approvals_tally_messages.iter().map(|atm| atm.0[i].approval_usages);
+    v.sort();
+    approval_usages_medians.push(v[num_validators/2]);
+}
+
+

Assuming more than 50% honersty, these median tell us how many approval votes form each validator

+

We re-weight the used_downloads from the ith validator by their median times their expected f+1 chunks and divided by how many chunks downloads they claimed, and sum them

+
#[cfg(offchain)]
+let mut my_missing_uploads = my_approvals_tally.iter().map(|l| l.used_uploads).collect();
+let mut reweighted_total_used_downloads = vec[0u64; num_validators];
+for (mmu,atm) in my_missing_uploads.iter_mut().zip(approvals_tally_messages) {
+    let d = atm.0.iter().map(|l| l.used_downloads).sum();
+    for i in 0..num_validators {
+        let atm_from_i = approval_usages_medians[i] * (f+1) / d;
+        #[cfg(offchain)]
+        if i == me { mmu -= atm_from_i };
+        reweighted_total_used_downloads[i] += atm_from_i;
+    }
+}
+
+

We distribute rewards on-chain using approval_usages_medians and reweighted_total_used_downloads. Approval checkers could later change from who they download chunks using my_missing_uploads.

Strategies

In theory, validators could adopt whatever strategy they like to penalize validators who stiff them on availability redistribution rewards, except they should not stiff back, only choose other availability providers. We discuss one good strategy below, but initially this could go unimplemented.

Explanation

@@ -367,7 +389,7 @@ At this point, we compute $\beta\prime_w = \sum_v \beta\prime_{w,v}$ on-chain fo - @@ -381,7 +403,7 @@ At this point, we compute $\beta\prime_w = \sum_v \beta\prime_{w,v}$ on-chain fo - diff --git a/new/0120-referenda-confirmation-by-candle-mechanism.html b/new/0120-referenda-confirmation-by-candle-mechanism.html new file mode 100644 index 0000000..658f2ec --- /dev/null +++ b/new/0120-referenda-confirmation-by-candle-mechanism.html @@ -0,0 +1,408 @@ + + + + + + + RFC-0120: Referenda Confirmation by Candle Mechanism - Polkadot Fellowship RFCs + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ + + + + + + + + + + + + + + + + + + +
+ +
+ + + + + + + + +
+
+

(source)

+

Table of Contents

+ +

RFC-0120: Referenda Confirmation by Candle Mechanism

+
+ + + +
Start Date22 March 2024
DescriptionProposal to decide polls after confirm period via a mechanism similar to a candle auction
AuthorsPablo Dorado, Daniel Olano
+
+

Summary

+

In an attempt to mitigate risks derived from unwanted behaviours around long ongoing periods on +referenda, this proposal describes how to finalize and decide a result of a poll via a +mechanism similar to candle auctions.

+

Motivation

+

Referenda protocol provide permissionless and efficient mechanisms to enable governance actors to +decide the future of the blockchains around Polkadot network. However, they pose a series of risks +derived from the game theory perspective around these mechanisms. One of them being where an actor +uses the the public nature of the tally of a poll as a way of determining the best point in time to +alter a poll in a meaningful way.

+

While this behaviour is expected based on the current design of the referenda logic, given the +recent extension of ongoing times (up to 1 month), the incentives for a bad actor to cause losses +on a proposer, reflected as wasted cost of opportunity increase, and thus, this otherwise +reasonable outcome becomes an attack vector, a potential risk to mitigate, especially when such +attack can compromise critical guarantees of the protocol (such as its upgradeability).

+

To mitigate this, the referenda underlying mechanisms should incentive actors to cast their votes +on a poll as early as possible. This proposal's approach suggests using a Candle Auction that will +be determined right after the confirm period finishes, thus decreasing the chances of actors to +alter the results of a poll on confirming state, and instead incentivizing them to cast their votes +earlier, on deciding state.

+

Stakeholders

+
    +
  • Governance actors: Tokenholders and Collectives that vote on polls that have this mechanism +enabled should be aware this change affects the outcome of failing a poll on its confirm period.
    • +
  • Runtime Developers: This change requires runtime developers to change configuration +parameters for the Referenda Pallet.
    • +
  • Tooling and UI developers: Applications that interact with referenda must update to reflect +the new Finalizing state.
    • +
+

Explanation

+

Currently, the process of a referendum/poll is defined as an sequence between an ongoing state +(where accounts can vote), comprised by a with a preparation period, a decision period, and a +confirm period. If the poll is passing before the decision period ends, it's possible to push +forward to confirm period, and still, go back in case the poll fails. Once the decision period +ends, a failure of the poll in the confirm period will lead to the poll to ultimately be rejected.

+
stateDiagram-v2
+    sb: Submission
+    pp: Preparation Period
+    dp: Decision Period
+    cp: Confirmation Period
+    state dpd <<choice>>
+    state ps <<choice>>
+    cf: Approved
+    rj: Rejected
+
+    [*] --> sb
+    sb --> pp
+    pp --> dp: decision period starts
+    dp --> cp: poll is passing
+    dp --> ps: decision period ends
+    ps --> cp: poll is passing
+    cp --> dpd: poll fails
+    dpd --> dp: decision period not deadlined
+    ps --> rj: poll is failing
+    dpd --> rj: decision period deadlined
+    cp --> cf
+    cf --> [*]
+    rj --> [*]
+
+

This specification proposes three changes to implement this candle mechanism:

+
    +
  1. +

    This mechanism MUST be enabled via a configuration parameter. Once enabled, the referenda system +MAY record the next poll ID from which to start enabling this mechanism. This is to preserve +backwards compatibility with currently ongoing polls.

    +
    2. +
  2. +

    A record of the poll status (whether it is passing or not) is stored once the decision period is +finished.

    +
    3. +
  3. +

    Including a Finalization period as part of the ongoing state. From this point, the poll MUST +be immutable at this point.

    +

    This period begins the moment after confirm period ends, and extends the decision for a couple +of blocks, until the VRF seed used to determine the candle block can be considered +"good enough". This is, not known before the ongoing period (decision/confirmation) was over.

    +

    Once that happens, a random block within the confirm period is chosen, and the decision of +approving or rejecting the poll is based on the status immediately before the block where the +candle was "lit-off".

    +
    4. +
+

When enabled, the state diagram for the referenda system is the following:

+
stateDiagram-v2
+    sb: Submission
+    pp: Preparation Period
+    dp: Decision Period
+    cp: Confirmation Period
+    cds: Finalization
+    state dpd <<choice>>
+    state ps <<choice>>
+    state cd <<choice>>
+    cf: Approved
+    rj: Rejected
+
+    [*] --> sb
+    sb --> pp
+    pp --> dp: decision period starts
+    dp --> cp: poll is passing
+    ps --> cp: poll is passing
+    dp --> ps: decision period ends
+    ps --> rj: poll is failing
+    cp --> dpd: poll fails
+    dpd --> cp: decision period over
+    dpd --> dp: decision period not over
+    cp --> cds: confirmation period ends
+    cds --> cd: define moment when candle lit-off
+    cd --> cf: poll passed
+    cd --> rj: poll failed
+    cf --> [*]
+    rj --> [*]
+
+

Drawbacks

+

This approach doesn't include a mechanism to determine whether a change of the poll status in the +confirming period is due to a legitimate change of mind of the voters, or an exploitation of its +aforementioned vulnerabilities (like a sniping attack), instead treating all of them as potential +attacks.

+

This is an issue that can be addressed by additional mechanisms, and heuristics that can help +determine the probability of a change of poll status to happen as a result of a legitimate behaviour.

+

Testing, Security, and Privacy

+

The implementation of this RFC will be tested on testnets (Paseo and Westend) first. Furthermore, it +should be enabled in a canary network (like Kusama) to ensure the behaviours it is trying to address +is indeed avoided.

+

An audit will be required to ensure the implementation doesn't introduce unwanted side effects.

+

There are no privacy related concerns.

+

Performance, Ergonomics, and Compatibility

+

Performance

+

The added steps imply pessimization, necessary to meet the expected changes. An implementation MUST +exit from the Finalization period as early as possible to minimize this impact.

+

Ergonomics

+

This proposal does not alter the already exposed interfaces or developers or end users. However, they +must be aware of the changes in the additional overhead the new period might incur (these depend on the +implemented VRF).

+

Compatibility

+

This proposal does not break compatibility with existing interfaces, older versions, but it alters the +previous implementation of the referendum processing algorithm.

+

An acceptable upgrade strategy that can be applied is defining a point in time (block number, poll index) +from which to start applying the new mechanism, thus, not affecting the already ongoing referenda.

+

Prior Art and References

+ +

Unresolved Questions

+
    +
  • How to determine in a statistically meaningful way that a change in the poll status corresponds to an +organic behaviour, and not an unwanted, malicious behaviour?
    • +
+ +

A proposed implementation of this change can be seen on this Pull Request.

+ +
+ + +
+
+ + + +
+ + + + + + + + + + + + + + + + + + +
+ + diff --git a/new/0121-iterable-referenda-tracks.html b/new/0121-iterable-referenda-tracks.html new file mode 100644 index 0000000..0daac3b --- /dev/null +++ b/new/0121-iterable-referenda-tracks.html @@ -0,0 +1,338 @@ + + + + + + + RFC-0121: Iterable Referenda Tracks - Polkadot Fellowship RFCs + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ + + + + + + + + + + + + + + + + + + +
+ +
+ + + + + + + + +
+
+

(source)

+

Table of Contents

+ +

RFC-0121: Iterable Referenda Tracks

+
+ + + +
Start Date17 September 2024
DescriptionAllow dynamic modifications of referenda tracks at runtime without the need for a full runtime upgrade.
AuthorsPablo Dorado, Daniel Olano
+
+

Summary

+

The protocol change introduces flexibility in the governance structure by enabling the referenda +track list to be modified dynamically at runtime. This is achieved by replacing static slices in +TracksInfo with iterators, facilitating storage-based track management. As a result, governance +tracks can be modified or added based on real-time decisions and without requiring runtime upgrades.

+

Motivation

+

Polkadot's governance system is designed to be adaptive and decentralized, but modifying the +referenda tracks (which determine decision-making paths for proposals) has historically required +runtime upgrades. This poses an operational challenge, delaying governance changes until an upgrade +is scheduled and executed. The new system provides the flexibility needed to adjust tracks +dynamically, reflecting real-time changes in governance needs without the latency and risks +associated with runtime upgrades. This reduces governance bottlenecks and allows for quicker +adaptation to emergent scenarios.

+

Stakeholders

+
    +
  • Network stakeholders: the change means reduced coordination effort for track adjustments.
    • +
  • Governance participants: this enables more responsive decision-making pathways.
    • +
+

Explanation

+

The protocol modification replaces the current static slice method used for storing referenda tracks +with an iterator-based approach that allows tracks to be managed dynamically using chain storage. +Governance participants can define and modify referenda tracks as needed, which are then accessed +through runtime rather than being hardcoded in the protocol. This system ensures that tracks are +adjustable at any time, reducing upgrade-related complexities and introducing agility in how +governance tracks are applied. This modification does not disrupt existing governance mechanisms but +rather enhances them by increasing adaptability.

+

In terms of technical structure, TracksInfo::tracks will now return iterators, making it possible +to alter track configurations based on storage data rather than static definitions. This opens up +possibilities for new track types and governance configurations to be deployed without the need for +upgrades that might take up weeks.

+

Drawbacks

+

The most significant drawback is the increased complexity for developers managing track configurations +via storage-based iterators, which require careful handling to avoid misuse or inefficiencies.

+

Additionally, this flexibility could introduce risks if track configurations are modified improperly +during runtime, potentially leading to governance instabilities.

+

Testing, Security, and Privacy

+

To ensure security, the change must be tested in testnet environments first (Paseo, Westend), +particularly in scenarios where multiple track changes happen concurrently. Potential +vulnerabilities in governance adjustments must be addressed to prevent abuse.

+

The proposal doesn't introduce privacy risks but increases the need for ensuring that any runtime +changes do not inadvertently lead to insecure governance structures.

+

Comprehensive tests should be conducted to validate correct track modifications in different +governance scenarios.

+

Performance, Ergonomics, and Compatibility

+

Performance

+

The proposal optimizes governance track management by avoiding the overhead of runtime upgrades, +reducing downtime, and eliminating the need for full consensus on upgrades. However, there is a +slight performance cost related to runtime access to storage-based iterators, though this is +mitigated by the overall system efficiency gains.

+

Ergonomics

+

Developers and governance actors benefit from simplified governance processes but must account for +the technical complexity of managing iterator-based track configurations.

+

Tools may need to be developed to help streamline track adjustments in runtime.

+

Compatibility

+

The change is backward compatible with existing governance operations, and does not require developers +to adjust how they interact with referenda tracks.

+

A migration is required to convert existing statically-defined tracks to dynamic storage-based +configurations without disruption.

+

Prior Art and References

+

This dynamic governance track approach builds on previous work around Polkadot's on-chain governance +and leverages standard iterator patterns in Rust programming to improve runtime flexibility. +Comparable solutions in other governance networks were examined, but this proposal uniquely tailors +them to Polkadot’s decentralized, runtime-upgradable architecture.

+

Unresolved Questions

+
    +
  • How to handle governance transitions for currently ongoing referenda when changing configuration +parameters of an existing track? Ideally, most tracks should not have to go through this change, +but some tactics might be applied (like a proposal that reduces the ongoing queue before a major +change and then executes the change, after a reasonable period of time has elapsed and no ongoing +referenda exists for that track).
    • +
+ +

There are already two proposed solutions for both the implementation and

+
    +
  • This Pull Request proposes changing pallet-referenda's TracksInfo to make tracks +return an iterator.
    • +
  • There is already a proposed implementation of pallet-referenda-tracks, which +stores the configurations, and implements TracksInfo using the iterator approach.
    • +
+ +
+ + +
+
+ + + +
+ + + + + + + + + + + + + + + + + + +
+ + diff --git a/new/0122-alias-origin-on-asset-transfers.html b/new/0122-alias-origin-on-asset-transfers.html new file mode 100644 index 0000000..492d358 --- /dev/null +++ b/new/0122-alias-origin-on-asset-transfers.html @@ -0,0 +1,354 @@ + + + + + + + RFC-0122: Asset transfers can alias XCM origin on destination to original origin - Polkadot Fellowship RFCs + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ + + + + + + + + + + + + + + + + + + +
+ +
+ + + + + + + + +
+
+

(source)

+

Table of Contents

+ +

RFC-0122: Asset transfers can alias XCM origin on destination to original origin

+
+ + + +
Start Date01 Sep 2024.
DescriptionSingle and Multi-hop asset transfers should be able to carry over original origin
AuthorsAdrian Catangiu
+
+

Summary

+

XCM programs generated by the InitiateAssetTransfer instruction shall have the option to carry over the original origin all the way to the final destination. They shall do so by internally making use of AliasOrigin or ClearOrigin depending on given parameters.

+

This allows asset transfers to retain their original origin even across multiple hops.

+

Ecosystem chains would have to change their trusted aliasing rules to effectively make use of this feature.

+

Motivation

+

Currently, all XCM asset transfer instructions ultimately clear the origin in the remote XCM message by use of the ClearOrigin instruction. This is done for security considerations to ensure that subsequent (user-controlled) instructions cannot command the authority of the sending chain.

+

The problem with this approach is that it limits what can be achieved on remote chains through XCM. Most XCM operations require having an origin, and following any asset transfer the origin is lost, meaning not much can be done other than depositing the transferred assets to some local account or transferring them onward to another chain.

+

For example, we cannot transfer some funds for buying execution, then do a Transact (all in the same XCM message).

+

The above example is a basic, core building block for cross-chain interactions and we should support it.

+

Transact XCM programs today require a two step process:

+Transact Today +

And we want to be able to do it using a single XCM program.

+

Stakeholders

+

Runtime Users, Runtime Devs, wallets, cross-chain dApps.

+

Explanation

+

In the case of XCM programs going from source-chain directly to dest-chain without an intermediary hop, we can enable scenarios such as above by using the AliasOrigin instruction instead of the ClearOrigin instruction.

+

Instead of clearing the source-chain origin, the destination chain shall attempt to alias source-chain to "original origin" on the source chain. +Most common such origin aliasing would be X1(Parachain(source-chain)) -> X2(Parachain(source-chain), AccountId32(origin-account)) for the case of a single hop transfer where the initiator is a (signed/pure/proxy) account origin-account on source-chain.

+

This allows an actor on chain A to Transact on chain B without having to prefund its SA account on chain B, instead they can simply transfer the required fees in the same XCM program as the Transact.

+

As long as the asset transfer has the same XCM route/hops as the rest of the program, this pattern of usage can be composed across multiple hops, to ultimately Transact on the final hop using the original origin on the source chain, effectively abstracting away any intermediary hops.

+

Trust assumptions

+

The model described above makes some aliasing trust assumptions, the most important being how the root location of the intermediate hop/chain has to be trusted to alias ("impersonate") other locations from the source chain.

+

The origin aliasing trust relationship is highly customizeable at the runtime level, so that parachains can define coarse filters or granular pairs of (source, target) locations aliasing.

+

Even so, this RFC aims to also propose a standard set of aliasing rules that all Parachains can integrate for allowing the vast majority of Transact usecases in a "one-click" manner (single XCM), without practically lowering their security posture.

+

Standard Aliasing Rules:

+
    +
  1. Any chain allows aliasing into a child location. Equivalent to DescendOrigin into an interior location.
    2. +
  2. Parachains allow Asset Hub root location to alias into any other origin.
    3. +
+

Now, the second rule as defined above in its most generic form might seem "dangerous" at first, but in practical terms if Asset Hub Root gets compromised and can access arbitrary sovereign accounts on Asset Hub and/or send arbitrary XCMs, the blast radius and potential damage to other parachains are not relevantly impacted by this aliasing rule.

+

This second rule can also be tightened by each parachain to their own liking, for example limit Asset Hub aliasing to a stricter range of locations:

+
    +
  • "allow Asset Hub root to alias Ethereum locations" - which enables support for Transact over the Ethereum Snowbridge (but doesn't support sibling parachain to Transact through Asset Hub)
    • +
+

XCM InitiateAssetsTransfer instruction changes

+

A new parameter preserve_origin to be added to the InitiateAssetsTransfer XCM instruction that specifies if the original origin should be preserved or cleared.

+
InitiateAssetsTransfer {
+	destination: Location,
+	assets: Vec<AssetTransferFilter>,
+	remote_fees: Option<AssetTransferFilter>,
++	preserve_origin: bool,
+	remote_xcm: Xcm<()>,
+}
+
+

This parameter is explicitly necessary because the instruction should be usable between any two chains regardless of their origin-aliasing trust relationship. Preserving the origin requires some level of trust, while clearing it works regardless of that relationship. +Specifying preserve_origin: false will always work regardless of the configured alias filters of the +involved chains.

+

Example scenarios

+

Transact within the ecosytem:

+
    +
  • between two chains using an asset native to either one of them for paying for Transact,
    • +
  • between two chains using an Asset Hub asset (e.g. USDT) for paying for Transact,
    • +
+Ecosystem Transact +

Transact over Snowbridge (same for other bridges):

+
    +
  • user on Ethereum calls function in Parachain A on Polkadot, pays with ETH,
    • +
  • user on ParaA on Polkdaot calls function on Ethereum, pays with ETH,
    • +
+Transact Over Bridge +

Drawbacks

+

In terms of ergonomics and user experience, this support for combining an asset transfer with a subsequent action (like Transact) is a net possitive.

+

In terms off performance, and privacy, this is neutral with no changes.

+

In terms of security, the feature by itself is also neutral because it allows preserve_origin: false usage for operating with no extra trust assumptions. When wanting to support preserving origin, chains need to configure secure origin aliasing filters. The "standard" one provided in this RFC will be the right choice for the majority of chains, but for others it will not be depending on their business model and logic (e.g. chain does not plan to integrate with Asset Hub). It is up to the individual chains to configure accordingly.

+

Testing, Security, and Privacy

+

Barriers should now allow AliasOrigin or ClearOrigin.

+

Normally, XCM program builders should audit their programs and eliminate assumptions of "no origin" on remote side of this instruction. In this case, the InitiateAssetsTransfer has not been released yet, it will be part of XCMv5, and we can make this change part of the same XCMv5 so that there isn't even the possibility of someone in the wild having built XCM programs using this instruction on those wrong assumptions.

+

The working assumption going forward is that the origin on the remote side can either be cleared or it can be the local origin's reanchored location. This assumption is in line with the current behavior of remote XCM programs sent over using pallet_xcm::send.

+

The existing DepositReserveAsset, InitiateReserveWithdraw and InitiateTeleport cross chain asset transfer instructions will not attempt to do origin aliasing and will always clear origin same as before for compatibility reasons.

+

Performance, Ergonomics, and Compatibility

+

Performance

+

No impact.

+

Ergonomics

+

Improves ergonomics by allowing the local origin to operate on the remote chain even when the XCM program includes an asset transfer.

+

Compatibility

+

At the executor-level this change is backwards and forwards compatible. Both types of programs can be executed on new and old versions of XCM with no changes in behavior.

+

New version of the InitiateAssetsTransfer instruction acts same as before when used with preserve_origin: false.

+

For using the new capabilities, the XCM builder has to verify that the involved chains have the required origin-aliasing filters configured and use some new version of Barriers aware of AliasOrigin as an allowed alternative to ClearOrigin.

+

For compatibility reasons, this RFC proposes this mechanism be added as an enhancement to the yet unreleased InitiateAssetsTransfer instruction, thus eliminating possibilities of XCM logic breakages in the wild. +Following the same logic, the existing DepositReserveAsset, InitiateReserveWithdraw and InitiateTeleport cross chain asset transfer instructions will not attempt to do origin aliasing and will always clear the origin same as before for compatibility reasons.

+

Any one of DepositReserveAsset, InitiateReserveWithdraw and InitiateTeleport instructions can be replaced with a InitiateAssetsTransfer instruction with or without origin aliasing, thus providing a clean and clear upgrade path for opting-in this new feature.

+

Prior Art and References

+ +

Unresolved Questions

+

None

+ + +
+ + +
+
+ + + +
+ + + + + + + + + + + + + + + + + + +
+ + diff --git a/print.html b/print.html index 89d7628..962c9da 100644 --- a/print.html +++ b/print.html @@ -91,7 +91,7 @@ @@ -294,7 +294,29 @@ pub struct ApprovalsTallyMessage(Vec<ApprovalTallyMessageLine>);

Rewards compoutation

We compute the approvals rewards by taking the median of the approval_usages fields for each validator across all validators ApprovalsTallyMessages.

-

TODO: used_downloads from $\beta'$ below.

+
let mut approval_usages_medians = Vec::new(); 
+for i in 0..num_validators {
+    let mut v: Vec<u32> = approvals_tally_messages.iter().map(|atm| atm.0[i].approval_usages);
+    v.sort();
+    approval_usages_medians.push(v[num_validators/2]);
+}
+
+

Assuming more than 50% honersty, these median tell us how many approval votes form each validator

+

We re-weight the used_downloads from the ith validator by their median times their expected f+1 chunks and divided by how many chunks downloads they claimed, and sum them

+
#[cfg(offchain)]
+let mut my_missing_uploads = my_approvals_tally.iter().map(|l| l.used_uploads).collect();
+let mut reweighted_total_used_downloads = vec[0u64; num_validators];
+for (mmu,atm) in my_missing_uploads.iter_mut().zip(approvals_tally_messages) {
+    let d = atm.0.iter().map(|l| l.used_downloads).sum();
+    for i in 0..num_validators {
+        let atm_from_i = approval_usages_medians[i] * (f+1) / d;
+        #[cfg(offchain)]
+        if i == me { mmu -= atm_from_i };
+        reweighted_total_used_downloads[i] += atm_from_i;
+    }
+}
+
+

We distribute rewards on-chain using approval_usages_medians and reweighted_total_used_downloads. Approval checkers could later change from who they download chunks using my_missing_uploads.

Strategies

In theory, validators could adopt whatever strategy they like to penalize validators who stiff them on availability redistribution rewards, except they should not stiff back, only choose other availability providers. We discuss one good strategy below, but initially this could go unimplemented.

Explanation

@@ -364,6 +386,422 @@ At this point, we compute $\beta\prime_w = \sum_v \beta\prime_{w,v}$ on-chain fo

Synthetic parachain flag

Any rewards protocol could simply be "out voted" by too many slow validators: An increase the number of parachain cores increases more workload, but this creates no-shows if too few validators could handle this workload.

We could add a synthetic parachain flag, only settable by governance, which treats no-shows as positive approval votes for that parachain, but without adding rewards. We should never enable this for real parachains, only for synthetic ones like gluttons. We should not enable the synthetic parachain flag long-term even for gluttonsm, because validators could easily modify their code. Yet, synthetic approval checks might enable pushing the hardware upgrades more agressively over the short-term.

+

(source)

+

Table of Contents

+ +

RFC-0120: Referenda Confirmation by Candle Mechanism

+
+ + + +
Start Date22 March 2024
DescriptionProposal to decide polls after confirm period via a mechanism similar to a candle auction
AuthorsPablo Dorado, Daniel Olano
+
+

Summary

+

In an attempt to mitigate risks derived from unwanted behaviours around long ongoing periods on +referenda, this proposal describes how to finalize and decide a result of a poll via a +mechanism similar to candle auctions.

+

Motivation

+

Referenda protocol provide permissionless and efficient mechanisms to enable governance actors to +decide the future of the blockchains around Polkadot network. However, they pose a series of risks +derived from the game theory perspective around these mechanisms. One of them being where an actor +uses the the public nature of the tally of a poll as a way of determining the best point in time to +alter a poll in a meaningful way.

+

While this behaviour is expected based on the current design of the referenda logic, given the +recent extension of ongoing times (up to 1 month), the incentives for a bad actor to cause losses +on a proposer, reflected as wasted cost of opportunity increase, and thus, this otherwise +reasonable outcome becomes an attack vector, a potential risk to mitigate, especially when such +attack can compromise critical guarantees of the protocol (such as its upgradeability).

+

To mitigate this, the referenda underlying mechanisms should incentive actors to cast their votes +on a poll as early as possible. This proposal's approach suggests using a Candle Auction that will +be determined right after the confirm period finishes, thus decreasing the chances of actors to +alter the results of a poll on confirming state, and instead incentivizing them to cast their votes +earlier, on deciding state.

+

Stakeholders

+ +

Explanation

+

Currently, the process of a referendum/poll is defined as an sequence between an ongoing state +(where accounts can vote), comprised by a with a preparation period, a decision period, and a +confirm period. If the poll is passing before the decision period ends, it's possible to push +forward to confirm period, and still, go back in case the poll fails. Once the decision period +ends, a failure of the poll in the confirm period will lead to the poll to ultimately be rejected.

+
stateDiagram-v2
+    sb: Submission
+    pp: Preparation Period
+    dp: Decision Period
+    cp: Confirmation Period
+    state dpd <<choice>>
+    state ps <<choice>>
+    cf: Approved
+    rj: Rejected
+
+    [*] --> sb
+    sb --> pp
+    pp --> dp: decision period starts
+    dp --> cp: poll is passing
+    dp --> ps: decision period ends
+    ps --> cp: poll is passing
+    cp --> dpd: poll fails
+    dpd --> dp: decision period not deadlined
+    ps --> rj: poll is failing
+    dpd --> rj: decision period deadlined
+    cp --> cf
+    cf --> [*]
+    rj --> [*]
+
+

This specification proposes three changes to implement this candle mechanism:

+
    +
  1. +

    This mechanism MUST be enabled via a configuration parameter. Once enabled, the referenda system +MAY record the next poll ID from which to start enabling this mechanism. This is to preserve +backwards compatibility with currently ongoing polls.

    +
    2. +
  2. +

    A record of the poll status (whether it is passing or not) is stored once the decision period is +finished.

    +
    3. +
  3. +

    Including a Finalization period as part of the ongoing state. From this point, the poll MUST +be immutable at this point.

    +

    This period begins the moment after confirm period ends, and extends the decision for a couple +of blocks, until the VRF seed used to determine the candle block can be considered +"good enough". This is, not known before the ongoing period (decision/confirmation) was over.

    +

    Once that happens, a random block within the confirm period is chosen, and the decision of +approving or rejecting the poll is based on the status immediately before the block where the +candle was "lit-off".

    +
    4. +
+

When enabled, the state diagram for the referenda system is the following:

+
stateDiagram-v2
+    sb: Submission
+    pp: Preparation Period
+    dp: Decision Period
+    cp: Confirmation Period
+    cds: Finalization
+    state dpd <<choice>>
+    state ps <<choice>>
+    state cd <<choice>>
+    cf: Approved
+    rj: Rejected
+
+    [*] --> sb
+    sb --> pp
+    pp --> dp: decision period starts
+    dp --> cp: poll is passing
+    ps --> cp: poll is passing
+    dp --> ps: decision period ends
+    ps --> rj: poll is failing
+    cp --> dpd: poll fails
+    dpd --> cp: decision period over
+    dpd --> dp: decision period not over
+    cp --> cds: confirmation period ends
+    cds --> cd: define moment when candle lit-off
+    cd --> cf: poll passed
+    cd --> rj: poll failed
+    cf --> [*]
+    rj --> [*]
+
+

Drawbacks

+

This approach doesn't include a mechanism to determine whether a change of the poll status in the +confirming period is due to a legitimate change of mind of the voters, or an exploitation of its +aforementioned vulnerabilities (like a sniping attack), instead treating all of them as potential +attacks.

+

This is an issue that can be addressed by additional mechanisms, and heuristics that can help +determine the probability of a change of poll status to happen as a result of a legitimate behaviour.

+

Testing, Security, and Privacy

+

The implementation of this RFC will be tested on testnets (Paseo and Westend) first. Furthermore, it +should be enabled in a canary network (like Kusama) to ensure the behaviours it is trying to address +is indeed avoided.

+

An audit will be required to ensure the implementation doesn't introduce unwanted side effects.

+

There are no privacy related concerns.

+

Performance, Ergonomics, and Compatibility

+

Performance

+

The added steps imply pessimization, necessary to meet the expected changes. An implementation MUST +exit from the Finalization period as early as possible to minimize this impact.

+

Ergonomics

+

This proposal does not alter the already exposed interfaces or developers or end users. However, they +must be aware of the changes in the additional overhead the new period might incur (these depend on the +implemented VRF).

+

Compatibility

+

This proposal does not break compatibility with existing interfaces, older versions, but it alters the +previous implementation of the referendum processing algorithm.

+

An acceptable upgrade strategy that can be applied is defining a point in time (block number, poll index) +from which to start applying the new mechanism, thus, not affecting the already ongoing referenda.

+

Prior Art and References

+ +

Unresolved Questions

+ + +

A proposed implementation of this change can be seen on this Pull Request.

+

(source)

+

Table of Contents

+ +

RFC-0121: Iterable Referenda Tracks

+
+ + + +
Start Date17 September 2024
DescriptionAllow dynamic modifications of referenda tracks at runtime without the need for a full runtime upgrade.
AuthorsPablo Dorado, Daniel Olano
+
+

Summary

+

The protocol change introduces flexibility in the governance structure by enabling the referenda +track list to be modified dynamically at runtime. This is achieved by replacing static slices in +TracksInfo with iterators, facilitating storage-based track management. As a result, governance +tracks can be modified or added based on real-time decisions and without requiring runtime upgrades.

+

Motivation

+

Polkadot's governance system is designed to be adaptive and decentralized, but modifying the +referenda tracks (which determine decision-making paths for proposals) has historically required +runtime upgrades. This poses an operational challenge, delaying governance changes until an upgrade +is scheduled and executed. The new system provides the flexibility needed to adjust tracks +dynamically, reflecting real-time changes in governance needs without the latency and risks +associated with runtime upgrades. This reduces governance bottlenecks and allows for quicker +adaptation to emergent scenarios.

+

Stakeholders

+ +

Explanation

+

The protocol modification replaces the current static slice method used for storing referenda tracks +with an iterator-based approach that allows tracks to be managed dynamically using chain storage. +Governance participants can define and modify referenda tracks as needed, which are then accessed +through runtime rather than being hardcoded in the protocol. This system ensures that tracks are +adjustable at any time, reducing upgrade-related complexities and introducing agility in how +governance tracks are applied. This modification does not disrupt existing governance mechanisms but +rather enhances them by increasing adaptability.

+

In terms of technical structure, TracksInfo::tracks will now return iterators, making it possible +to alter track configurations based on storage data rather than static definitions. This opens up +possibilities for new track types and governance configurations to be deployed without the need for +upgrades that might take up weeks.

+

Drawbacks

+

The most significant drawback is the increased complexity for developers managing track configurations +via storage-based iterators, which require careful handling to avoid misuse or inefficiencies.

+

Additionally, this flexibility could introduce risks if track configurations are modified improperly +during runtime, potentially leading to governance instabilities.

+

Testing, Security, and Privacy

+

To ensure security, the change must be tested in testnet environments first (Paseo, Westend), +particularly in scenarios where multiple track changes happen concurrently. Potential +vulnerabilities in governance adjustments must be addressed to prevent abuse.

+

The proposal doesn't introduce privacy risks but increases the need for ensuring that any runtime +changes do not inadvertently lead to insecure governance structures.

+

Comprehensive tests should be conducted to validate correct track modifications in different +governance scenarios.

+

Performance, Ergonomics, and Compatibility

+

Performance

+

The proposal optimizes governance track management by avoiding the overhead of runtime upgrades, +reducing downtime, and eliminating the need for full consensus on upgrades. However, there is a +slight performance cost related to runtime access to storage-based iterators, though this is +mitigated by the overall system efficiency gains.

+

Ergonomics

+

Developers and governance actors benefit from simplified governance processes but must account for +the technical complexity of managing iterator-based track configurations.

+

Tools may need to be developed to help streamline track adjustments in runtime.

+

Compatibility

+

The change is backward compatible with existing governance operations, and does not require developers +to adjust how they interact with referenda tracks.

+

A migration is required to convert existing statically-defined tracks to dynamic storage-based +configurations without disruption.

+

Prior Art and References

+

This dynamic governance track approach builds on previous work around Polkadot's on-chain governance +and leverages standard iterator patterns in Rust programming to improve runtime flexibility. +Comparable solutions in other governance networks were examined, but this proposal uniquely tailors +them to Polkadot’s decentralized, runtime-upgradable architecture.

+

Unresolved Questions

+ + +

There are already two proposed solutions for both the implementation and

+ +

(source)

+

Table of Contents

+ +

RFC-0122: Asset transfers can alias XCM origin on destination to original origin

+
+ + + +
Start Date01 Sep 2024.
DescriptionSingle and Multi-hop asset transfers should be able to carry over original origin
AuthorsAdrian Catangiu
+
+

Summary

+

XCM programs generated by the InitiateAssetTransfer instruction shall have the option to carry over the original origin all the way to the final destination. They shall do so by internally making use of AliasOrigin or ClearOrigin depending on given parameters.

+

This allows asset transfers to retain their original origin even across multiple hops.

+

Ecosystem chains would have to change their trusted aliasing rules to effectively make use of this feature.

+

Motivation

+

Currently, all XCM asset transfer instructions ultimately clear the origin in the remote XCM message by use of the ClearOrigin instruction. This is done for security considerations to ensure that subsequent (user-controlled) instructions cannot command the authority of the sending chain.

+

The problem with this approach is that it limits what can be achieved on remote chains through XCM. Most XCM operations require having an origin, and following any asset transfer the origin is lost, meaning not much can be done other than depositing the transferred assets to some local account or transferring them onward to another chain.

+

For example, we cannot transfer some funds for buying execution, then do a Transact (all in the same XCM message).

+

The above example is a basic, core building block for cross-chain interactions and we should support it.

+

Transact XCM programs today require a two step process:

+Transact Today +

And we want to be able to do it using a single XCM program.

+

Stakeholders

+

Runtime Users, Runtime Devs, wallets, cross-chain dApps.

+

Explanation

+

In the case of XCM programs going from source-chain directly to dest-chain without an intermediary hop, we can enable scenarios such as above by using the AliasOrigin instruction instead of the ClearOrigin instruction.

+

Instead of clearing the source-chain origin, the destination chain shall attempt to alias source-chain to "original origin" on the source chain. +Most common such origin aliasing would be X1(Parachain(source-chain)) -> X2(Parachain(source-chain), AccountId32(origin-account)) for the case of a single hop transfer where the initiator is a (signed/pure/proxy) account origin-account on source-chain.

+

This allows an actor on chain A to Transact on chain B without having to prefund its SA account on chain B, instead they can simply transfer the required fees in the same XCM program as the Transact.

+

As long as the asset transfer has the same XCM route/hops as the rest of the program, this pattern of usage can be composed across multiple hops, to ultimately Transact on the final hop using the original origin on the source chain, effectively abstracting away any intermediary hops.

+

Trust assumptions

+

The model described above makes some aliasing trust assumptions, the most important being how the root location of the intermediate hop/chain has to be trusted to alias ("impersonate") other locations from the source chain.

+

The origin aliasing trust relationship is highly customizeable at the runtime level, so that parachains can define coarse filters or granular pairs of (source, target) locations aliasing.

+

Even so, this RFC aims to also propose a standard set of aliasing rules that all Parachains can integrate for allowing the vast majority of Transact usecases in a "one-click" manner (single XCM), without practically lowering their security posture.

+

Standard Aliasing Rules:

+
    +
  1. Any chain allows aliasing into a child location. Equivalent to DescendOrigin into an interior location.
    2. +
  2. Parachains allow Asset Hub root location to alias into any other origin.
    3. +
+

Now, the second rule as defined above in its most generic form might seem "dangerous" at first, but in practical terms if Asset Hub Root gets compromised and can access arbitrary sovereign accounts on Asset Hub and/or send arbitrary XCMs, the blast radius and potential damage to other parachains are not relevantly impacted by this aliasing rule.

+

This second rule can also be tightened by each parachain to their own liking, for example limit Asset Hub aliasing to a stricter range of locations:

+ +

XCM InitiateAssetsTransfer instruction changes

+

A new parameter preserve_origin to be added to the InitiateAssetsTransfer XCM instruction that specifies if the original origin should be preserved or cleared.

+
InitiateAssetsTransfer {
+	destination: Location,
+	assets: Vec<AssetTransferFilter>,
+	remote_fees: Option<AssetTransferFilter>,
++	preserve_origin: bool,
+	remote_xcm: Xcm<()>,
+}
+
+

This parameter is explicitly necessary because the instruction should be usable between any two chains regardless of their origin-aliasing trust relationship. Preserving the origin requires some level of trust, while clearing it works regardless of that relationship. +Specifying preserve_origin: false will always work regardless of the configured alias filters of the +involved chains.

+

Example scenarios

+

Transact within the ecosytem:

+ +Ecosystem Transact +

Transact over Snowbridge (same for other bridges):

+ +Transact Over Bridge +

Drawbacks

+

In terms of ergonomics and user experience, this support for combining an asset transfer with a subsequent action (like Transact) is a net possitive.

+

In terms off performance, and privacy, this is neutral with no changes.

+

In terms of security, the feature by itself is also neutral because it allows preserve_origin: false usage for operating with no extra trust assumptions. When wanting to support preserving origin, chains need to configure secure origin aliasing filters. The "standard" one provided in this RFC will be the right choice for the majority of chains, but for others it will not be depending on their business model and logic (e.g. chain does not plan to integrate with Asset Hub). It is up to the individual chains to configure accordingly.

+

Testing, Security, and Privacy

+

Barriers should now allow AliasOrigin or ClearOrigin.

+

Normally, XCM program builders should audit their programs and eliminate assumptions of "no origin" on remote side of this instruction. In this case, the InitiateAssetsTransfer has not been released yet, it will be part of XCMv5, and we can make this change part of the same XCMv5 so that there isn't even the possibility of someone in the wild having built XCM programs using this instruction on those wrong assumptions.

+

The working assumption going forward is that the origin on the remote side can either be cleared or it can be the local origin's reanchored location. This assumption is in line with the current behavior of remote XCM programs sent over using pallet_xcm::send.

+

The existing DepositReserveAsset, InitiateReserveWithdraw and InitiateTeleport cross chain asset transfer instructions will not attempt to do origin aliasing and will always clear origin same as before for compatibility reasons.

+

Performance, Ergonomics, and Compatibility

+

Performance

+

No impact.

+

Ergonomics

+

Improves ergonomics by allowing the local origin to operate on the remote chain even when the XCM program includes an asset transfer.

+

Compatibility

+

At the executor-level this change is backwards and forwards compatible. Both types of programs can be executed on new and old versions of XCM with no changes in behavior.

+

New version of the InitiateAssetsTransfer instruction acts same as before when used with preserve_origin: false.

+

For using the new capabilities, the XCM builder has to verify that the involved chains have the required origin-aliasing filters configured and use some new version of Barriers aware of AliasOrigin as an allowed alternative to ClearOrigin.

+

For compatibility reasons, this RFC proposes this mechanism be added as an enhancement to the yet unreleased InitiateAssetsTransfer instruction, thus eliminating possibilities of XCM logic breakages in the wild. +Following the same logic, the existing DepositReserveAsset, InitiateReserveWithdraw and InitiateTeleport cross chain asset transfer instructions will not attempt to do origin aliasing and will always clear the origin same as before for compatibility reasons.

+

Any one of DepositReserveAsset, InitiateReserveWithdraw and InitiateTeleport instructions can be replaced with a InitiateAssetsTransfer instruction with or without origin aliasing, thus providing a clean and clear upgrade path for opting-in this new feature.

+

Prior Art and References

+ +

Unresolved Questions

+

None

+

(source)

Table of Contents

-

Drawbacks

+

Drawbacks

This RFC might be difficult to implement in Substrate due to the internal code design. It is not clear to the author of this RFC how difficult it would be.

Prior Art

The API of these new functions was heavily inspired by API used by the C programming language.

-

Unresolved Questions

+

Unresolved Questions

The changes in this RFC would need to be benchmarked. This involves implementing the RFC and measuring the speed difference.

It is expected that most host functions are faster or equal speed to their deprecated counterparts, with the following exceptions:

 -

Drawbacks

+

Drawbacks

-

Testing, Security, and Privacy

+

Testing, Security, and Privacy

Standard audit/review requirements apply.

-

Performance, Ergonomics, and Compatibility

-

Performance

+

Performance, Ergonomics, and Compatibility

+

Performance

Doing back of the envelop calculation to proof that the stateful multisig is more efficient than the stateless multisig given it's smaller footprint size on blocks.

Quick review over the extrinsics for both as it affects the block size:

Stateless Multisig: @@ -2321,17 +2759,17 @@ We have the following extrinsics:

| Stateless | N^2 | Nil | | Stateful | N | N |

So even though the stateful multisig has a larger state size, it's still more efficient in terms of block size and total footprint on the blockchain.

-

Ergonomics

+

Ergonomics

The Stateful Multisig will have better ergonomics for managing multisig accounts for both developers and end-users.

-

Compatibility

+

Compatibility

This RFC is compatible with the existing implementation and can be handled via upgrades and migration. It's not intended to replace the existing multisig pallet.

-

Prior Art and References

+

Prior Art and References

multisig pallet in polkadot-sdk

-

Unresolved Questions

+

Unresolved Questions

- +

Solution Requirements

The maximum length of identity PGP Fingerprint values should be increased from the current 20 bytes/chars limit at least a 40 bytes/chars limit to support PGP Fingerprints and GPG Fingerprints.

-

Stakeholders

+

Stakeholders

-

Explanation

+

Explanation

If a user tries to setting an on-chain identity by creating an extrinsic using Polkadot.js with identity > setIdentity(info), then if they try to provide their 40 character long PGP Fingerprint or GPG Fingerprint, which is longer than the maximum length of 20 bytes/chars [u8;20], then they will encounter this error:

createType(Call):: Call: failed decoding identity.setIdentity:: Struct: failed on args: {...}:: Struct: failed on pgpFingerprint: Option<[u8;20]>:: Expected input with 20 bytes (160 bits), found 40 bytes

Increasing maximum length of identity PGP Fingerprint values from the current 20 bytes/chars limit to at least a 40 bytes/chars limit would overcome these errors and support PGP Fingerprints and GPG Fingerprints, satisfying the solution requirements.

-

Drawbacks

+

Drawbacks

No drawbacks have been identified.

-

Testing, Security, and Privacy

+

Testing, Security, and Privacy

Implementations would be tested for adherance by checking that 40 bytes/chars PGP Fingerprints are supported.

No effect on security or privacy has been identified than already exists.

No implementation pitfalls have been identified.

-

Performance, Ergonomics, and Compatibility

-

Performance

+

Performance, Ergonomics, and Compatibility

+

Performance

It would be an optimization, since the associated exposed interfaces to developers and end-users could start being used.

To minimize additional overhead the proposal suggests a 40 bytes/chars limit since that would at least provide support for PGP Fingerprints, satisfying the solution requirements.

-

Ergonomics

+

Ergonomics

No potential ergonomic optimizations have been identified.

-

Compatibility

+

Compatibility

Updates to Polkadot.js Apps, API and its documentation and those referring to it may be required.

-

Prior Art and References

+

Prior Art and References

No prior articles or references.

-

Unresolved Questions

+

Unresolved Questions

No further questions at this stage.

- +

Relates to RFC entitled "Increase maximum length of identity raw data values from 32 bytes".

(source)

Table of Contents

@@ -2475,10 +2913,10 @@ Implement call filters. This will allow multisig accounts to only accept certain AuthorsLuke Schoen -

Summary

+

Summary

This proposes to require a slashable deposit in the broker pallet when initially purchasing or renewing Bulk Coretime or Instantaneous Coretime cores.

Additionally, it proposes to record a reputational status based on the behavior of the purchaser, as it relates to their use of Kusama Coretime cores that they purchase, and to possibly reserve a proportion of the cores for prospective purchasers that have an on-chain identity.

-

Motivation

+

Motivation

Background

There are sales of Kusama Coretime cores that are scheduled to occur later this month by Coretime Marketplace Lastic.xyz initially in limited quantities, and potentially also by RegionX in future that is subject to their Polkadot referendum #582. This poses a risk in that some Kusama Coretime core purchasers may buy Kusama Coretime cores when they have no intention of actually placing a workload on them or leasing them out, which would prevent those that wish to purchase and actually use Kusama Coretime cores from being able to use any at cores at all.

Problem

@@ -2510,34 +2948,34 @@ Implement call filters. This will allow multisig accounts to only accept certain

Reputation. To disincentivise certain behaviours, a reputational status indicator could be used to record the historic behavior of the purchaser and whether on-chain judgement has determined they have adequately rectified that behaviour, as it relates to their usage of Kusama Coretime cores that they purchase.

-

Stakeholders

+

Stakeholders

-

Drawbacks

-

Performance

+

Drawbacks

+

Performance

The slashable deposit if set too high, may result in an economic impact, where less Kusama Coretime core sales are purchased.

-

Testing, Security, and Privacy

+

Testing, Security, and Privacy

Lack of a slashable deposit in the Broker pallet is a security concern, since it exposes Kusama Coretime sales to potential abuse.

Reserving a proportion of Kusama Coretime sales cores for those with on-chain identities should not be to the exclusion of accounts that wish to remain anonymous or cause cores to be wasted unnecessarily. As such, if cores that are reserved for on-chain identities remain unsold then they should be released to anonymous accounts that are on a waiting list.

No implementation pitfalls have been identified.

-

Performance, Ergonomics, and Compatibility

-

Performance

+

Performance, Ergonomics, and Compatibility

+

Performance

It should improve performance as it reduces the potential for state bloat since there is less risk of undesirable Kusama Coretime sales activity that would be apparent with no requirement for a slashable deposit or there being no reputational risk to purchasers that waste or misuse Kusama Coretime cores.

The solution proposes to minimize the risk of some Kusama Coretime cores not even being used or leased to perform any tasks at all.

It will be important to monitor and manage the slashable deposits, purchaser reputations, and utilization of the proportion of cores that are reserved for accounts with an on-chain identity.

-

Ergonomics

+

Ergonomics

The mechanism for setting a slashable deposit amount, should avoid undue complexity for users.

-

Compatibility

+

Compatibility

Updates to Polkadot.js Apps, API and its documentation and those referring to it may be required.

-

Prior Art and References

+

Prior Art and References

Prior Art

No prior articles.

-

Unresolved Questions

+

Unresolved Questions

None

- +

None

(source)

Table of Contents

@@ -2570,7 +3008,7 @@ Implement call filters. This will allow multisig accounts to only accept certain AuthorsKian Paimani -

Summary

+

Summary

This RFC proposes a new pallet_inflation to be added to the Polkadot runtime, which improves inflation machinery of the Polkadot relay chain in a number of ways:

    @@ -2580,7 +3018,7 @@ inflation machinery of the Polkadot relay chain in a number of ways:

    systems, as proposed RFC32.
-

Motivation

+

Motivation

The existing inflation logic in the relay chain suffers from a number of drawbacks: