On TCR requirements and technical specs the interface for the used Voting app is defined so that addresses that voted for and addresses that voted against are returned along with the vote result. This is needed for token redistribution (see here).
The problem is that this doesn’t seem scalable at all. With large participations there would be too much data passed around and therefore very expensive too.
Possible solution #1:
If we finally force voters to claim rewards, like here, there’s no need for this data.
Possible solution #2:
If we use aragonOS
EVMScripts (see this topic), there’s no need for this data either. We could grant permission to Voting app to move tokens after vote is closed. But redistribution would still be expensive, as there may be a lot of calls to staking app unless we find a better way to do it.
Possible solution #3: Compression. Rejected.
I have been exploring this possibility, but arrived to the conclusion that vote result (as voters for and against) is completely random without any fixed pattern we take advantage of (plus we have to take into account abstentions). Any outcome is possible and although some algorithms could be very effective for some cases, I don’t think there is one that would work for all them.
Besides, we should count the gas cost of the compress and uncompress computations.