Empty storage entries in conviction-voting pallet

[muharem]

Context

After inspecting the Polkadot storage snapshot from January 17, 2025, I found 20575 VotingFor records with zero capital (zero-balance votes, no delegations, no prior locks) and 8522 ClassLocksFor entries with zero-balance locks. These records likely serve no purpose and should not be stored.

Definition of zero record for VotingFor - https://github.com/muharem/polkadot-runtimes/blob/8f2deec8afa1384c56bd3795c6fa3e3e098b02f7/pallets/rc-migrator/src/conviction_voting.rs#L155
Definition of zero record for ClassLocksFor - https://github.com/muharem/polkadot-runtimes/blob/8f2deec8afa1384c56bd3795c6fa3e3e098b02f7/pallets/rc-migrator/src/conviction_voting.rs#L125

Note that a zero vote perhaps should still be possible if an account has delegations and to vote using only those delegations.

Task

Verify or refute the findings above. If the issue is present, prevent the creation of such records and implement a migration or a call to remove them from storage.

[Nathy-bajo]

@muharem I'll look into this

[muharem]

@muharem I'll look into this

before implementing a fix, please do your own research. share here with your proposal to fix it. we review it together.

[Nathy-bajo]

@muharem The current implementation of the conviction voting pallet stores zero-balance records in the VotingFor and ClassLocksFor storage maps, which serve no purpose.

Proposed Solution
Prevent Creation of Zero-Balance Records: Modify the try_vote function to return an InsufficientFunds error if a vote has a zero balance. Similarly, update the extend_lock function to skip storing locks with a zero balance.
Migration to Clean Up Existing Zero-Balance Records.
Optional: Add a Call to Remove Zero-Balance Records: Introduce a new extrinsic (remove_zero_balance_records) to allow users to remove their own zero-balance records.

I might be wrong. what do you think?

[muharem]

@Nathy-bajo instead of migration we use a call. bc such migration iterating over storage map would require a multi block migration. also commented you draft PR

[x3c41a]

Just adding my 5 cents to the thread: regarding the Westend migration, the votingFor inconsistency still persists, whereas classLocksFor appears to be consistent.

[muharem]

Just adding my 5 cents to the thread: regarding the Westend migration, the votingFor inconsistency still persists, whereas classLocksFor appears to be consistent.

you mean even if we take that filter into account?

[x3c41a]

you mean even if we take that filter into account?

no, that's without filtering