9e393a79d9
* Include LICENCE in the Jekyll build * Replace old licence link with new and improved licence link * Add note to EIP-1 mandating the new link * Maybe this fixes it? * Rename LICENCE so that jekyll picks it up * Add original LICENCE file back * Delete the markdown file * Add Jekyll header Hopefully the tooling still detects it as CC0 * Remove Jekyll header * Maybe this will trick Jekyll and satisfy github? * Remove config changes * Enable incremental build * Will it work if I rename it? * I'll just paste the content of the licence into the file... * Perhaps this will work * Replace the licence file * Fix false positive Co-authored-by: Micah Zoltu <micah@zoltu.net> * Resolve feedback * Perhaps this might work * It didn't work This reverts commit 55116e15168fb20ae57dea97388bb260c0941465. * Will licencee still detect this correctly? * Jekyll Preamble in licence file * Include it? * Licence -> License, get rid of CC0.md * Force wording of copyright waiver * Formatting consistent with the rest of the list * Spelling * Escape * Task failed successfully * Fix two more links * Will this render it? * Perhaps this will work too * .md essential * Fix the issues Micah noted Co-authored-by: Micah Zoltu <micah@zoltu.net>
3.3 KiB
| eip | title | author | discussions-to | status | type | category | created |
|---|---|---|---|---|---|---|---|
| 1051 | Overflow checking for the EVM | Nick Johnson <arachnid@notdot.net> | https://ethereum-magicians.org/t/eip-arithmetic-overflow-detection-for-the-evm/261 | Stagnant | Standards Track | Core | 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
ADDopcode 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
SUBopcode occurs and the result has the same MSB as the subtractand (second argument) (eg,(+a) - (-b) = (-c)or(-a) - (+b) = (+c). - When a
MULopcode with both inputs being positive has a negative output. - When a
MULopcode with both inputs being negative has a negative output. - When a
MULopcode 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.