President Elector

Summary

The RankedChoice.sol contract does not reset vote counts stored in s_candidateVotesByRound and rankings stored in s_rankings after each election cycle. This leads to unnecessary storage consumption and increased gas costs over time as old data continues to accumulate.

Vulnerability Details

In the RankedChoice.sol contract, vote counts for each candidate are stored in the s_candidateVotesByRound mapping, and voter rankings are stored in the s_rankings mapping. However, these mappings are not reset after an election ends. As the number of election cycles increases, the contract accumulates old data, which consumes more storage and increases gas costs for future interactions with the contract.

The lack of a reset mechanism results in:

1. s_candidateVotesByRound: Vote counts for candidates are retained even after the election ends, leading to storage bloat.

2. s_rankings: Voter rankings are not cleared, adding to storage inefficiency.

Without resetting this data after each election, the contract becomes less efficient in terms of both storage and gas usage, especially as the number of elections grows.

Impact

Failure to reset old election data leads to significant storage consumption and increased gas costs. This can affect the contract's scalability and make it more expensive for users to interact with over time.

Tools Used

Manual code review.

Recommendations

• Reset s_candidateVotesByRound After Each Election: Implement logic to clear the vote counts for all candidates once an election has ended to free up storage space.

  Example:

• Reset s_rankings After Each Election: Clear voter rankings after each election to prevent accumulation of old data in s_rankings.

  Example:

Implementing these reset mechanisms will improve the contract's storage efficiency and reduce gas costs, ensuring scalability as more elections take place.