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

ECIPs/ECIP-1045.md

@@ -0,0 +1,96 @@
+### 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 <[email protected]>
+    Created: 2018-06-18
+
+### 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:
+
+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.
+
+### 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](https://github.com/ethereumproject/go-ethereum/releases/tag/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](https://github.com/ethereum/go-ethereum/releases/tag/v1.7.0).
+
+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
+
+
+
+