diff --git a/404.html b/404.html index 4b0b5a2..153b044 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 548b40a..560f920 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 c69f7f3..340be92 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 25f5f4f..fa55b7d 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 795b49a..8f23f32 100644 --- a/approved/0008-parachain-bootnodes-dht.html +++ b/approved/0008-parachain-bootnodes-dht.html @@ -90,7 +90,7 @@ diff --git a/approved/0009-improved-net-light-client-requests.html b/approved/0009-improved-net-light-client-requests.html index 9a2230e..3a0acf9 100644 --- a/approved/0009-improved-net-light-client-requests.html +++ b/approved/0009-improved-net-light-client-requests.html @@ -90,7 +90,7 @@ diff --git a/approved/0010-burn-coretime-revenue.html b/approved/0010-burn-coretime-revenue.html index b37c21c..e698760 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 ca15231..ad4aaa6 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 da9c5b6..2a00c62 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 f951f68..157fe80 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/0017-coretime-market-redesign.html b/approved/0017-coretime-market-redesign.html index be850da..763d6bc 100644 --- a/approved/0017-coretime-market-redesign.html +++ b/approved/0017-coretime-market-redesign.html @@ -90,7 +90,7 @@ diff --git a/approved/0022-adopt-encointer-runtime.html b/approved/0022-adopt-encointer-runtime.html index 435c3b1..79231a9 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 6a8002d..2eb72ba 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 f989f1d..f60079b 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 51adc3e..7c6899c 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 466210b..d87b2ed 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 2961e6c..455147d 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 e446784..d68d712 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 e55f4ed..a70ce6f 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 c9ea49c..43ee49e 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 1317900..4e23c14 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 f68b949..92150b2 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 615061e..16f7f74 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 65741d4..281d3d8 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 9d0cefb..d15dcd2 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 5a09b7a..5bda87d 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 fbecdb2..afa583d 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 21082c7..e9e408e 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 7fd1234..927c230 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 6ad76f9..853e9bb 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 103a285..f419f3f 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 58b6867..d2b371d 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 0a6456e..eadcf95 100644 --- a/approved/0108-xcm-remove-testnet-ids.html +++ b/approved/0108-xcm-remove-testnet-ids.html @@ -90,7 +90,7 @@ diff --git a/approved/0122-alias-origin-on-asset-transfers.html b/approved/0122-alias-origin-on-asset-transfers.html index 8bd9014..5cec9ff 100644 --- a/approved/0122-alias-origin-on-asset-transfers.html +++ b/approved/0122-alias-origin-on-asset-transfers.html @@ -90,7 +90,7 @@ diff --git a/approved/0123-pending-code-as-storage-location-for-runtime-upgrades.html b/approved/0123-pending-code-as-storage-location-for-runtime-upgrades.html index 8d5677b..3f76f1c 100644 --- a/approved/0123-pending-code-as-storage-location-for-runtime-upgrades.html +++ b/approved/0123-pending-code-as-storage-location-for-runtime-upgrades.html @@ -90,7 +90,7 @@ diff --git a/approved/0125-xcm-asset-metadata.html b/approved/0125-xcm-asset-metadata.html index 5ee4e19..5cabca6 100644 --- a/approved/0125-xcm-asset-metadata.html +++ b/approved/0125-xcm-asset-metadata.html @@ -90,7 +90,7 @@ diff --git a/approved/0126-introduce-pvq.html b/approved/0126-introduce-pvq.html index 7df4c30..f24db13 100644 --- a/approved/0126-introduce-pvq.html +++ b/approved/0126-introduce-pvq.html @@ -90,7 +90,7 @@ diff --git a/approved/0135-compressed-blob-prefixes.html b/approved/0135-compressed-blob-prefixes.html index 64880f9..3dee789 100644 --- a/approved/0135-compressed-blob-prefixes.html +++ b/approved/0135-compressed-blob-prefixes.html @@ -90,7 +90,7 @@ diff --git a/approved/0139-faster-erasure-coding.html b/approved/0139-faster-erasure-coding.html index f65bdbd..9004a87 100644 --- a/approved/0139-faster-erasure-coding.html +++ b/approved/0139-faster-erasure-coding.html @@ -90,7 +90,7 @@ diff --git a/approved/0146-deflationary-fee-proposal.html b/approved/0146-deflationary-fee-proposal.html index 1d5cdf9..c770e6f 100644 --- a/approved/0146-deflationary-fee-proposal.html +++ b/approved/0146-deflationary-fee-proposal.html @@ -90,7 +90,7 @@ diff --git a/approved/0149-rfc-1-renewal-adjustment.html b/approved/0149-rfc-1-renewal-adjustment.html index 26d2d08..e577b6b 100644 --- a/approved/0149-rfc-1-renewal-adjustment.html +++ b/approved/0149-rfc-1-renewal-adjustment.html @@ -90,7 +90,7 @@ @@ -346,7 +346,7 @@ a few cores not for sale should be enough to mitigate such a situation.

- @@ -360,7 +360,7 @@ a few cores not for sale should be enough to mitigate such a situation.

- diff --git a/proposed/0150-voting-while-delegating.html b/approved/0150-voting-while-delegating.html similarity index 79% rename from proposed/0150-voting-while-delegating.html rename to approved/0150-voting-while-delegating.html index f36210f..98d45fa 100644 --- a/proposed/0150-voting-while-delegating.html +++ b/approved/0150-voting-while-delegating.html @@ -90,7 +90,7 @@ @@ -174,7 +174,7 @@
-

(source)

+

(source)

Table of Contents

diff --git a/index.html b/index.html index a0083f4..301df4d 100644 --- a/index.html +++ b/index.html @@ -90,7 +90,7 @@ diff --git a/introduction.html b/introduction.html index a0083f4..301df4d 100644 --- a/introduction.html +++ b/introduction.html @@ -90,7 +90,7 @@ diff --git a/print.html b/print.html index 1f48d65..5c12c86 100644 --- a/print.html +++ b/print.html @@ -91,7 +91,7 @@ @@ -921,138 +921,6 @@ $$

A runtime function called through such an entrypoint gets the length of SCALE-encoded input data as its only argument. After that, the function must allocate exactly the amount of bytes it is requested, and call the ext_input_read host function to obtain the encoded input data.

If a runtime happens to import both functions that allocate on the host side and functions that allocate on the runtime side, the host must not proceed with execution of such a runtime, aborting before the execution takes place.

-

(source)

-

Table of Contents

- -

RFC-150: Allow Voting While Delegating

-
- - - -
Start DateJune 5th, 2025
DescriptionAllow voters to simultaneously delegate and vote
Authorspolka.dom (polkadotdom)
-
-

Summary

-

This RFC proposes changes to pallet-conviction-voting that allow for simultaneous voting and delegation. For example, Alice could delegate to Bob, then later vote on a referendum while keeping their delegation to Bob intact. It is a strict subset of Leemo's RFC 35.

-

Motivation

-

Backdrop

-

Under our current voting system, a voter can either vote or delegate. To vote, they must first ensure they have no delegate, and to delegate, they must first clear their current votes.

-

The Issue

-

Empirically, the vast majority of people do not vote on day to day policy. This was foreseen and is the reason governance has delegation. However, more worriedly, it has also been observed that most people do not delegate either, leaving a large percentage of our voting population unrepresented.

-

Factors Limiting Delegation

-

One could think of three major reasons for this lack of delegation.

- -

This RFC aims to solve the second and third issue and thus more accurately align governance to the true voter preferences.

-

An Aside

-

One may ask, could a voter not just undelegate, vote, then delegate again? Could this just be built into the user interface? Unfortunately, this does not work due to the need to clear their votes before redelegation. In practice the voter would undelegate, vote, wait until the referendum is closed, hope that there's no other referenda they would like to vote on, then redelegate. At best it's a temporally extended friction. At worst the voter goes unrepresented in voting for the duration of the vote clearing period.

-

Stakeholders

-

Runtime developers: If runtime developers are relying on the previous assumptions for their VotingHooks implementations, they will need to rethink their approach. In addition, a runtime migration is needed. Lastly, it is a serious change in governance that requires some consideration beyond the technical.

-

App developers: Apps like Subsquare and Polkassembly would need to update their user interface logic. They will also need to handle the new error.

-

Users: We will want users to be aware of the new functionality, though not required.

-

Technical Writers: This change will require rewrites of documentation and tutorials.

-

Explanation

-

New Data & Runtime Logic

-

The new logic allows a delegator's vote on a specific poll to override their delegation for that poll only. When a delegator votes, their delegated voting power is temporarily "clawed back" from their delegate for that single referendum. This ensures a delegator's direct vote takes precedence.

-

The core of the algorithm is as follows:

