How long will `uint256` last?
It all start with a small discussion in my team. The conversation made me ask — what is the value of uint256 and how long will it last? In my post before, I briefly talked about the uint256 data type. We often use this data type as an id variable and add operations to increase its value. But, did you know simple additive and subtractive operations make this data type vulnerable to errors? These operations can cause integer overflow and underflow.
An overflow/underflow happens when an arithmetic operation reach the maximum or minimum size of the type. For example if you store your number in the uint256 type, it means your number will be stored in a 256 bits unsigned number ranging from 0 to 2²⁵⁶. In computer programming, an integer overflow occurs when an arithmetic operation attempts to create a numeric value that is outside of the range that can be represented with a given number of bits — either larger than the maximum or lower than the minimum representable value.
When the operation reaches the maximum size of the data type, the value generated may be deceiving. Moreover, the operation result can be iterated as 0 again.
Integer overflow and underflow was mentioned on Ethernaut level 5. This problem asks us to cheat on ‘transfer’ function so we can obtain a huge amount of ether. The solution is to use a huge number when calling the function. The require condition and balances variable will catch integer underflow then we have the ether.
The results produced by shift right of negative values of signed integer types is different from those produced by other programming languages. In Solidity, shift right maps to division so the shifted negative values are going to be rounded towards zero (truncated). In other programming languages the shift right of negative values works like division with rounding down (towards negative infinity).
Source: https://solidity.readthedocs.io/en/latest/types.html#addition-subtraction-and-multiplication
Then what the connection with uint256 life? And why using incremental id with uint256 is not a problem?
Actually, this discussion starts with one question,
How long is uint256?
As we know uint256 range is 0 to 2²⁵⁶–1. Where 2²⁵⁶–1 = 1.1579209e+77.
For example, we create a smart contract with a variable named total.
Let say, people in this earth is 8 Billion (8.0e+09).
Consider that every second a transaction occurs, in increments of the total variable. It means 1 year = 12 months = 365 days = 8760 hours = 525600 minutes = 3.154e+7 seconds. If all humans in the Earth conducts the same transaction, the variable, total, will be approximately 10¹⁶, the product of 10⁷ seconds in a year and 10⁹ people.
If in a year uint256 value increases by 10¹⁶ and its range is 10⁷⁷, then in a year, only 1/10⁶¹ of uint256’s range is used for total.
Therefore, uint256 actually has the same length as bytes32, a data type that is used for transaction hash. As we used uint256 in incremental and always have different numbers, the probability of hash collision is small. So, at the point where the id increment overflowed, some transaction hash DEFINITELY had collided.
Maybe all uint256 will be used when the fire nation attack.
Notes:
Length of uint256 might be very long. But for safety reason, it’s better to use SafeMath Library from OpenZeppelin to prevent from integer overflow/underflow in the future.
Join our community on Telegram!
Learn more about HARA
- Visit the HARA website
- Read our White Paper
- Join our Telegram Community
- Follow our Social Media
Facebook, Twitter, Instagram, Medium & LinkedIn
