Skip to content
Branch: master
Find file Copy path
Fetching contributors…
Cannot retrieve contributors at this time
97 lines (50 sloc) 6.82 KB

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

ECIP: 1045/undecided
Title: Support for ETH Byzantium & Constantinople EVM and Protocol Upgrades
Status: Draft
Type: Standard Track
Author: Isaac Ardis <>
Created: 2018-06-18


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.


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


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


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:

  1. account states remain changed
  2. 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.


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


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:

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.

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.

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

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.

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

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.

Returns the keccak256 hash of a contract's code

You can’t perform that action at this time.