Conviction Voting Delegation Modifications #35
Conversation
|
👍 🚀 💯 |
|
Keep in mind with # 4, I'm not sure costs would decrease much because all of the logic has to be done for every track anyway, with exception of a couple things that don't change like the nonsense check, the lock, and the balance check. And # 1 is definitely needed as well. It definitely alleviates worries delegators have about disagreeing with a specific vote even though they agree with a delegate generally. |
|
|
||
| 3. **Have delegated votes follow their delegates abstain votes** – there are times where delegates may vote abstain on a particular referendum and adding this functionality will increase the support of a particular referendum. It has a secondary benefit of meaning that Validators who are delegating their voting power do not lose points in the 1KV program in the event that their delegate votes abstain (another pain point which may be preventing those network participants from delegating). | ||
|
|
||
| 4. **Allow a Delegator to delegate/ undelegate their votes for all tracks with a single call** - in order to delegate votes across all tracks, a user must batch 15 calls - resulting in high costs for delegation. A single call for `delegate_all`/ `undelegate_all` would reduce the complexity and therefore costs of delegations considerably for prospective Delegators. |
There was a problem hiding this comment.
To me, this one seems very doable.
|
|
||
| 2. **Allow nested delegations – for example Charlie delegates to Bob who delegates to Alice – when Alice votes then both Bob and Charlie vote alongside Alice (in the current runtime Charlie will not vote when Alice votes)** – This would allow network participants who control multiple (possibly derived) accounts to be able to delegate all of their voting power to a single account under their control, which would in turn delegate to a more active voting participant. Then if the delegator wishes to vote independently of their delegate they can control all of their voting power from a single account, which again removes the pain point of having to issue multiple undelegate extrinsics in the event that they disagree with their delegate. | ||
|
|
||
| 3. **Have delegated votes follow their delegates abstain votes** – there are times where delegates may vote abstain on a particular referendum and adding this functionality will increase the support of a particular referendum. It has a secondary benefit of meaning that Validators who are delegating their voting power do not lose points in the 1KV program in the event that their delegate votes abstain (another pain point which may be preventing those network participants from delegating). |
There was a problem hiding this comment.
Without a deep look at the code, this seems to me to be much more complex than you might think to implement.
The chain would need to know the association between delegator and voter at all times.
It does seem possible, as a user chooses to abstain, that they provide the voter which has their balance, and we can reduce that voting amount.
But an easy attack against this would be that the voter then removes their vote, and then votes again.
It is not simple for the blockchain to know, when a user votes, that the delegator may have chosen to abstain. For example, imagine a voter with 1M+ delegators, and 1,000 people voted to abstain, some which may be delegated to this voter and others without. There is no simple way to find the matching delegators, and remove their votes without basically doing a lookup on all users.
Of course, this may be programmed lazily, where any user can trigger to reduce the vote of a delegator if a delegator has abstained, but this is obviously not perfect and might be quite inefficient in terms of storage.
All in all, I think this kind of idea is easy to have, but hard to implement well.
|
|
||
| 1. **Allow a Delegator to vote independently of their Delegate if they so desire** – this would empower network participants to more actively delegate their voting power to active voters, removing the tedious steps of having to undelegate across an entire track every time they do not agree with their delegate's voting direction for a particular referendum. | ||
|
|
||
| 2. **Allow nested delegations – for example Charlie delegates to Bob who delegates to Alice – when Alice votes then both Bob and Charlie vote alongside Alice (in the current runtime Charlie will not vote when Alice votes)** – This would allow network participants who control multiple (possibly derived) accounts to be able to delegate all of their voting power to a single account under their control, which would in turn delegate to a more active voting participant. Then if the delegator wishes to vote independently of their delegate they can control all of their voting power from a single account, which again removes the pain point of having to issue multiple undelegate extrinsics in the event that they disagree with their delegate. |
There was a problem hiding this comment.
AFAIK nested delegation (or at least some simple primitive of it) is already implemented.
Am I wrong?
There was a problem hiding this comment.
Nested delegations do not work on Kusama or Polkadot, there may be some code somewhere that hasn't yet been implemented that I am not aware of.
|
|
||
| This RFC proposes to make 4 changes to the convictionVoting pallet logic in order to improve the user experience of those delegating their voting power to another account. | ||
|
|
||
| 1. **Allow a Delegator to vote independently of their Delegate if they so desire** – this would empower network participants to more actively delegate their voting power to active voters, removing the tedious steps of having to undelegate across an entire track every time they do not agree with their delegate's voting direction for a particular referendum. |
There was a problem hiding this comment.
this would be equal complexity to my notes about having individual delegators vote abstain below.
To me, there is no difference in complexity around voting different than the delegator or abstaining.
Again, a totally sensible idea, one that is easy to understand, but I think will not be easy to implement well.
There was a problem hiding this comment.
I assume the trade off here is state bloat from needing to keep track of all these associations? Is there anyway to estimate the state bloat at different levels of delegators and delegates?
There was a problem hiding this comment.
Would it be too much extra storage bloat and computing to keep a map of (referendum, delegator) -> Option<votes> and then either checking it when the delegate votes (to filter off those delegators) or checking it when computing the state of the referendum poll (to grab the map's votes instead of the delegate's votes)?
indeed, the decrease in costs may not be huge, but there should be some number of redundant storage item reads / writes which can be reduced by up to 15x, since we can assume all of those redundant reads will be in the overlay. It seems okay to at least make a more accurate estimate as to the weight / fee costs improvements before moving forward with implementing 4. Otherwise, perhaps the real solution here would be to have more advance benchmarking / weight systems which can detect redundant storage reads by default and refund weights. |
|
can you make this |
…tion-voting-delegation-modifications,md
…viction-voting-delegation-modifications.md
|
|
||
| ## Explanation | ||
|
|
||
| This RFC proposes to make 4 changes to the convictionVoting pallet logic in order to improve the user experience of those delegating their voting power to another account. |
There was a problem hiding this comment.
Explanation should really explain the algorithm / the change, not explain the motivation, which, well, should be part of the motivation section. Otherwise we cannot know the drawbacks, performance / compatibility impacts.
|
I'll underline @xlc 's remarks. As it stands, this is just a wishlist. For it to be taken seriously it must include implementation specifics, including how to achieve bounded-complexity compute and state-changes on all operations. |
| @@ -0,0 +1,77 @@ | |||
| # RFC-0035: Conviction Voting Delegation Modifications | |||
There was a problem hiding this comment.
| # RFC-0035: Conviction Voting Delegation Modifications | |
| # RFC-0035: Conviction Voting Delegation Modifications |
Just a cosmetic.
This RFC proposes changes to OpenGov delegations.