ECIP 1045: Support for ETH Byzantium & Constantinople EVM and Protocol Upgrades

Author	Isaac Ardis
Status	Superseded
Type	Meta
Created	2018-06-18

NOTE

The ECIP was replaced by ECIP-1054 - Atlantis and ECIP-1056 - Agharta. This ECIP was never activated.

Abstract

Add support for a subset of protocol-impacting changes introduced in the Ethereum Foundation (ETH) network via the Byzantium hardfork. The proposed changes include:

Byzantium EVM opcodes and precompiled contracts, namely opcodes REVERT (EIP 206/140), RETURNDATASIZE (EIP 211), RETURNDATACOPY (EIP 211), and STATICCALL (EIP 214/116); and precompiled contracts for modular exponentiation, elliptic curve addition, scalar multiplication, and pairing (EIPs 198, 212/197, 213/196)
Expected Constantinople EVM opcodes, namely bitwise shifting operators SHL, SHR, and SAR (EIP 215); CREATE2 (EIP 1014); and EXTCODEHASH (EIP 1052).
- TODO: Research and discuss gas metering changes for SSTORE, proposed in EIP 1283.
Replacing the intermediate state root field in transaction receipts with the contract return status (EIP 658).

This document proposes block 7,100,000 as the upcoming block height at which to implement these changes in the network, placing the expected date of protocol hardfork in January 2019.

For more information on the opcodes and their respective EIPs and implementations, please see the History section of this document.

Motivation

To enable and maintain interoperability between Foundation and Classic Ethereum Virtual Machines (“EVM”s).

Specification

As per associated EIPs’s specifications and implementations, and success determined by interoperability (implementation) of smart contracts utilizing the introduced opcode and precompiled contracts (implementation before technical specification in case of discrepency).

Rationale

Interoperability: establishing and maintaining interoperable behavior between Ethereum clients is important for developers and end-user adoption, yielding benefits for all participating chains (eg. ETH and ETC).

On Immutability: Introducing new opcodes in the VM has the potential to change behavior of existing contracts; in the case where previously an arbitrary invalid bytecode series (yielding invalid opcode) would now be assigned a meaning, and thus could generate or return a value other than invalid. In essence, this means “making music where there was only noise before.” There is a concern that this behavior change contradicts an essential promise of Immutability, since an existing failing smart contract is liable to become a succeeding (not failing) contract. In counterargument to this concern are two critical points:

account states remain changed
the “Homestead” hardfork established a precedent for this type of change, having introduced the DELEGATECALL opcode at block 1,150,000.

With these arguments in place, along with precedence and expectation for other continuing and varied consensus-impacting protocol upgrades (eg soft- and hard-forks), it follows that the definition of Immutability is not extended to guarantee perfect consistency for future behavior of historical account states, but only to only to guarantee the immutability of the account states themselves.

Implementation

Adoption of the content of this ECIP requires a hard fork, and herein that adoption is proposed to be scheduled for block 7,100,000, roughly estimated to arrive in January 2019.

The ethereumproject/go-ethereum client implemented an API-only (non-consensus impacting) partial adoption of EIP-658 Transaction status code change via the v5.5.0 release, and this proposal would augment that change to extend through to the RLP encoding (and thus modify consensus protocol).

History

Byzantium changes

These changes were introduced in the Ethereum Foundation go-ethereum client via the 1.7 “Megara” release.

These changes were catalogued via the EIP process in the following:

EIP-658: Transaction receipts embedding status code instead of intermediate state root field - https://github.com/ethereum/EIPs/pull/658
EIP-140: REVERT - https://github.com/ethereum/EIPs/pull/206/files

The REVERT instruction provides a way to stop execution and revert state changes, without consuming all provided gas and with the ability to return a reason.

EIP-211: RETURNDATASIZE, RETURNDATACOPY - https://github.com/ethereum/EIPs/pull/211/files

A mechanism to allow returning arbitrary-length data inside the EVM has been requested for quite a while now. Existing proposals always had very intricate problems associated with charging gas. This proposal solves the same problem while at the same time, it has a very simple gas charging mechanism and requires minimal changes to the call opcodes. Its workings are very similar to the way calldata is handled already; after a call, return data is kept inside a virtual buffer from which the caller can copy it (or parts thereof) into memory. At the next call, the buffer is overwritten. This mechanism is 100% backwards compatible.

EIP-214: STATICCALL - https://github.com/ethereum/EIPs/pull/214/files

To increase smart contract security, this proposal adds a new opcode that can be used to call another contract (or itself) while disallowing any modifications to the state during the call (and its subcalls, if present).

EIP-198: Precompiled contract for modular exponentiation - https://github.com/ethereum/EIPs/pull/198
EIP-212: Precompiled contract for elliptic curve pairing - https://github.com/ethereum/EIPs/pull/212
EIP-213: Precompiled contract for elliptic curve addition and scalar multiplication - https://github.com/ethereum/EIPs/pull/213

Constantinople changes

These changes are expected to be implemented by the anticipated Constantinople hard fork, which may take place on the ETH network sometime near October 30, 2018, although to date no block number configuration has been accepted to the master branch of the ethereum/go-ethereum client.

EIP-215:(replacing EIP-145) (https://github.com/ethereum/EIPs/pull/215): Introduce bitwise shifting

To provide native bitwise shifting with cost on par with other arithmetic operations.

EIP-1014 (https://github.com/ethereum/EIPs/pull/1247): Use keccak256 name instead of sha3 (CREATE2)

Adds a new opcode at 0xf5, which takes 4 stack arguments: endowment, memory_start, memory_length, salt. Behaves identically to CREATE, except using keccak256(msg.sender ++ salt ++ init_code)[12:] instead of the usual sender-and-nonce-hash as the address where the contract is initialized at.

EIP-1052 (https://github.com/ethereum/EIPs/pull/1052): EXTCODEHASH opcode

Returns the keccak256 hash of a contract’s code

ECIP 1045: Support for ETH Byzantium & Constantinople EVM and Protocol Upgrades Source