Solidity's uint256 can cause overflow.
Why not resolve this problem in the EVM?
Add a comment
|
3 Answers
The reason behind this is that overflow checking is expensive.
It would be bad for overall EVM performance and by extension bad for tx rate, node performance, etc.
The way it is now, they are leaving it up to a higher level to decide, you can chose wether or not your program is slowed down for safety. Maybe in your particular case there is a much cheaper way within the logic of the program to perform the check or to prevent overflow otherwise.
-
Execution of Ethereum smart contracts is limited by the gas limit on each block which is currently around 6m. This only allows for between one thousand and one million instructions in each block (every 15 seconds). Checking for overflow a million times each second is not expensive on processors produced in this millennium. I have to disagree with you on this answer. Commented Apr 26, 2018 at 20:33
Since soldity 0.4.16 there is a support for overflow checking:
From the documentation :
solc now include experimental support for automated overflow and assertion checking at compile-time using the SMT solver Z3
answered Apr 25, 2018 at 11:40
Adding two uint256 numbers may lead to an overflow. But the behavior is veldefined since the result of adding a and b will be a + b mod 2^256.
Allowing overflow is common in processors. In Ethereum it is up to the smart contract developers to check for overflow. In some situations the overflowed addition may be desired.
But it could probably be argued that overflow should throw an exception and halt the execution. This is a design choice and perhaps the Ethereum developers has made a suboptimal choice here.
answered Apr 25, 2018 at 11:36