-
    -
  1. -

    Calculating a User's Voting Power: A user's total voting power on any given poll is their own balance plus the total balance delegated to them, minus the total amount retracted by any of their delegators who chose to vote directly on that poll.

    -
    2. -
  2. -

    Tracking Clawbacks: When a delegator votes, the system records the full amount of their delegated stake as "retracted" on their delegate's account for that specific poll. This clawback is always for the delegator's full delegated amount, regardless of the amount they personally vote with. This is for simplicity and to avoid making assumptions about the delegator's intent. Crucially, clawbacks from multiple delegators can be accumulated, such that only one tracking entry per referendum is necessary.

    -
    3. -
-

Here is how the logic plays out in different scenarios:

- -

A key consequence of this design is that a delegator's vote can alter their delegate's storage. If adding a "retracted votes" entry pushes the delegate's voting data beyond the MaxVotes limit, the delegator's transaction will fail. A new error will be introduced to signal this specific case. While a constraint, this will incentivize delegates to regularly clear their voting data for concluded referenda, and given our current referenda rates and MaxVotes set to 512, this scenario is unlikely to occur.

-

Locked Balance

-

A user's locked balance will be the greater of the delegation lock and the voting lock.

-

Migrations

-

A multi-block runtime migration is necessary. It would iterate over the VotingFor storage item and convert the old vote data structure to the new structure.

-

Drawbacks

-

There are two potential drawbacks to this system -

-

An unbounded rate of change of the voter preferences function

-

If implemented, there will be no friction in delegating, undelegating, and voting. Therefore, there could be large and immediate shifts in the voter preferences function. In other voting systems we see bounds added to the rate of change (voting cycles, etc). That said, it is unclear whether this is desired or advantageous. Additionally, there are more easily parameterized and analytically tractable ways to handle this than what we currently have. See future directions.

-

Lessened value in becoming a delegate

-

If a delegate's voting power can be stripped from them at any point, then there is necessarily a reduction in their power within the system. This provides less incentive to become a delegate. But again, there are more customizable ways to handle this if it proves necessary.

-

Testing, Security, and Privacy

-

The changes herein would allow for a cost-symmetric grief in which a delegator votes on every referendum, adding more votes to the delegate's record, then accepts the lock and waits until the delegate themselves pays to remove the vote from their record-- costing the delegate cost_of_removal_per_ref * number_of_refs_not_voted_on. This cost will inevitably be small and accepted by aspirational delegates, considering they'll be voting on most refs anyway. However, for those who don't want to incur the possibility of this cost, we introduce a per voting class flag that toggles delegator voting on/off.

-

In addition, these changes would mean a more complicated STF, which would increase the difficulty of hardening. Though sufficient unit testing should handle this with ease.

-

Performance, Ergonomics, and Compatibility

-

Performance

-

The proposed changes would increase both the compute and storage requirements by about 2x for all voting functions. No change in complexity.

-

Ergonomics

-

Voting and delegation will both become more ergonomic for users, as there are no longer hard constraints affecting what you can do and when you can do it.

-

Compatibility

-

Runtime developers will need to add the migration and ensure their hooks still work.

-

App developers will need to update their user interfaces to accommodate the new functionality. They will need to handle the new error as well.

-

Prior Art and References

-

A current implementation can be found here.

-

Unresolved Questions

-

None

- -

It is possible we would like to add a system parameter for the rate of change of the voting/delegation system. This could prevent wild swings in the voter preferences function and motivate/shield delegates by solidifying their positions over some amount of time. However, it's unclear that this would be valuable or even desirable.

(source)

Table of Contents

-

Prior Art and References

+

Prior Art and References

Robert Habermeier initially wrote on the subject of Polkadot blockspace-centric in the article Polkadot Blockspace over Blockchains. While not going into details, the article served as an early reframing piece for moving beyond one-slot-per-chain models and building out secondary market infrastructure for resource allocation.

(source)

Table of Contents

@@ -1880,10 +1748,10 @@ InstaPoolHistory: (empty) AuthorsGavin Wood, Robert Habermeier -

Summary

+

Summary

In the Agile Coretime model of the Polkadot Ubiquitous Computer, as proposed in RFC-1 and RFC-3, it is necessary for the allocating parachain (envisioned to be one or more pallets on a specialised Brokerage System Chain) to communicate the core assignments to the Relay-chain, which is responsible for ensuring those assignments are properly enacted.

This is a proposal for the interface which will exist around the Relay-chain in order to communicate this information and instructions.

-

Motivation

+

Motivation

The background motivation for this interface is splitting out coretime allocation functions and secondary markets from the Relay-chain onto System parachains. A well-understood and general interface is necessary for ensuring the Relay-chain receives coretime allocation instructions from one or more System chains without introducing dependencies on the implementation details of either side.

Requirements

-

Stakeholders

+

Stakeholders

Primary stakeholder sets are:

Socialization:

This content of this RFC was discussed in the Polkdot Fellows channel.

-

Explanation

+

Explanation

The interface has two sections: The messages which the Relay-chain is able to receive from the allocating parachain (the UMP message types), and messages which the Relay-chain is able to send to the allocating parachain (the DMP message types). These messages are expected to be able to be implemented in a well-known pallet and called with the XCM Transact instruction.

Future work may include these messages being introduced into the XCM standard.

UMP Message Types

@@ -1978,17 +1846,17 @@ assert_eq!(targets.iter().map(|x| x.1).sum(), 57600);

Realistic Limits of the Usage

For request_revenue_info, a successful request should be possible if when is no less than the Relay-chain block number on arrival of the message less 100,000.

For assign_core, a successful request should be possible if begin is no less than the Relay-chain block number on arrival of the message plus 10 and workload contains no more than 100 items.

-

Performance, Ergonomics and Compatibility

+

Performance, Ergonomics and Compatibility

No specific considerations.

-

Testing, Security and Privacy

+

Testing, Security and Privacy

Standard Polkadot testing and security auditing applies.

The proposal introduces no new privacy concerns.

- +

RFC-1 proposes a means of determining allocation of Coretime using this interface.

RFC-3 proposes a means of implementing the high-level allocations within the Relay-chain.

Drawbacks, Alternatives and Unknowns

None at present.

-

Prior Art and References

+

Prior Art and References

None.

(source)

Table of Contents

@@ -2034,13 +1902,13 @@ assert_eq!(targets.iter().map(|x| x.1).sum(), 57600); AuthorsJoe Petrowski -

Summary

+

Summary

As core functionality moves from the Relay Chain into system chains, so increases the reliance on the liveness of these chains for the use of the network. It is not economically scalable, nor necessary from a game-theoretic perspective, to pay collators large rewards. This RFC proposes a mechanism -- part technical and part social -- for ensuring reliable collator sets that are resilient to attemps to stop any subsytem of the Polkadot protocol.

-

Motivation

+

Motivation

