Skip to content
This repository has been archived by the owner on Nov 15, 2023. It is now read-only.

Refactor Democracy #5248

Closed
gavofyork opened this issue Mar 13, 2020 · 0 comments · Fixed by #5294
Closed

Refactor Democracy #5248

gavofyork opened this issue Mar 13, 2020 · 0 comments · Fixed by #5294
Labels
I7-refactor Code needs refactoring. Z3-substantial Can be fixed by an experienced coder with a working knowledge of the codebase.
Milestone

Comments

@gavofyork
Copy link
Member

Democracy module currently works in two stages: votes are registered initially, then funds possibly locked only at the point that votes are counted. In the case of a high number of votes, this can lead overweight on_initialize in blocks, which is bad for consensus.

A more robust design would be to lock funds immediately upon voting (a cancel_vote extrinsic could accordingly reverse that operation if done before the vote deadline) and keep a running tally of voting funds, thereby making the operation entirely incremental and avoiding any large compute/storage payloads at the end of blocks.

Unlocking should happen lazily, to avoid the need of keeping large Vecs of account IDs around. Votes and directions should remain in storage until either the vote is cancelled, the funds are unlocked because the vote was against the final decision or the funds are unlocked because the conviction lock period is over.

@gavofyork gavofyork added I7-refactor Code needs refactoring. Z3-substantial Can be fixed by an experienced coder with a working knowledge of the codebase. labels Mar 13, 2020
@gavofyork gavofyork added this to the Polkadot milestone Mar 13, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
I7-refactor Code needs refactoring. Z3-substantial Can be fixed by an experienced coder with a working knowledge of the codebase.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

1 participant