From cd26a35017456f92b6d1ab4dbccb0f621754d0a5 Mon Sep 17 00:00:00 2001 From: meows Date: Mon, 11 Feb 2019 10:01:07 -0600 Subject: [PATCH 01/25] Init bare file --- ECLIPs/ECLIP-etcbyz.md | 0 1 file changed, 0 insertions(+), 0 deletions(-) create mode 100644 ECLIPs/ECLIP-etcbyz.md diff --git a/ECLIPs/ECLIP-etcbyz.md b/ECLIPs/ECLIP-etcbyz.md new file mode 100644 index 0000000..e69de29 From d9813d95aaa8053039729aaa18198c54385dd6dd Mon Sep 17 00:00:00 2001 From: meows Date: Mon, 11 Feb 2019 10:05:46 -0600 Subject: [PATCH 02/25] Init copy ECIP-1045 --- ECLIPs/ECLIP-etcbyz.md | 97 ++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 97 insertions(+) diff --git a/ECLIPs/ECLIP-etcbyz.md b/ECLIPs/ECLIP-etcbyz.md index e69de29..b0c194b 100644 --- a/ECLIPs/ECLIP-etcbyz.md +++ b/ECLIPs/ECLIP-etcbyz.md @@ -0,0 +1,97 @@ +### ECLIP-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 + + +### 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 + + + + From 5448cb500f97f06997f187262c4c5c303955d839 Mon Sep 17 00:00:00 2001 From: meows Date: Mon, 11 Feb 2019 10:56:43 -0600 Subject: [PATCH 03/25] Swap ECIP for ECLIP, remove Const. from Header --- ECLIPs/ECLIP-etcbyz.md | 15 +++++++-------- 1 file changed, 7 insertions(+), 8 deletions(-) diff --git a/ECLIPs/ECLIP-etcbyz.md b/ECLIPs/ECLIP-etcbyz.md index b0c194b..73bc9f0 100644 --- a/ECLIPs/ECLIP-etcbyz.md +++ b/ECLIPs/ECLIP-etcbyz.md @@ -1,12 +1,11 @@ -### ECLIP-1045: Support for ETH Byzantium & Constantinople EVM and Protocol Upgrades +### ECLIP-?: Support for ETH Byzantium EVM and Protocol Upgrades - ECIP: 1045/undecided - Title: Support for ETH Byzantium & Constantinople EVM and Protocol Upgrades + ECLIP: undecided + Title: Support for ETH Byzantium EVM and Protocol Upgrades Status: Draft - Type: Standard Track - Author: Isaac Ardis - Created: 2018-06-18 - + Type: Standards Track + Author: Isaac Ardis + Created: 2019-02-11 ### Abstract @@ -42,7 +41,7 @@ With these arguments in place, along with precedence and expectation for other c ### 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. +Adoption of the content of this ECLIP 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). From 55c44609b989781ec198855eabeb347c3fc6f2b6 Mon Sep 17 00:00:00 2001 From: meows Date: Mon, 11 Feb 2019 11:42:40 -0600 Subject: [PATCH 04/25] Remove Constantinople specs and undefine ETA Along w/ a few other minor grammatical tweaks --- ECLIPs/ECLIP-etcbyz.md | 43 ++++++++++++------------------------------ 1 file changed, 12 insertions(+), 31 deletions(-) diff --git a/ECLIPs/ECLIP-etcbyz.md b/ECLIPs/ECLIP-etcbyz.md index 73bc9f0..44dedbc 100644 --- a/ECLIPs/ECLIP-etcbyz.md +++ b/ECLIPs/ECLIP-etcbyz.md @@ -12,21 +12,19 @@ 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. +This document proposes block `X,XXX,XXX` as the upcoming block height at which to implement these changes in the network, placing the expected date of protocol hardfork date on _XXXX-XX-XX_. 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). +To enable and maintain interoperability between Foundation and Classic Ethereum Virtual Machines ("EVM"s). This protocol specification notably omits the scheduled features of the anticipated _Constantinople_ fork, which would be expected to include various further EVM upgrades. The reasoning for this omission hinges on a hedge toward battle-testing of those changes in light of multiple delays of that fork ([here](https://medium.com/ethereum-cat-herders/a-post-mortem-report-the-constantinople-ethereum-hard-fork-postponement-dd780d7ae63d), a postmortem of the latest delay) due to security and implementation discrepencies. ### 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). +As per associated EIPs's specifications and implementations, with feature-readiness determined by interoperability (implementation) of smart contracts utilizing the introduced opcode and precompiled contracts (implementation before technical specification in case of discrepency). Technical specifications for each EIP can be found at those documents respectively. ### Rationale @@ -41,19 +39,21 @@ With these arguments in place, along with precedence and expectation for other c ### Implementation -Adoption of the content of this ECLIP 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. +Adoption of the content of this ECLIP requires a hard fork, and herein that adoption is proposed to be scheduled for block X,XXX,XXX roughly estimated to arrive _XXXX-XX-XX_. 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). +ETC Labs Core plans to advocate and support the adoption of [ethoxy/multi-geth](https://github.com/ethoxy/multi-geth) as a fully-featured and maintenance-scheduled client for this fork and beyond. + ### 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 introduced in the `ethereum/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: +These changes are 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-658: Transaction receipts embedding status code instead of intermediate state root field - https://github.com/ethereum/EIPs/pull/658/files - EIP-140: `REVERT` - https://github.com/ethereum/EIPs/pull/206/files @@ -69,28 +69,9 @@ These changes were catalogued via the EIP process in the following: > 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 - +- EIP-198: Precompiled contract for modular exponentiation - https://github.com/ethereum/EIPs/pull/198/files +- EIP-212: Precompiled contract for elliptic curve pairing - https://github.com/ethereum/EIPs/pull/212/files +- EIP-213: Precompiled contracts for elliptic curve addition and scalar multiplication - https://github.com/ethereum/EIPs/pull/213/files From 9081155c581989c5e0df89ea9671889c46ea2bdb Mon Sep 17 00:00:00 2001 From: Zac Mitton Date: Tue, 12 Feb 2019 08:06:50 -0600 Subject: [PATCH 05/25] Update ECLIPs/ECLIP-etcbyz.md Fixes EIP658 name; Tx status code -> receipt status code Co-Authored-By: meowsbits <45600330+meowsbits@users.noreply.github.com> --- ECLIPs/ECLIP-etcbyz.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/ECLIPs/ECLIP-etcbyz.md b/ECLIPs/ECLIP-etcbyz.md index 44dedbc..fb79e56 100644 --- a/ECLIPs/ECLIP-etcbyz.md +++ b/ECLIPs/ECLIP-etcbyz.md @@ -41,7 +41,7 @@ With these arguments in place, along with precedence and expectation for other c Adoption of the content of this ECLIP requires a hard fork, and herein that adoption is proposed to be scheduled for block X,XXX,XXX roughly estimated to arrive _XXXX-XX-XX_. -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). +The `ethereumproject/go-ethereum` client implemented an API-only (non-consensus impacting) partial adoption of EIP-658 receipt 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). ETC Labs Core plans to advocate and support the adoption of [ethoxy/multi-geth](https://github.com/ethoxy/multi-geth) as a fully-featured and maintenance-scheduled client for this fork and beyond. From b07af653d3054004c35864ad5ea6ef4bcbfcc541 Mon Sep 17 00:00:00 2001 From: meows Date: Tue, 12 Feb 2019 08:24:40 -0600 Subject: [PATCH 06/25] Revise motivation section Prioritize the actual outcomes of the proposed features, not first the case of interoperability. Rel https://github.com/etclabscore/ECLIPs/pull/2#discussion_r255920563 --- ECLIPs/.#ECLIP-etcbyz.md | 1 + ECLIPs/ECLIP-etcbyz.md | 4 +++- 2 files changed, 4 insertions(+), 1 deletion(-) create mode 120000 ECLIPs/.#ECLIP-etcbyz.md diff --git a/ECLIPs/.#ECLIP-etcbyz.md b/ECLIPs/.#ECLIP-etcbyz.md new file mode 120000 index 0000000..87495b9 --- /dev/null +++ b/ECLIPs/.#ECLIP-etcbyz.md @@ -0,0 +1 @@ +ia@ubp52.17806:1549812866 \ No newline at end of file diff --git a/ECLIPs/ECLIP-etcbyz.md b/ECLIPs/ECLIP-etcbyz.md index fb79e56..96d40a1 100644 --- a/ECLIPs/ECLIP-etcbyz.md +++ b/ECLIPs/ECLIP-etcbyz.md @@ -20,7 +20,9 @@ For more information on the opcodes and their respective EIPs and implementation ### Motivation -To enable and maintain interoperability between Foundation and Classic Ethereum Virtual Machines ("EVM"s). This protocol specification notably omits the scheduled features of the anticipated _Constantinople_ fork, which would be expected to include various further EVM upgrades. The reasoning for this omission hinges on a hedge toward battle-testing of those changes in light of multiple delays of that fork ([here](https://medium.com/ethereum-cat-herders/a-post-mortem-report-the-constantinople-ethereum-hard-fork-postponement-dd780d7ae63d), a postmortem of the latest delay) due to security and implementation discrepencies. +To enhance the EVM's capabilities by adding 5 opcodes and 4 precompiled contracts, all of which have been in use on the ETH network since 2017-10-16. Adoption of the "receipt status" feature provides a helpful method for Dapp developers to access the successful or failed state a contact. This would (re)establish a greater level of interoperability between Foundation and Classic Ethereum Virtual Machines ("EVM"s), and make a wider array of tooling available for the ETC network (eg. Solidity version, several contract debugging tools). + +This protocol specification notably omits the scheduled features of the anticipated _Constantinople_ fork, which would be expected to include various further EVM upgrades. The reasoning for this omission hinges on a hedge toward battle-testing of those changes in light of multiple delays of that fork ([here](https://medium.com/ethereum-cat-herders/a-post-mortem-report-the-constantinople-ethereum-hard-fork-postponement-dd780d7ae63d), a postmortem of the latest delay) due to security and implementation discrepencies. ### Specification From 9dfa5dc33032f84e933730d2b5b9dceefc8ed3bc Mon Sep 17 00:00:00 2001 From: meows Date: Tue, 12 Feb 2019 08:34:57 -0600 Subject: [PATCH 07/25] Fix typo, add note about strangeness of 'unbreaking opcode' case Rel https://github.com/etclabscore/ECLIPs/pull/2#discussion_r255923767 --- ECLIPs/.#ECLIP-etcbyz.md | 1 - ECLIPs/ECLIP-etcbyz.md | 9 ++++----- 2 files changed, 4 insertions(+), 6 deletions(-) delete mode 120000 ECLIPs/.#ECLIP-etcbyz.md diff --git a/ECLIPs/.#ECLIP-etcbyz.md b/ECLIPs/.#ECLIP-etcbyz.md deleted file mode 120000 index 87495b9..0000000 --- a/ECLIPs/.#ECLIP-etcbyz.md +++ /dev/null @@ -1 +0,0 @@ -ia@ubp52.17806:1549812866 \ No newline at end of file diff --git a/ECLIPs/ECLIP-etcbyz.md b/ECLIPs/ECLIP-etcbyz.md index 96d40a1..672039b 100644 --- a/ECLIPs/ECLIP-etcbyz.md +++ b/ECLIPs/ECLIP-etcbyz.md @@ -20,7 +20,7 @@ For more information on the opcodes and their respective EIPs and implementation ### Motivation -To enhance the EVM's capabilities by adding 5 opcodes and 4 precompiled contracts, all of which have been in use on the ETH network since 2017-10-16. Adoption of the "receipt status" feature provides a helpful method for Dapp developers to access the successful or failed state a contact. This would (re)establish a greater level of interoperability between Foundation and Classic Ethereum Virtual Machines ("EVM"s), and make a wider array of tooling available for the ETC network (eg. Solidity version, several contract debugging tools). +To enhance the EVM's capabilities by adding 5 opcodes and 4 precompiled contracts, all of which have been in use on the ETH network since 2017-10-16. Adoption of the "receipt status" feature provides a helpful method for Dapp developers to access the successful or failed state a contact. This would (re)establish a greater level of interoperability between Foundation and Classic Ethereum Virtual Machines ("EVM"s), and make a wider array of tooling available for the ETC network (eg. Solidity version, several contract debugging tools). This protocol specification notably omits the scheduled features of the anticipated _Constantinople_ fork, which would be expected to include various further EVM upgrades. The reasoning for this omission hinges on a hedge toward battle-testing of those changes in light of multiple delays of that fork ([here](https://medium.com/ethereum-cat-herders/a-post-mortem-report-the-constantinople-ethereum-hard-fork-postponement-dd780d7ae63d), a postmortem of the latest delay) due to security and implementation discrepencies. @@ -30,11 +30,11 @@ As per associated EIPs's specifications and implementations, with feature-readin ### 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). +__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: +__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 "possibly 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, albeit in a hypothetical case of extreme coincidence and gross misuse of an opcode. In counterargument to this concern are two critical points: -1. account states remain changed +1. account states remain unchanged 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. @@ -76,4 +76,3 @@ These changes are catalogued via the EIP process in the following: - EIP-212: Precompiled contract for elliptic curve pairing - https://github.com/ethereum/EIPs/pull/212/files - EIP-213: Precompiled contracts for elliptic curve addition and scalar multiplication - https://github.com/ethereum/EIPs/pull/213/files - From 210894061ebc7d89cb8f6d2877da351bb59ba16d Mon Sep 17 00:00:00 2001 From: meows Date: Tue, 12 Feb 2019 08:41:38 -0600 Subject: [PATCH 08/25] Add Rationale conclusion note about feature upgrade Rel https://github.com/etclabscore/ECLIPs/pull/2#discussion_r255925157 --- ECLIPs/ECLIP-etcbyz.md | 2 ++ 1 file changed, 2 insertions(+) diff --git a/ECLIPs/ECLIP-etcbyz.md b/ECLIPs/ECLIP-etcbyz.md index 672039b..b257c44 100644 --- a/ECLIPs/ECLIP-etcbyz.md +++ b/ECLIPs/ECLIP-etcbyz.md @@ -39,6 +39,8 @@ __On Immutability__: Introducing new opcodes in the VM has the potential to chan 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. +Adding opcodes and precompiled contracts to the EVM increases its functionality (only in an extremely rare case of gross misuse would be seen to _change_ it's functionality), and should be considered a feature upgrade rather than a modification. + ### Implementation Adoption of the content of this ECLIP requires a hard fork, and herein that adoption is proposed to be scheduled for block X,XXX,XXX roughly estimated to arrive _XXXX-XX-XX_. From eef2e02e02d3332245c923d66ec5f4f721a2eca3 Mon Sep 17 00:00:00 2001 From: Zachary Belford Date: Tue, 19 Feb 2019 07:06:42 -0600 Subject: [PATCH 09/25] Update ECLIPs/ECLIP-etcbyz.md Fixes typo. Co-Authored-By: meowsbits <45600330+meowsbits@users.noreply.github.com> --- ECLIPs/ECLIP-etcbyz.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/ECLIPs/ECLIP-etcbyz.md b/ECLIPs/ECLIP-etcbyz.md index b257c44..1da36e3 100644 --- a/ECLIPs/ECLIP-etcbyz.md +++ b/ECLIPs/ECLIP-etcbyz.md @@ -20,7 +20,7 @@ For more information on the opcodes and their respective EIPs and implementation ### Motivation -To enhance the EVM's capabilities by adding 5 opcodes and 4 precompiled contracts, all of which have been in use on the ETH network since 2017-10-16. Adoption of the "receipt status" feature provides a helpful method for Dapp developers to access the successful or failed state a contact. This would (re)establish a greater level of interoperability between Foundation and Classic Ethereum Virtual Machines ("EVM"s), and make a wider array of tooling available for the ETC network (eg. Solidity version, several contract debugging tools). +To enhance the EVM's capabilities by adding 5 opcodes and 4 precompiled contracts, all of which have been in use on the ETH network since 2017-10-16. Adoption of the "receipt status" feature provides a helpful method for Dapp developers to access the successful or failed state of a contract. This would (re)establish a greater level of interoperability between Foundation and Classic Ethereum Virtual Machines ("EVM"s), and make a wider array of tooling available for the ETC network (eg. Solidity version, several contract debugging tools). This protocol specification notably omits the scheduled features of the anticipated _Constantinople_ fork, which would be expected to include various further EVM upgrades. The reasoning for this omission hinges on a hedge toward battle-testing of those changes in light of multiple delays of that fork ([here](https://medium.com/ethereum-cat-herders/a-post-mortem-report-the-constantinople-ethereum-hard-fork-postponement-dd780d7ae63d), a postmortem of the latest delay) due to security and implementation discrepencies. From 4113214861b81f5718af94cad777152ef10158fd Mon Sep 17 00:00:00 2001 From: Zachary Belford Date: Tue, 19 Feb 2019 07:08:14 -0600 Subject: [PATCH 10/25] Update ECLIPs/ECLIP-etcbyz.md Makes sentence more assertive. Co-Authored-By: meowsbits <45600330+meowsbits@users.noreply.github.com> --- ECLIPs/ECLIP-etcbyz.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/ECLIPs/ECLIP-etcbyz.md b/ECLIPs/ECLIP-etcbyz.md index 1da36e3..11ecafb 100644 --- a/ECLIPs/ECLIP-etcbyz.md +++ b/ECLIPs/ECLIP-etcbyz.md @@ -47,7 +47,7 @@ Adoption of the content of this ECLIP requires a hard fork, and herein that adop The `ethereumproject/go-ethereum` client implemented an API-only (non-consensus impacting) partial adoption of EIP-658 receipt 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). -ETC Labs Core plans to advocate and support the adoption of [ethoxy/multi-geth](https://github.com/ethoxy/multi-geth) as a fully-featured and maintenance-scheduled client for this fork and beyond. +ETC Labs Core advocates and supports the adoption of [ethoxy/multi-geth](https://github.com/ethoxy/multi-geth) as a fully-featured and maintenance-scheduled client for this fork and beyond. ### History From f349db11e4bab3eb64be3aa79c65e9bee0792adb Mon Sep 17 00:00:00 2001 From: meows Date: Mon, 18 Mar 2019 10:50:44 -0500 Subject: [PATCH 11/25] Add EIP100 to proposal --- ECLIPs/ECLIP-etcbyz.md | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/ECLIPs/ECLIP-etcbyz.md b/ECLIPs/ECLIP-etcbyz.md index 11ecafb..730d9e4 100644 --- a/ECLIPs/ECLIP-etcbyz.md +++ b/ECLIPs/ECLIP-etcbyz.md @@ -13,6 +13,7 @@ Add support for a subset of protocol-impacting changes introduced in the Ethereu - 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) - Replacing the intermediate state root field in transaction receipts with the contract return status (EIP 658). +- Change difficulty adjustment to target mean block time including uncle (EIP 100) This document proposes block `X,XXX,XXX` as the upcoming block height at which to implement these changes in the network, placing the expected date of protocol hardfork date on _XXXX-XX-XX_. @@ -20,7 +21,7 @@ For more information on the opcodes and their respective EIPs and implementation ### Motivation -To enhance the EVM's capabilities by adding 5 opcodes and 4 precompiled contracts, all of which have been in use on the ETH network since 2017-10-16. Adoption of the "receipt status" feature provides a helpful method for Dapp developers to access the successful or failed state of a contract. This would (re)establish a greater level of interoperability between Foundation and Classic Ethereum Virtual Machines ("EVM"s), and make a wider array of tooling available for the ETC network (eg. Solidity version, several contract debugging tools). +To enhance the EVM's capabilities by adding 5 opcodes and 4 precompiled contracts, all of which have been in use on the ETH network since 2017-10-16. Adoption of the "receipt status" feature provides a helpful method for Dapp developers to access the successful or failed state of a contract. This would (re)establish a greater level of interoperability between Foundation and Classic Ethereum Virtual Machines ("EVM"s), and make a wider array of tooling available for the ETC network (eg. Solidity version, several contract debugging tools). The proposed change to the difficulty formula ensures that the difficulty adjustment algorithm targets a constant average rate of blocks produced including uncles, and so ensures a highly predictable issuance rate that cannot be manipulated upward by manipulating the uncle rate. This protocol specification notably omits the scheduled features of the anticipated _Constantinople_ fork, which would be expected to include various further EVM upgrades. The reasoning for this omission hinges on a hedge toward battle-testing of those changes in light of multiple delays of that fork ([here](https://medium.com/ethereum-cat-herders/a-post-mortem-report-the-constantinople-ethereum-hard-fork-postponement-dd780d7ae63d), a postmortem of the latest delay) due to security and implementation discrepencies. @@ -59,6 +60,8 @@ These changes are 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/files +- EIP-100: Change difficulty adjustment to target mean block time including uncles - https://github.com/ethereum/EIPs/issues/100 + - 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. From f7b7483c2f785ac07bdb25f386f2c4f9cbb46929 Mon Sep 17 00:00:00 2001 From: soc1c Date: Wed, 20 Mar 2019 13:09:47 +0100 Subject: [PATCH 12/25] ecip: give byzantium a number 1054 --- ECLIPs/{ECLIP-etcbyz.md => ECIP-1054.md} | 0 1 file changed, 0 insertions(+), 0 deletions(-) rename ECLIPs/{ECLIP-etcbyz.md => ECIP-1054.md} (100%) diff --git a/ECLIPs/ECLIP-etcbyz.md b/ECLIPs/ECIP-1054.md similarity index 100% rename from ECLIPs/ECLIP-etcbyz.md rename to ECLIPs/ECIP-1054.md From de5c9eef58fc35dc4c4ab50fc14574d2f27e0e6d Mon Sep 17 00:00:00 2001 From: soc1c Date: Wed, 20 Mar 2019 13:11:36 +0100 Subject: [PATCH 13/25] ECIP-1054: add simple summary --- ECLIPs/ECIP-1054.md | 10 +++++++--- 1 file changed, 7 insertions(+), 3 deletions(-) diff --git a/ECLIPs/ECIP-1054.md b/ECLIPs/ECIP-1054.md index 730d9e4..276ec66 100644 --- a/ECLIPs/ECIP-1054.md +++ b/ECLIPs/ECIP-1054.md @@ -1,12 +1,16 @@ -### ECLIP-?: Support for ETH Byzantium EVM and Protocol Upgrades +### ECIP-1054: Support for ETH Byzantium EVM and Protocol Upgrades - ECLIP: undecided + ECIP: 1054 Title: Support for ETH Byzantium EVM and Protocol Upgrades Status: Draft Type: Standards Track Author: Isaac Ardis Created: 2019-02-11 +### Simple Summary + +Enable the Ethereum Foundation network protocol "Byzantium" upgrades on the Ethereum Classic network. + ### 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: @@ -40,7 +44,7 @@ __On Immutability__: Introducing new opcodes in the VM has the potential to chan 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. -Adding opcodes and precompiled contracts to the EVM increases its functionality (only in an extremely rare case of gross misuse would be seen to _change_ it's functionality), and should be considered a feature upgrade rather than a modification. +Adding opcodes and precompiled contracts to the EVM increases its functionality (only in an extremely rare case of gross misuse would be seen to _change_ it's functionality), and should be considered a feature upgrade rather than a modification. ### Implementation From 568b3f23b593538dc6a65cc127c72516a2a8091d Mon Sep 17 00:00:00 2001 From: soc1c Date: Wed, 20 Mar 2019 13:18:41 +0100 Subject: [PATCH 14/25] ECIP-1054: improve abstract --- ECLIPs/ECIP-1054.md | 23 +++++++++++++++++------ 1 file changed, 17 insertions(+), 6 deletions(-) diff --git a/ECLIPs/ECIP-1054.md b/ECLIPs/ECIP-1054.md index 276ec66..65eac2a 100644 --- a/ECLIPs/ECIP-1054.md +++ b/ECLIPs/ECIP-1054.md @@ -9,17 +9,28 @@ ### Simple Summary -Enable the Ethereum Foundation network protocol "Byzantium" upgrades on the Ethereum Classic network. +Enable the Ethereum Foundation network protocol _Byzantium_ upgrades on the Ethereum Classic network. ### 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) -- Replacing the intermediate state root field in transaction receipts with the contract return status (EIP 658). -- Change difficulty adjustment to target mean block time including uncle (EIP 100) - -This document proposes block `X,XXX,XXX` as the upcoming block height at which to implement these changes in the network, placing the expected date of protocol hardfork date on _XXXX-XX-XX_. +- Byzantium EVM opcodes, namely: + - `REVERT` (EIP-140) + - `RETURNDATASIZE` and `RETURNDATACOPY` (EIP-211) + - `STATICCALL` (EIP-214) +- Byzantium EVM precompiled contracts, namely: + - addition and scalar multiplication on the elliptic curve alt_bn128 (EIP-196) + - optimal ate pairing check on the elliptic curve alt_bn128 (EIP-197) + - bigint modular exponentiation (EIP-198) +- Replacing the intermediate state root field in transaction receipts with the contract return status (EIP-658). +- Change difficulty adjustment to target mean block time including uncle (EIP-100) + +This document proposes the following blocks at which to implement these changes in the Classic networks: + +- `X_XXX_XXX` on Ethereum Classic mainnet +- `X_XXX_XXX` on Morden Classic testnet +- `X_XXX_XXX` on Kotti Classic testnet For more information on the opcodes and their respective EIPs and implementations, please see the __History__ section of this document. From afb495ee075a2e0dbb10d2e2a9ee828096ff90bf Mon Sep 17 00:00:00 2001 From: soc1c Date: Wed, 20 Mar 2019 13:23:54 +0100 Subject: [PATCH 15/25] ECIP-1054: improve motivation and specification --- ECLIPs/ECIP-1054.md | 17 +++++++++++++---- 1 file changed, 13 insertions(+), 4 deletions(-) diff --git a/ECLIPs/ECIP-1054.md b/ECLIPs/ECIP-1054.md index 65eac2a..ee8935d 100644 --- a/ECLIPs/ECIP-1054.md +++ b/ECLIPs/ECIP-1054.md @@ -36,16 +36,25 @@ For more information on the opcodes and their respective EIPs and implementation ### Motivation -To enhance the EVM's capabilities by adding 5 opcodes and 4 precompiled contracts, all of which have been in use on the ETH network since 2017-10-16. Adoption of the "receipt status" feature provides a helpful method for Dapp developers to access the successful or failed state of a contract. This would (re)establish a greater level of interoperability between Foundation and Classic Ethereum Virtual Machines ("EVM"s), and make a wider array of tooling available for the ETC network (eg. Solidity version, several contract debugging tools). The proposed change to the difficulty formula ensures that the difficulty adjustment algorithm targets a constant average rate of blocks produced including uncles, and so ensures a highly predictable issuance rate that cannot be manipulated upward by manipulating the uncle rate. - -This protocol specification notably omits the scheduled features of the anticipated _Constantinople_ fork, which would be expected to include various further EVM upgrades. The reasoning for this omission hinges on a hedge toward battle-testing of those changes in light of multiple delays of that fork ([here](https://medium.com/ethereum-cat-herders/a-post-mortem-report-the-constantinople-ethereum-hard-fork-postponement-dd780d7ae63d), a postmortem of the latest delay) due to security and implementation discrepencies. +To enhance the EVM's capabilities, various opcodes and precompiled contracts will be added to the Ethereum Classic networks, all of which have been in use on the Ethereum Foundation networks since late 2017. Adoption of the _receipt status_ feature provides a helpful method for decentralized-application developers to access the successful or failed state of a contract. This would establish a greater level of interoperability between Foundation and Classic Ethereum Virtual Machines ("EVM"s), and make a wider array of tooling available for the ETC network (e.g., Solidity version, contract debugging tools). The proposed change to the difficulty formula ensures that the difficulty adjustment algorithm targets a constant average rate of blocks produced including uncles, and so ensures a highly predictable issuance rate that cannot be manipulated upward by manipulating the uncle rate. ### Specification -As per associated EIPs's specifications and implementations, with feature-readiness determined by interoperability (implementation) of smart contracts utilizing the introduced opcode and precompiled contracts (implementation before technical specification in case of discrepency). Technical specifications for each EIP can be found at those documents respectively. +Technical specifications for each EIP can be found at those documents respectively: + +- [EIP 100](https://eips.ethereum.org/EIPS/eip-100) (Change difficulty adjustment to target mean block time including uncles) +- [EIP 140](https://eips.ethereum.org/EIPS/eip-140) (REVERT instruction in the Ethereum Virtual Machine) +- [EIP 196](https://eips.ethereum.org/EIPS/eip-196) (Precompiled contracts for addition and scalar multiplication on the elliptic curve alt_bn128) +- [EIP 197](https://eips.ethereum.org/EIPS/eip-197) (Precompiled contracts for optimal ate pairing check on the elliptic curve alt_bn128) +- [EIP 198](https://eips.ethereum.org/EIPS/eip-198) (Precompiled contract for bigint modular exponentiation) +- [EIP 211](https://eips.ethereum.org/EIPS/eip-211) (New opcodes: RETURNDATASIZE and RETURNDATACOPY) +- [EIP 214](https://eips.ethereum.org/EIPS/eip-214) (New opcode STATICCALL) +- [EIP 658](https://eips.ethereum.org/EIPS/eip-658) (Embedding transaction status code in receipts) ### Rationale +This protocol specification notably omits the scheduled features of the anticipated _Constantinople_ fork, which would be expected to include various further EVM upgrades. The reasoning for this omission hinges on a hedge toward battle-testing of those changes in light of multiple delays of that fork ([here](https://medium.com/ethereum-cat-herders/a-post-mortem-report-the-constantinople-ethereum-hard-fork-postponement-dd780d7ae63d), a postmortem of the latest delay) due to security and implementation discrepancies. + __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 "possibly 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, albeit in a hypothetical case of extreme coincidence and gross misuse of an opcode. In counterargument to this concern are two critical points: From 869444feef686c967ed79d28c6b3a8cf29ebaff2 Mon Sep 17 00:00:00 2001 From: soc1c Date: Wed, 20 Mar 2019 13:32:20 +0100 Subject: [PATCH 16/25] ECIP-1054: improve rationale and implementation --- ECLIPs/ECIP-1054.md | 24 +++++++++++++----------- 1 file changed, 13 insertions(+), 11 deletions(-) diff --git a/ECLIPs/ECIP-1054.md b/ECLIPs/ECIP-1054.md index ee8935d..03013a3 100644 --- a/ECLIPs/ECIP-1054.md +++ b/ECLIPs/ECIP-1054.md @@ -36,7 +36,7 @@ For more information on the opcodes and their respective EIPs and implementation ### Motivation -To enhance the EVM's capabilities, various opcodes and precompiled contracts will be added to the Ethereum Classic networks, all of which have been in use on the Ethereum Foundation networks since late 2017. Adoption of the _receipt status_ feature provides a helpful method for decentralized-application developers to access the successful or failed state of a contract. This would establish a greater level of interoperability between Foundation and Classic Ethereum Virtual Machines ("EVM"s), and make a wider array of tooling available for the ETC network (e.g., Solidity version, contract debugging tools). The proposed change to the difficulty formula ensures that the difficulty adjustment algorithm targets a constant average rate of blocks produced including uncles, and so ensures a highly predictable issuance rate that cannot be manipulated upward by manipulating the uncle rate. +To enhance the Ethereum Virtual Machine's (EVM) capabilities, various opcodes and precompiled contracts will be added to the Ethereum Classic networks, all of which have been in use on the Ethereum Foundation networks since late 2017. Adoption of the _receipt status_ feature provides a helpful method for decentralized-application developers to access the successful or failed state of a contract. This would establish a greater level of interoperability between Foundation and Classic EVMs, and make a wider array of tooling available for the ETC network (e.g., Solidity version, contract debugging tools). The proposed change to the difficulty formula ensures that the difficulty adjustment algorithm targets a constant average rate of blocks produced including uncles, and so ensures a highly predictable issuance rate that cannot be manipulated upward by manipulating the uncle rate. ### Specification @@ -53,26 +53,28 @@ Technical specifications for each EIP can be found at those documents respective ### Rationale -This protocol specification notably omits the scheduled features of the anticipated _Constantinople_ fork, which would be expected to include various further EVM upgrades. The reasoning for this omission hinges on a hedge toward battle-testing of those changes in light of multiple delays of that fork ([here](https://medium.com/ethereum-cat-herders/a-post-mortem-report-the-constantinople-ethereum-hard-fork-postponement-dd780d7ae63d), a postmortem of the latest delay) due to security and implementation discrepancies. +This protocol specification notably omits the scheduled features of the anticipated _Constantinople_ protocol upgrade, which would be expected to include various further EVM upgrades. The reasoning for this omission hinges on a hedge toward battle-testing of those changes in light of multiple delays of that fork ([here](https://medium.com/ethereum-cat-herders/a-post-mortem-report-the-constantinople-ethereum-hard-fork-postponement-dd780d7ae63d), a postmortem of the latest delay) due to security and implementation discrepancies. -__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). +__Interoperability__: establishing and maintaining interoperable behavior between Ethereum clients is important for developers and end-user adoption, yielding benefits for all participating chains (e.g., ETH and ETC, Ropsten and Morden, Görli and Kotti). -__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 "possibly 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, albeit in a hypothetical case of extreme coincidence and gross misuse of an opcode. In counterargument to this concern are two critical points: +__On Immutability__: Introducing new opcodes in the EVM 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 _"possibly 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, albeit in a hypothetical case of extreme coincidence and gross misuse of an opcode. In counterargument to this concern are two critical points: -1. account states remain unchanged -2. the "Homestead" hardfork established a precedent for this type of change, having introduced the `DELEGATECALL` opcode at block 1,150,000. +1. Account states remain unchanged. +2. The _Homestead_ upgrade 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. +With these arguments in place, along with precedence and expectation for other continuing and varied consensus-impacting protocol upgrades (e.g., 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. -Adding opcodes and precompiled contracts to the EVM increases its functionality (only in an extremely rare case of gross misuse would be seen to _change_ it's functionality), and should be considered a feature upgrade rather than a modification. +Adding opcodes and precompiled contracts to the EVM increases its functionality, and should be considered a feature upgrade rather than a modification. ### Implementation -Adoption of the content of this ECLIP requires a hard fork, and herein that adoption is proposed to be scheduled for block X,XXX,XXX roughly estimated to arrive _XXXX-XX-XX_. +Adoption of the content of this ECIP requires a hard fork as it introduces changes that are not backwards compatible. -The `ethereumproject/go-ethereum` client implemented an API-only (non-consensus impacting) partial adoption of EIP-658 receipt 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). +The following clients with Ethereum Classic support implement the Byzantium features: -ETC Labs Core advocates and supports the adoption of [ethoxy/multi-geth](https://github.com/ethoxy/multi-geth) as a fully-featured and maintenance-scheduled client for this fork and beyond. +- Multi Geth: all Byzantium features +- Parity Ethereum: all Byzantium features +- Geth Classic: partial support for EIP-658 receipt status code change ### History From 807cbe908578ebb2ee1d5411d60002a38e599199 Mon Sep 17 00:00:00 2001 From: soc1c Date: Wed, 20 Mar 2019 13:34:41 +0100 Subject: [PATCH 17/25] ECIP-1054: remove redundant history section --- ECLIPs/ECIP-1054.md | 34 +++------------------------------- 1 file changed, 3 insertions(+), 31 deletions(-) diff --git a/ECLIPs/ECIP-1054.md b/ECLIPs/ECIP-1054.md index 03013a3..3d641e4 100644 --- a/ECLIPs/ECIP-1054.md +++ b/ECLIPs/ECIP-1054.md @@ -32,7 +32,7 @@ This document proposes the following blocks at which to implement these changes - `X_XXX_XXX` on Morden Classic testnet - `X_XXX_XXX` on Kotti Classic testnet -For more information on the opcodes and their respective EIPs and implementations, please see the __History__ section of this document. +For more information on the opcodes and their respective EIPs and implementations, please see the _Specification_ section of this document. ### Motivation @@ -76,34 +76,6 @@ The following clients with Ethereum Classic support implement the Byzantium feat - Parity Ethereum: all Byzantium features - Geth Classic: partial support for EIP-658 receipt status code change -### History +## Copyright -##### Byzantium changes - -These changes were introduced in the `ethereum/go-ethereum` client via the [1.7 "Megara" release](https://github.com/ethereum/go-ethereum/releases/tag/v1.7.0). - -These changes are 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/files - -- EIP-100: Change difficulty adjustment to target mean block time including uncles - https://github.com/ethereum/EIPs/issues/100 - -- 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/files - -- EIP-212: Precompiled contract for elliptic curve pairing - https://github.com/ethereum/EIPs/pull/212/files - -- EIP-213: Precompiled contracts for elliptic curve addition and scalar multiplication - https://github.com/ethereum/EIPs/pull/213/files +Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/). From d7d67a14b4defdf07feaf10faff6f02f7472eee1 Mon Sep 17 00:00:00 2001 From: soc1c Date: Fri, 22 Mar 2019 11:25:50 +0100 Subject: [PATCH 18/25] ECIP-1054: check grammar and spelling --- ECLIPs/ECIP-1054.md | 12 ++++++------ 1 file changed, 6 insertions(+), 6 deletions(-) diff --git a/ECLIPs/ECIP-1054.md b/ECLIPs/ECIP-1054.md index 3d641e4..66a37ef 100644 --- a/ECLIPs/ECIP-1054.md +++ b/ECLIPs/ECIP-1054.md @@ -22,7 +22,7 @@ Add support for a subset of protocol-impacting changes introduced in the Ethereu - Byzantium EVM precompiled contracts, namely: - addition and scalar multiplication on the elliptic curve alt_bn128 (EIP-196) - optimal ate pairing check on the elliptic curve alt_bn128 (EIP-197) - - bigint modular exponentiation (EIP-198) + - BIGINT modular exponentiation (EIP-198) - Replacing the intermediate state root field in transaction receipts with the contract return status (EIP-658). - Change difficulty adjustment to target mean block time including uncle (EIP-100) @@ -36,7 +36,7 @@ For more information on the opcodes and their respective EIPs and implementation ### Motivation -To enhance the Ethereum Virtual Machine's (EVM) capabilities, various opcodes and precompiled contracts will be added to the Ethereum Classic networks, all of which have been in use on the Ethereum Foundation networks since late 2017. Adoption of the _receipt status_ feature provides a helpful method for decentralized-application developers to access the successful or failed state of a contract. This would establish a greater level of interoperability between Foundation and Classic EVMs, and make a wider array of tooling available for the ETC network (e.g., Solidity version, contract debugging tools). The proposed change to the difficulty formula ensures that the difficulty adjustment algorithm targets a constant average rate of blocks produced including uncles, and so ensures a highly predictable issuance rate that cannot be manipulated upward by manipulating the uncle rate. +To enhance the Ethereum Virtual Machine's (EVM) capabilities, various opcodes and precompiled contracts shall be added to the Ethereum Classic networks, all of which have been in use on the Ethereum Foundation networks since late 2017. Adoption of the _receipt status_ feature provides a helpful method for decentralized-application developers to access the successful or failed state of a contract. This would establish a higher level of interoperability between Foundation and Classic EVMs, and make a more extensive array of tooling available for the ETC network (e.g., Solidity version, contract debugging tools). The proposed change to the difficulty formula ensures that the difficulty adjustment algorithm targets a constant average rate of blocks produced including uncles, and so ensures a highly predictable issuance rate that cannot be manipulated upward by manipulating the uncle rate. ### Specification @@ -55,20 +55,20 @@ Technical specifications for each EIP can be found at those documents respective This protocol specification notably omits the scheduled features of the anticipated _Constantinople_ protocol upgrade, which would be expected to include various further EVM upgrades. The reasoning for this omission hinges on a hedge toward battle-testing of those changes in light of multiple delays of that fork ([here](https://medium.com/ethereum-cat-herders/a-post-mortem-report-the-constantinople-ethereum-hard-fork-postponement-dd780d7ae63d), a postmortem of the latest delay) due to security and implementation discrepancies. -__Interoperability__: establishing and maintaining interoperable behavior between Ethereum clients is important for developers and end-user adoption, yielding benefits for all participating chains (e.g., ETH and ETC, Ropsten and Morden, Görli and Kotti). +__Interoperability__: establishing and maintaining interoperable behavior between Ethereum clients is essential for developers and end-user adoption, yielding benefits for all participating chains (e.g., ETH, ETC, Ropsten and Morden, Görli and Kotti). -__On Immutability__: Introducing new opcodes in the EVM 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 _"possibly 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, albeit in a hypothetical case of extreme coincidence and gross misuse of an opcode. In counterargument to this concern are two critical points: +__On Immutability__: Introducing new opcodes in the EVM has the potential to change the 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 _"possibly 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, albeit in a hypothetical case of extreme coincidence and gross misuse of an opcode. In counterargument to this concern are two critical points: 1. Account states remain unchanged. 2. The _Homestead_ upgrade 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 (e.g., 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. -Adding opcodes and precompiled contracts to the EVM increases its functionality, and should be considered a feature upgrade rather than a modification. +Adding opcodes and precompiled contracts to the EVM increases its functionality and should be considered a feature upgrade rather than a modification. ### Implementation -Adoption of the content of this ECIP requires a hard fork as it introduces changes that are not backwards compatible. +Adoption of the content of this ECIP requires a hard fork as it introduces changes that are not backward compatible. The following clients with Ethereum Classic support implement the Byzantium features: From a0b65686413b09a5d8f0f4dbb62a29b704ac4308 Mon Sep 17 00:00:00 2001 From: soc1c Date: Fri, 22 Mar 2019 11:27:41 +0100 Subject: [PATCH 19/25] ECIP-1054: reformat paragraphs --- ECLIPs/ECIP-1054.md | 44 +++++++++++++++++++++++++++++++++++--------- 1 file changed, 35 insertions(+), 9 deletions(-) diff --git a/ECLIPs/ECIP-1054.md b/ECLIPs/ECIP-1054.md index 66a37ef..8889a05 100644 --- a/ECLIPs/ECIP-1054.md +++ b/ECLIPs/ECIP-1054.md @@ -13,7 +13,8 @@ Enable the Ethereum Foundation network protocol _Byzantium_ upgrades on the Ethe ### 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: +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, namely: - `REVERT` (EIP-140) @@ -32,11 +33,19 @@ This document proposes the following blocks at which to implement these changes - `X_XXX_XXX` on Morden Classic testnet - `X_XXX_XXX` on Kotti Classic testnet -For more information on the opcodes and their respective EIPs and implementations, please see the _Specification_ section of this document. +For more information on the opcodes and their respective EIPs and implementations, please see the _Specification_ +section of this document. ### Motivation -To enhance the Ethereum Virtual Machine's (EVM) capabilities, various opcodes and precompiled contracts shall be added to the Ethereum Classic networks, all of which have been in use on the Ethereum Foundation networks since late 2017. Adoption of the _receipt status_ feature provides a helpful method for decentralized-application developers to access the successful or failed state of a contract. This would establish a higher level of interoperability between Foundation and Classic EVMs, and make a more extensive array of tooling available for the ETC network (e.g., Solidity version, contract debugging tools). The proposed change to the difficulty formula ensures that the difficulty adjustment algorithm targets a constant average rate of blocks produced including uncles, and so ensures a highly predictable issuance rate that cannot be manipulated upward by manipulating the uncle rate. +To enhance the Ethereum Virtual Machine's (EVM) capabilities, various opcodes and precompiled contracts shall be added +to the Ethereum Classic networks, all of which have been in use on the Ethereum Foundation networks since late 2017. +Adoption of the _receipt status_ feature provides a helpful method for decentralized-application developers to access +the successful or failed state of a contract. This would establish a higher level of interoperability between Foundation +and Classic EVMs, and make a more extensive array of tooling available for the ETC network (e.g., Solidity version, +contract debugging tools). The proposed change to the difficulty formula ensures that the difficulty adjustment +algorithm targets a constant average rate of blocks produced including uncles, and so ensures a highly predictable +issuance rate that cannot be manipulated upward by manipulating the uncle rate. ### Specification @@ -53,18 +62,35 @@ Technical specifications for each EIP can be found at those documents respective ### Rationale -This protocol specification notably omits the scheduled features of the anticipated _Constantinople_ protocol upgrade, which would be expected to include various further EVM upgrades. The reasoning for this omission hinges on a hedge toward battle-testing of those changes in light of multiple delays of that fork ([here](https://medium.com/ethereum-cat-herders/a-post-mortem-report-the-constantinople-ethereum-hard-fork-postponement-dd780d7ae63d), a postmortem of the latest delay) due to security and implementation discrepancies. +This protocol specification notably omits the scheduled features of the anticipated _Constantinople_ protocol upgrade, +which would be expected to include various further EVM upgrades. The reasoning for this omission hinges on a hedge +toward battle-testing of those changes in light of multiple delays of that fork +([here](https://medium.com/ethereum-cat-herders/a-post-mortem-report-the-constantinople-ethereum-hard-fork-postponement-dd780d7ae63d), +a postmortem of the latest delay) due to security and implementation discrepancies. -__Interoperability__: establishing and maintaining interoperable behavior between Ethereum clients is essential for developers and end-user adoption, yielding benefits for all participating chains (e.g., ETH, ETC, Ropsten and Morden, Görli and Kotti). +__Interoperability__: establishing and maintaining interoperable behavior between Ethereum clients is essential for +developers and end-user adoption, yielding benefits for all participating chains (e.g., ETH and ETC, Ropsten and Morden, +Görli and Kotti). -__On Immutability__: Introducing new opcodes in the EVM has the potential to change the 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 _"possibly 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, albeit in a hypothetical case of extreme coincidence and gross misuse of an opcode. In counterargument to this concern are two critical points: +__On Immutability__: Introducing new opcodes in the EVM has the potential to change the 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 _"possibly 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, albeit +in a hypothetical case of extreme coincidence and gross misuse of an opcode. In counterargument to this concern are two +critical points: 1. Account states remain unchanged. -2. The _Homestead_ upgrade established a precedent for this type of change, having introduced the `DELEGATECALL` opcode at block `1_150_000`. +2. The _Homestead_ upgrade 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 (e.g., 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. +With these arguments in place, along with precedence and expectation for other continuing and varied consensus-impacting +protocol upgrades (e.g., 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. -Adding opcodes and precompiled contracts to the EVM increases its functionality and should be considered a feature upgrade rather than a modification. +Adding opcodes and precompiled contracts to the EVM increases its functionality and should be considered a feature +upgrade rather than a modification. ### Implementation From ed01f85ed13f0c9cdc197351f728d9d172b60b44 Mon Sep 17 00:00:00 2001 From: soc1c Date: Fri, 22 Mar 2019 11:31:44 +0100 Subject: [PATCH 20/25] ECIP-1054: simplify abstract --- ECLIPs/ECIP-1054.md | 27 +++++++++++---------------- 1 file changed, 11 insertions(+), 16 deletions(-) diff --git a/ECLIPs/ECIP-1054.md b/ECLIPs/ECIP-1054.md index 8889a05..c3f4fa3 100644 --- a/ECLIPs/ECIP-1054.md +++ b/ECLIPs/ECIP-1054.md @@ -1,7 +1,7 @@ -### ECIP-1054: Support for ETH Byzantium EVM and Protocol Upgrades +### ECIP-1054: Support for Byzantium EVM and Protocol Upgrades ECIP: 1054 - Title: Support for ETH Byzantium EVM and Protocol Upgrades + Title: Support for Byzantium EVM and Protocol Upgrades Status: Draft Type: Standards Track Author: Isaac Ardis @@ -9,29 +9,24 @@ ### Simple Summary -Enable the Ethereum Foundation network protocol _Byzantium_ upgrades on the Ethereum Classic network. +Enable the Ethereum Foundation _Byzantium_ network protocol upgrades on the Ethereum Classic network. ### 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, namely: - - `REVERT` (EIP-140) - - `RETURNDATASIZE` and `RETURNDATACOPY` (EIP-211) - - `STATICCALL` (EIP-214) -- Byzantium EVM precompiled contracts, namely: - - addition and scalar multiplication on the elliptic curve alt_bn128 (EIP-196) - - optimal ate pairing check on the elliptic curve alt_bn128 (EIP-197) - - BIGINT modular exponentiation (EIP-198) -- Replacing the intermediate state root field in transaction receipts with the contract return status (EIP-658). -- Change difficulty adjustment to target mean block time including uncle (EIP-100) +- Byzantium EVM opcodes, namely `REVERT`, `RETURNDATASIZE`, `RETURNDATACOPY`, and `STATICCALL`. +- Byzantium EVM precompiled contracts, namely addition and scalar multiplication on the elliptic curve `alt_bn128`, + optimal ate pairing check on the elliptic curve `alt_bn128`, and BIGINT modular exponentiation. +- Replacing the intermediate state root field in transaction receipts with the contract return status. +- Change difficulty adjustment to target mean block time including uncle. This document proposes the following blocks at which to implement these changes in the Classic networks: -- `X_XXX_XXX` on Ethereum Classic mainnet -- `X_XXX_XXX` on Morden Classic testnet -- `X_XXX_XXX` on Kotti Classic testnet +- `X_XXX_XXX` on Ethereum Classic mainnet (_TBD_) +- `X_XXX_XXX` on Morden Classic testnet (_TBD_) +- `X_XXX_XXX` on Kotti Classic testnet (_TBD_) For more information on the opcodes and their respective EIPs and implementations, please see the _Specification_ section of this document. From 637d762c661bab8a183dcb217bd2fdf50b9ef62f Mon Sep 17 00:00:00 2001 From: soc1c Date: Fri, 22 Mar 2019 11:42:05 +0100 Subject: [PATCH 21/25] ECIP-1054: improve rationale --- ECLIPs/ECIP-1054.md | 50 +++++++++++++++------------------------------ 1 file changed, 17 insertions(+), 33 deletions(-) diff --git a/ECLIPs/ECIP-1054.md b/ECLIPs/ECIP-1054.md index c3f4fa3..3bd2a5b 100644 --- a/ECLIPs/ECIP-1054.md +++ b/ECLIPs/ECIP-1054.md @@ -47,54 +47,38 @@ issuance rate that cannot be manipulated upward by manipulating the uncle rate. Technical specifications for each EIP can be found at those documents respectively: - [EIP 100](https://eips.ethereum.org/EIPS/eip-100) (Change difficulty adjustment to target mean block time including uncles) -- [EIP 140](https://eips.ethereum.org/EIPS/eip-140) (REVERT instruction in the Ethereum Virtual Machine) -- [EIP 196](https://eips.ethereum.org/EIPS/eip-196) (Precompiled contracts for addition and scalar multiplication on the elliptic curve alt_bn128) -- [EIP 197](https://eips.ethereum.org/EIPS/eip-197) (Precompiled contracts for optimal ate pairing check on the elliptic curve alt_bn128) -- [EIP 198](https://eips.ethereum.org/EIPS/eip-198) (Precompiled contract for bigint modular exponentiation) -- [EIP 211](https://eips.ethereum.org/EIPS/eip-211) (New opcodes: RETURNDATASIZE and RETURNDATACOPY) -- [EIP 214](https://eips.ethereum.org/EIPS/eip-214) (New opcode STATICCALL) +- [EIP 140](https://eips.ethereum.org/EIPS/eip-140) (`REVERT` instruction in the Ethereum Virtual Machine) +- [EIP 196](https://eips.ethereum.org/EIPS/eip-196) (Precompiled contracts for addition and scalar multiplication on the elliptic curve `alt_bn128`) +- [EIP 197](https://eips.ethereum.org/EIPS/eip-197) (Precompiled contracts for optimal ate pairing check on the elliptic curve `alt_bn128`) +- [EIP 198](https://eips.ethereum.org/EIPS/eip-198) (Precompiled contract for BIGINT modular exponentiation) +- [EIP 211](https://eips.ethereum.org/EIPS/eip-211) (New opcodes `RETURNDATASIZE` and `RETURNDATACOPY`) +- [EIP 214](https://eips.ethereum.org/EIPS/eip-214) (New opcode `STATICCALL`) - [EIP 658](https://eips.ethereum.org/EIPS/eip-658) (Embedding transaction status code in receipts) ### Rationale -This protocol specification notably omits the scheduled features of the anticipated _Constantinople_ protocol upgrade, -which would be expected to include various further EVM upgrades. The reasoning for this omission hinges on a hedge -toward battle-testing of those changes in light of multiple delays of that fork -([here](https://medium.com/ethereum-cat-herders/a-post-mortem-report-the-constantinople-ethereum-hard-fork-postponement-dd780d7ae63d), -a postmortem of the latest delay) due to security and implementation discrepancies. +__Atomicity__: This protocol specification notably omits the scheduled features of the anticipated _Constantinople_ +protocol upgrade, which would be expected to include various further EVM upgrades. This allows for dedicated testing of +the proposed changes in light of multiple delays of the Constantinople fork +([a postmortem of the latest delay](https://medium.com/ethereum-cat-herders/a-post-mortem-report-the-constantinople-ethereum-hard-fork-postponement-dd780d7ae63d)). __Interoperability__: establishing and maintaining interoperable behavior between Ethereum clients is essential for developers and end-user adoption, yielding benefits for all participating chains (e.g., ETH and ETC, Ropsten and Morden, Görli and Kotti). -__On Immutability__: Introducing new opcodes in the EVM has the potential to change the 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 _"possibly 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, albeit -in a hypothetical case of extreme coincidence and gross misuse of an opcode. In counterargument to this concern are two -critical points: - -1. Account states remain unchanged. -2. The _Homestead_ upgrade 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 (e.g., 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. - -Adding opcodes and precompiled contracts to the EVM increases its functionality and should be considered a feature -upgrade rather than a modification. +__Immutability__: None of the introduced new opcodes in the EVM has the potential to change the behavior of existing +contracts; in the case where previously an arbitrary invalid bytecode would have been deployed to the network, none of +them would be able to modify the state of the Ethereum Classic networks retrospectively. Adding opcodes and precompiled +contracts to the EVM increases its functionality and should be considered a feature upgrade rather than a modification. ### Implementation Adoption of the content of this ECIP requires a hard fork as it introduces changes that are not backward compatible. -The following clients with Ethereum Classic support implement the Byzantium features: +The following clients with Ethereum Classic support implement the Byzantium features currently: -- Multi Geth: all Byzantium features -- Parity Ethereum: all Byzantium features +- Multi Geth: all Byzantium features due to Ethereum Foundation compatibility +- Parity Ethereum: all Byzantium features due to Ethereum Foundation compatibility - Geth Classic: partial support for EIP-658 receipt status code change ## Copyright From f2bd4cfb681c08d3ca22e3922d991da8b5041a7f Mon Sep 17 00:00:00 2001 From: soc1c Date: Fri, 22 Mar 2019 11:44:27 +0100 Subject: [PATCH 22/25] ECIP-1054: assign a name to the upgrade --- ECLIPs/ECIP-1054.md | 9 +++++---- 1 file changed, 5 insertions(+), 4 deletions(-) diff --git a/ECLIPs/ECIP-1054.md b/ECLIPs/ECIP-1054.md index 3bd2a5b..b9161a1 100644 --- a/ECLIPs/ECIP-1054.md +++ b/ECLIPs/ECIP-1054.md @@ -1,7 +1,7 @@ -### ECIP-1054: Support for Byzantium EVM and Protocol Upgrades +### ECIP-1054: Atlantis EVM and Protocol Upgrades ECIP: 1054 - Title: Support for Byzantium EVM and Protocol Upgrades + Title: Atlantis EVM and Protocol Upgrades Status: Draft Type: Standards Track Author: Isaac Ardis @@ -9,12 +9,13 @@ ### Simple Summary -Enable the Ethereum Foundation _Byzantium_ network protocol upgrades on the Ethereum Classic network. +Enable the Ethereum Foundation _Byzantium_ network protocol upgrades on the Ethereum Classic network in a hard-fork +code-named _Atlantis_. ### 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_ hardfork. The proposed changes for Ethereum Classic's _Atlantis_ upgrade include: - Byzantium EVM opcodes, namely `REVERT`, `RETURNDATASIZE`, `RETURNDATACOPY`, and `STATICCALL`. - Byzantium EVM precompiled contracts, namely addition and scalar multiplication on the elliptic curve `alt_bn128`, From fc8fdac7b3228503dcb8d3ef2e748db4ad9b5991 Mon Sep 17 00:00:00 2001 From: soc1c Date: Fri, 22 Mar 2019 15:14:17 +0100 Subject: [PATCH 23/25] ECIP-1054: include outstanding spurious dragon eips --- ECLIPs/ECIP-1054.md | 16 ++++++++++------ 1 file changed, 10 insertions(+), 6 deletions(-) diff --git a/ECLIPs/ECIP-1054.md b/ECLIPs/ECIP-1054.md index b9161a1..f33e676 100644 --- a/ECLIPs/ECIP-1054.md +++ b/ECLIPs/ECIP-1054.md @@ -9,14 +9,16 @@ ### Simple Summary -Enable the Ethereum Foundation _Byzantium_ network protocol upgrades on the Ethereum Classic network in a hard-fork -code-named _Atlantis_. +Enable the outstanding Ethereum Foundation _Spurious Dragon_ and _Byzantium_ network protocol upgrades on the Ethereum +Classic network in a hard-fork code-named _Atlantis_ to enable maximum compatibility across these networks. ### Abstract Add support for a subset of protocol-impacting changes introduced in the Ethereum Foundation (ETH) network via the -_Byzantium_ hardfork. The proposed changes for Ethereum Classic's _Atlantis_ upgrade include: +_Spurious Dragon_ and _Byzantium_ hardforks. The proposed changes for Ethereum Classic's _Atlantis_ upgrade include: +- Spurious Dragon state-trie clearing. +- Spurious Dragon contract-code size limit. - Byzantium EVM opcodes, namely `REVERT`, `RETURNDATASIZE`, `RETURNDATACOPY`, and `STATICCALL`. - Byzantium EVM precompiled contracts, namely addition and scalar multiplication on the elliptic curve `alt_bn128`, optimal ate pairing check on the elliptic curve `alt_bn128`, and BIGINT modular exponentiation. @@ -49,6 +51,8 @@ Technical specifications for each EIP can be found at those documents respective - [EIP 100](https://eips.ethereum.org/EIPS/eip-100) (Change difficulty adjustment to target mean block time including uncles) - [EIP 140](https://eips.ethereum.org/EIPS/eip-140) (`REVERT` instruction in the Ethereum Virtual Machine) +- [EIP 161](https://eips.ethereum.org/EIPS/eip-161) (State-trie clearing) +- [EIP 170](https://eips.ethereum.org/EIPS/eip-170) (Contract-code size limit) - [EIP 196](https://eips.ethereum.org/EIPS/eip-196) (Precompiled contracts for addition and scalar multiplication on the elliptic curve `alt_bn128`) - [EIP 197](https://eips.ethereum.org/EIPS/eip-197) (Precompiled contracts for optimal ate pairing check on the elliptic curve `alt_bn128`) - [EIP 198](https://eips.ethereum.org/EIPS/eip-198) (Precompiled contract for BIGINT modular exponentiation) @@ -76,10 +80,10 @@ contracts to the EVM increases its functionality and should be considered a feat Adoption of the content of this ECIP requires a hard fork as it introduces changes that are not backward compatible. -The following clients with Ethereum Classic support implement the Byzantium features currently: +The following clients with Ethereum Classic support implement the _Spurious Dragon_ and _Byzantium_ features currently: -- Multi Geth: all Byzantium features due to Ethereum Foundation compatibility -- Parity Ethereum: all Byzantium features due to Ethereum Foundation compatibility +- Multi Geth: all features due to Ethereum Foundation compatibility +- Parity Ethereum: all features due to Ethereum Foundation compatibility - Geth Classic: partial support for EIP-658 receipt status code change ## Copyright From 85b899bc8d3f585fe705f913c51db144a85ac2dc Mon Sep 17 00:00:00 2001 From: soc1c Date: Fri, 22 Mar 2019 15:36:58 +0100 Subject: [PATCH 24/25] ECIP-1054: propose block numbers --- ECLIPs/ECIP-1054.md | 11 ++++++----- 1 file changed, 6 insertions(+), 5 deletions(-) diff --git a/ECLIPs/ECIP-1054.md b/ECLIPs/ECIP-1054.md index f33e676..d01316e 100644 --- a/ECLIPs/ECIP-1054.md +++ b/ECLIPs/ECIP-1054.md @@ -27,9 +27,9 @@ _Spurious Dragon_ and _Byzantium_ hardforks. The proposed changes for Ethereum C This document proposes the following blocks at which to implement these changes in the Classic networks: -- `X_XXX_XXX` on Ethereum Classic mainnet (_TBD_) -- `X_XXX_XXX` on Morden Classic testnet (_TBD_) -- `X_XXX_XXX` on Kotti Classic testnet (_TBD_) +- `1_039_000` on Kotti Classic PoA-testnet (early August 2019) +- `4_723_000` on Morden Classic PoW-testnet (early August 2019) +- `8_750_000` on Ethereum Classic PoW-mainnet (mid-September 2019) For more information on the opcodes and their respective EIPs and implementations, please see the _Specification_ section of this document. @@ -82,9 +82,10 @@ Adoption of the content of this ECIP requires a hard fork as it introduces chang The following clients with Ethereum Classic support implement the _Spurious Dragon_ and _Byzantium_ features currently: -- Multi Geth: all features due to Ethereum Foundation compatibility -- Parity Ethereum: all features due to Ethereum Foundation compatibility - Geth Classic: partial support for EIP-658 receipt status code change +- Parity Ethereum: all features due to Ethereum Foundation compatibility +- Multi Geth: all features due to Ethereum Foundation compatibility +- Mantis: no support yet ## Copyright From cd3e903f7189b9038e2af44a56072e6f6ea0b52e Mon Sep 17 00:00:00 2001 From: soc1c Date: Fri, 22 Mar 2019 17:56:51 +0100 Subject: [PATCH 25/25] ECIP-1054: mantis supports all included changes --- ECLIPs/ECIP-1054.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/ECLIPs/ECIP-1054.md b/ECLIPs/ECIP-1054.md index d01316e..3caacc9 100644 --- a/ECLIPs/ECIP-1054.md +++ b/ECLIPs/ECIP-1054.md @@ -85,7 +85,7 @@ The following clients with Ethereum Classic support implement the _Spurious Drag - Geth Classic: partial support for EIP-658 receipt status code change - Parity Ethereum: all features due to Ethereum Foundation compatibility - Multi Geth: all features due to Ethereum Foundation compatibility -- Mantis: no support yet +- Mantis: all features due to Ethereum Foundation compatibility ## Copyright