EVM: overflow detection in arithmetic instructions

[axic]

Abstract

The goal is to support overflow detection in arithmetic functions. An overflow flag is introduced in the VM. This flag can only be set or unset by instructions and can only be read indirectly by programs.

Motivation

Overflow detection can be accomplished by checking the inputs before the arithmetic instructions. This is what Solidity does currently (see this extensive thread: ethereum/solidity#796). This proposal would make these checks cheaper.

Specification

1. The overflow flag is unset at the beginning of execution.
2. Every arithmetic instruction (ADD, MUL, SUB, DIV, SDIV, MOD, SMOD, ADDMOD, MULMOD, EXP, SIGNEXTEND) unsets the overflow flag at the start of execution.
3. DIV, SDIV sets the overflow flag if the divisor is 0.
4. ADD, MUL, EXP sets the overflow flag if the result was truncated to fit into 256 bits.
5. SUB sets the overflow flag when the second argument exceeds the first.
6. SDIV sets the overflow flag when - 2**255 is divided by -1 (highest bit set div all bits set).
7. ADDMOD, MULMOD when the mod argument is 0.
8. SIGNEXTEND sets the overflow flag if the position parameter is > 31.
9. A new instruction, JUMPOF (at 0x5c) is introduced. It takes one argument, the jump destination. If the overflow flag is set it will jump.

TBD: define the overflow behaviour for the rest of the arithmetic instructions.

An alternative to JUMPOF could be introducing PUSHOF and using it with JUMPI. This could be useful if in the future more flags are introduced as they could be combined:

PUSHOF (overflow flag)
PUSHSF (signed flag)
AND
JUMPI

[axic]

Alternatively, this could be extended to support non-arithmetic instructions, e.g if CALL* or SELFDESTRUCT receives a non-160 bit address, CALLDATALOAD reads over the provided input, etc. (Idea from @pirapira.)

[vbuterin]

Is this really that much better than just doing overflow checking at HLL level? You still need one branch condition per arithmetic operation if we're doing it this way. What if we unset the overflow flag only during JUMP and JUMPI? This would allow complex expressions to be evaluated with overflow only being checked once.

[gcolvin]

It's worse than doing it at the HLL level so far as interpreter performance unless the multiprecision code already provides a cheap overflow flag.
It's not just the comparison, it's computing enough extra precision to be able to make the comparison. And paying that price for programs that don't need the check, either because truncation is the semantics they want, or because they have statically assured that overflow can't happen.

[github-actions]

There has been no activity on this issue for two months. It will be closed in a week if no further activity occurs. If you would like to move this EIP forward, please respond to any outstanding feedback or add a comment indicating that you have addressed all required feedback and are ready for a review.

[github-actions]

This issue was closed due to inactivity. If you are still pursuing it, feel free to reopen it and respond to any feedback or request a review in a comment.