This commit introduces a change that has been largely discussed in #65
Generally the idea is the following:
Prior to this commit, the amount of votes to be evaluated is unbounded, meaning we can potentially run out of gas when too many votes have to be evaluated in a single transaction.
To account for that, vote processing has to be batched based on a limit that is provided when the contract is called.
As a result of batching, finalization of votes can happen over multiple transactions which makes checking balances of voters tricky because evaluation happens at different blocks where balances might have changed.
That's why we're also introducing the use of MiniMeToken over standard ERC20 because it allows us to check balances of accounts at certain blocks.
This commit introduces the following changes in both VotingContract and FeaturedVotingContract:
Evaluation of votes now always happens in three places: When a voting is initialized, when votes are casted and when a voting is being finalized.
When initializing a voting or casting votes, the votes are evaluated against the current block, front-ends can therefore show a good estimation of the current vote state.
Only the "new" votes are evaluated, which should equal to the amount of votes being sent.
When finalizaing a vote, all votes are (re)evaluated against the block at which the finalization has started. This means with finalization, all votes are evaluated again to ensure they represent the latest state.
In terms of code this means:
_evaluateVotes() requires and additional limit, as a result of that finializeVoting() and finalizeVotingRoom() require a limit as well. castVotes() derives the limit from the vote amount that's being sent.
r4bbit