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
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
CREATE2(EIP 1014); and
- TODO: Research and discuss gas metering changes for
SSTORE, proposed in EIP 1283.
- TODO: Research and discuss gas metering changes for
- 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:
- account states remain changed
- the “Homestead” hardfork established a precedent for this type of change, having introduced the
DELEGATECALLopcode 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.
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).
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
REVERTinstruction 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).
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
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 (
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):
Returns the keccak256 hash of a contract’s code