---
eip: 1985
title: Sane limits for certain EVM parameters
author: Alex Beregszaszi (@axic), Paweł Bylica (@chfast)
discussions-to: https://ethereum-magicians.org/t/eip-1985-sane-limits-for-certain-evm-parameters/3224
status: Draft
type: Standards Track
category: Core
created: 2018-08-01
---

## Abstract

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 unrealistic edge cases.

## Specification

If `block.number >= {FORK_BLOCK}`, the following value ranges are introduced.
They restrict the results (i.e. values pushed to the stack) of the instructions listed below.

1. *gas*, *gas limit*, *block gas limit*
   is a range between `0` and `0x7fffffffffffffff` (`2**63 - 1`, `9223372036854775807`).
   It affects the following instructions:
   - `GASLIMIT` (`0x45`),
   - `GAS` (`0x5a`).

2. *block number*, *timestamp*
   is a range between `0` and `0x7fffffffffffffff` (`2**63 - 1`, `9223372036854775807`).
   It affects the following instructions:
   - `TIMESTAMP` (`0x42`),
   - `NUMBER` (`0x43`).

3. *account address*
   is a range between `0` and `0xffffffffffffffffffffffffffffffffffffffff` (`2**160 - 1`, `1461501637330902918203684832716283019655932542975`)
   i.e. the address occupies the 160 low bits of the 256-bit value and the remaining top 96 bits must be zeros.
   It affects the following instructions:
   - `ADDRESS` (`0x30`),
   - `ORIGIN` (`0x32`),
   - `CALLER` (`0x33`),
   - `COINBASE` (`0x41`),
   - `CREATE` (`0xf0`),
   - `CREATE2` (`0xf5`).

4. *buffer size*, *code size*, *memory size*
   is a range between `0` and `0xffffffff` (`2**32 - 1`, `4294967295`).
   It affects the following instructions:
   - `CALLDATASIZE` (`0x36`),
   - `CODESIZE` (`0x38`),
   - `EXTCODESIZE` (`0x3b`),
   - `RETURNDATASIZE` (`0x3d`),
   - `MSIZE` (`0x59`),
   - `PC` (`0x58`).


## Rationale

These limits have been:
- proposed by [EVMC]
- 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

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,
  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.

### Addresses

The size of addresses is specified in the [Yellow Paper] as 20 bytes.
E.g. the `COINBASE` instruction is specified to return *H*<sub>c</sub> ∈ 𝔹<sub>20</sub> which has 20 bytes.

### Memory size

Memory expansion cost is not linear and is determined by the following formula:
        cost = cost_per_word * number_of_words + (number_of_words ^ 2 / 512)

Expanding to over `2^32 - 1` bytes would cost `35184774742016` gas. This number fits into the gas limit imposed above (`2 ^ 63 - 1`) and would cost around 35184 Ether in a transaction to exhaust, with a 1 GWei gas cost, which can be attained on mainnet.

However, setting the limit `2^32 - 1` is beneficial from a VM design perspective and we believe limiting memory should be done via carefully selecting the block gas limit.

### Code size

[EIP-170](http://eips.ethereum.org/EIPS/eip-170) has implemented a code size limit of 0x6000, however even before that, it was practically impossible to deploy a code blob exceeding `2**32 - 1` bytes in size.

### Comparing current implementations

- 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]
- Memory, buffer and code sizes are implemented as 64-bit values in [geth]

## 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.

## Test Cases

TBA

## Implementation

TBA

## References

- [EIP-92](https://github.com/ethereum/EIPs/issues/92) proposed the transaction gas limit to be limited at `2**63 - 1` and had a lengthy discussion about other limits.
- [EIP-106](https://github.com/ethereum/EIPs/issues/106) proposed the block gas limit to be limited at `2**63 - 1`.

## TODO

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/).

[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