Update scores from uint64 to uint

[juliangruber]

uint256 is cheaper than uint64, this reduces cost by ~1.5%

See also https://www.linkedin.com/pulse/solidity-gas-golfing-1-uint8-vs-uint256-sudeep-sagar/

cc @AmeanAsad

test_TransferScheduled() (gas: -25169 (-0.997%)) 
test_SetScoresMultipleCalls() (gas: -31425 (-1.293%)) 
test_SetScoresMultipleParticipants() (gas: -29157 (-1.432%)) 
test_SetScoresFractions() (gas: -29135 (-1.482%)) 
test_RewardBurner() (gas: -29136 (-1.492%)) 
test_rewardsScheduledFor() (gas: -29030 (-1.496%)) 
test_MinBalanceForTransfer() (gas: -29115 (-1.502%)) 
test_SetScores() (gas: -29129 (-1.504%)) 
test_Reward() (gas: -29242 (-1.506%)) 
test_AvailableBalance() (gas: -29219 (-1.524%)) 
test_ReleaseReward() (gas: -28898 (-1.525%)) 
test_AdvanceRoundCleanUp() (gas: -29030 (-1.598%)) 
test_SetScoresTooBigHistoric() (gas: -29153 (-1.606%)) 
test_SetScoresOverflow() (gas: -28792 (-1.611%)) 
test_AdvanceRound() (gas: -28775 (-1.612%)) 
test_SetNextRoundLength() (gas: -28819 (-1.613%)) 
test_SetScoresEmptyRound() (gas: -28902 (-1.622%)) 
test_SetScoresTooBig() (gas: -29023 (-1.624%)) 
test_AddMeasurements() (gas: -28863 (-1.634%)) 
test_SetScoresNotEvaluator() (gas: -28884 (-1.639%)) 
test_SetRoundRewardNotAdmin() (gas: -28886 (-1.640%)) 
test_SetScoresUnfinishedRound() (gas: -28884 (-1.641%)) 
test_SetRoundReward() (gas: -28842 (-1.641%)) 
test_GasSetScores() (gas: -134881 (-1.755%)) 
Overall gas change: -800389 (-1.553%)

[bajtos]

uint256 is cheaper than uint64, this reduces cost by ~1.5%

Wow, that's rather counterintuitive!

Could you please double-check that the gas cost savings also apply when there are thousands of scores?

[juliangruber]

test_GasSetScoresManyParticipants() (gas: -23870849 (-9.853%))

This tests 1k participants, called 100 times in succession. Apparently smaller types are only cheaper if they're aligned so that they consume less space together (eg in a struct). Otherwise, there's an overhead associated with smaller types, since computation is necessary after reading it, since multiple entries can fit into one slot (vs a uint256 consumes the whole slot)