ope
| Authors | Bryan Chen, Pablo Dorado |
-
+
A followup of the RFC-0014. This RFC proposes adding a new collective to the Polkadot Collectives
Chain: The Unbrick Collective, as well as improvements in the mechanisms that will allow teams
operating paras that had stopped producing blocks to be assisted, in order to restore the production
of blocks of these paras.
-
+
Since the initial launch of Polkadot parachains, there has been many incidients causing parachains
to stop producing new blocks (therefore, being bricked) and many occurrences that required
Polkadot governance to update the parachain head state/wasm. This can be due to many reasons range
@@ -618,14 +512,14 @@ damage to the parachain and users.
Polkadot Fellowship), due to the nature of their mission, are not fit to carry these kind of tasks.
In consequence, the idea of a Unbrick Collective that can provide assistance to para teams when
they brick and further protection against future halts is reasonable enough.
-
+
- Parachain teams
- Parachain users
- OpenGov users
- Polkadot Fellowship
-
+
The Unbrick Collective is defined as an unranked collective of members, not paid by the Polkadot
Treasury. Its main goal is to serve as a point of contact and assistance for enacting the actions
@@ -693,31 +587,31 @@ of the new PVF being set). Therefore, they must have the technical capacity to p
Being a CTO or Technical Lead in a para team that has opted-in to delegate the Unbrick Collective
to manage the PVF/head state of the para.
-
+
The ability to modify the Head State and/or the PVF of a para means a possibility to perform
arbitrary modifications of it (i.e. take control the native parachain token or any bridged assets
in the para).
This could introduce a new attack vector, and therefore, such great power needs to be handled
carefully.
-
+
The implementation of this RFC will be tested on testnets (Rococo and Westend) first.
An audit will be required to ensure the implementation doesn't introduce unwanted side effects.
There are no privacy related concerns.
-
-
+
+
This RFC should not introduce any performance impact.
-
+
This RFC should improve the experience for new and existing parachain teams, lowering the barrier
to unbrick a stalled para.
-
+
This RFC is fully compatible with existing interfaces.
-
+
-
+
- What are the parameters for the
WhitelistedUnbrickCaller track?
- Any other methods that shall be updated to accept
Unbrick origin?
@@ -769,7 +663,7 @@ of the paras, the locked/unlocked state, and the manager info.
| Authors | Pierre Krieger, Someone Unknown |
-
+
Update the runtime-host interface so that it no longer uses the host-side allocator.
The API of these new functions was heavily inspired by the API used by the C programming language.
@@ -785,14 +679,14 @@ of the paras, the locked/unlocked state, and the manager info.
- Added new versions of
ext_misc_runtime_version and ext_offchain_random_seed.
- Addressed discussions from the original RFC-4 discussion flow.
-
+
The heap allocation of the runtime is currently controlled by the host using a memory allocator on the host side.
The API of many host functions contains buffer allocations. For example, when calling ext_hashing_twox_256_version_1, the host allocates a 32-byte buffer using the host allocator, and returns a pointer to this buffer to the runtime. The runtime later has to call ext_allocator_free_version_1 on this pointer to free the buffer.
Even though no benchmark has been done, it is pretty obvious that this design is very inefficient. To continue with the example of ext_hashing_twox_256_version_1, it would be more efficient to instead write the output hash to a buffer allocated by the runtime on its stack and passed by pointer to the function. Allocating a buffer on the stack in the worst-case scenario consists of simply decreasing a number; in the best-case scenario, it is free. Doing so would save many VM memory reads and writes by the allocator, and would save a function call to ext_allocator_free_version_1.
Furthermore, the existence of the host-side allocator has become questionable over time. It is implemented in a very naive way, and for determinism and backwards compatibility reasons, it needs to be implemented exactly identically in every client implementation. Runtimes make substantial use of heap memory allocations, and each allocation needs to go through the runtime <-> host boundary twice (once for allocating and once for freeing). Moving the allocator to the runtime side would be a good idea, although it would increase the runtime size. But before the host-side allocator can be deprecated, all the host functions that use it must be updated to avoid using it.
-
+
No attempt was made to convince stakeholders.
-
+
This section contains a list of new host functions to introduce and amendments to the existing ones.
(func $ext_storage_read_version_2
@@ -1002,7 +896,7 @@ The ext_crypto_ed25519_public_key_version_1 function writes the pub
ext_allocator_free_version_1
ext_offchain_network_state_version_1
-
+
The changes in this RFC would need to be benchmarked. That involves implementing the RFC and measuring the speed difference.
It is expected that most host functions are faster or equal in speed to their deprecated counterparts, with the following exceptions:
@@ -1043,7 +937,7 @@ The ext_crypto_ed25519_public_key_version_1 function writes the pub
| Authors | Jonas Gehrlein |
-
+
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.
-
@@ -1054,7 +948,7 @@ The
ext_crypto_ed25519_public_key_version_1 function writes the pub
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.
-
+
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:
@@ -1062,7 +956,7 @@ The ext_crypto_ed25519_public_key_version_1 function writes the pub
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.
-
+
Some system parachains may accept other assets deemed sufficient for transaction fees. This has no implication for this proposal as the asset conversion pallet ensures that DOT is ultimately used to pay for the fees, which can be burned.
+(source)
+Table of Contents
+
+
+ | |
|---|
+| Start Date | June 5th, 2025 |
+| Description | Allow voters to simultaneously delegate and vote |
+| Authors | polka.dom (polkadotdom) |
+
+
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.
+
+
+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.
+
+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.
+
+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.
+
+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.
+
+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.
+
+
+The Voting Enum is first collapsed, as there's no longer a distinction between the variants. Then a (poll index -> retracted votes count) data item would be added to the user's voting data stored in VotingFor. This would keep track of the per poll balance that has been clawed back from the user by those delegating to them.
+The implementation must allow for the (poll index -> retracted votes) data to exist even if the user does not currently have a vote for that poll. A simple example that highlights the necessity is as follows: A delegator votes first, then the delegate does. If the delegator is not allowed to create the retracted votes data on the delegate, the tally count would be corrupted when the delegate votes.
+It follows then that the delegator must also handle clean up of that data when their vote is removed. Otherwise, the delegate has no immediate monetary incentive to clean the retracted votes state.
+All changes to pallet-conviction-voting's STF would follow those simple changes. For example, when a user votes standard, the final amount added to the poll's tally will be balance + (amount delegated to user - retracted votes). Then, if they are delegating, it will update their delegate's vote data with the newly retracted votes.
+The retracted amount is always the full delegated amount. For example, if Alice delegates 10 UNITS to Bob and then votes with 5 UNITS, the full 10 UNITS is still added as a clawback to Bob for that poll. This is both for simplicity and to ensure we don't make unnecessary assumptions about what Alice wants.
+Because you need to add the clawback, a delegator's vote can affect a delegate's voting data. If a delegator's vote or delegation makes the delegate's voting data exceed MaxVotes, the transaction will fail. In practice, this means this new system is somewhere between the old and the ideal. However, this will incentivize delegates to stay on top of voting data clearance. And given our current referenda rates and MaxVotes set to 512, it would be difficult to hit this limit.
+A new error is to be introduced that signals MaxVotes was reached specifically for the delegate's voting data.
+
+A user's locked balance will be the greater of the delegation lock and the voting lock.
+
+A runtime migration is necessary, though simple considering voting and delegation are currently separate.
+
+There are two potential drawbacks to this system -
+
+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.
+
+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.
+
+This change would mean a more complicated STF for voting, which would increase difficulty of hardening. Though sufficient unit testing should handle this with ease.
+
+
+The proposed changes would increase both the compute and storage requirements by about 2x for all voting functions. No change in complexity.
+
+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.
+
+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.
+
+A current WIP implementation can be found here. While WIP, it is STF complete & heavily commented for ease of understanding.
+
+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/0000-pre-elves_soft.html b/proposed/0000-pre-elves_soft.html
index f50984c..edca180 100644
--- a/proposed/0000-pre-elves_soft.html
+++ b/proposed/0000-pre-elves_soft.html
@@ -90,7 +90,7 @@
@@ -276,7 +276,7 @@