In order to guarantee access to Polkadot's system, the collators on its system chains must propose blocks (provide liveness) and allow all transactions to eventually be included. That is, some collators may censor transactions, but there must exist one collator in the set who will include a @@ -2076,12 +1944,12 @@ to censor any subset of transactions.

  • Collators selected by governance SHOULD have a reasonable expectation that the Treasury will reimburse their operating costs.
    • -

    Stakeholders

    +

    Stakeholders

    -

    Explanation

    +

    Explanation

    This protocol builds on the existing Collator Selection pallet and its notion of Invulnerables. Invulnerables are collators (identified by their AccountIds) who @@ -2117,27 +1985,27 @@ approximately:

  • of which 15 are Invulnerable, and
  • five are elected by bond.
    • -

    Drawbacks

    +

    Drawbacks

    The primary drawback is a reliance on governance for continued treasury funding of infrastructure costs for Invulnerable collators.

    -

    Testing, Security, and Privacy

    +

    Testing, Security, and Privacy

    The vast majority of cases can be covered by unit testing. Integration test should ensure that the Collator Selection UpdateOrigin, which has permission to modify the Invulnerables and desired number of Candidates, can handle updates over XCM from the system's governance location.

    -

    Performance, Ergonomics, and Compatibility

    +

    Performance, Ergonomics, and Compatibility

    This proposal has very little impact on most users of Polkadot, and should improve the performance of system chains by reducing the number of missed blocks.

    -

    Performance

    +

    Performance

    As chains have strict PoV size limits, care must be taken in the PoV impact of the session manager. Appropriate benchmarking and tests should ensure that conservative limits are placed on the number of Invulnerables and Candidates.

    -

    Ergonomics

    +

    Ergonomics

    The primary group affected is Candidate collators, who, after implementation of this RFC, will need to compete in a bond-based election rather than a race to claim a Candidate spot.

    -

    Compatibility

    +

    Compatibility

    This RFC is compatible with the existing implementation and can be handled via upgrades and migration.

    -

    Prior Art and References

    +

    Prior Art and References

    Written Discussions

    -

    Unresolved Questions

    +

    Unresolved Questions

    None at this time.

    - +

    There may exist in the future system chains for which this model of collator selection is not appropriate. These chains should be evaluated on a case-by-case basis.

    (source)

    @@ -2193,10 +2061,10 @@ appropriate. These chains should be evaluated on a case-by-case basis.

    AuthorsPierre Krieger -

    Summary

    +

    Summary

    The full nodes of the Polkadot peer-to-peer network maintain a distributed hash table (DHT), which is currently used for full nodes discovery and validators discovery purposes.

    This RFC proposes to extend this DHT to be used to discover full nodes of the parachains of Polkadot.

    -

    Motivation

    +

    Motivation

    The maintenance of bootnodes has long been an annoyance for everyone.

    When a bootnode is newly-deployed or removed, every chain specification must be updated in order to take the update into account. This has lead to various non-optimal solutions, such as pulling chain specifications from GitHub repositories. When it comes to RPC nodes, UX developers often have trouble finding up-to-date addresses of parachain RPC nodes. With the ongoing migration from RPC nodes to light clients, similar problems would happen with chain specifications as well.

    @@ -2205,9 +2073,9 @@ When it comes to RPC nodes, UX developers often have trouble finding up-to-date

    Because the list of bootnodes in chain specifications is so annoying to modify, the consequence is that the number of bootnodes is rather low (typically between 2 and 15). In order to better resist downtimes and DoS attacks, a better solution would be to use every node of a certain chain as potential bootnode, rather than special-casing some specific nodes.

    While this RFC doesn't solve these problems for relay chains, it aims at solving it for parachains by storing the list of all the full nodes of a parachain on the relay chain DHT.

    Assuming that this RFC is implemented, and that light clients are used, deploying a parachain wouldn't require more work than registering it onto the relay chain and starting the collators. There wouldn't be any need for special infrastructure nodes anymore.

    -

    Stakeholders

    +

    Stakeholders

    This RFC has been opened on my own initiative because I think that this is a good technical solution to a usability problem that many people are encountering and that they don't realize can be solved.

    -

    Explanation

    +

    Explanation

    The content of this RFC only applies for parachains and parachain nodes that are "Substrate-compatible". It is in no way mandatory for parachains to comply to this RFC.

    Note that "Substrate-compatible" is very loosely defined as "implements the same mechanisms and networking protocols as Substrate". The author of this RFC believes that "Substrate-compatible" should be very precisely specified, but there is controversy on this topic.

    While a lot of this RFC concerns the implementation of parachain nodes, it makes use of the resources of the Polkadot chain, and as such it is important to describe them in the Polkadot specification.

    @@ -2244,10 +2112,10 @@ message Response {

    The maximum size of a response is set to an arbitrary 16kiB. The responding side should make sure to conform to this limit. Given that fork_id is typically very small and that the only variable-length field is addrs, this is easily achieved by limiting the number of addresses.

    Implementers should be aware that addrs might be very large, and are encouraged to limit the number of addrs to an implementation-defined value.

    -

    Drawbacks

    +

    Drawbacks

    The peer_id and addrs fields are in theory not strictly needed, as the PeerId and addresses could be always equal to the PeerId and addresses of the node being registered as the provider and serving the response. However, the Cumulus implementation currently uses two different networking stacks, one of the parachain and one for the relay chain, using two separate PeerIds and addresses, and as such the PeerId and addresses of the other networking stack must be indicated. Asking them to use only one networking stack wouldn't feasible in a realistic time frame.

    The values of the genesis_hash and fork_id fields cannot be verified by the requester and are expected to be unused at the moment. Instead, a client that desires connecting to a parachain is expected to obtain the genesis hash and fork ID of the parachain from the parachain chain specification. These fields are included in the networking protocol nonetheless in case an acceptable solution is found in the future, and in order to allow use cases such as discovering parachains in a not-strictly-trusted way.

    -

    Testing, Security, and Privacy

    +

    Testing, Security, and Privacy

    Because not all nodes want to be used as bootnodes, implementers are encouraged to provide a way to disable this mechanism. However, it is very much encouraged to leave this mechanism on by default for all parachain nodes.

    This mechanism doesn't add or remove any security by itself, as it relies on existing mechanisms. However, if the principle of chain specification bootnodes is entirely replaced with the mechanism described in this RFC (which is the objective), then it becomes important whether the mechanism in this RFC can be abused in order to make a parachain unreachable.

    @@ -2256,22 +2124,22 @@ Furthermore, when a large number of providers (here, a provider is a bootnode) a

    For this reason, an attacker can abuse this mechanism by randomly generating libp2p PeerIds until they find the 20 entries closest to the key representing the target parachain. They are then in control of the parachain bootnodes. Because the key changes periodically and isn't predictable, and assuming that the Polkadot DHT is sufficiently large, it is not realistic for an attack like this to be maintained in the long term.

    Furthermore, parachain clients are expected to cache a list of known good nodes on their disk. If the mechanism described in this RFC went down, it would only prevent new nodes from accessing the parachain, while clients that have connected before would not be affected.

    -

    Performance, Ergonomics, and Compatibility

    -

    Performance

    +

    Performance, Ergonomics, and Compatibility

    +

    Performance

    The DHT mechanism generally has a low overhead, especially given that publishing providers is done only every 24 hours.

    Doing a Kademlia iterative query then sending a provider record shouldn't take more than around 50 kiB in total of bandwidth for the parachain bootnode.

    Assuming 1000 parachain full nodes, the 20 Polkadot full nodes corresponding to a specific parachain will each receive a sudden spike of a few megabytes of networking traffic when the key rotates. Again, this is relatively negligible. If this becomes a problem, one can add a random delay before a parachain full node registers itself to be the provider of the key corresponding to BabeApi_next_epoch.

    Maybe the biggest uncertainty is the traffic that the 20 Polkadot full nodes will receive from light clients that desire knowing the bootnodes of a parachain. Light clients are generally encouraged to cache the peers that they use between restarts, so they should only query these 20 Polkadot full nodes at their first initialization. If this every becomes a problem, this value of 20 is an arbitrary constant that can be increased for more redundancy.

    -

    Ergonomics

    +

    Ergonomics

    Irrelevant.

    -

    Compatibility

    +

    Compatibility

    Irrelevant.

    -

    Prior Art and References

    +

    Prior Art and References

    None.

    -

    Unresolved Questions

    +

    Unresolved Questions

    While it fundamentally doesn't change much to this RFC, using BabeApi_currentEpoch and BabeApi_nextEpoch might be inappropriate. I'm not familiar enough with good practices within the runtime to have an opinion here. Should it be an entirely new pallet?

    - +

    It is possible that in the future a client could connect to a parachain without having to rely on a trusted parachain specification.

    (source)

    Table of Contents

    @@ -2304,9 +2172,9 @@ If this every becomes a problem, this value of 20 is an arbitrary constant that AuthorsPierre Krieger -

    Summary

    +

    Summary

    Improve the networking messages that query storage items from the remote, in order to reduce the bandwidth usage and number of round trips of light clients.

    -

    Motivation

    +

    Motivation

    Clients on the Polkadot peer-to-peer network can be divided into two categories: full nodes and light clients. So-called full nodes are nodes that store the content of the chain locally on their disk, while light clients are nodes that don't. In order to access for example the balance of an account, a full node can do a disk read, while a light client needs to send a network message to a full node and wait for the full node to reply with the desired value. This reply is in the form of a Merkle proof, which makes it possible for the light client to verify the exactness of the value.

    Unfortunately, this network protocol is suffering from some issues:

    Once Polkadot and Kusama will have transitioned to state_version = 1, which modifies the format of the trie entries, it will be possible to generate Merkle proofs that contain only the hashes of values in the storage. Thanks to this, it is already possible to prove the existence of a key without sending its entire value (only its hash), or to prove that a value has changed or not between two blocks (by sending just their hashes). Thus, the only reason why aforementioned issues exist is because the existing networking messages don't give the possibility for the querier to query this. This is what this proposal aims at fixing.

    -

    Stakeholders

    +

    Stakeholders

    This is the continuation of https://github.com/w3f/PPPs/pull/10, which itself is the continuation of https://github.com/w3f/PPPs/pull/5.

    -

    Explanation

    +

    Explanation

    The protobuf schema of the networking protocol can be found here: https://github.com/paritytech/substrate/blob/5b6519a7ff4a2d3cc424d78bc4830688f3b184c0/client/network/light/src/schema/light.v1.proto

    The proposal is to modify this protocol in this way:

    @@ -11,6 +11,7 @@ message Request {
@@ -2376,26 +2244,26 @@ An alternative could have been to specify the child_trie_info for e
 Also note that child tries aren't considered as descendants of the main trie when it comes to the includeDescendants flag. In other words, if the request concerns the main trie, no content coming from child tries is ever sent back.
    
 
    This protocol keeps the same maximum response size limit as currently exists (16 MiB). It is not possible for the querier to know in advance whether its query will lead to a reply that exceeds the maximum size. If the reply is too large, the replier should send back only a limited number (but at least one) of requested items in the proof. The querier should then send additional requests for the rest of the items. A response containing none of the requested items is invalid.
    
 
    The server is allowed to silently discard some keys of the request if it judges that the number of requested keys is too high. This is in line with the fact that the server might truncate the response.
    
-
    Drawbacks
    
+
    Drawbacks
    
 
    This proposal doesn't handle one specific situation: what if a proof containing a single specific item would exceed the response size limit? For example, if the response size limit was 1 MiB, querying the runtime code (which is typically 1.0 to 1.5 MiB) would be impossible as it's impossible to generate a proof less than 1 MiB. The response size limit is currently 16 MiB, meaning that no single storage item must exceed 16 MiB.
    
 
    Unfortunately, because it's impossible to verify a Merkle proof before having received it entirely, parsing the proof in a streaming way is also not possible.
    
 
    A way to solve this issue would be to Merkle-ize large storage items, so that a proof could include only a portion of a large storage item. Since this would require a change to the trie format, it is not realistically feasible in a short time frame.
    
-
    Testing, Security, and Privacy
    
+
    Testing, Security, and Privacy
    
 
    The main security consideration concerns the size of replies and the resources necessary to generate them. It is for example easily possible to ask for all keys and values of the chain, which would take a very long time to generate. Since responses to this networking protocol have a maximum size, the replier should truncate proofs that would lead to the response being too large. Note that it is already possible to send a query that would lead to a very large reply with the existing network protocol. The only thing that this proposal changes is that it would make it less complicated to perform such an attack.
    
 
    Implementers of the replier side should be careful to detect early on when a reply would exceed the maximum reply size, rather than inconditionally generate a reply, as this could take a very large amount of CPU, disk I/O, and memory. Existing implementations might currently be accidentally protected from such an attack thanks to the fact that requests have a maximum size, and thus that the list of keys in the query was bounded. After this proposal, this accidental protection would no longer exist.
    
 
    Malicious server nodes might truncate Merkle proofs even when they don't strictly need to, and it is not possible for the client to (easily) detect this situation. However, malicious server nodes can already do undesirable things such as throttle down their upload bandwidth or simply not respond. There is no need to handle unnecessarily truncated Merkle proofs any differently than a server simply not answering the request.
    
-
    Performance, Ergonomics, and Compatibility
    
-
    Performance
    
+
    Performance, Ergonomics, and Compatibility
    
+
    Performance
    
 
    It is unclear to the author of the RFC what the performance implications are. Servers are supposed to have limits to the amount of resources they use to respond to requests, and as such the worst that can happen is that light client requests become a bit slower than they currently are.
    
-
    Ergonomics
    
+
    Ergonomics
    
 
    Irrelevant.
    
-
    Compatibility
    
+
    Compatibility
    
 
    The prior networking protocol is maintained for now. The older version of this protocol could get removed in a long time.
    
-
    Prior Art and References
    
+
    Prior Art and References
    
 
    None. This RFC is a clean-up of an existing mechanism.
    
-
    Unresolved Questions
    
+
    Unresolved Questions
    
 
    None
    
-
+
 
    The current networking protocol could be deprecated in a long time. Additionally, the current "state requests" protocol (used for warp syncing) could also be deprecated in favor of this one.
    
 
    (source)
    
 
    Table of Contents
    
@@ -2416,13 +2284,13 @@ Also note that child tries aren't considered as descendants of the main trie whe
 AuthorsJonas Gehrlein
 
 
-
    Summary
    
+
    Summary
    
 
    The Polkadot UC will generate revenue from the sale of available Coretime. The question then arises: how should we handle these revenues? Broadly, there are two reasonable paths – burning the revenue and thereby removing it from total issuance or divert it to the Treasury. This Request for Comment (RFC) presents arguments favoring burning as the preferred mechanism for handling revenues from Coretime sales.
    
-
    Motivation
    
+
    Motivation
    
 
    How to handle the revenue accrued from Coretime sales is an important economic question that influences the value of DOT and should be properly discussed before deciding for either of the options. Now is the best time to start this discussion.
    
-
    Stakeholders
    
+
    Stakeholders
    
 
    Polkadot DOT token holders.
    
-
    Explanation
    
+
    Explanation
    
 
    This RFC discusses potential benefits of burning the revenue accrued from Coretime sales instead of diverting them to Treasury. Here are the following arguments for it.
    
 
    It's in the interest of the Polkadot community to have a consistent and predictable Treasury income, because volatility in the inflow can be damaging, especially in situations when it is insufficient. As such, this RFC operates under the presumption of a steady and sustainable Treasury income flow, which is crucial for the Polkadot community's stability. The assurance of a predictable Treasury income, as outlined in a prior discussion here, or through other equally effective measures, serves as a baseline assumption for this argument. 
    
 
    Consequently, we need not concern ourselves with this particular issue here. This naturally begs the question - why should we introduce additional volatility to the Treasury by aligning it with the variable Coretime sales? It's worth noting that Coretime revenues often exhibit an inverse relationship with periods when Treasury spending should ideally be ramped up. During periods of low Coretime utilization (indicated by lower revenue), Treasury should spend more on projects and endeavours to increase the demand for Coretime. This pattern underscores that Coretime sales, by their very nature, are an inconsistent and unpredictable source of funding for the Treasury. Given the importance of maintaining a steady and predictable inflow, it's unnecessary to rely on another volatile mechanism. Some might argue that we could have both: a steady inflow (from inflation) and some added bonus from Coretime sales, but burning the revenue would offer further benefits as described below.
    
@@ -2465,13 +2333,13 @@ Also note that child tries aren't considered as descendants of the main trie whe
 AuthorsJoe Petrowski
 
 
-
    Summary
    
+
    Summary
    
 
    Since the introduction of the Collectives parachain, many groups have expressed interest in forming
 new -- or migrating existing groups into -- on-chain collectives. While adding a new collective is
 relatively simple from a technical standpoint, the Fellowship will need to merge new pallets into
 the Collectives parachain for each new collective. This RFC proposes a means for the network to
 ratify a new collective, thus instructing the Fellowship to instate it in the runtime.
    
-
    Motivation
    
+
    Motivation
    
 
    Many groups have expressed interest in representing collectives on-chain. Some of these include:
    
 
 
    The premise of this proposal is to offer a straightforward design that discovers the price of coretime within a period as a clearing_price. Long-term coretime holders still retain the privilege to keep their cores if they can pay the price discovered by the market (with some premium for that privilege). The proposed model aims to strike a balance between leveraging market forces for allocation while operating within defined bounds. In particular, prices are capped within a BULK_PERIOD, which gives some certainty about prices to existing teams. It must be noted, however, that under high demand, prices could increase exponentially between multiple market cycles. This is a necessary feature to ensure proper price discovery and efficient coretime allocation.
    
 
    Ultimately, the framework proposed here seeks to adhere to all requirements originally stated in RFC-1.
    
-
    Stakeholders
    
+
    Stakeholders
    
 
    Primary stakeholder sets are:
    
 
      
 
    • Protocol researchers, developers, and the Polkadot Fellowship.
      • 
 
    • Polkadot Parachain teams both present and future, and their users.
      • 
 
    • Polkadot DOT token holders.
      • 
 
    
-
    Explanation
    
+
    Explanation
    
 
    Overview
    
 
    The BULK_PERIOD has been restructured into two primary segments: the MARKET_PERIOD and the RENEWAL_PERIOD, along with an auxiliarySETTLEMENT_PERIOD. The latter does not require any active participation from the coretime system chain except to simply execute transfers of ownership between market participants. A significant departure from the current design lies in the timing of renewals, which now occur after the market phase. This adjustment aims to harmonize renewal prices with their market counterparts, ensuring a more consistent and equitable pricing model.
    
 
    Market Period (14 days)
    
@@ -2964,7 +2832,7 @@ To mitigate this, we propose preventing the market from closing at the ope
 
 
 
-
    Prior Art and References
    
+
    Prior Art and References
    
 
    This RFC builds extensively on the available ideas put forward in RFC-1. 
    
 
    Additionally, I want to express a special thanks to Samuel Haefner, Shahar Dobzinski, and Alistair Stewart for fruitful discussions and helping me structure my thoughts.
    
 
    (source)
    
@@ -2992,19 +2860,19 @@ To mitigate this, we propose preventing the market from closing at the ope
 Authors@brenzi for Encointer Association, 8000 Zurich, Switzerland
 
 
-
    Summary
    
+
    Summary
    
 
    Encointer is a system chain on Kusama since Jan 2022 and has been developed and maintained by the Encointer association. This RFC proposes to treat Encointer like any other system chain and include it in the fellowship repo with this PR.
    
-
    Motivation
    
+
    Motivation
    
 
    Encointer does not seek to be in control of its runtime repository. As a decentralized system, the fellowship has a more suitable structure to maintain a system chain runtime repo than the Encointer association does.
    
 
    Also, Encointer aims to update its runtime in batches with other system chains in order to have consistency for interoperability across system chains. 
    
-
    Stakeholders
    
+
    Stakeholders
    
 
      
 
    • Fellowship: Will continue to take upon them the review and auditing work for the Encointer runtime, but the process is streamlined with other system chains and therefore less time-consuming compared to the separate repo and CI process we currently have.
      • 
 
    • Kusama Network: Tokenholders can easily see the changes of all system chains in one place.
      • 
 
    • Encointer Association: Further decentralization of the Encointer Network necessities like devops.
      • 
 
    • Encointer devs: Being able to work directly in the Fellowship runtimes repo to streamline and synergize with other developers. 
      • 
 
    
-
    Explanation
    
+
    Explanation
    
 
    Our PR has all details about our runtime and how we would move it into the fellowship repo.
    
 
    Noteworthy: All Encointer-specific pallets will still be located in encointer's repo for the time being: https://github.com/encointer/pallets 
    
 
    It will still be the duty of the Encointer team to keep its runtime up to date and provide adequate test fixtures. Frequent dependency bumps with Polkadot releases would be beneficial for interoperability and could be streamlined with other system chains but that will not be a duty of fellowship. Whenever possible, all system chains could be upgraded jointly (including Encointer) with a batch referendum.
    
@@ -3013,17 +2881,17 @@ To mitigate this, we propose preventing the market from closing at the ope
 
  • Encointer will publish all its crates crates.io
    • 
 
  • Encointer does not carry out external auditing of its runtime nor pallets. It would be beneficial but not a requirement from our side if Encointer could join the auditing process of other system chains. 
    • 
 
-
    Drawbacks
    
+
    Drawbacks
    
 
    Other than all other system chains, development and maintenance of the Encointer Network is mainly financed by the KSM Treasury and possibly the DOT Treasury in the future. Encointer is dedicated to maintaining its network and runtime code for as long as possible, but there is a dependency on funding which is not in the hands of the fellowship. The only risk in the context of funding, however, is that the Encointer runtime will see less frequent updates if there's less funding. 
    
-
    Testing, Security, and Privacy
    
+
    Testing, Security, and Privacy
    
 
    No changes to the existing system are proposed. Only changes to how maintenance is organized.
    
-
    Performance, Ergonomics, and Compatibility
    
+
    Performance, Ergonomics, and Compatibility
    
 
    No changes
    
-
    Prior Art and References
    
+
    Prior Art and References
    
 
    Existing Encointer runtime repo
    
-
    Unresolved Questions
    
+
    Unresolved Questions
    
 
    None identified
    
-
+
 
    More info on Encointer: encointer.org
    
 
    (source)
    
 
    Table of Contents
    
@@ -3943,11 +3811,11 @@ other privacy-enhancing mechanisms to address this concern.
 AuthorsJoe Petrowski, Gavin Wood
 
 
-
    Summary
    
+
    Summary
    
 
    The Relay Chain contains most of the core logic for the Polkadot network. While this was necessary
 prior to the launch of parachains and development of XCM, most of this logic can exist in
 parachains. This is a proposal to migrate several subsystems into system parachains.
    
-
    Motivation
    
+
    Motivation
    
 
    Polkadot's scaling approach allows many distinct state machines (known generally as parachains) to
 operate with common guarantees about the validity and security of their state transitions. Polkadot
 provides these common guarantees by executing the state transitions on a strict subset (a backing
@@ -3959,13 +3827,13 @@ blockspace) to the network.
    
 
    By minimising state transition logic on the Relay Chain by migrating it into "system chains" -- a
 set of parachains that, with the Relay Chain, make up the Polkadot protocol -- the Polkadot
 Ubiquitous Computer can maximise its primary offering: secure blockspace.
    
-
    Stakeholders
    
+
    Stakeholders
    
 
      
 
    • Parachains that interact with affected logic on the Relay Chain;
      • 
 
    • Core protocol and XCM format developers;
      • 
 
    • Tooling, block explorer, and UI developers.
      • 
 
    
-
    Explanation
    
+
    Explanation
    
 
    The following pallets and subsystems are good candidates to migrate from the Relay Chain:
    
 
      
 
    • Identity
      • 
@@ -3990,7 +3858,7 @@ Ubiquitous Computer can maximise its primary offering: secure blockspace.
      
 
    
 
    Note: The Auctions and Crowdloan pallets will be replaced by Coretime, its system chain and
 interface described in RFC-1 and RFC-5, respectively.
    
-
    Migrations
    
+
    Migrations
    
 
    Some subsystems are simpler to move than others. For example, migrating Identity can be done by
 simply preventing state changes in the Relay Chain, using the Identity-related state as the genesis
 for a new chain, and launching that new chain with the genesis and logic (pallet) needed.
    
@@ -4111,36 +3979,36 @@ sensible to rehearse a migration.
    
 Staking is the subsystem most constrained by PoV limits. Ensuring that elections, payouts, session
 changes, offences/slashes, etc. work in a parachain on Kusama -- with its larger validator set --
 will give confidence to the chain's robustness on Polkadot.
    
-
    Drawbacks
    
+
    Drawbacks
    
 
    These subsystems will have reduced resources in cores than on the Relay Chain. Staking in particular
 may require some optimizations to deal with constraints.
    
-
    Testing, Security, and Privacy
    
+
    Testing, Security, and Privacy
    
 
    Standard audit/review requirements apply. More powerful multi-chain integration test tools would be
 useful in developement.
    
-
    Performance, Ergonomics, and Compatibility
    
+
    Performance, Ergonomics, and Compatibility
    
 
    Describe the impact of the proposal on the exposed functionality of Polkadot.
    
-
    Performance
    
+
    Performance
    
 
    This is an optimization. The removal of public/user transactions on the Relay Chain ensures that its
 primary resources are allocated to system performance.
    
-
    Ergonomics
    
+
    Ergonomics
    
 
    This proposal alters very little for coretime users (e.g. parachain developers). Application
 developers will need to interact with multiple chains, making ergonomic light client tools
 particularly important for application development.
    
 
    For existing parachains that interact with these subsystems, they will need to configure their
 runtimes to recognize the new locations in the network.
    
-
    Compatibility
    
+
    Compatibility
    
 
    Implementing this proposal will require some changes to pallet APIs and/or a pub-sub protocol.
 Application developers will need to interact with multiple chains in the network.
    
-
    Prior Art and References
    
+
    Prior Art and References
    
 
-
    Unresolved Questions
    
+
    Unresolved Questions
    
 
    There remain some implementation questions, like how to use balances for both Staking and
 Governance. See, for example, Moving Staking off the Relay
 Chain.
    
-
+
 
    Ideally the Relay Chain becomes transactionless, such that not even balances are represented there.
 With Staking and Governance off the Relay Chain, this is not an unreasonable next step.
    
 
    With Identity on Polkadot, Kusama may opt to drop its People Chain.
    
@@ -4175,13 +4043,13 @@ With Staking and Governance off the Relay Chain, this is not an unreasonable nex
 AuthorsVedhavyas Singareddi
 
 
-
    Summary
    
+
    Summary
    
 
    At the moment, we have system_version field on RuntimeVersion that derives which state version is used for the
 Storage.
 We have a use case where we want extrinsics root is derived using StateVersion::V1. Without defining a new field
 under RuntimeVersion,
 we would like to propose adding system_version that can be used to derive both storage and extrinsic state version.
    
-
    Motivation
    
+
    Motivation
    
 
    Since the extrinsic state version is always StateVersion::V0, deriving extrinsic root requires full extrinsic data.
 This would be problematic when we need to verify the extrinsics root if the extrinsic sizes are bigger. This problem is
 further explored in https://github.com/polkadot-fellows/RFCs/issues/19
    
@@ -4193,11 +4061,11 @@ One of the main challenge here is some extrinsics could be big enough that this
 included in the Consensus block due to Block's weight restriction.
 If the extrinsic root is derived using StateVersion::V1, then we do not need to pass the full extrinsic data but
 rather at maximum, 32 byte of extrinsic data.
    
-
    Stakeholders
    
+
    Stakeholders
    
 
      
 
    • Technical Fellowship, in its role of maintaining system runtimes.
      • 
 
    
-
    Explanation
    
+
    Explanation
    
 
    In order to use project specific StateVersion for extrinsic roots, we proposed
 an implementation that introduced
 parameter to frame_system::Config but that unfortunately did not feel correct.
@@ -4223,26 +4091,26 @@ pub const VERSION: RuntimeVersion = RuntimeVersion {
 		system_version: 1,
 	};
 }
    -

    Drawbacks

    +

    Drawbacks

    There should be no drawbacks as it would replace state_version with same behavior but documentation should be updated so that chains know which system_version to use.

    -

    Testing, Security, and Privacy

    +

    Testing, Security, and Privacy

    AFAIK, should not have any impact on the security or privacy.

    -

    Performance, Ergonomics, and Compatibility

    +

    Performance, Ergonomics, and Compatibility

    These changes should be compatible for existing chains if they use state_version value for system_verision.

    -

    Performance

    +

    Performance

    I do not believe there is any performance hit with this change.

    -

    Ergonomics

    +

    Ergonomics

    This does not break any exposed Apis.

    -

    Compatibility

    +

    Compatibility

    This change should not break any compatibility.

    -

    Prior Art and References

    +

    Prior Art and References

    We proposed introducing a similar change by introducing a parameter to frame_system::Config but did not feel that is the correct way of introducing this change.

    -

    Unresolved Questions

    +

    Unresolved Questions

    I do not have any specific questions about this change at the moment.

    - +

    IMO, this change is pretty self-contained and there won't be any future work necessary.

    (source)

    Table of Contents

    @@ -4271,9 +4139,9 @@ is the correct way of introducing this change.

    AuthorsSebastian Kunert -

    Summary

    +

    Summary

    This RFC proposes a new host function for parachains, storage_proof_size. It shall provide the size of the currently recorded storage proof to the runtime. Runtime authors can use the proof size to improve block utilization by retroactively reclaiming unused storage weight.

    -

    Motivation

    +

    Motivation

    The number of extrinsics that are included in a parachain block is limited by two constraints: execution time and proof size. FRAME weights cover both concepts, and block-builders use them to decide how many extrinsics to include in a block. However, these weights are calculated ahead of time by benchmarking on a machine with reference hardware. The execution-time properties of the state-trie and its storage items are unknown at benchmarking time. Therefore, we make some assumptions about the state-trie:

     Transact Over Bridge -

    Drawbacks

    +

    Drawbacks

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

    In terms of 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 one suggested in this RFC should be the right choice for the majority of chains, but each chain will ultimately choose 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

    +

    Testing, Security, and Privacy

    Barriers should now allow AliasOrigin, DescendOrigin 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

    +

    Performance, Ergonomics, and Compatibility

    +

    Performance

    No impact.

    -

    Ergonomics

    +

    Ergonomics

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

    -

    Compatibility

    +

    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

    +

    Prior Art and References

    -

    Unresolved Questions

    +

    Unresolved Questions

    None

    - +

    (source)

    Table of Contents

    -

    Stakeholders

    +

    Stakeholders

    • Runtime Developers
    • Tools/UI Developers
    -

    Explanation

    +

    Explanation

    The core idea of PVQ is to have a unified interface that meets the aforementioned requirements.

    On the runtime side, an extension-based system is introduced to serve as a standardization layer across different chains. Each extension specification defines a set of cohesive APIs. @@ -7742,12 +7610,12 @@ enum PvqError {

  • ExceedsMaxMessageSize
  • Transport
    • -

    Drawbacks

    +

    Drawbacks

    Performance issues

    • PVQ Program Size: The size of a complicated PVQ program may be too large to be suitable for efficient storage and transmission via XCMP/HRMP.
    -

    Testing, Security, and Privacy

    +

    Testing, Security, and Privacy

    • Testing:

      @@ -7784,27 +7652,27 @@ enum PvqError { N/A

    -

    Performance, Ergonomics, and Compatibility

    -

    Performance

    +

    Performance, Ergonomics, and Compatibility

    +

    Performance

    As a newly introduced feature, PVQ operates independently and does not impact or degrade the performance of existing runtime implementations.

    -

    Ergonomics

    +

    Ergonomics

    From the perspective of off-chain tooling, this proposal streamlines development by unifying multiple chain-specific RuntimeAPIs under a single consistent interface. This significantly benefits wallet and dApp developers by eliminating the need to handle individual implementations for similar operations across different chains. The proposal also enhances development flexibility by allowing custom computations to be modularly encapsulated as PolkaVM programs that interact with the exposed APIs.

    -

    Compatibility

    +

    Compatibility

    For RuntimeAPI integration, the proposal defines new APIs, which do not break compatibility with existing interfaces. For XCM Integration, the proposal does not modify the existing XCM message format, which is backwards compatible.

    -

    Prior Art and References

    +

    Prior Art and References

    There are several discussions related to the proposal, including:

    • Original discussion about having a mechanism to avoid code duplications between the runtime and front-ends/wallets. In the original design, the custom computations are compiled as a wasm function.
    • View functions aims to provide view-only functions at the pallet level. Additionally, Facade Project aims to gather and return commonly wanted information in runtime level. PVQ does not conflict with them, and it can take advantage of these Pallet View Functions / Runtime APIs and allow people to build arbitrary PVQ programs to obtain more custom/complex data that is not otherwise expressed by these two proposals.
    -

    Unresolved Questions

    +

    Unresolved Questions

    • The specific conversion between gas and weight has not been finalized and will likely require development of a suitable benchmarking methodology.
    - +

    Once PVQ and the aforementioned Facade Project are ready, there are opportunities to consolidate overlapping functionality between the two systems. For example, the metadata APIs could potentially be unified to provide a more cohesive interface for runtime information. This would help reduce duplication and improve maintainability while preserving the distinct benefits of each approach.

    (source)

    Table of Contents

    @@ -7842,14 +7710,14 @@ PVQ does not conflict with them, and it can take advantage of these Pallet View Authorss0me0ne-unkn0wn (13WGadgNgqSjiGQvfhimw9pX26mvGdYQ6XgrjPANSEDRoGMt) -

    Summary

    +

    Summary

    This RFC proposes a change that makes it possible to identify types of compressed blobs stored on-chain, as well as used off-chain, without the need for decompression.

    -

    Motivation

    +

    Motivation

    Currently, a compressed blob does not give any idea of what's inside because the only thing that can be inside, according to the spec, is Wasm. In reality, other blob types are already being used, and more are to come. Apart from being error-prone by itself, the current approach does not allow to properly route the blob through the execution paths before its decompression, which will result in suboptimal implementations when more blob types are used. Thus, it is necessary to introduce a mechanism allowing to identify the blob type without decompressing it.

    This proposal is intended to support future work enabling Polkadot to execute PolkaVM and, more generally, other-than-Wasm parachain runtimes, and allow developers to introduce arbitrary compression methods seamlessly in the future.

    -

    Stakeholders

    +

    Stakeholders

    Node developers are the main stakeholders for this proposal. It also creates a foundation on which parachain runtime developers will build.

    -

    Explanation

    +

    Explanation

    Overview

    The current approach to compressing binary blobs involves using zstd compression, and the resulting compressed blob is prefixed with a unique 64-bit magic value specified in that subsection. The same procedure is used to compress both Wasm code blobs and proofs-of-validity. Currently, having solely a compressed blob, it's impossible to tell what's inside it without decompression, a Wasm blob, or a PoV. That doesn't cause problems in the current protocol, as Wasm blobs and PoV blobs take completely different execution paths in the code.

    The changes proposed below are intended to define the means for distinguishing compressed blob types in a backward-compatible and future-proof way.

    @@ -7870,26 +7738,26 @@ PVQ does not conflict with them, and it can take advantage of these Pallet View
  • Conservatively, wait until no more PVFs prefixed with CBLOB_ZSTD_LEGACY remain on-chain. That may take quite some time. Alternatively, create a migration that alters prefixes of existing blobs;
  • Removing CBLOB_ZSTD_LEGACY prefix will be possible after all the nodes in all the networks cease using the prefix which is a long process, and additional incentives should be offered to the community to make people upgrade.
    • -

    Drawbacks

    +

    Drawbacks

    Currently, the only requirement for a compressed blob prefix is not to coincide with Wasm magic bytes (as stated in code comments). Changes proposed here increase prefix collision risk, given that arbitrary data may be compressed in the future. However, it must be taken into account that:

    • Collision probability per arbitrary blob is ≈5,4×10⁻²⁰ for a single random 64-bit prefix (current situation) and ≈2,17×10⁻¹⁹ for the proposed set of four 64-bit prefixes (proposed situation), which is still low enough;
    • The current de facto protocol uses the current compression implementation to compress PoVs, which are arbitrary binary data, so the collision risk already exists and is not introduced by changes proposed here.
    -

    Testing, Security, and Privacy

    +

    Testing, Security, and Privacy

    As the change increases granularity, it will positively affect both testing possibilities and security, allowing developers to check what's inside a given compressed blob precisely. Testing the change itself is trivial. Privacy is not affected by this change.

    -

    Performance, Ergonomics, and Compatibility

    -

    Performance

    +

    Performance, Ergonomics, and Compatibility

    +

    Performance

    The current implementation's performance is not affected by this change. Future implementations allowing for the execution of other-than-Wasm parachain runtimes will benefit from this change performance-wise.

    -

    Ergonomics

    +

    Ergonomics

    The end-user ergonomics is not affected. The ergonomics for developers will benefit from this change as it enables exact checks and less guessing.

    -

    Compatibility

    +

    Compatibility

    The change is designed to be backward-compatible.

    -

    Prior Art and References

    +

    Prior Art and References

    SDK PR#6704 (WIP) introduces a mechanism similar to that described in this proposal and proves the necessity of such a change.

    -

    Unresolved Questions

    +

    Unresolved Questions

    None

    - +

    This proposal creates a foundation for two future work directions:

    • Proposing to introduce other-than-Wasm code executors, including PolkaVM, allowing parachain runtime authors to seamlessly change execution platform using the existing mechanism of runtime upgrades;
      • @@ -7929,9 +7797,9 @@ PVQ does not conflict with them, and it can take advantage of these Pallet View Authorsordian -

      Summary

      +

      Summary

      This RFC proposes changes to the erasure coding algorithm and the method for computing the erasure root on Polkadot to improve performance of both processes.

      -

      Motivation

      +

      Motivation

      The Data Availability (DA) Layer in Polkadot provides a foundation for shared security, enabling Approval Checkers and Collators to download Proofs-of-Validity (PoV) for security and liveness purposes respectively. @@ -7948,12 +7816,12 @@ The proposed change is orthogonal to RFC-47 and can be used in conjunction with collator nodes), we propose bundling another performance-enhancing breaking change that addresses the CPU bottleneck in the erasure coding process, but using a separate node feature (NodeFeatures part of HostConfiguration) for its activation.

      -

      Stakeholders

      +

      Stakeholders

      • Infrastructure providers (operators of validator/collator nodes) will need to upgrade their client version in a timely manner
      -

      Explanation

      +

      Explanation

      We propose two specific changes:

      1. @@ -7987,24 +7855,24 @@ faster deployment for most parachains but would add complexity.

      2. Activate RFC-47 via Configuration::set_node_feature runtime change.
      3. Activate the new erasure coding scheme using another Configuration::set_node_feature runtime change.
      -

      Drawbacks

      +

      Drawbacks

      Bundling this breaking change with RFC-47 might reset progress in updating collators. However, the omni node initiative should help mitigate this issue.

      -

      Testing, Security, and Privacy

      +

      Testing, Security, and Privacy

      Testing is needed to ensure binary compatibility across implementations in multiple languages.

      Performance and Compatibility

      -

      Performance

      +

      Performance

      According to benchmarks:

      • A proper SIMD implementation of Reed-Solomon is 3-4× faster for encoding and up to 9× faster for full decoding
      • Binary Merkle Trees produce proofs that are 4× smaller and slightly faster to generate and verify
      -

      Compatibility

      +

      Compatibility

      This requires a breaking change that can be coordinated following the same approach as in RFC-47.

      -

      Prior Art and References

      +

      Prior Art and References

      JAM already utilizes the same optimizations described in the Graypaper.

      -

      Unresolved Questions

      +

      Unresolved Questions

      None.

      - +

      Future improvements could include:

      • Using ZK proofs to eliminate the need for re-encoding data to verify correct encoding
        • @@ -8034,7 +7902,7 @@ faster deployment for most parachains but would add complexity.

        AuthorsJonas Gehrlein -

        Summary

        +

        Summary

        This RFC proposes burning 80% of transaction fees accrued on Polkadot’s Relay Chain and, more significantly, on all its system parachains. The remaining 20% would continue to incentivize Validators (on the Relay Chain) and Collators (on system parachains) for including transactions. The 80:20 split is motivated by preserving the incentives for Validators, which are crucial for the security of the network, while establishing a consistent fee policy across the Relay Chain and all system parachains.

        • @@ -8045,7 +7913,7 @@ faster deployment for most parachains but would add complexity.

        This proposal extends the system's deflationary direction and is enabling direct value capture for DOT holders of an overall increased activity on the network.

        -

        Motivation

        +

        Motivation

        Historically, transaction fees on both the Relay Chain and the system parachains (with a few exceptions) have been relatively low. This is by design—Polkadot is built to scale and offer low-cost transactions. While this principle remains unchanged, growing network activity could still result in a meaningful accumulation of fees over time.

        Implementing this RFC ensures that potentially increasing activity manifesting in more fees is captured for all token holders. It further aligns the way that the network is handling fees (such as from transactions or for coretime usage) is handled. The arguments in support of this are close to those outlined in RFC0010. Specifically, burning transaction fees has the following benefits:

        Compensation for Coretime Usage

        @@ -8053,7 +7921,7 @@ faster deployment for most parachains but would add complexity.

        Value Accrual and Deflationary Pressure

        By burning the transaction fees, the system effectively reduces the token supply and thereby increase the scarcity of the native token. This deflationary pressure can increase the token's long-term value and ensures that the value captured is translated equally to all existing token holders.

        This proposal requires only minimal code changes, making it inexpensive to implement, yet it introduces a consistent policy for handling transaction fees across the network. Crucially, it positions Polkadot for a future where fee burning could serve as a counterweight to an otherwise inflationary token model, ensuring that value generated by network usage is returned to all DOT holders.

        -

        Stakeholders

        +

        Stakeholders

        • All DOT Token Holders: Benefit from reduced supply and direct value capture as network usage increases.

          @@ -8091,12 +7959,12 @@ faster deployment for most parachains but would add complexity.

          Authorseskimor -

          Summary

          +

          Summary

          This RFC proposes an amendment to RFC-1 Agile Coretime: Renewal prices will no longer only be adjusted based on a configurable renewal bump, but also to the lower end of the current sale - if that turns out higher.

          An implementation can be found here.

          -

          Motivation

          +

          Motivation

          In RFC-1, we strived for perfect predictability on renewal prices, but what we expected unfortunately got proven in practice: Perfect predictability allows for core hoarding and cheap market manipulation, with the effect that both on @@ -8108,9 +7976,9 @@ extend to elastic scaling and in practice, even existing teams wanting to keep their core, because they forgot to renew in the interlude.

          In a nutshell the current situation is severely hindering teams from deploying on Polkadot: We are essentially in a Denial of Service situation.

          -

          Stakeholders

          +

          Stakeholders

          Stakeholders should be existing teams already having a core and new teams wanting to join the ecosystem.

          -

          Explanation

          +

          Explanation

          This RFC proposes to fix this situation, by limiting renewal price predictability to reasonable levels, by introducing a weak coupling to the current market price: We ensure that the price for renewals is at least as high @@ -8178,13 +8046,13 @@ ensures that any additional attack will be expensive: 10 cores, results in to 100% capacity to have some leeway for governance in case of unforeseen attacks/weaknesses.

          • -

          Drawbacks

          +

          Drawbacks

          We are dropping almost perfect predictability on renewal prices, in favor of predictability within reasonable bounds. The introduction of a minimum price, will also result in huge relative price adjustments for existing tenants, because prices were so unreasonably low on Kusama. In practice this should not be an issue for any real project.

          -

          Testing, Security, and Privacy

          +

          Testing, Security, and Privacy

          This RFC is proposing a single line of code change. A test has been added to make sure it is working as expected.

          @@ -8207,15 +8075,15 @@ tenants. Having them exposed at least with this 10x reduction seems a sensible valuation.

          There are no privacy concerns.

          -

          Performance, Ergonomics, and Compatibility

          +

          Performance, Ergonomics, and Compatibility

          The proposed changes are backwards compatible. No interfaces are changed. Performance is not affected. Ergonomics should be greatly improved especially for new entrants, as cores will be available for sale again. A configured minimum price also ensures that the starting price of the Dutch auction stays reasonably high, deterring sniping all the cores at the beginning of a sale.

          -

          Prior Art and References

          +

          Prior Art and References

          This RFC is altering RFC-1 and taking ideas from RFC-17, mainly the introduction of a minimum price.

          - +

          This RFC should solve the immediate problems we are seeing in production right now. Longer term, improvements to the market in terms of price discovery (RFC-17) should be considered, especially once demand grows.

          @@ -8230,6 +8098,138 @@ now. Longer term, improvements to the market in terms of price discovery

          Mitigation for this edge case is relatively simple: Bump renewals more aggressively the less cores are available on the free market. For now, leaving a few cores not for sale should be enough to mitigate such a situation.

          +

          (source)

          +

          Table of Contents

          + +

          RFC-150: Allow Voting While Delegating

          +
          + + + +
          Start DateJune 5th, 2025
          DescriptionAllow voters to simultaneously delegate and vote
          Authorspolka.dom (polkadotdom)
          +
          +

          Summary

          +

          This RFC proposes changes to pallet-conviction-voting that allow for simultaneous voting and delegation. For example, Alice could delegate to Bob, then later vote on a referendum while keeping their delegation to Bob intact. It is a strict subset of Leemo's RFC 35.

          +

          Motivation

          +

          Backdrop

          +

          Under our current voting system, a voter can either vote or delegate. To vote, they must first ensure they have no delegate, and to delegate, they must first clear their current votes.

          +

          The Issue

          +

          Empirically, the vast majority of people do not vote on day to day policy. This was foreseen and is the reason governance has delegation. However, more worriedly, it has also been observed that most people do not delegate either, leaving a large percentage of our voting population unrepresented.

          +

          Factors Limiting Delegation

          +

          One could think of three major reasons for this lack of delegation.

          +
            +
          • The voter does not know of anyone who accurately represents them.
            • +
          • The voter does not want their right to vote stripped, in consideration of some yet unknown, highly important, referendum.
            • +
          • The voter does not want to clear their voting data so as to delegate.
            • +
          +

          This RFC aims to solve the second and third issue and thus more accurately align governance to the true voter preferences.

          +

          An Aside

          +

          One may ask, could a voter not just undelegate, vote, then delegate again? Could this just be built into the user interface? Unfortunately, this does not work due to the need to clear their votes before redelegation. In practice the voter would undelegate, vote, wait until the referendum is closed, hope that there's no other referenda they would like to vote on, then redelegate. At best it's a temporally extended friction. At worst the voter goes unrepresented in voting for the duration of the vote clearing period.

          +

          Stakeholders

          +

          Runtime developers: If runtime developers are relying on the previous assumptions for their VotingHooks implementations, they will need to rethink their approach. In addition, a runtime migration is needed. Lastly, it is a serious change in governance that requires some consideration beyond the technical.

          +

          App developers: Apps like Subsquare and Polkassembly would need to update their user interface logic. They will also need to handle the new error.

          +

          Users: We will want users to be aware of the new functionality, though not required.

          +

          Technical Writers: This change will require rewrites of documentation and tutorials.

          +

          Explanation

          +

          New Data & Runtime Logic

          +

          The new logic allows a delegator's vote on a specific poll to override their delegation for that poll only. When a delegator votes, their delegated voting power is temporarily "clawed back" from their delegate for that single referendum. This ensures a delegator's direct vote takes precedence.

          +

          The core of the algorithm is as follows:

          +
            +
          1. +

            Calculating a User's Voting Power: A user's total voting power on any given poll is their own balance plus the total balance delegated to them, minus the total amount retracted by any of their delegators who chose to vote directly on that poll.

            +
            2. +
          2. +

            Tracking Clawbacks: When a delegator votes, the system records the full amount of their delegated stake as "retracted" on their delegate's account for that specific poll. This clawback is always for the delegator's full delegated amount, regardless of the amount they personally vote with. This is for simplicity and to avoid making assumptions about the delegator's intent. Crucially, clawbacks from multiple delegators can be accumulated, such that only one tracking entry per referendum is necessary.

            +
            3. +
          +

          Here is how the logic plays out in different scenarios:

          +
            +
          • +

            When a Delegator Votes:

            +
              +
            1. Alice delegates 10 UNITS to Bob. She then votes 'Aye' on Referendum #5 with her own 5 UNITS.
              2. +
            2. The system adds Alice's 5 UNITS to the 'Aye' tally for Referendum #5.
              3. +
            3. Simultaneously, the system creates a "retracted votes" entry on Bob's account, specific to Referendum #5, for the full 10 UNITS. If he had already voted, the tally would be adjusted to remove Alice's 10 UNITS.
              4. +
            4. If Bob now votes, or changes his previous vote, his voting power will be his own balance plus all delegations except for Alice's 10 UNITS for this specific poll.
              5. +
            +
            • +
          • +

            When a Delegator Removes Their Vote:

            +
              +
            1. Following the above, Alice removes her vote from Referendum #5.
              2. +
            2. The system removes her 5 UNITS from the 'Aye' tally.
              3. +
            3. The system also removes the "retracted votes" entry from Bob's account. This action "returns" the 10 UNITS of voting power to Bob for Referendum #5. If Bob has a vote, the poll tally is updated accordingly.
              4. +
            4. The cleanup of the delegate's state is handled by the delegator's transaction to ensure no orphaned data remains.
              5. +
            +
            • +
          +

          A key consequence of this design is that a delegator's vote can alter their delegate's storage. If adding a "retracted votes" entry pushes the delegate's voting data beyond the MaxVotes limit, the delegator's transaction will fail. A new error will be introduced to signal this specific case. While a constraint, this will incentivize delegates to regularly clear their voting data for concluded referenda, and given our current referenda rates and MaxVotes set to 512, this scenario is unlikely to occur.

          +

          Locked Balance

          +

          A user's locked balance will be the greater of the delegation lock and the voting lock.

          +

          Migrations

          +

          A multi-block runtime migration is necessary. It would iterate over the VotingFor storage item and convert the old vote data structure to the new structure.

          +

          Drawbacks

          +

          There are two potential drawbacks to this system -

          +

          An unbounded rate of change of the voter preferences function

          +

          If implemented, there will be no friction in delegating, undelegating, and voting. Therefore, there could be large and immediate shifts in the voter preferences function. In other voting systems we see bounds added to the rate of change (voting cycles, etc). That said, it is unclear whether this is desired or advantageous. Additionally, there are more easily parameterized and analytically tractable ways to handle this than what we currently have. See future directions.

          +

          Lessened value in becoming a delegate

          +

          If a delegate's voting power can be stripped from them at any point, then there is necessarily a reduction in their power within the system. This provides less incentive to become a delegate. But again, there are more customizable ways to handle this if it proves necessary.

          +

          Testing, Security, and Privacy

          +

          The changes herein would allow for a cost-symmetric grief in which a delegator votes on every referendum, adding more votes to the delegate's record, then accepts the lock and waits until the delegate themselves pays to remove the vote from their record-- costing the delegate cost_of_removal_per_ref * number_of_refs_not_voted_on. This cost will inevitably be small and accepted by aspirational delegates, considering they'll be voting on most refs anyway. However, for those who don't want to incur the possibility of this cost, we introduce a per voting class flag that toggles delegator voting on/off.

          +

          In addition, these changes would mean a more complicated STF, which would increase the difficulty of hardening. Though sufficient unit testing should handle this with ease.

          +

          Performance, Ergonomics, and Compatibility

          +

          Performance

          +

          The proposed changes would increase both the compute and storage requirements by about 2x for all voting functions. No change in complexity.

          +

          Ergonomics

          +

          Voting and delegation will both become more ergonomic for users, as there are no longer hard constraints affecting what you can do and when you can do it.

          +

          Compatibility

          +

          Runtime developers will need to add the migration and ensure their hooks still work.

          +

          App developers will need to update their user interfaces to accommodate the new functionality. They will need to handle the new error as well.

          +

          Prior Art and References

          +

          A current implementation can be found here.

          +

          Unresolved Questions

          +

          None

          + +

          It is possible we would like to add a system parameter for the rate of change of the voting/delegation system. This could prevent wild swings in the voter preferences function and motivate/shield delegates by solidifying their positions over some amount of time. However, it's unclear that this would be valuable or even desirable.

          (source)

          Table of Contents

            diff --git a/proposed/0145-remove-unnecessary-allocator-usage.html b/proposed/0145-remove-unnecessary-allocator-usage.html index 59ea877..3dcd437 100644 --- a/proposed/0145-remove-unnecessary-allocator-usage.html +++ b/proposed/0145-remove-unnecessary-allocator-usage.html @@ -90,7 +90,7 @@ @@ -924,7 +924,7 @@ $$

            - @@ -938,7 +938,7 @@ $$

            - diff --git a/proposed/0154-multi-slot-aura.html b/proposed/0154-multi-slot-aura.html index 39a1673..c59c678 100644 --- a/proposed/0154-multi-slot-aura.html +++ b/proposed/0154-multi-slot-aura.html @@ -90,7 +90,7 @@ @@ -266,7 +266,7 @@ This approach is compatible with the Slot-Based collation and the currently depl