Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Conviction Voting Delegation Modifications #35

Open
wants to merge 3 commits into
base: main
Choose a base branch
from
+77 −0
Open

Conviction Voting Delegation Modifications #35

Changes from 1 commit
Commits
Show all changes
3 commits
Select commit Hold shift + click to select a range
c59266b
Add files via upload
Leemo94 Oct 10, 2023
a918811
Rename 0035-conviction-voting-delegation-modifications to 0035-convic…
x676f64 Oct 11, 2023
149ec4b
Rename 0035-conviction-voting-delegation-modifications,md to 0035-con…
x676f64 Oct 11, 2023
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
77 changes: 77 additions & 0 deletions text/0035-conviction-voting-delegation-modifications
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -0,0 +1,77 @@
# RFC-0035: Conviction Voting Delegation Modifications

| | |
| --------------- | ------------------------------------------------------------------------------------------- |
| **October 10, 2023** | |
| **Conviction Voting Delegation Modifications** | |
| **ChaosDAO** | |

## Summary

This RFC proposes to make modifications to voting power delegations as part of the Conviction Voting pallet. The changes being proposed include:

1. Allow a Delegator to vote independently of their Delegate if they so desire.
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 implementation Charlie will not vote when Alice votes).
3. Make a change so that when a delegate votes abstain their delegated votes also vote abstain.
4. Allow a Delegator to delegate/ undelegate their votes for all tracks with a single call.

## Motivation

It has become clear since the launch of OpenGov that there are a few common tropes which pop up time and time again:
1. The frequency of referenda is often too high for network participants to have sufficient time to review, comprehend, and ultimately vote on each individual referendum. This means that these network participants end up being inactive in on-chain governance.
2. There are active network participants who are reviewing every referendum and are providing feedback in an attempt to help make the network thrive – but often time these participants do not control enough voting power to influence the network with their positive efforts.
3. Delegating votes for all tracks currently requires long batched calls which result in high fees for the Delegator - resulting in a reluctance from many to delegate their votes.

We believe (based on feedback from token holders with a larger stake in the network) that if there were some changes made to delegation mechanics, these larger stake holders would be more likely to delegate their voting power to active network participants – thus greatly increasing the support turnout.

## Stakeholders

The primary stakeholders of this RFC are:

- The Polkadot Technical Fellowship who will have to research and implement the technical aspects of this RFC
- DOT token holders in general

## 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.

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.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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?

Copy link

@arrudagates arrudagates Oct 12, 2023 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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)?


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.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

AFAIK nested delegation (or at least some simple primitive of it) is already implemented.

Am I wrong?

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.


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).
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.


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.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

To me, this one seems very doable.


## Drawbacks

We do not foresee any drawbacks by implementing these changes. If anything we believe that this should help to increase overall voter turnout (via the means of delegation) which we see as a net positive.

## Testing, Security, and Privacy

We feel that the Polkadot Technical Fellowship would be the most competent collective to identify the testing requirements for the ideas presented in this RFC.

## Performance, Ergonomics, and Compatibility

### Performance

This change may add extra chain storage requirements on Polkadot, especially with respect to nested delegations.

### Ergonomics & Compatibility

The change to add nested delegations may affect governance interfaces such as Nova Wallet who will have to apply changes to their indexers to support nested delegations. It may also affect the Polkadot Delegation Dashboard as well as Polkassembly & SubSquare.

We want to highlight the importance for ecosystem builders to create a mechanism for indexers and wallets to be able to understand that changes have occurred such as increasing the pallet version, etc.

## Prior Art and References

N/A

## Unresolved Questions

N/A

## Future Directions and Related Material
Additionally we would like to re-open the conversation about the potential for there to be free delegations. This was discussed by Dr Gavin Wood at Sub0 2022 and we feel like this would go a great way towards increasing the amount of network participants that are delegating: https://youtu.be/hSoSA6laK3Q?t=526

Overall, we strongly feel that delegations are a great way to increase voter turnout, and the ideas presented in this RFC would hopefully help in that aspect.