60 lines
3.3 KiB
Markdown
60 lines
3.3 KiB
Markdown
---
|
|
eip: 1051
|
|
title: Overflow checking for the EVM
|
|
author: Nick Johnson <arachnid@notdot.net>
|
|
discussions-to: https://ethereum-magicians.org/t/eip-arithmetic-overflow-detection-for-the-evm/261
|
|
status: Stagnant
|
|
type: Standards Track
|
|
category: Core
|
|
created: 2018-05-02
|
|
---
|
|
|
|
## Abstract
|
|
This EIP adds overflow checking for EVM arithmetic operations, and two new opcodes that check and clear the overflow flags.
|
|
|
|
## Motivation
|
|
The correct functioning of many contracts today is dependent on detecting and preventing overflow of arithmetic operations. Since the EVM operates on mod 2^256 integers and provides no built-in overflow detection or prevention, this requires manual checks on every arithmetic operation.
|
|
|
|
In the interests of facilitating efficient and secure contracts, we propose new opcodes that permit efficient detection of overflows, which can be checked periodically rather than after each operation.
|
|
|
|
## Specification
|
|
|
|
Two new flags are added to the EVM state: overflow (`ovf`) and signed overflow (`sovf`).
|
|
|
|
The `ovf` flag is set in the following circumstances:
|
|
|
|
- When an `ADD` (`0x01`) opcode, with both inputs treated as unsigned integers, produces an ideal output in excess of 2^256 - 1.
|
|
- When a `SUB` (`0x03`) opcode, with both inputs treated as unsigned integers, produces an ideal output less than 0.
|
|
- When a `MUL`(`0x02`) opcode, with both inputs treated as unsigned integers, produces an ideal output in excess of 2^256 - 1.
|
|
|
|
The `sovf` flag is set whenever the `ovf` flag is set, and additionally in the following circumstances:
|
|
|
|
- When an `ADD` opcode with both inputs having the same MSB results in the output having a different MSB (eg, `(+a) + (+b) = (-c)` or `(-a) + (-b) = (+c)`).
|
|
- When a `SUB` opcode occurs and the result has the same MSB as the subtractand (second argument) (eg, `(+a) - (-b) = (-c)` or `(-a) - (+b) = (+c)`.
|
|
- When a `MUL` opcode with both inputs being positive has a negative output.
|
|
- When a `MUL` opcode with both inputs being negative has a negative output.
|
|
- When a `MUL` opcode with one negative input and one positive input has a positive output.
|
|
|
|
A new opcode, `OFV` is added, with number `0x0c`. This opcode takes 0 arguments from the stack. When executed, it pushes `1` if the `ovf` flag is set, and `0` otherwise. It then sets the `ovf` flag to false.
|
|
|
|
A new opcode, `SOVF` is added, with number `0x0d`. This opcode takes 0 arguments from the stack. When executed, it pushes `1` if the `sovf` flag is set, and `0` otherwise. It then sets the `sovf` flag to false.
|
|
|
|
## Rationale
|
|
Any change to implement overflow protection needs to preserve behaviour of existing contracts, which precludes many changes to the arithmetic operations themselves. One option would be to provide an opcode that enables overflow protection, causing a throw or revert if an overflow happens. However, this limits the manner in which overflows can be handled.
|
|
|
|
Instead, we replicate functionality from real world CPUs, which typically implement 'carry' and 'overflow' flags.
|
|
|
|
Separate flags for signed and unsigned overflow are necessary due to the fact that a signed overflow may not result in an unsigned overflow.
|
|
|
|
## Backwards Compatibility
|
|
This EIP introduces no backwards compatibility issues.
|
|
|
|
## Test Cases
|
|
TBD
|
|
|
|
## Implementation
|
|
TBD
|
|
|
|
## Copyright
|
|
Copyright and related rights waived via [CC0](../LICENSE.md).
|