Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Custom size uint is not more efficient than uint256 #289

Open
code423n4 opened this issue Dec 1, 2021 · 1 comment
Open

Custom size uint is not more efficient than uint256 #289

code423n4 opened this issue Dec 1, 2021 · 1 comment
Labels
bug Something isn't working G (Gas Optimization) sponsor confirmed Sponsor agrees this is a problem and intends to fix it (OK to use w/ "disagree with severity")

Comments

@code423n4
Copy link
Contributor

Handle

0x0x0x

Vulnerability details

Concept

In MovingAverage.sol, uint64 is used for computation of time etc. But computations with uint64 does cost more gas and furthermore block.timestamp is uint256, which is additionally casted to uint64. uint32 is used for indexes, but this can also be changed with uint256.

Same applies for RewardDistributer.sol.

Recommendation

Use uint256 rather than custom uint.

@code423n4 code423n4 added bug Something isn't working G (Gas Optimization) labels Dec 1, 2021
code423n4 added a commit that referenced this issue Dec 1, 2021
@0xScotch 0xScotch added the sponsor confirmed Sponsor agrees this is a problem and intends to fix it (OK to use w/ "disagree with severity") label Dec 9, 2021
@GalloDaSballo
Copy link
Collaborator

This brought up some interesting conversation on twitter
https://twitter.com/_hrkrshnn/status/1477682676853133315

The short answer is that there is no advantage in using smaller ints, and in some cases it ends up being more expensive.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working G (Gas Optimization) sponsor confirmed Sponsor agrees this is a problem and intends to fix it (OK to use w/ "disagree with severity")
Projects
None yet
Development

No branches or pull requests

3 participants