Difference between calculated and stored uint sizes can lead to overflows

[3esmit]

All balances in MiniMeToken are saved as uint128 in the checkpoints (as
well as total supplies). Since all inputs and calculations are done with uint256, there were no
checks for the uin128 size thus allowing overflows.
While on most tokens such amounts are unrealistic (config dependant on the decimals), this
might also open up an unintended centralization risk that could’ve been avoided (minter can
deliberately zero out someone’s balance - or even the total supply - just by minting, which
shouldn’t be expected).
Current overflow checks are all on uint256 size, so they don’t circumvent this potential issue.

[3esmit]

PR #22 changed everything to uint128, however this caused an overhead on processing, which is not necessary.

If we guarantee there is no overflows in mint/burn functions, than any other overflow in transfer would be mathematically impossible.