From c0d2943b32b3a868a1acc31c57191a537daaa99a Mon Sep 17 00:00:00 2001 From: Alex Beregszaszi Date: Tue, 6 Nov 2018 16:10:06 +0000 Subject: [PATCH 01/16] sane --- EIPS/eip-draft_sane_evm_limits.md | 89 +++++++++++++++++++++++++++++++ 1 file changed, 89 insertions(+) create mode 100644 EIPS/eip-draft_sane_evm_limits.md diff --git a/EIPS/eip-draft_sane_evm_limits.md b/EIPS/eip-draft_sane_evm_limits.md new file mode 100644 index 00000000000000..318aa6f2b7fa69 --- /dev/null +++ b/EIPS/eip-draft_sane_evm_limits.md @@ -0,0 +1,89 @@ +--- +eip: +title: Sane limits for certain protocol and EVM parameters +author: Alex Beregszaszi (@axic) +discussions-to: +status: Draft +type: Standards Track +category: Core +created: 2018-08-01 +--- + +## Abstract + +Introduce an explicit value range for certain protocol and EVM parameters (such as gas limits, block number, block timestamp, size field when returning/copying data within EVM). +Some of these already have an implicit value range due to various reasons. + +## Motivation + +Having such an explicit value range can help in creating compatible client implementations, in certain cases it can also offer minor speed improvements, +and can reduce the effort needed to create consensus critical test cases. + +## Specification + +If `block.number >= {FORK_BLOCK}`, the following value ranges are introduced: + +- *gas* - 64 bit signed number +- *block number* - + +As a result the behaviour of the following EVM opcodes are altered as stated: + +1) `GAS` (`0xf3`) + +2) `NUMBER` (`0xf3`) + +3) `TIMESTAMP` + +4) `BLOCKGAS` + +5) `CALL` / `CALLGAS` / `DELEGATECALL` / `STATICCALL` + +If `block.number >= BYZANTIUM_FORK_BLKNUM`, add two new opcodes and amend the semantics of any opcode that creates a new call frame (like `CALL`, `CREATE`, `DELEGATECALL`, ...) called call-like opcodes in the following. It is assumed that the EVM (to be more specific: an EVM call frame) has a new internal buffer of variable size, called the return data buffer. This buffer is created empty for each new call frame. Upon executing any call-like opcode, the buffer is cleared (its size is set to zero). After executing a call-like opcode, the complete return data (or failure data, see [EIP-140](./eip-140.md)) of the call is stored in the return data buffer (of the caller), and its size changed accordingly. As an exception, `CREATE` and `CREATE2` are considered to return the empty buffer in the success case and the failure data in the failure case. If the call-like opcode is executed but does not really instantiate a call frame (for example due to insufficient funds for a value transfer or if the called contract does not exist), the return data buffer is empty. + + +In EVM the + + evmc_uint256be tx_gas_price; /**< The transaction gas price. */ + evmc_address tx_origin; /**< The transaction origin account. */ + evmc_address block_coinbase; /**< The miner of the block. */ + int64_t block_number; /**< The block number. */ + int64_t block_timestamp; /**< The block timestamp. */ + int64_t block_gas_limit; /**< The block gas limit. */ + evmc_uint256be block_difficulty; /**< The block difficulty. */ + + +The technical specification should describe the syntax and semantics of any new feature. The specification should be detailed enough to allow competing, interoperable implementations for any of the current Ethereum platforms (go-ethereum, parity, cpp-ethereum, ethereumj, ethereumjs, and [others](https://github.com/ethereum/wiki/wiki/Clients)). + +## Rationale + +These limits have been: +- proposed by [EVMC] +- implemented partially by certain clients, such as [Aleth] and [ethereumjs] +- allowed by certain test cases in the [Ethereum testing suite] +- and implicitly also allowed by certain assumptions, such as due to gas limits some of these values cannot grow past a certain limit + +Most of the limits proposed in this document have been previously explored and tested in [EVM]. + + +The rationale fleshes out the specification by describing what motivated the design and why particular design decisions were made. It should describe alternate designs that were considered and related work, e.g. how the feature is supported in other languages. The rationale may also provide evidence of consensus within the community, and should discuss important objections or concerns raised during discussion.--> + +## Backwards Compatibility + +All of these limits are already enforced mostly through the block gas limit. Since the out of range case results in a transaction failure, there should not be a change in behaviour. +Potentially however, certain contracts could fail at a different point after this change is introduced, and as a result would consume more or less gas than before while doing so. + +## Test Cases + +TBA + +## Implementation + +TBA + +## Copyright +Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/). + +[EVMC]: https://github.com/ethereum/evmc +[Aleth]: https://github.com/ethereum/aleth +[ethereumjs]: https://github.com/ethereumjs +[Ethereum testing suite]: https://github.com/ethereum/tests From e63ddd03d7ad5e335b6a725c77a1079e46b67a77 Mon Sep 17 00:00:00 2001 From: Alex Beregszaszi Date: Thu, 28 Mar 2019 16:37:54 +0000 Subject: [PATCH 02/16] some clarifications --- EIPS/eip-draft_sane_evm_limits.md | 13 ++++++++----- 1 file changed, 8 insertions(+), 5 deletions(-) diff --git a/EIPS/eip-draft_sane_evm_limits.md b/EIPS/eip-draft_sane_evm_limits.md index 318aa6f2b7fa69..ca5d4f6a809730 100644 --- a/EIPS/eip-draft_sane_evm_limits.md +++ b/EIPS/eip-draft_sane_evm_limits.md @@ -12,23 +12,26 @@ created: 2018-08-01 ## Abstract Introduce an explicit value range for certain protocol and EVM parameters (such as gas limits, block number, block timestamp, size field when returning/copying data within EVM). -Some of these already have an implicit value range due to various reasons. +Some of these already have an implicit value range due to various (practical) reasons. ## Motivation Having such an explicit value range can help in creating compatible client implementations, in certain cases it can also offer minor speed improvements, -and can reduce the effort needed to create consensus critical test cases. +and can reduce the effort needed to create consensus critical test cases by eliminating ## Specification If `block.number >= {FORK_BLOCK}`, the following value ranges are introduced: - *gas* - 64 bit signed number -- *block number* - +- *block gas limit* - 64 bit signed number +- *block number* - 64 bit unsigned number +- *account address* - 160 bit value +- *timestamp* - 64 bit unsigned number As a result the behaviour of the following EVM opcodes are altered as stated: -1) `GAS` (`0xf3`) +1) `GAS` (`0xf3`) - can only return 2) `NUMBER` (`0xf3`) @@ -62,7 +65,7 @@ These limits have been: - allowed by certain test cases in the [Ethereum testing suite] - and implicitly also allowed by certain assumptions, such as due to gas limits some of these values cannot grow past a certain limit -Most of the limits proposed in this document have been previously explored and tested in [EVM]. +Most of the limits proposed in this document have been previously explored and tested in [EVMC]. The rationale fleshes out the specification by describing what motivated the design and why particular design decisions were made. It should describe alternate designs that were considered and related work, e.g. how the feature is supported in other languages. The rationale may also provide evidence of consensus within the community, and should discuss important objections or concerns raised during discussion.--> From 5e41b99bb1ee69b7fde29b8fa80d4f0ead064369 Mon Sep 17 00:00:00 2001 From: Alex Beregszaszi Date: Thu, 28 Mar 2019 16:38:12 +0000 Subject: [PATCH 03/16] remove cruft --- EIPS/eip-draft_sane_evm_limits.md | 5 ----- 1 file changed, 5 deletions(-) diff --git a/EIPS/eip-draft_sane_evm_limits.md b/EIPS/eip-draft_sane_evm_limits.md index ca5d4f6a809730..31140f3f08ee7f 100644 --- a/EIPS/eip-draft_sane_evm_limits.md +++ b/EIPS/eip-draft_sane_evm_limits.md @@ -54,9 +54,6 @@ In EVM the int64_t block_gas_limit; /**< The block gas limit. */ evmc_uint256be block_difficulty; /**< The block difficulty. */ - -The technical specification should describe the syntax and semantics of any new feature. The specification should be detailed enough to allow competing, interoperable implementations for any of the current Ethereum platforms (go-ethereum, parity, cpp-ethereum, ethereumj, ethereumjs, and [others](https://github.com/ethereum/wiki/wiki/Clients)). - ## Rationale These limits have been: @@ -67,8 +64,6 @@ These limits have been: Most of the limits proposed in this document have been previously explored and tested in [EVMC]. - -The rationale fleshes out the specification by describing what motivated the design and why particular design decisions were made. It should describe alternate designs that were considered and related work, e.g. how the feature is supported in other languages. The rationale may also provide evidence of consensus within the community, and should discuss important objections or concerns raised during discussion.--> ## Backwards Compatibility From c0cacf273936b8a5616eec1ea9c2fa1ae4ec97ef Mon Sep 17 00:00:00 2001 From: Alex Beregszaszi Date: Thu, 28 Mar 2019 16:43:21 +0000 Subject: [PATCH 04/16] some clarifications --- EIPS/eip-draft_sane_evm_limits.md | 56 +++++++++++++++++++------------ 1 file changed, 35 insertions(+), 21 deletions(-) diff --git a/EIPS/eip-draft_sane_evm_limits.md b/EIPS/eip-draft_sane_evm_limits.md index 31140f3f08ee7f..56267541502eb5 100644 --- a/EIPS/eip-draft_sane_evm_limits.md +++ b/EIPS/eip-draft_sane_evm_limits.md @@ -23,36 +23,50 @@ and can reduce the effort needed to create consensus critical test cases by elim If `block.number >= {FORK_BLOCK}`, the following value ranges are introduced: -- *gas* - 64 bit signed number -- *block gas limit* - 64 bit signed number -- *block number* - 64 bit unsigned number -- *account address* - 160 bit value -- *timestamp* - 64 bit unsigned number +- *gas* - 64-bit signed number +- *block gas limit* - 64-bit signed number +- *block number* - 64-bit unsigned number +- *account address* - 160-bit value +- *timestamp* - 64-bit unsigned number +- *buffer sizes* - 32-bit unsigned number + +### Protocol changes + +### EVM changes + +List of affected EVM opcodes: +- address +- balance +- origin +- caller +- callvalue +- calldatasize +- codesize +- gasprice +- extcodesize +- returndatasize +- coinbase +- timestamp +- number +- gaslimit +- msize +- gas +- create +- create2 As a result the behaviour of the following EVM opcodes are altered as stated: -1) `GAS` (`0xf3`) - can only return +1) `GAS` (`0xf3`) - can only return a 64-bit value -2) `NUMBER` (`0xf3`) +2) `NUMBER` (`0xf3`) - can only return a 64-bit value -3) `TIMESTAMP` +3) `TIMESTAMP` - can only return a 64-bit value -4) `BLOCKGAS` +4) `BLOCKGAS` - can only return a 64-bit value 5) `CALL` / `CALLGAS` / `DELEGATECALL` / `STATICCALL` -If `block.number >= BYZANTIUM_FORK_BLKNUM`, add two new opcodes and amend the semantics of any opcode that creates a new call frame (like `CALL`, `CREATE`, `DELEGATECALL`, ...) called call-like opcodes in the following. It is assumed that the EVM (to be more specific: an EVM call frame) has a new internal buffer of variable size, called the return data buffer. This buffer is created empty for each new call frame. Upon executing any call-like opcode, the buffer is cleared (its size is set to zero). After executing a call-like opcode, the complete return data (or failure data, see [EIP-140](./eip-140.md)) of the call is stored in the return data buffer (of the caller), and its size changed accordingly. As an exception, `CREATE` and `CREATE2` are considered to return the empty buffer in the success case and the failure data in the failure case. If the call-like opcode is executed but does not really instantiate a call frame (for example due to insufficient funds for a value transfer or if the called contract does not exist), the return data buffer is empty. - - -In EVM the - - evmc_uint256be tx_gas_price; /**< The transaction gas price. */ - evmc_address tx_origin; /**< The transaction origin account. */ - evmc_address block_coinbase; /**< The miner of the block. */ - int64_t block_number; /**< The block number. */ - int64_t block_timestamp; /**< The block timestamp. */ - int64_t block_gas_limit; /**< The block gas limit. */ - evmc_uint256be block_difficulty; /**< The block difficulty. */ +TBD. ## Rationale From 7afa5d2dc0dc129b314fd7602e0e37f7568e2bf7 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Pawe=C5=82=20Bylica?= Date: Fri, 19 Apr 2019 11:06:31 +0200 Subject: [PATCH 05/16] propose spec changes --- EIPS/eip-draft_sane_evm_limits.md | 21 ++++++++++++--------- 1 file changed, 12 insertions(+), 9 deletions(-) diff --git a/EIPS/eip-draft_sane_evm_limits.md b/EIPS/eip-draft_sane_evm_limits.md index 56267541502eb5..59c983b025df3a 100644 --- a/EIPS/eip-draft_sane_evm_limits.md +++ b/EIPS/eip-draft_sane_evm_limits.md @@ -23,19 +23,22 @@ and can reduce the effort needed to create consensus critical test cases by elim If `block.number >= {FORK_BLOCK}`, the following value ranges are introduced: -- *gas* - 64-bit signed number -- *block gas limit* - 64-bit signed number -- *block number* - 64-bit unsigned number -- *account address* - 160-bit value -- *timestamp* - 64-bit unsigned number -- *buffer sizes* - 32-bit unsigned number +- *gas* - a number between 0 and 9223372036854775807 (2**63 - 1) +- *transaction gas limit* - a number between 0 and 9223372036854775807 (2**63 - 1) +- *block gas limit* - a number between 0 and 9223372036854775807 (2**63 - 1) +- *block number* - a number between 0 and 9223372036854775807 (2**63 - 1) +- *account address* - a number between 0 and 1461501637330902918203684832716283019655932542975 (2**160 - 1) +- *timestamp* - a number between 0 and 9223372036854775807 (2**63 - 1) +- *buffer sizes* - a number between 0 and 4294967295 (2**31 - 1) ### Protocol changes +1. A transaction with out-of-range gas limit is invalid. + ### EVM changes List of affected EVM opcodes: -- address +- ADDRESS: pushes to the stack the address of current account mod 2**160 - balance - origin - caller @@ -47,7 +50,7 @@ List of affected EVM opcodes: - returndatasize - coinbase - timestamp -- number +- NUMBER: pushes to the stack the current block number mod 2**63 - gaslimit - msize - gas @@ -56,7 +59,7 @@ List of affected EVM opcodes: As a result the behaviour of the following EVM opcodes are altered as stated: -1) `GAS` (`0xf3`) - can only return a 64-bit value +1) `GAS` (`0xf3`) - pushes a 63-bit value (mod 2**63) 2) `NUMBER` (`0xf3`) - can only return a 64-bit value From 3bcd17be18ec970b00011b4edbd8f068ecf3e0ac Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Pawe=C5=82=20Bylica?= Date: Tue, 30 Apr 2019 13:05:07 +0200 Subject: [PATCH 06/16] limit the scope to EVM only --- EIPS/eip-draft_sane_evm_limits.md | 70 +++++++++++++------------------ 1 file changed, 29 insertions(+), 41 deletions(-) diff --git a/EIPS/eip-draft_sane_evm_limits.md b/EIPS/eip-draft_sane_evm_limits.md index 59c983b025df3a..4c0d4d8dfdeeff 100644 --- a/EIPS/eip-draft_sane_evm_limits.md +++ b/EIPS/eip-draft_sane_evm_limits.md @@ -1,7 +1,7 @@ --- eip: -title: Sane limits for certain protocol and EVM parameters -author: Alex Beregszaszi (@axic) +title: Sane limits for certain EVM parameters +author: Alex Beregszaszi (@axic), Paweł Bylica (@chfast) discussions-to: status: Draft type: Standards Track @@ -11,65 +11,48 @@ created: 2018-08-01 ## Abstract -Introduce an explicit value range for certain protocol and EVM parameters (such as gas limits, block number, block timestamp, size field when returning/copying data within EVM). +Introduce an explicit value range for certain EVM parameters +(such as gas limit, block number, block timestamp, size field when returning/copying data within EVM). Some of these already have an implicit value range due to various (practical) reasons. ## Motivation -Having such an explicit value range can help in creating compatible client implementations, in certain cases it can also offer minor speed improvements, -and can reduce the effort needed to create consensus critical test cases by eliminating +Having such an explicit value range can help in creating compatible client implementations, +in certain cases it can also offer minor speed improvements, +and can reduce the effort needed to create consensus critical test cases +by eliminating unrealistic edge cases. ## Specification If `block.number >= {FORK_BLOCK}`, the following value ranges are introduced: - *gas* - a number between 0 and 9223372036854775807 (2**63 - 1) -- *transaction gas limit* - a number between 0 and 9223372036854775807 (2**63 - 1) +- *gas limit* - a number between 0 and 9223372036854775807 (2**63 - 1) - *block gas limit* - a number between 0 and 9223372036854775807 (2**63 - 1) - *block number* - a number between 0 and 9223372036854775807 (2**63 - 1) - *account address* - a number between 0 and 1461501637330902918203684832716283019655932542975 (2**160 - 1) - *timestamp* - a number between 0 and 9223372036854775807 (2**63 - 1) - *buffer sizes* - a number between 0 and 4294967295 (2**31 - 1) -### Protocol changes - -1. A transaction with out-of-range gas limit is invalid. - ### EVM changes -List of affected EVM opcodes: -- ADDRESS: pushes to the stack the address of current account mod 2**160 -- balance -- origin -- caller -- callvalue -- calldatasize -- codesize -- gasprice -- extcodesize -- returndatasize -- coinbase -- timestamp -- NUMBER: pushes to the stack the current block number mod 2**63 -- gaslimit -- msize -- gas -- create -- create2 - As a result the behaviour of the following EVM opcodes are altered as stated: -1) `GAS` (`0xf3`) - pushes a 63-bit value (mod 2**63) - -2) `NUMBER` (`0xf3`) - can only return a 64-bit value - -3) `TIMESTAMP` - can only return a 64-bit value - -4) `BLOCKGAS` - can only return a 64-bit value - -5) `CALL` / `CALLGAS` / `DELEGATECALL` / `STATICCALL` - -TBD. +1) `ADDRESS` (`0x30`) - pushes a 160-bit (mod 2**160) value to the stack +1) `ORIGIN` (`0x32`) - pushes a 160-bit (mod 2**160) value to the stack +1) `CALLER` (`0x33`) - pushes a 160-bit (mod 2**160) value to the stack +1) `CALLDATASIZE` (`0x36`) - pushes a 32-bit (mod 2**32) value to the stack +1) `CODESIZE` (`0x38`) - pushes a 32-bit (mod 2**32) value to the stack +1) `EXTCODESIZE` (`0x3b`) - pushes a 32-bit (mod 2**32) value to the stack +1) `RETURNDATASIZE` (`0x3d`) - pushes a 32-bit (mod 2**32) value to the stack +1) `COINBASE` (`0x41`) - pushes a 160-bit (mod 2**160) value to the stack +1) `TIMESTAMP` (`0x42`) - pushes a 63-bit (mod 2**63) value to the stack +1) `NUMBER` (`0x43`) - pushes a 63-bit (mod 2**63) value to the stack +1) `GASLIMIT` (`0x45`) - pushes a 63-bit (mod 2**63) value to the stack +1) `MSIZE` (`0x59`) - pushes a 32-bit (mod 2**32) value to the stack +1) `GAS` (`0x5a`) - pushes a 63-bit (mod 2**63) value to the stack +1) `CREATE` (`0xf0`) - pushes a 160-bit (mod 2**160) value to the stack +1) `CREATE2` (`0xf5`) - pushes a 160-bit (mod 2**160) value to the stack ## Rationale @@ -95,6 +78,11 @@ TBA TBA +## TODO + +1. The size of addresses are specified in Yellow Paper, +e.g. COINBASE is specified as returning H_c which has 20 bytes. + ## Copyright Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/). From d16a430e04a307b5c2bc0eb5acf0c6a13a08d7af Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Pawe=C5=82=20Bylica?= Date: Tue, 30 Apr 2019 13:30:01 +0200 Subject: [PATCH 07/16] more rationale --- EIPS/eip-draft_sane_evm_limits.md | 5 +++++ 1 file changed, 5 insertions(+) diff --git a/EIPS/eip-draft_sane_evm_limits.md b/EIPS/eip-draft_sane_evm_limits.md index 4c0d4d8dfdeeff..c5919d71c57da0 100644 --- a/EIPS/eip-draft_sane_evm_limits.md +++ b/EIPS/eip-draft_sane_evm_limits.md @@ -64,6 +64,11 @@ These limits have been: Most of the limits proposed in this document have been previously explored and tested in [EVMC]. +Using the `2**63 - 1` constant to limit some of the ranges: +- allows using singed 64-bit integer type to represent it, + what helps programming languages not having unsigned types, +- makes arithmetic simpler (e.g. checking out-of-gas conditions is simple as `gas_counter < 0`). + ## Backwards Compatibility From 3268e11353769a0bd3924905e17758b6f2a4d60f Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Pawe=C5=82=20Bylica?= Date: Tue, 30 Apr 2019 13:30:26 +0200 Subject: [PATCH 08/16] group affected opcodes by ranges --- EIPS/eip-draft_sane_evm_limits.md | 64 +++++++++++++++++-------------- 1 file changed, 35 insertions(+), 29 deletions(-) diff --git a/EIPS/eip-draft_sane_evm_limits.md b/EIPS/eip-draft_sane_evm_limits.md index c5919d71c57da0..4f80d2cd4dfe4b 100644 --- a/EIPS/eip-draft_sane_evm_limits.md +++ b/EIPS/eip-draft_sane_evm_limits.md @@ -24,35 +24,40 @@ by eliminating unrealistic edge cases. ## Specification -If `block.number >= {FORK_BLOCK}`, the following value ranges are introduced: - -- *gas* - a number between 0 and 9223372036854775807 (2**63 - 1) -- *gas limit* - a number between 0 and 9223372036854775807 (2**63 - 1) -- *block gas limit* - a number between 0 and 9223372036854775807 (2**63 - 1) -- *block number* - a number between 0 and 9223372036854775807 (2**63 - 1) -- *account address* - a number between 0 and 1461501637330902918203684832716283019655932542975 (2**160 - 1) -- *timestamp* - a number between 0 and 9223372036854775807 (2**63 - 1) -- *buffer sizes* - a number between 0 and 4294967295 (2**31 - 1) - -### EVM changes - -As a result the behaviour of the following EVM opcodes are altered as stated: - -1) `ADDRESS` (`0x30`) - pushes a 160-bit (mod 2**160) value to the stack -1) `ORIGIN` (`0x32`) - pushes a 160-bit (mod 2**160) value to the stack -1) `CALLER` (`0x33`) - pushes a 160-bit (mod 2**160) value to the stack -1) `CALLDATASIZE` (`0x36`) - pushes a 32-bit (mod 2**32) value to the stack -1) `CODESIZE` (`0x38`) - pushes a 32-bit (mod 2**32) value to the stack -1) `EXTCODESIZE` (`0x3b`) - pushes a 32-bit (mod 2**32) value to the stack -1) `RETURNDATASIZE` (`0x3d`) - pushes a 32-bit (mod 2**32) value to the stack -1) `COINBASE` (`0x41`) - pushes a 160-bit (mod 2**160) value to the stack -1) `TIMESTAMP` (`0x42`) - pushes a 63-bit (mod 2**63) value to the stack -1) `NUMBER` (`0x43`) - pushes a 63-bit (mod 2**63) value to the stack -1) `GASLIMIT` (`0x45`) - pushes a 63-bit (mod 2**63) value to the stack -1) `MSIZE` (`0x59`) - pushes a 32-bit (mod 2**32) value to the stack -1) `GAS` (`0x5a`) - pushes a 63-bit (mod 2**63) value to the stack -1) `CREATE` (`0xf0`) - pushes a 160-bit (mod 2**160) value to the stack -1) `CREATE2` (`0xf5`) - pushes a 160-bit (mod 2**160) value to the stack +If `block.number >= {FORK_BLOCK}`, the following value ranges are introduced. +They restrict the results (i.e. values pushed to the stack) of the opcodes listed below. + +1. *gas*, *gas limit*, *block gas limit* + is a range between `0` and `9223372036854775807` (`2**63 - 1`). + It affects following the opcodes: + - `GASLIMIT` (`0x45`), + - `GAS` (`0x5a`). + +2. *block number*, *timestamp* + is a range between `0` and `9223372036854775807` (`2**63 - 1`). + It affects the following opcodes: + - `TIMESTAMP` (`0x42`), + - `NUMBER` (`0x43`). + +3. *account address* + is a range between `0` and `1461501637330902918203684832716283019655932542975` (`2**160 - 1`). + It affects the following opcodes: + - `ADDRESS` (`0x30`), + - `ORIGIN` (`0x32`), + - `CALLER` (`0x33`), + - `COINBASE` (`0x41`), + - `CREATE` (`0xf0`), + - `CREATE2` (`0xf5`). + +4. *buffer size* + is a range between `0` and `4294967295` (`2**32 - 1`). + It affects the following opcodes: + - `CALLDATASIZE` (`0x36`), + - `CODESIZE` (`0x38`), + - `EXTCODESIZE` (`0x3b`), + - `RETURNDATASIZE` (`0x3d`), + - `MSIZE` (`0x59`). + ## Rationale @@ -87,6 +92,7 @@ TBA 1. The size of addresses are specified in Yellow Paper, e.g. COINBASE is specified as returning H_c which has 20 bytes. +2. Do the gas limit applies for the gas param in CALL? ## Copyright Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/). From a74cfa22119589fa00b8b537cbd0c2699e5dea95 Mon Sep 17 00:00:00 2001 From: Alex Beregszaszi Date: Tue, 30 Apr 2019 15:28:52 +0100 Subject: [PATCH 09/16] Rename to EIP-1985 --- EIPS/{eip-draft_sane_evm_limits.md => eip-1985.md} | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) rename EIPS/{eip-draft_sane_evm_limits.md => eip-1985.md} (99%) diff --git a/EIPS/eip-draft_sane_evm_limits.md b/EIPS/eip-1985.md similarity index 99% rename from EIPS/eip-draft_sane_evm_limits.md rename to EIPS/eip-1985.md index 4f80d2cd4dfe4b..9123e5c2de840b 100644 --- a/EIPS/eip-draft_sane_evm_limits.md +++ b/EIPS/eip-1985.md @@ -1,5 +1,5 @@ --- -eip: +eip: 1985 title: Sane limits for certain EVM parameters author: Alex Beregszaszi (@axic), Paweł Bylica (@chfast) discussions-to: From 077310bf37d68cc3720899b2b90bcb16b386c15f Mon Sep 17 00:00:00 2001 From: Alex Beregszaszi Date: Tue, 30 Apr 2019 21:18:04 +0100 Subject: [PATCH 10/16] Add discussion URL to EIP-1985 --- EIPS/eip-1985.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/EIPS/eip-1985.md b/EIPS/eip-1985.md index 9123e5c2de840b..1ede015845d660 100644 --- a/EIPS/eip-1985.md +++ b/EIPS/eip-1985.md @@ -2,7 +2,7 @@ eip: 1985 title: Sane limits for certain EVM parameters author: Alex Beregszaszi (@axic), Paweł Bylica (@chfast) -discussions-to: +discussions-to: https://ethereum-magicians.org/t/eip-1985-sane-limits-for-certain-evm-parameters/3224 status: Draft type: Standards Track category: Core From 2a04d51b19ddc087638e01b0022a24ba1422b395 Mon Sep 17 00:00:00 2001 From: Alex Beregszaszi Date: Fri, 17 May 2019 11:34:25 +0100 Subject: [PATCH 11/16] Include a reference to EIP106 --- EIPS/eip-1985.md | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/EIPS/eip-1985.md b/EIPS/eip-1985.md index 1ede015845d660..0f36010fc437d1 100644 --- a/EIPS/eip-1985.md +++ b/EIPS/eip-1985.md @@ -88,6 +88,10 @@ TBA TBA +## References + +[EIP-106](https://github.com/ethereum/EIPs/issues/106) proposed the block gas limit to be limited at `2**63 - 1`. + ## TODO 1. The size of addresses are specified in Yellow Paper, From dd25128415400027a9b5a559cc029876b6ed4243 Mon Sep 17 00:00:00 2001 From: Alex Beregszaszi Date: Fri, 17 May 2019 11:47:50 +0100 Subject: [PATCH 12/16] Add more rationale --- EIPS/eip-1985.md | 14 +++++++++++++- 1 file changed, 13 insertions(+), 1 deletion(-) diff --git a/EIPS/eip-1985.md b/EIPS/eip-1985.md index 0f36010fc437d1..94a5857f4e4bc1 100644 --- a/EIPS/eip-1985.md +++ b/EIPS/eip-1985.md @@ -63,7 +63,7 @@ They restrict the results (i.e. values pushed to the stack) of the opcodes liste These limits have been: - proposed by [EVMC] -- implemented partially by certain clients, such as [Aleth] and [ethereumjs] +- implemented partially by certain clients, such as [Aleth], [geth], [Parity] and [ethereumjs] - allowed by certain test cases in the [Ethereum testing suite] - and implicitly also allowed by certain assumptions, such as due to gas limits some of these values cannot grow past a certain limit @@ -74,6 +74,15 @@ Using the `2**63 - 1` constant to limit some of the ranges: what helps programming languages not having unsigned types, - makes arithmetic simpler (e.g. checking out-of-gas conditions is simple as `gas_counter < 0`). +### Timestamp + +The [Yellow Paper] defines the timestamp in block as "A scalar value equal to the reasonable output of Unix’s time() at this block’s inception". +IEEE Std 1003.1-2001 (POSIX.1) leaves that definition implementation defined. + +### Comparing current implementations + +- Timestamp is implemented as a 64-bit value in [geth] and [Parity] +- Block gas limit is implemented as a 64-bit in [aleth] and [geth] ## Backwards Compatibility @@ -103,5 +112,8 @@ Copyright and related rights waived via [CC0](https://creativecommons.org/public [EVMC]: https://github.com/ethereum/evmc [Aleth]: https://github.com/ethereum/aleth +[geth]: https://github.com/ethereum/go-ethereum +[Parity]: https://github.com/paritytech/parity-ethereum [ethereumjs]: https://github.com/ethereumjs [Ethereum testing suite]: https://github.com/ethereum/tests +[Yellow Paper]: https://github.com/ethereum/yellowpaper From 893430eb41ea9c5f2e6e0c379aab9e90241dcb72 Mon Sep 17 00:00:00 2001 From: Alex Beregszaszi Date: Fri, 17 May 2019 11:48:45 +0100 Subject: [PATCH 13/16] fix typo --- EIPS/eip-1985.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/EIPS/eip-1985.md b/EIPS/eip-1985.md index 94a5857f4e4bc1..b646982f4f0495 100644 --- a/EIPS/eip-1985.md +++ b/EIPS/eip-1985.md @@ -70,7 +70,7 @@ These limits have been: Most of the limits proposed in this document have been previously explored and tested in [EVMC]. Using the `2**63 - 1` constant to limit some of the ranges: -- allows using singed 64-bit integer type to represent it, +- allows using signed 64-bit integer type to represent it, what helps programming languages not having unsigned types, - makes arithmetic simpler (e.g. checking out-of-gas conditions is simple as `gas_counter < 0`). From 7c8ee4217abe764d918099905bb950be5e95f41a Mon Sep 17 00:00:00 2001 From: Alex Beregszaszi Date: Fri, 17 May 2019 11:52:35 +0100 Subject: [PATCH 14/16] Remove unfounded worry --- EIPS/eip-1985.md | 1 - 1 file changed, 1 deletion(-) diff --git a/EIPS/eip-1985.md b/EIPS/eip-1985.md index b646982f4f0495..fb51961f7ec638 100644 --- a/EIPS/eip-1985.md +++ b/EIPS/eip-1985.md @@ -87,7 +87,6 @@ IEEE Std 1003.1-2001 (POSIX.1) leaves that definition implementation defined. ## Backwards Compatibility All of these limits are already enforced mostly through the block gas limit. Since the out of range case results in a transaction failure, there should not be a change in behaviour. -Potentially however, certain contracts could fail at a different point after this change is introduced, and as a result would consume more or less gas than before while doing so. ## Test Cases From 6c2b2a6e432b45db1db43580ce60278cc8039bde Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Pawe=C5=82=20Bylica?= Date: Fri, 17 May 2019 16:40:05 +0200 Subject: [PATCH 15/16] mention timestamp being 64-bit value in Aleth --- EIPS/eip-1985.md | 20 ++++++++++---------- 1 file changed, 10 insertions(+), 10 deletions(-) diff --git a/EIPS/eip-1985.md b/EIPS/eip-1985.md index fb51961f7ec638..22825bc89835b5 100644 --- a/EIPS/eip-1985.md +++ b/EIPS/eip-1985.md @@ -19,7 +19,7 @@ Some of these already have an implicit value range due to various (practical) re Having such an explicit value range can help in creating compatible client implementations, in certain cases it can also offer minor speed improvements, -and can reduce the effort needed to create consensus critical test cases +and can reduce the effort needed to create consensus critical test cases by eliminating unrealistic edge cases. ## Specification @@ -32,13 +32,13 @@ They restrict the results (i.e. values pushed to the stack) of the opcodes liste It affects following the opcodes: - `GASLIMIT` (`0x45`), - `GAS` (`0x5a`). - + 2. *block number*, *timestamp* is a range between `0` and `9223372036854775807` (`2**63 - 1`). It affects the following opcodes: - `TIMESTAMP` (`0x42`), - `NUMBER` (`0x43`). - + 3. *account address* is a range between `0` and `1461501637330902918203684832716283019655932542975` (`2**160 - 1`). It affects the following opcodes: @@ -47,8 +47,8 @@ They restrict the results (i.e. values pushed to the stack) of the opcodes liste - `CALLER` (`0x33`), - `COINBASE` (`0x41`), - `CREATE` (`0xf0`), - - `CREATE2` (`0xf5`). - + - `CREATE2` (`0xf5`). + 4. *buffer size* is a range between `0` and `4294967295` (`2**32 - 1`). It affects the following opcodes: @@ -57,7 +57,7 @@ They restrict the results (i.e. values pushed to the stack) of the opcodes liste - `EXTCODESIZE` (`0x3b`), - `RETURNDATASIZE` (`0x3d`), - `MSIZE` (`0x59`). - + ## Rationale @@ -70,7 +70,7 @@ These limits have been: Most of the limits proposed in this document have been previously explored and tested in [EVMC]. Using the `2**63 - 1` constant to limit some of the ranges: -- allows using signed 64-bit integer type to represent it, +- allows using signed 64-bit integer type to represent it, what helps programming languages not having unsigned types, - makes arithmetic simpler (e.g. checking out-of-gas conditions is simple as `gas_counter < 0`). @@ -81,8 +81,8 @@ IEEE Std 1003.1-2001 (POSIX.1) leaves that definition implementation defined. ### Comparing current implementations -- Timestamp is implemented as a 64-bit value in [geth] and [Parity] -- Block gas limit is implemented as a 64-bit in [aleth] and [geth] +- Timestamp is implemented as a 64-bit value in [Aleth], [geth] and [Parity] +- Block gas limit is implemented as a 64-bit in [Aleth] and [geth] ## Backwards Compatibility @@ -102,7 +102,7 @@ TBA ## TODO -1. The size of addresses are specified in Yellow Paper, +1. The size of addresses are specified in Yellow Paper, e.g. COINBASE is specified as returning H_c which has 20 bytes. 2. Do the gas limit applies for the gas param in CALL? From cd2fa7fb5070f7acaedb7fe186a5bb3354339820 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Pawe=C5=82=20Bylica?= Date: Fri, 17 May 2019 16:55:13 +0200 Subject: [PATCH 16/16] resolved an TODO item as Rationale entry --- EIPS/eip-1985.md | 9 ++++++--- 1 file changed, 6 insertions(+), 3 deletions(-) diff --git a/EIPS/eip-1985.md b/EIPS/eip-1985.md index 22825bc89835b5..8f3eca24a883bb 100644 --- a/EIPS/eip-1985.md +++ b/EIPS/eip-1985.md @@ -79,6 +79,11 @@ Using the `2**63 - 1` constant to limit some of the ranges: The [Yellow Paper] defines the timestamp in block as "A scalar value equal to the reasonable output of Unix’s time() at this block’s inception". IEEE Std 1003.1-2001 (POSIX.1) leaves that definition implementation defined. +### Addresses + +The size of addresses is specified in the [Yellow Paper] as 20 bytes. +E.g. the `COINBASE` instruction is specified to return *H*c ∈ 𝔹20 which has 20 bytes. + ### Comparing current implementations - Timestamp is implemented as a 64-bit value in [Aleth], [geth] and [Parity] @@ -102,9 +107,7 @@ TBA ## TODO -1. The size of addresses are specified in Yellow Paper, -e.g. COINBASE is specified as returning H_c which has 20 bytes. -2. Do the gas limit applies for the gas param in CALL? +1. Does the gas limit apply to the gas argument for call instructions? ## Copyright Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/).